From: Eric Dumazet <edumazet@google.com>
To: "David S . Miller" <davem@davemloft.net>
Cc: netdev <netdev@vger.kernel.org>, Florian Westphal <fw@strlen.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
Thomas Graf <tgraf@suug.ch>,
Nikolay Aleksandrov <nikolay@redhat.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Alexander Aring <alex.aring@gmail.com>,
Stefan Schmidt <stefan@osg.samsung.com>,
Eric Dumazet <edumazet@google.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: [PATCH net-next 0/6] inet: frags: bring rhashtables to IP defrag
Date: Thu, 29 Mar 2018 22:21:13 -0700 [thread overview]
Message-ID: <20180330052119.206462-1-edumazet@google.com> (raw)
IP defrag processing is one of the remaining problematic layer in linux.
It uses static hash tables of 1024 buckets, and up to 128 items per bucket.
A work queue is supposed to garbage collect items when host is under memory
pressure, and doing a hash rebuild, changing seed used in hash computations.
This work queue blocks softirqs for up to 25 ms when doing a hash rebuild,
occurring every 5 seconds if host is under fire.
Then there is the problem of sharing this hash table for all netns.
It is time to switch to rhashtables, and allocate one of them per netns
to speedup netns dismantle, since this is a critical metric these days.
Lookup is now using RCU, and 64bit hosts can now provision whatever amount
of memory needed to handle the expected workloads.
Eric Dumazet (6):
ipv6: frag: remove unused field
inet: frags: change inet_frags_init_net() return value
inet: frags: add a pointer to struct netns_frags
inet: frags: use rhashtables for reassembly units
inet: frags: remove some helpers
inet: frags: break the 2GB limit for frags storage
Documentation/networking/ip-sysctl.txt | 13 +-
include/net/inet_frag.h | 134 ++++----
include/net/ip.h | 1 -
include/net/ipv6.h | 28 +-
net/ieee802154/6lowpan/6lowpan_i.h | 26 +-
net/ieee802154/6lowpan/reassembly.c | 140 ++++----
net/ipv4/inet_fragment.c | 404 +++++-------------------
net/ipv4/ip_fragment.c | 199 ++++++------
net/ipv4/proc.c | 6 +-
net/ipv6/netfilter/nf_conntrack_reasm.c | 96 +++---
net/ipv6/proc.c | 5 +-
net/ipv6/reassembly.c | 182 ++++++-----
12 files changed, 450 insertions(+), 784 deletions(-)
--
2.17.0.rc1.321.gba9d0f2565-goog
reply other threads:[~2018-03-30 5:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20180330052119.206462-1-edumazet@google.com \
--to=edumazet@google.com \
--cc=alex.aring@gmail.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=nikolay@redhat.com \
--cc=stefan@osg.samsung.com \
--cc=tgraf@suug.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox