All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: eric.dumazet@gmail.com
Cc: fw@strlen.de, netdev@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] sk_buff: add skb extension infrastructure
Date: Tue, 27 Nov 2018 16:39:17 -0800 (PST)	[thread overview]
Message-ID: <20181127.163917.1798640931979072354.davem@davemloft.net> (raw)
In-Reply-To: <d5d33539-3ecc-1078-ca73-c16e810388e3@gmail.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 26 Nov 2018 15:05:02 -0800

> One thing that could be done without too much impact is to provide a cbext[]
> only for TCP packets in write/rtx queue, that is not in sk_buff but
> on the struct sk_buff_fclones
> 
> This extra space would not be 0-initialized at alloc_skb()
> and would not be copied at skb_clone()
> 
> I mentioned this idea a while back already.
> 
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 73902acf2b71c8800d81b744a936a7420f33b459..c4bfc2fd98eb9723c0219d5cd8bf5b28afaf5398 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1018,6 +1018,8 @@ struct sk_buff_fclones {
>         struct sk_buff  skb2;
>  
>         refcount_t      fclone_ref;
> +
> +       char            cbext[128] __aligned(8);
>  };

So, potentially at least, MP-TCP could use this.

The down side is that it doesn't allow for the br_netfilter, skb->sp,
etc. consoldation down to one test.

      reply	other threads:[~2018-11-28 11:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 11:38 [RFC PATCH 0/3] sk_buff: add skb extension infrastructure Florian Westphal
2018-11-26 11:38 ` [RFC PATCH 1/3] netfilter: avoid using skb->nf_bridge directly Florian Westphal
2018-11-26 11:38 ` [RFC PATCH 2/3] sk_buff: add skb extension infrastructure Florian Westphal
2018-11-26 11:38 ` [RFC PATCH 3/3] net: convert bridge_nf to use " Florian Westphal
2018-11-26 20:41 ` [RFC PATCH 0/3] sk_buff: add " David Miller
2018-11-26 21:19   ` Florian Westphal
2018-11-26 21:27     ` David Miller
2018-11-26 21:41       ` Florian Westphal
2018-11-26 23:05 ` Eric Dumazet
2018-11-28  0:39   ` David Miller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181127.163917.1798640931979072354.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.