From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2436DC74A21 for ; Wed, 10 Jul 2019 14:52:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F1D9D20645 for ; Wed, 10 Jul 2019 14:52:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727359AbfGJOwO (ORCPT ); Wed, 10 Jul 2019 10:52:14 -0400 Received: from dispatch1-us1.ppe-hosted.com ([148.163.129.52]:48416 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbfGJOwN (ORCPT ); Wed, 10 Jul 2019 10:52:13 -0400 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 4FFFFA40073; Wed, 10 Jul 2019 14:52:12 +0000 (UTC) Received: from [10.17.20.203] (10.17.20.203) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 07:52:08 -0700 Subject: Re: [RFC PATCH net-next 0/3] net: batched receive in GRO path To: Paolo Abeni , David Miller CC: netdev , Eric Dumazet References: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com> From: Edward Cree Message-ID: <677040f4-05d1-e664-d24a-5ee2d2edcdbd@solarflare.com> Date: Wed, 10 Jul 2019 15:52:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.203] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24750.005 X-TM-AS-Result: No-4.957400-4.000000-10 X-TMASE-MatchedRID: X4bcv0S75KnmLzc6AOD8DfHkpkyUphL9+IfriO3cV8T5+tteD5RzhWRW ePusFQaMQP46fVlibR/zCPLlhTGnu63czi5f92v9Knjj4PzuQYcT2wrWDpJvKDnZfxjBVQRbgYq Cs2yuWCZbdScq6YVMbr+l/MvfKaYIX4o9HAogemZTLFbi+a8u3aI0K26z6c862C69GeK9wyi0sx 58aisyVazDOPZyHOu1ceEONRK33irCetoOXF2sRVb0VO9AmFFdaKq1Yhw50ju67Q3uPo9KIxOC3 iCulpIKdEq4zFoA8pZ68WLQFTm00WDgAHcIsJL2zNIobH2DzGH348e2CE/wYopc3JtqeiRPXa9+ 3ZJzfMIM4/EABi8Rha4j4Hj3LB/CaBevM/eurMeeAiCmPx4NwHJnzNw42kCxxEHRux+uk8jQ9TR N0mhS11EdxJidWUOjb9C/89aoPjQ7oYwEPB4mL5nFo/AWVHrAS4EMi5G6bY6eVvvvn/KGjmKi9O PpPTo8rzzfBwjd8W+G7c45hdXqQYVyAlz5A0zC7xsmi8libwVi6nHReNJA8sM4VWYqoYnhs+fe0 WifpQo= X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.957400-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24750.005 X-MDID: 1562770332-OMrC8JgZktOC Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 10/07/2019 08:27, Paolo Abeni wrote: > I'm toying with a patch similar to your 3/3 (most relevant difference > being the lack of a limit to the batch size), on top of ixgbe (which > sends all the pkts to the GRO engine), and I'm observing more > controversial results (UDP only): > > * when a single rx queue is running, I see a just-above-noise > peformance delta > * when multiple rx queues are running, I observe measurable regressions > (note: I use small pkts, still well under line rate even with multiple > rx queues) > > I'll try to test your patch in the following days. I look forward to it. > Side note: I think that in patch 3/3, it's necessary to add a call to > gro_normal_list() also inside napi_busy_loop(). Hmm, I was caught out by the call to napi_poll() actually being a local  function pointer, not the static function of the same name.  How did a  shadow like that ever get allowed? But in that case I _really_ don't understand napi_busy_loop(); nothing  in it seems to ever flush GRO, so it's relying on either  (1) stuff getting flushed because the bucket runs out of space, or  (2) the next napi poll after busy_poll_stop() doing the flush. What am I missing, and where exactly in napi_busy_loop() should the  gro_normal_list() call go? -Ed