Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dbf9fa57-2ed1-3e50-32be-aa5512dafc6f@intel.com>
Date:   Fri, 14 Jul 2023 16:17:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
Subject: Re: [Intel-wired-lan] [PATCH RFC net-next v4 2/9] iavf: kill
 "legacy-rx" for good
Content-Language: en-US
To:     Alexander Lobakin <aleksander.lobakin@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>
CC:     Paul Menzel <pmenzel@molgen.mpg.de>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        Larysa Zaremba <larysa.zaremba@intel.com>,
        <netdev@vger.kernel.org>, Alexander Duyck <alexanderduyck@fb.com>,
        "Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
        <linux-kernel@vger.kernel.org>,
        Yunsheng Lin <linyunsheng@huawei.com>,
        Michal Kubiak <michal.kubiak@intel.com>,
        <intel-wired-lan@lists.osuosl.org>,
        "David Christensen" <drc@linux.vnet.ibm.com>
References: <20230705155551.1317583-1-aleksander.lobakin@intel.com>
 <20230705155551.1317583-3-aleksander.lobakin@intel.com>
From:   Przemek Kitszel <przemyslaw.kitszel@intel.com>
In-Reply-To: <20230705155551.1317583-3-aleksander.lobakin@intel.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NWNDUS91anVObWt6SFA0bWx5K1BQZ1FpNWhNYzBxSXhhMDhnQkV5cG1hbnpI?=
 =?utf-8?B?NTMzYldld1p0MXBveWZRZGxkU01ZSURLSXRRdVZ0ZVFrKzJDdjhKTE5IUVdO?=
 =?utf-8?B?T0xCZXhZL0VOSGJzcVhsV3lPSWY1RG5OMTM0S3pKV1pCNSs3U2ZPU2RxSi9L?=
 =?utf-8?B?eGROZ0lZaU9xTFhPemxCbHNrMTRpZlN0bFV0ZnBDcFFPWWt4R1YyOUU1MytH?=
 =?utf-8?B?WlB5V2J5aWh5ZFl2UlVRNzRiYTNuR0o1bnZCQ0J0U0Uzc3VFOC9OSEtqVzRC?=
 =?utf-8?B?UDZzYlFIeHRvcUhNcVFoZS92STl3V01ydVg1c0dkSmMvd0oxQjAwS2IzV3Bp?=
 =?utf-8?B?SDVKVW9DbEk1UEQvQy9MWVo2cDU1SWtXeU9WTTArc25JMFF4Qm9oSmVPK1BH?=
 =?utf-8?B?a0FRQ0l3NHMzb0FEaGNKcHFsNzNUak12VmxCaHkzUktZSWlKV1gwSjVET2J2?=
 =?utf-8?B?b2pUdHZ6VVRTTmJWYURQYmFnVkROei8vYzdlaEo3NC9idWIybEs1d1NabVJm?=
 =?utf-8?B?VmlmeUdGZG52bk8vYm84QTFRTk5iRStPQjl2Tm5BdVh2KzNCZGpHTzZ3OHFV?=
 =?utf-8?B?Q1JZU0ozWGM3bjNDaHkySFM4WDBiYzlSYys4S1ZoQWUwWXUvazlsbmFYaVov?=
 =?utf-8?B?Z3ZrZWxJdTZhdTJ1S2pyLzROUkdJVDcyaGZqdXc0dzZiRHNqVjRidTVHVi9J?=
 =?utf-8?B?b0xPUUJRS2s0TkMzV29PL3RQOHl3bVViS2VHTWxMWlBUajFwRUJXMll3SEN6?=
 =?utf-8?B?NTdHazltTkMyUnJMd3JhSE1LMm1PTHhld092MEpPYTZhT3VIT0RKQXFXbUpm?=
 =?utf-8?B?MXZXcy95QTVTbkN3VHBGRzRMTVIybHpSbmVFdk44MmRWQXJ0c2xWMHNXb1VY?=
 =?utf-8?B?Z0Vtb29tOFBjQXh3T1Rxa3d4U2QwVG4wdEYvTkhGM3QyYkNKRzZnclp3SEls?=
 =?utf-8?B?ZVhEY0pUYWJkN3BUL0NQUU85eFZvOHNMVUFScnpNU2Z4OW5PQnFlTDRpbzBl?=
 =?utf-8?B?TStzVHd3Y1lieGZsWnQrNnpwREVlMWVwUkFubDIrSzMwQmRvZC9hZVd6MnRR?=
 =?utf-8?B?a0ZSejk5TGY2SmYwLzlZRmVCUVZka0JJeGFDRWw2b0NTWjAySi9uQUJvcmxW?=
 =?utf-8?B?NGV2TEdHd1Y3L0p4KzZGam54WEVlTDlYdi9BbTlYYTF0Q2thdTlXVmxSTDda?=
 =?utf-8?B?aWRwQStLMjlKcWd2Vlhlemk3Z2I1d2ZUTVlDaTFpcHFWTDliUjBWZ1FZK0pP?=
 =?utf-8?B?M1h1NGwzY3A3UVNJVXJRVmEzeGFHUFNzOUdNeHRxRFZGWHlDdVZ0SWl1VnFU?=
 =?utf-8?B?M0hUQnJNbG5Xdmd0RVRtd0RYR0FBeWwwT3QwZEJad0lpRTVKOEk2eEErRTR5?=
 =?utf-8?B?UmM4dUxNNGtlRHJMcGR5a05IcHZxdmxWeldnSzdVSFFhUHRqTk5rNTlGZHFS?=
 =?utf-8?B?T3hGbUlyREg4QkxRa2Z6SnBUS0tqMXhtRmhPWDVxMS94QWtscHJ2aFlVQ2ph?=
 =?utf-8?B?S2lPZnpJeXJORmlZV1ZaQ2NLeDU3WEZWRGJLZXJZRmNjRGVNdTd6U3N3K2gx?=
 =?utf-8?B?cTlsZXdjUjFzaFZZcjR0Q25tRTAzUG4vSWt5VXB5MGFyRDhhNmxmaTlPODFW?=
 =?utf-8?B?RzdDQWorUWRYNzJpR01mVnF2enVhbE9mRVcxbDVIWkpCa1VwT3BFWll1QXI0?=
 =?utf-8?B?dGdKTTRvYnZOQlFnY2VGa0V1L29Ja1BIdUtrWVc2NUhkbk9xMmN4Z1pWK3Jv?=
 =?utf-8?B?eGYrZk1lUm11ZHNmc0lNZXNETjlEbVJhSExSN2xxWFgvZy9QZ212cnNYK0N3?=
 =?utf-8?B?RWIzbDE2YWJQQkE5dEFUSkxWSTc2UGl1dDBMVSt3MC9GTXlwbGltOHJ1anF0?=
 =?utf-8?B?QUo3MUtHa0ZkY3JYTy9qL2JlaENtbVNnSjBYeUJsRVlxT2UxODlDTnIwZHho?=
 =?utf-8?B?M25BNm1BdHE5dFh0ZUdVOUI5MXVja2l6dXFnWi9tTXBzbXdKRC8vR1J4eUlu?=
 =?utf-8?B?QzdHUG1TdU0wL3A1U1R3cEYxQ0J6WGpWYUJqbEhpenFLQnFJTWIwMVNYbCtl?=
 =?utf-8?B?RGQ4ZktxVDROZmxaT0UwWkVPaUVQblhxeEg5U05USG1lZEVieGJUYnIrc2V6?=
 =?utf-8?B?aUFSNEF3Q3lXVUFiMFQzMHpvWGhSQVEzYk1NUXAzdDdaay9IaXYvMGhiVzdj?=
 =?utf-8?Q?rRVhZ73502jgVm6sXkZbgOc=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: eb5cea9b-294b-4811-faf9-08db8475269d
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3672.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2023 14:18:09.9809
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tvGeoEb/yMS+gPq1UHfu5sx26OM8kX7jsqECieQvywLf79ZIGNfFzMb/5N7W14ZNltTS3zI69mKcZ0yMV1vJeVdRC28rt6z3N6atUc6jw2o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB8082
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,
        SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 7/5/23 17:55, Alexander Lobakin wrote:
