Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp2119101ybp; Sat, 12 Oct 2019 04:32:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqzPhCw/eWx/ovSn+N6u0vIeum6saWBC12qa3VCMoQ9UHrLkmFB0T9DnwRGOVjDDCEwr08ZA X-Received: by 2002:a17:906:29db:: with SMTP id y27mr18900812eje.185.1570879968598; Sat, 12 Oct 2019 04:32:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570879968; cv=none; d=google.com; s=arc-20160816; b=vfuV70QKpMina0tJtU6wYpCkN24czVliOEZ08+5EZBKQHTu1Km2Ux3Dwdc+eIxPJYt N2onOMatIwDAcSpbOv56dXV82lmgrYSMfX1xhvtkNMNGYq4+9PeeJPVXEfv/YFvBJJ7l KsnS4vsWUmCDGuWqHElxrv1Jqjyn92VmYSkZ83Zir1tm9G/oDw2iRoFfS508YkKSpuhT 8D791WbieoXrljvYXePe1mijLx14Ot2fB4kw3TLK/MAiPXrLTuXDStWvVycYIoBvrzy6 P+tTe/v2isc/v+uGP5lEnPxpIY+RHUrD/Rd5j7HC2cHj5Q22VNCd34dUOxkoeKuXpz7m 4sfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hABoQwLdO0uMm4YXkBCFk8W+eev136YlKUX9aXvX8MQ=; b=wKRSlgMBrDJpm+ziQjq5dWthBu2rPfXpyv6SwyPsIiabFGwmPh2ht0CV+dr4V1xZAL DFSujmGgRKSM9KCGn/U9/htsbPIo45DM81gGbe2d/VF4VLi+ofcfKCih9KsSKrzCQUIZ EN1JByAQIQtdKlqYzN7mHs29luqhC8N/S+mkcHt/qI2g4jmGrS/WAD9AdGpkaAwJzH/3 uV1W/y00uOU5iKS85xXRNkrbpKAl4MfyXuj7Nw6tOnak/6eKZpvhkDv3gOnYf663Yisp SLBObQqGIqanmunSmFc6b+pLE/NoPxG9nFIc25BtyvwSzHE74HaRUlGkvbXhJsEzmXW8 55eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=D7mHgPzH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g90si8596277edd.329.2019.10.12.04.32.23; Sat, 12 Oct 2019 04:32:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=D7mHgPzH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729117AbfJLLTJ (ORCPT + 99 others); Sat, 12 Oct 2019 07:19:09 -0400 Received: from mail-yw1-f68.google.com ([209.85.161.68]:39805 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727423AbfJLLTI (ORCPT ); Sat, 12 Oct 2019 07:19:08 -0400 Received: by mail-yw1-f68.google.com with SMTP id n11so4437266ywn.6 for ; Sat, 12 Oct 2019 04:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hABoQwLdO0uMm4YXkBCFk8W+eev136YlKUX9aXvX8MQ=; b=D7mHgPzHHTjdRL5OoclG/V+NKJIlPgeUibKjAWXcA7kIdPCd1XFPkfIyBuFuGwE2P+ MrEzs8F+PLYTxDH7ouh8EEEy/e6BEoGBjYbDgQTWpvl1t6uv5b1purG/AhX+7F5S/XHr MNSbgSGnJaoqe4a9mxi+0NmcCJmKRSvg6o6KyHN4EoY2PckPjdpYR87r82qzkJm4Z96/ ZAipfmQiNMA0Cnt9YBnNvNO7quDOmC2t+0DHM2qaYIasyDERsY8dzwGmDvE10fGVmuxs bkjJbp4M1R1rManGnfz7uhb+pds7C8qEl7FJqoQ8kyOTrRWsTxMjvoM0WbNsQuMp18D1 IAEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hABoQwLdO0uMm4YXkBCFk8W+eev136YlKUX9aXvX8MQ=; b=ccM85NTBdDdp7XZHd8Vww8FGa1EG+psR27/zRXFulqE+9IzjIomQywtX9Zv8NN6u72 i48AEt0tJuueYGDl2HHAk1z9jKLmth9RwOftMdFBpke8v6kVGh3pq0HgwdVOq97rUiwr TanuBEEtLYAaCqvgwPjlQESXKdPFOZ74C2yeXrmVK25VQozNlVyhP9ywWxc0lr9zRMue 0nf14a0G2kvt/9HawW1tPUXIno7kS6Fx9W+W+wEeYcujgGCJMomVYTisr38dn6TtZb3q aKAMhuUFBQj9LvyJEznXmxGW/liwSXVBt+rUtG/mLxPd9yrmfZsrCRU0wV4rcQMc1Hr/ 3s4A== X-Gm-Message-State: APjAAAXukRt1/RE7sddslFY0/LwQ9/mrDWat9tWaDXL1lKdXJy3T/opk K4hR0BVdLf0o98+sJGSkxSpdsx1wXdKE9eaZrjsC3w== X-Received: by 2002:a0d:fd03:: with SMTP id n3mr5796321ywf.170.1570879146864; Sat, 12 Oct 2019 04:19:06 -0700 (PDT) MIME-Version: 1.0 References: <20191010144226.4115-1-alobakin@dlink.ru> <20191010144226.4115-3-alobakin@dlink.ru> <1eaac2e1f1d65194a4a39232d7e45870@dlink.ru> <3c459c84df86f79b593632d3f08d5f4c@dlink.ru> In-Reply-To: <3c459c84df86f79b593632d3f08d5f4c@dlink.ru> From: Eric Dumazet Date: Sat, 12 Oct 2019 04:18:55 -0700 Message-ID: Subject: Re: [PATCH net-next 2/2] net: core: increase the default size of GRO_NORMAL skb lists to flush To: Alexander Lobakin Cc: Edward Cree , "David S. Miller" , Jiri Pirko , Ido Schimmel , Paolo Abeni , Petr Machata , Sabrina Dubroca , Florian Fainelli , Jassi Brar , Ilias Apalodimas , netdev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 12, 2019 at 2:22 AM Alexander Lobakin wrote: > > I've generated an another solution. Considering that gro_normal_batch > is very individual for every single case, maybe it would be better to > make it per-NAPI (or per-netdevice) variable rather than a global > across the kernel? > I think most of all network-capable configurations and systems has more > than one network device nowadays, and they might need different values > for achieving their bests. > > One possible variant is: > > #define THIS_DRIVER_GRO_NORMAL_BATCH 16 > > /* ... */ > > netif_napi_add(dev, napi, this_driver_rx_poll, NAPI_POLL_WEIGHT); /* > napi->gro_normal_batch will be set to the systcl value during NAPI > context initialization */ > napi_set_gro_normal_batch(napi, THIS_DRIVER_GRO_NORMAL_BATCH); /* new > static inline helper, napi->gro_normal_batch will be set to the > driver-speficic value of 16 */ > > The second possible variant is to make gro_normal_batch sysctl > per-netdevice to tune it from userspace. > Or we can combine them into one to make it available for tweaking from > both driver and userspace, just like it's now with XPS CPUs setting. > > If you'll find any of this reasonable and worth implementing, I'll come > with it in v2 after a proper testing. Most likely the optimal tuning is also a function of the host cpu caches. Building a too big list can also lead to premature cache evictions. Tuning the value on your test machines does not mean the value will be good for other systems. Adding yet another per device value should only be done if you demonstrate a significant performance increase compared to the conservative value Edward chose. Also the behavior can be quite different depending on the protocols, make sure you test handling of TCP pure ACK packets. Accumulating 64 (in case the device uses standard NAPI_POLL_WEIGHT) of them before entering upper stacks seems not a good choice, since 64 skbs will need to be kept in the GRO system, compared to only 8 with Edward value.