[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1430255273-3045254-1-git-send-email-kafai@fb.com>
Date: Tue, 28 Apr 2015 14:07:47 -0700
From: Martin KaFai Lau <kafai@...com>
To: netdev <netdev@...r.kernel.org>
CC: Hannes Frederic Sowa <hannes@...essinduktion.org>,
Steffen Klassert <steffen.klassert@...unet.com>,
David Miller <davem@...emloft.net>,
Kernel Team <Kernel-team@...com>
Subject: [PATCH net-next 0/6 v2] ipv6: Only create RTF_CACHE route after encountering pmtu exception
v1 -> v2:
- Move the /128 route bug fixes to another series (posted).
- Create a function for checking (rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)).
- Avoid shuffling the skb network_header. Instead, change the function
signature to take iph instead of skb.
The perf numbers do not change much since v1.
It depends on another patch series,
'ipv6: Stop /128 route from disappearing after pmtu update', which
should be applied first.
Many thanks to "Hannes Frederic Sowa <hannes@...essinduktion.org>" on
reviewing the patches and giving advice.
--Martin
~~~ start: v1 compose message (with the out-dated parts removed) ~~~
This series is to avoid creating a RTF_CACHE route whenever we are consulting
the fib6 tree with a new destination. Instead, only create RTF_CACHE route
when we see a pmtu exception.
Out of all ipv6 RTF_CACHE routes that are created, the percentage that has a
different mtu is very small. In one of our end-user facing proxy server,
only 1k out of 80k RTF_CACHE routes have a smaller MTU. For our DC
traffic, there is no mtu exception.
A large fib6 tree has problems like, 'ip -6 r show' takes a long time.
gc may kick in too often. Also, when a service has restarted and a lot
of new TCP conn requests come in, it creates pressure on the tree by inserting
a lot of RTF_CACHE in a short time and it currently requires a write lock
to do that.
The first few patches are prep works to remove assumption that the
returned rt is always RTF_CACHE.
The patch 'ipv6: Only create RTF_CACHE routes after encountering pmtu exception'
do the lazy RTF_CACHE route creation.
The following patches added percpu rt to compensate the performance loss after
doing the RTF_CACHE lazy creation.
Here is some numbers of the udpflood test. The udpflood has been
slightly modified to have a time limit instead of count limit.
A /64 via gateway route is used for the test. Each udpflood uses 10000 dst
addresses. The dst addresses of different udpflood processes do not overlap
with each other.
# of udpflood # of trans (patched) # of trans (upstream)
1 16M 15M
10 61M 61M
20 65M 62M
40 88M 83M
~~~ end: v1 compose message ~~~
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists