[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20191114.173015.93572744645212390.davem@davemloft.net>
Date: Thu, 14 Nov 2019 17:30:15 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: xiangxia.m.yue@...il.com
Cc: pshelar@....org, gvrose8192@...il.com, blp@....org,
netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [PATCH net-next v4] net: openvswitch: add hash info to upcall
From: xiangxia.m.yue@...il.com
Date: Wed, 13 Nov 2019 23:04:49 +0800
> From: Tonghao Zhang <xiangxia.m.yue@...il.com>
>
> When using the kernel datapath, the upcall don't
> include skb hash info relatived. That will introduce
> some problem, because the hash of skb is important
> in kernel stack. For example, VXLAN module uses
> it to select UDP src port. The tx queue selection
> may also use the hash in stack.
>
> Hash is computed in different ways. Hash is random
> for a TCP socket, and hash may be computed in hardware,
> or software stack. Recalculation hash is not easy.
>
> Hash of TCP socket is computed:
> tcp_v4_connect
> -> sk_set_txhash (is random)
>
> __tcp_transmit_skb
> -> skb_set_hash_from_sk
>
> There will be one upcall, without information of skb
> hash, to ovs-vswitchd, for the first packet of a TCP
> session. The rest packets will be processed in Open vSwitch
> modules, hash kept. If this tcp session is forward to
> VXLAN module, then the UDP src port of first tcp packet
> is different from rest packets.
>
> TCP packets may come from the host or dockers, to Open vSwitch.
> To fix it, we store the hash info to upcall, and restore hash
> when packets sent back.
...
> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@...il.com>
Applied, thank you.
Powered by blists - more mailing lists