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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61AD0C6379F for ; Wed, 15 Feb 2023 09:44:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233671AbjBOJnz (ORCPT ); Wed, 15 Feb 2023 04:43:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234107AbjBOJno (ORCPT ); Wed, 15 Feb 2023 04:43:44 -0500 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:237:300::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78C5B4ED3 for ; Wed, 15 Feb 2023 01:43:42 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1pSEK4-00030C-W2; Wed, 15 Feb 2023 10:43:33 +0100 Date: Wed, 15 Feb 2023 10:43:32 +0100 From: Florian Westphal To: Jakub Kicinski Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com, willemb@google.com, fw@strlen.de Subject: Re: [RFC] net: skbuff: let struct skb_ext live inside the head Message-ID: <20230215094332.GB9908@breakpoint.cc> References: <20230215034444.482178-1-kuba@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230215034444.482178-1-kuba@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jakub Kicinski wrote: > This is a bit more crazy than the previous patch. For drivers > which already use build_skb() it's relatively easy to add more > space to the shinfo. Use this approach to place skb_ext inside > the head. No allocation needed. > > This approach is a bit slower in trivial benchmarks than the recycling > because it requires extra cache line accesses (12.1% loss, ->18.6Gbps). > > In-place skb_ext may be shorter than a full skb_ext object. > The driver only reserves space for exts it may use. > Any later addition will reallocate the space via CoW, > abandoning the in-place skb_ext and copying the data to > a full slab object. I think the cleaner solution would be to move the new extension ids into sk_buff itself (at the end, uninitialized data unless used). Those extensions would always reside there and not in the slab object. Obviously that only makes sense for extensions where we assume that typical workload will require them, which might be a hard call to make. I concur with Paolo that the napi-caching is nicer/less intrusive, I think we have to wait and see if it helps with psp (async crypto needed?) when it lands.