Sašo Kiselkov wrote:
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.).
In that case, I agree completely. Once both port numbers are fed into
the hash, it doesn't make any sense to leave the other address out.
Darren
-------------------------------------------
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
