Message ID | 20230427134527.18127-1-atenart@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | net: tcp: make txhash use consistent for IPv4 | expand |
On Thu, Apr 27, 2023 at 3:45 PM Antoine Tenart <atenart@kernel.org> wrote: > > Hello, > > Series is divided in two parts. First two commits make the txhash (used > for the skb hash in TCP) to be consistent for all IPv4/TCP packets (IPv6 > doesn't have the same issue). Last two commits improve doc/comment > hash-related parts. > > One example is when using OvS with dp_hash, which uses skb->hash, to > select a path. We'd like packets from the same flow to be consistent, as > well as the hash being stable over time when using net.core.txrehash=0. > Same applies for kernel ECMP which also can use skb->hash. How do you plan to test these patches ? > > IMHO the series makes sense in net-next, but we could argue (some) > commits be seen as fixes and I can resend if necessary. net-next is closed...
Quoting Eric Dumazet (2023-04-27 17:15:27) > On Thu, Apr 27, 2023 at 3:45 PM Antoine Tenart <atenart@kernel.org> wrote: > > > > Series is divided in two parts. First two commits make the txhash (used > > for the skb hash in TCP) to be consistent for all IPv4/TCP packets (IPv6 > > doesn't have the same issue). Last two commits improve doc/comment > > hash-related parts. > > > > One example is when using OvS with dp_hash, which uses skb->hash, to > > select a path. We'd like packets from the same flow to be consistent, as > > well as the hash being stable over time when using net.core.txrehash=0. > > Same applies for kernel ECMP which also can use skb->hash. > > How do you plan to test these patches ? I did perform manual checks (with net.core.txrehash=0 to make sure the hash was consistent) using a setup with OvS and dp_hash (~ECMP like) and looking which path packets took. Not sure if there is a simpler test that could be automated, we can't use autoflowlabel to make simple scripts like for IPv6. Anything you'd like to see specifically? > > IMHO the series makes sense in net-next, but we could argue (some) > > commits be seen as fixes and I can resend if necessary. > > net-next is closed... I was convinced to have checked, but well, completely missed it. Sorry about that... Will resend when appropriate. Thanks, Antoine