From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net-next 02/13] sk_buff: add skb extension infrastructure Date: Wed, 12 Dec 2018 21:40:03 -0800 Message-ID: <8ae68a38-c981-f317-39b1-1092e7efbeeb@gmail.com> References: <20181210145006.19098-1-fw@strlen.de> <20181210145006.19098-3-fw@strlen.de> <4a43ca01-d09b-71e8-18e1-9a5707787ae0@gmail.com> <20181212184446.gyjwbwoyzhrk7kxw@breakpoint.cc> <7906a8d9-c2f9-0883-3d13-5ef38e53f10c@gmail.com> <20181212205236.sja4fw4sf5egtkyw@breakpoint.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: Florian Westphal , Eric Dumazet Return-path: Received: from mail-wr1-f65.google.com ([209.85.221.65]:39084 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726226AbeLMFkI (ORCPT ); Thu, 13 Dec 2018 00:40:08 -0500 Received: by mail-wr1-f65.google.com with SMTP id t27so648827wra.6 for ; Wed, 12 Dec 2018 21:40:07 -0800 (PST) In-Reply-To: <20181212205236.sja4fw4sf5egtkyw@breakpoint.cc> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 12/12/2018 12:52 PM, Florian Westphal wrote: > Eric Dumazet wrote: >>> If you prefer that, ok, but I don't see why we can't unify them behind >>> a single layer? >> >> Well, for a start we do not use nf_brifge or secpath. > > Then the extension framework isn't built and the result > is exactly the same as before these patches: helpers > turn into empty inline stubs. > > If its built, sk_buff size is reduced by up to one pointer, > and the added one isn't initialised at allocation time. > > sk_buff layout with the extension patches is almost same > as with XFRM=n BRIDGE_NF=n (because nf_bridge and sp pointers > get removed), there is only one additional pointer at the end, > not inited at alloc time. The other new member fills a hole. > >> XDP is all about not unifying because unifying has a cost. >> >> Do we really want to slow down the stack just because MPTCP is coming ? > > I don't want to slow down the stack. All places that gain a helper call > do so instead of the nf_bridge/secpath one. They only expand into code > if at least one of secpath or nf_bridge are built in. > Both struct secpath and nf_bridge have their refcounts removed, so no > additional reference counts are added. > > If you still think this is proposal is a bad idea, ok, let me know > and I will stop working on this. Certainly not a bad idea. > > MPTCP can then just add skb->cb2[], but neither nf_bridge nor secpath can > use it. > > If not, I will send another iteration that just allocates the entire > extension space if first extension is added, it simplifies allocation > handling a little. > I am still unsure of the added extra costs, but for a start, TCP xmit clones the skbs. Does it mean an additional pair of atomic operations if the skb comes from MPTCP enabled flow ? The clone is used in the lower layers (IP , qdisc, device xmit), so I do not see why a clone should share the extdata from the master.