On 07/02/2012 01:01 PM, Darren Reed wrote: > On 2/07/2012 7:44 PM, Sašo Kiselkov wrote: >> On 07/02/2012 11:06 AM, Darren Reed wrote: >>> On 2/07/2012 4:47 PM, Sašo Kiselkov wrote: >>>> Well, as far as I'm concerned, I always wondered why it was >>>> "src_addr ^ src_port" to begin with, other than the author assuming that >>>> the bulk of all traffic being unicast (which naturally tends towards >>>> unique src-port tuples). If I had a say in that, I'd always advocate for >>>> "src_addr ^ src_port ^ dst_addr ^ dst_port" to give the maximum amount >>>> of entropy for the fanout and then have a per-link tunable (settable via >>>> dladm set-linkprop) to allow configuring other fanout strategies, like >>>> is possible for link-aggregation (L2, L3, L4, etc.). >>> At present the hash is on both the source address and the 32bit >>> representation of the source and destination ports (this is what >>> "whereptr" is for.) If you look at the definition of HASH_ADDR, >>> you'll see that all 32bits of the ports are used. >>> >>> I'd be somewhat hesitant to use "src ^ dst" as for hosts on the >>> same network the hash will almost reduce to just the ports. It >>> might be better to do "(src + dst) ^ ports". >> Agree, src+dst works better than src^dst. Is there a reason why not to >> use it across the board for all fanout hashing by default? (I don't >> think any external code should depend on the specific algorithm used.) > > Taking the ports out of the hashing would force all traffic between any > given pair of hosts to always be queued up together. This might be rather > undesirable when you're using zfs send/receive between a pair of hosts > that are also supporting ssh traffic, for instance. Whilst there is no way > to guarantee that both connections will end up being fanned out > differently, adding in the ports increases the chances vs just leaving > it as the IP addresses. For IPv6 flows, the flow id from the IPv6 header > should most definitely play some part.
I meant that src+dst should be taken _in_addition_ to port-based hashing. Of course, port-based hashing is beneficial - for all cases we should strive to be able to randomize per smallest practical flow in the network (i.e. a TCP session, UDP packet flow, etc.). Cheers, -- Saso ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
