Messages in this thread | | | Subject | Re: [PATCH net-next v2 4/4] bonding: balance ICMP echoes in layer3+4 mode | From | Nikolay Aleksandrov <> | Date | Tue, 29 Oct 2019 23:50:33 +0200 |
| |
On 29/10/2019 23:03, Eric Dumazet wrote: > > > On 10/29/19 11:35 AM, Nikolay Aleksandrov wrote: > >> Hi Matteo, >> Wouldn't it be more useful and simpler to use some field to choose the slave (override the hash >> completely) in a deterministic way from user-space ? >> For example the mark can be interpreted as a slave id in the bonding (should be >> optional, to avoid breaking existing setups). ping already supports -m and >> anything else can set it, this way it can be used to do monitoring for a specific >> slave with any protocol and would be a much simpler change. >> User-space can then implement any logic for the monitoring case and as a minor bonus >> can monitor the slaves in parallel. And the opposite as well - if people don't want >> these balanced for some reason, they wouldn't enable it. >> > > I kind of agree giving user more control. But I do not believe we need to use the mark > (this might be already used by other layers) > > TCP uses sk->sk_hash to feed skb->hash. > > Anything using skb_set_owner_w() is also using sk->sk_hash if set. > > So presumably we could add a generic SO_TXHASH socket option to let user space > read/set this field. >
Right, I was just giving it as an example. Your suggestion sounds much better and wouldn't interfere with other layers, plus we already use skb->hash in bond_xmit_hash() and skb_set_owner_w() sets l4_hash if txhash is present which is perfect.
One thing - how do we deal with sk_rethink_txhash() ? I guess we'll need some way to signal that the user specified the txhash and it is not to be recomputed ? That can also be used to avoid the connect txhash set as well if SO_TXHASH was set prior to the connect. It's quite late here, I'll look into it more tomorrow. :)
Thanks, Nik
| |