[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406557222.12728.23.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Mon, 28 Jul 2014 16:20:22 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Tom Herbert <therbert@...gle.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] udp: UDP Fast Port
On Sat, 2014-07-26 at 15:29 -0700, Tom Herbert wrote:
> This patch implements fast ports in UDP. The idea is that a kernel
> module registers a port and associated receive function. In UDP receive,
> the list of fast ports is scanned and the destinaton port is matched
> against the registered port. If there is a match, then the receive
> function is called to process the packet. When a UDP fast port is used,
> we can receive encap'ed packets without performing or accessing a
> socket. This is a performance gain, especially since we don't need to
> take socket ref count on every packet.
>
> Signed-off-by: Tom Herbert <therbert@...gle.com>
> ---
> include/net/udp.h | 23 +++++++++++++++++++
> net/ipv4/udp.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
> net/ipv6/udp.c | 21 +++++++++++++++--
> 3 files changed, 108 insertions(+), 5 deletions(-)
I find this very hacky. I do not think we should have different sorts of
UDP sockets.
If we believe we need a fast UDP path, without socket refcount being
touched, we should remove the SLAB_DESTROY_BY_RCU and switch to rcu
socket freeing (call_rcu())
At the time we added RCU lookups to UDP, we hadn't vxlan, and fear was
that the extra RCU grace period at socket dismantle was too heavy cost,
like TCP sockets.
Meanwhile, RCU cleanups got lot of attention, and UDP sockets serve as
tunnels vehicle.
--
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