From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH v3 net-next 0/4] net: batched receive in GRO path Date: Thu, 15 Nov 2018 12:08:22 -0800 Message-ID: References: <8e9ea3c4-82e0-a34c-08ea-32a387e4c9e1@solarflare.com> <53c61113-dfce-88c6-7711-a308fcf451ad@solarflare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org To: Edward Cree , linux-net-drivers@solarflare.com, davem@davemloft.net Return-path: Received: from mail-pf1-f194.google.com ([209.85.210.194]:34522 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727701AbeKPGRl (ORCPT ); Fri, 16 Nov 2018 01:17:41 -0500 Received: by mail-pf1-f194.google.com with SMTP id h3so3665464pfg.1 for ; Thu, 15 Nov 2018 12:08:25 -0800 (PST) In-Reply-To: <53c61113-dfce-88c6-7711-a308fcf451ad@solarflare.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 11/15/2018 10:43 AM, Edward Cree wrote: Most of the packet isn't touched and thus won't be brought into cache. > Only the headers of each packet (worst-case let's say 256 bytes) will >  be touched during batch processing, that's 16kB. You assume perfect use of the caches, but part of the cache has collisions. I am alarmed by the complexity added, for example in GRO, considering that we also added GRO for UDP. I dunno, can you show us for example if a reassembly workload can benefit from all this stuff ? Paolo Abeni sure will be interested knowing if we can get a 20% increase for this IP defrag workloads. If you present numbers for traffic that GRO handles just fine, it does not really make sense, unless your plan maybe is to remove GRO completely ? We have observed at Google a constant increase of cpu cycles spent for TCP_RR on latest kernels. The gap is now about 20% with kernels from two years ago, and I could not yet find a faulty commit. It seems we add little overhead after another, and every patch author is convinced he is doing the right thing. With multi queue NICS, vast majority of napi->poll() invocations handle only one packet. Unfortunately we can not really increase interrupt mitigations (ethtool -c) on NIC without sacrificing latencies.