All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: <netdev@vger.kernel.org>
Subject: [RFC PATCH 0/3] sk_buff: add skb extension infrastructure
Date: Mon, 26 Nov 2018 12:38:54 +0100	[thread overview]
Message-ID: <20181126113857.29270-1-fw@strlen.de> (raw)

The (out-of-tree) Multipath-TCP implementation needs a significant amount
of extra space in the skb control buffer.

Increasing skb->cb[] size in mainline is a non-starter for memory and
and performance reasons (f.e. increase in cb size also moves several
frequently-accessed fields to other cache lines).

One approach that might work for MPTCP is to extend skb_shared_info instead
of sk_buff.  However, this comes with other drawbacks, e.g.  it either
needs special skb allocation to make sure there is enough space for such
'extended shinfo' at the end of data buffer (which makes this only useable
for tx path) or increased size of skb_shared_info.

This adds an extension infrastructure for sk_buff instead:
1. extension memory is released when the sk_buff is free'd.
2. data is shared after cloning an skb.
3. adding extension to an skb will COW the extension
   buffer if needed.

This is also how xfrm and bridge_nf extra data (skb->sp, skb->nf_bridge)
are handled.

In the future, protocols that need to store more than 48 bytes in skb->cb[]
could add a 'SKB_EXT_EXTRA_CB' or similar to allocate extra space.

Two new members are added to sk_buff:
1. 'active_extensions' byte (filling a hole), telling which extensions
   have been enabled for this skb.
2. extension pointer, located at the end of the sk_buff.
   If active_extensions byte is 0, pointer value is undefined.

Last patch converts nf_bridge to use the extension infrastructure:
The 'nf_bridge' pointer is removed, i.e. sk_buff size remains the same.

Extra code added to skb clone and free paths (to deal with
refcount/free of extension area) replace the existing code that
deals with skb->nf_bridge.

Conversion of skb->sp (ipsec/xfrm secpath) to an skb extension could be
done as a followup, but I'm reluctant to work on this before there is
agreement that this is the right direction.

Comments welcome.

 include/linux/netfilter_bridge.h     |   33 +++++---
 include/linux/skbuff.h               |  142 +++++++++++++++++++++++++++++------
 include/net/netfilter/br_netfilter.h |   14 ---
 net/Kconfig                          |    4 
 net/bridge/br_netfilter_hooks.c      |   39 +++------
 net/bridge/br_netfilter_ipv6.c       |    4 
 net/core/skbuff.c                    |  134 ++++++++++++++++++++++++++++++++-
 net/ipv4/ip_output.c                 |    1 
 net/ipv4/netfilter/nf_reject_ipv4.c  |    6 -
 net/ipv6/ip6_output.c                |    1 
 net/ipv6/netfilter/nf_reject_ipv6.c  |   10 +-
 net/netfilter/nf_log_common.c        |   20 ++--
 net/netfilter/nf_queue.c             |   50 ++++++++----
 net/netfilter/nfnetlink_queue.c      |   23 ++---
 net/netfilter/xt_physdev.c           |    2 
 15 files changed, 368 insertions(+), 115 deletions(-)

             reply	other threads:[~2018-11-26 22:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 11:38 Florian Westphal [this message]
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

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=20181126113857.29270-1-fw@strlen.de \
    --to=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.