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.) 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
