netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next] net: Reflect RX hash for transmit
@ 2015-02-15 18:37 Tom Herbert
  2015-02-15 19:59 ` Daniel Borkmann
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Tom Herbert @ 2015-02-15 18:37 UTC (permalink / raw)
  To: davem, netdev

This patch allows a driver to request that the receive hash it provides
to the stack is reflected back in skb->hash for packets transmitted
on the associated connection. The hash value returned by a device could
have meaning when used in transmit to identify a flow, for instance
the hash may by a flow ID for a flow created in a (virtual) device.
With the flow ID provided on transmit this can obviate the need
to create the hash and do the lookup on the fly in transmit.

Note that this is an opportunistic optimization, there is no
separate negotiation between the stack and driver/device for
the hash used in either TX or RX.

Signed-off-by: Tom Herbert <therbert@google.com>
---
 include/linux/skbuff.h | 3 ++-
 include/net/sock.h     | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 1bb36ed..f792a0d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -605,7 +605,8 @@ struct sk_buff {
 	__u8			ipvs_property:1;
 	__u8			inner_protocol_type:1;
 	__u8			remcsum_offload:1;
-	/* 3 or 5 bit hole */
+	__u8			reflect_hash:1;
+	/* 2 or 4 bit hole */
 
 #ifdef CONFIG_NET_SCHED
 	__u16			tc_index;	/* traffic control index */
diff --git a/include/net/sock.h b/include/net/sock.h
index e138245..133fc51 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -871,6 +871,8 @@ static inline void sock_rps_save_rxhash(struct sock *sk,
 	if (unlikely(sk->sk_rxhash != skb->hash))
 		sk->sk_rxhash = skb->hash;
 #endif
+	if (unlikely(skb->reflect_hash && sk->sk_txhash != skb->hash))
+		sk->sk_txhash = skb->hash;
 }
 
 static inline void sock_rps_reset_rxhash(struct sock *sk)
-- 
2.2.0.rc0.207.ga3a616c

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] net: Reflect RX hash for transmit
  2015-02-15 18:37 [PATCH net-next] net: Reflect RX hash for transmit Tom Herbert
@ 2015-02-15 19:59 ` Daniel Borkmann
  2015-02-15 20:19   ` Tom Herbert
  2015-02-16 12:29 ` Eric Dumazet
  2015-02-19 20:54 ` David Miller
  2 siblings, 1 reply; 6+ messages in thread
From: Daniel Borkmann @ 2015-02-15 19:59 UTC (permalink / raw)
  To: Tom Herbert, davem, netdev

On 02/15/2015 07:37 PM, Tom Herbert wrote:
> This patch allows a driver to request that the receive hash it provides
> to the stack is reflected back in skb->hash for packets transmitted
> on the associated connection.
[...]
> +	if (unlikely(skb->reflect_hash && sk->sk_txhash != skb->hash))
> +		sk->sk_txhash = skb->hash;

Is there also an initial user setting this somewhere?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] net: Reflect RX hash for transmit
  2015-02-15 19:59 ` Daniel Borkmann
@ 2015-02-15 20:19   ` Tom Herbert
  2015-02-15 20:27     ` Daniel Borkmann
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Herbert @ 2015-02-15 20:19 UTC (permalink / raw)
  To: Daniel Borkmann; +Cc: David Miller, Linux Netdev List

On Sun, Feb 15, 2015 at 11:59 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 02/15/2015 07:37 PM, Tom Herbert wrote:
>>
>> This patch allows a driver to request that the receive hash it provides
>> to the stack is reflected back in skb->hash for packets transmitted
>> on the associated connection.
>
> [...]
>>
>> +       if (unlikely(skb->reflect_hash && sk->sk_txhash != skb->hash))
>> +               sk->sk_txhash = skb->hash;
>
>
> Is there also an initial user setting this somewhere?