> Ever since build_skb() became stable, the old way with allocating an skb
> for storing the headers separately, which will be then copied manually,
> was slower, less flexible and thus obsolete.
> 
> * it had higher pressure on MM since it actually allocates new pages,
>    which then get split and refcount-biased (NAPI page cache);
> * it implies memcpy() of packet headers (40+ bytes per each frame);
> * the actual header length was calculated via eth_get_headlen(), which
>    invokes Flow Dissector and thus wastes a bunch of CPU cycles;
> * XDP makes it even more weird since it requires headroom for long and
>    also tailroom for some time (since mbuf landed). Take a look at the
>    ice driver, which is built around work-arounds to make XDP work with
>    it.
> 
> Even on some quite low-end hardware (not a common case for 100G NICs) it
> was performing worse.
> The only advantage "legacy-rx" had is that it didn't require any
> reserved headroom and tailroom. But iavf didn't use this, as it always
> splits pages into two halves of 2k, while that save would only be useful
> when striding. And again, XDP effectively removes that sole pro.
> 
> There's a train of features to land in IAVF soon: Page Pool, XDP, XSk,
> multi-buffer etc. Each new would require adding more and more Danse
> Macabre for absolutely no reason, besides making hotpath less and less
> effective.
> Remove the "feature" with all the related code. This includes at least
> one very hot branch (typically hit on each new frame), which was either
> always-true or always-false at least for a complete NAPI bulk of 64
> frames, the whole private flags cruft, and so on. Some stats:
> 
> Function: add/remove: 0/4 grow/shrink: 0/7 up/down: 0/-757 (-757)
> RO Data: add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-40 (-40)
> 
> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
>   drivers/net/ethernet/intel/iavf/iavf.h        |   2 +-
>   .../net/ethernet/intel/iavf/iavf_ethtool.c    | 140 ------------------
>   drivers/net/ethernet/intel/iavf/iavf_main.c   |  10 +-
>   drivers/net/ethernet/intel/iavf/iavf_txrx.c   |  84 +----------
>   drivers/net/ethernet/intel/iavf/iavf_txrx.h   |  27 +---
>   .../net/ethernet/intel/iavf/iavf_virtchnl.c   |   3 +-
>   6 files changed, 8 insertions(+), 258 deletions(-)

Good one, there were some random questions in my mind during the read,
but all are resolved by subsequent patches.
(It's a pity I have not found yet time to fully read them though)

Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>