Thread (15 messages) 15 messages, 4 authors, 2011-04-06

Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets (v2)

flat view

From: Neil Horman <nhorman@tuxdriver.com>
Date: 2011-04-06 20:42:36

On Wed, Apr 06, 2011 at 01:07:49PM -0700, David Miller wrote:
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed,  6 Apr 2011 15:37:27 -0400
quoted
properly record sk_rxhash in ipv6 sockets (v2)

Noticed while working on another project that flows to sockets which I had open
on a test systems weren't getting steered properly when I had RFS enabled.
Looking more closely I found that:

1) The affected sockets were all ipv6
2) They weren't getting steered because sk->sk_rxhash was never set from the
incomming skbs on that socket.

This was occuring because there are several points in the IPv4 tcp and udp code
which save the rxhash value when a new connection is established.  Those calls
to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
This patch adds those calls.  Tested by myself to properly enable RFS
functionalty on ipv6.

Change notes:
v2:
	Filtered UDP to only arm RFS on bound sockets (Eric Dumazet)

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Ok, I've decided to apply this to net-2.6

The current behavior even surprised me, I was pretty sure we had added
the hooks to both ipv4 and ipv6.

Thanks a lot Neil.
Thanks Dave, I was kind of suprised too, but we definately weren't recording the
rxhash. FWIW It doesn't appear to be a regression.  I can't find where in the
history we ever had the hooks.  Perhaps at one point tcp and udp rcv paths were
common between ipv4 and 6 address families, and then we bifurcated without
replicating the sock_rps_save_rxhash calls?

Neil
 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help