Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp2136592ybp; Sat, 12 Oct 2019 04:55:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqyBwXruY0k5pMzjd459Eg9JAYWXhh3TiT3KfbFP//9pY0vRQqXETswqdaChaBX6SO/X6Jtb X-Received: by 2002:a17:906:6a14:: with SMTP id o20mr2673789ejr.230.1570881327830; Sat, 12 Oct 2019 04:55:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570881327; cv=none; d=google.com; s=arc-20160816; b=RdIibYhMdQ0hgDFcWozuCQniSaUFsstaTJTJcdg573ndb46ivJ8Ub4+QlPLXOE3+I5 lf4XNBKYhjNm8S0LMetuabS8+x+7DRIUJCtbPmLyd1Mb44E2pwBsaeHRa/TmxEiXE87Y kfh1EDjziRS1vTXuCSV96g3n5fdHtk9nrwoIzF8SA1Mionfdv6Y6smpW246+LuSUfmoZ 2dKlItXDyA6GGvG+aEQnWPTBqp22l9xXOaXv7KGq11l5pgLDccw2j/S9+4kg6WsP6cHp z9TLtpq6mAWmhpiMW68l1JzYvZVq2qIEEoVjt8R7DNj3YerarSWh4gDAp1byG9vYM+j4 LJbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-filter:dkim-signature:dkim-filter; bh=GVdyMAkJoaCzEF7enJYVSyxNIEivWNJHyH4jL2SwDe8=; b=YEKXB2NTQqbzXqoPDAt5XkWqSbda64qFc2BhWIIcHePf4YSPgBlAOC3uS0ORh/DZoq 26DZR92ZcMfR87mcRUF24FQjdTx7fKbeKQMETWlaCfcJfA8CLmba9jmmXUDNzhNNocXX 3pHwtyhKPgo4wJrc5f+jt8wRTurnQiEgqQCuGVl+I3rVTjWt8hLHRtLXjh1k87mLhn+f tOdyryjm6cLiM5+Cai1eskZlp0UdWbplHAM9WogeLueAr/yg6QnA6UdcGdim40O/pYZs /lr+JgrCeUlNQNAyxCeyrkmubg2mjv6bcG9eWCCqJi94coiHe8bum5xFt9gT/DoMh2xU v1nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dlink.ru header.s=mail header.b=R1cXAHL0; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a14si8464644eda.111.2019.10.12.04.55.04; Sat, 12 Oct 2019 04:55:27 -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=@dlink.ru header.s=mail header.b=R1cXAHL0; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729102AbfJLLx4 (ORCPT + 99 others); Sat, 12 Oct 2019 07:53:56 -0400 Received: from fd.dlink.ru ([178.170.168.18]:46642 "EHLO fd.dlink.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727231AbfJLLv4 (ORCPT ); Sat, 12 Oct 2019 07:51:56 -0400 Received: by fd.dlink.ru (Postfix, from userid 5000) id 944891B20983; Sat, 12 Oct 2019 14:51:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 fd.dlink.ru 944891B20983 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dlink.ru; s=mail; t=1570881112; bh=GVdyMAkJoaCzEF7enJYVSyxNIEivWNJHyH4jL2SwDe8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=R1cXAHL0FigCYkYf211zc5POTUXLGBUKygLqCdjJb0OCLYxcHzAAIjkjk1ywkK+g1 T3iDsNnAVd8/6r/UT04PVGfoXRm/p9P6NslcMsy3mZ9VzalPDyZPU4h6uopD78ewsk N70f9jDbkBTYjPlnG1fjMPkUNIv+qF8Bg/d9hWSI= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.dlink.ru X-Spam-Level: X-Spam-Status: No, score=-99.2 required=7.5 tests=BAYES_50,URIBL_BLOCKED, USER_IN_WHITELIST autolearn=disabled version=3.4.1 Received: from mail.rzn.dlink.ru (mail.rzn.dlink.ru [178.170.168.13]) by fd.dlink.ru (Postfix) with ESMTP id 388411B202D2; Sat, 12 Oct 2019 14:51:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 fd.dlink.ru 388411B202D2 Received: by mail.rzn.dlink.ru (Postfix, from userid 5000) id 232351B21890; Sat, 12 Oct 2019 14:51:49 +0300 (MSK) Received: from mail.rzn.dlink.ru (localhost [127.0.0.1]) by mail.rzn.dlink.ru (Postfix) with ESMTPA id 7A6C71B2120F; Sat, 12 Oct 2019 14:51:41 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 12 Oct 2019 14:51:41 +0300 From: Alexander Lobakin To: Eric Dumazet Cc: Edward Cree , "David S. Miller" , Jiri Pirko , Ido Schimmel , Paolo Abeni , Petr Machata , Sabrina Dubroca , Florian Fainelli , Jassi Brar , Ilias Apalodimas , netdev , LKML Subject: Re: [PATCH net-next 2/2] net: core: increase the default size of GRO_NORMAL skb lists to flush In-Reply-To: References: <20191010144226.4115-1-alobakin@dlink.ru> <20191010144226.4115-3-alobakin@dlink.ru> <1eaac2e1f1d65194a4a39232d7e45870@dlink.ru> <3c459c84df86f79b593632d3f08d5f4c@dlink.ru> Message-ID: X-Sender: alobakin@dlink.ru User-Agent: Roundcube Webmail/1.3.6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, Eric Dumazet wrote 12.10.2019 14:18: > 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. Oh, I missed that it might be a lot more machine-dependent than netdevice-dependent. Thank you for explanation. The best I can do in that case is to leave batch control in its current. I'll publish v2 containing only the acked first part of the series on Monday if nothing serious will happen. Addition of listified Rx to napi_gro_receive() was the main goal anyway. > > 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. Regards, ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