inet_set_txhash and ip6_set_txhash are called for connected sockets.
There is no user API to set these.

Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] net: Reflect RX hash for transmit
  2015-02-15 20:19   ` Tom Herbert
@ 2015-02-15 20:27     ` Daniel Borkmann
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Borkmann @ 2015-02-15 20:27 UTC (permalink / raw)
  To: Tom Herbert; +Cc: David Miller, Linux Netdev List

On 02/15/2015 09:19 PM, Tom Herbert wrote:
> On Sun, Feb 15, 2015 at 11:59 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 02/15/2015 07:37 PM, Tom Herbert wrote:
>>>
>>> This patch allows a driver to request that the receive hash it provides
>>> to the stack is reflected back in skb->hash for packets transmitted
>>> on the associated connection.
>>
>> [...]
>>>
>>> +       if (unlikely(skb->reflect_hash && sk->sk_txhash != skb->hash))
>>> +               sk->sk_txhash = skb->hash;
>>
>>
>> Is there also an initial user setting this somewhere?
>
> inet_set_txhash and ip6_set_txhash are called for connected sockets.
> There is no user API to set these.

Yes sure, this was maybe a bit unclear; I was referring to reflect_hash.

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] net: Reflect RX hash for transmit
  2015-02-15 18:37 [PATCH net-next] net: Reflect RX hash for transmit Tom Herbert
  2015-02-15 19:59 ` Daniel Borkmann
@ 2015-02-16 12:29 ` Eric Dumazet
  2015-02-19 20:54 ` David Miller
  2 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2015-02-16 12:29 UTC (permalink / raw)
  To: Tom Herbert; +Cc: davem, netdev

On Sun, 2015-02-15 at 10:37 -0800, Tom Herbert wrote:
> This patch allows a driver to request that the receive hash it provides
> to the stack is reflected back in skb->hash for packets transmitted
> on the associated connection. The hash value returned by a device could
> have meaning when used in transmit to identify a flow, for instance
> the hash may by a flow ID for a flow created in a (virtual) device.
> With the flow ID provided on transmit this can obviate the need
> to create the hash and do the lookup on the fly in transmit.
> 
> Note that this is an opportunistic optimization, there is no
> separate negotiation between the stack and driver/device for
> the hash used in either TX or RX.
> 
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---

It is not clear to me why we would want to consume yet another skb->bit
for this.

This seems it might be a socket attribute, rather than a device provided
one on every packet.

Anyway, this seems a premature change, as no driver currently needs this
yet ?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] net: Reflect RX hash for transmit
  2015-02-15 18:37 [PATCH net-next] net: Reflect RX hash for transmit Tom Herbert
  2015-02-15 19:59 ` Daniel Borkmann
  2015-02-16 12:29 ` Eric Dumazet
@ 2015-02-19 20:54 ` David Miller
  2 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2015-02-19 20:54 UTC (permalink / raw)
  To: therbert; +Cc: netdev

From: Tom Herbert <therbert@google.com>
Date: Sun, 15 Feb 2015 10:37:18 -0800

> This patch allows a driver to request that the receive hash it provides
> to the stack is reflected back in skb->hash for packets transmitted
> on the associated connection. The hash value returned by a device could
> have meaning when used in transmit to identify a flow, for instance
> the hash may by a flow ID for a flow created in a (virtual) device.
> With the flow ID provided on transmit this can obviate the need
> to create the hash and do the lookup on the fly in transmit.
> 
> Note that this is an opportunistic optimization, there is no
> separate negotiation between the stack and driver/device for
> the hash used in either TX or RX.
> 
> Signed-off-by: Tom Herbert <therbert@google.com>

Like Eric, I'd like to see this resubmitted alongside an actual user
of the new facility.

Thanks!

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-02-19 20:54 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-15 18:37 [PATCH net-next] net: Reflect RX hash for transmit Tom Herbert
2015-02-15 19:59 ` Daniel Borkmann
2015-02-15 20:19   ` Tom Herbert
2015-02-15 20:27     ` Daniel Borkmann
2015-02-16 12:29 ` Eric Dumazet
2015-02-19 20:54 ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).