svn commit: r327559 - in head: . sys/net

[Matt Joras]

On Fri, Jan 5, 2018 at 7:42 AM, Steven Hartland <steven at multiplay.co.uk> wrote:
> My current thinking is that flowid shouldn't be used for either LACP or
> loadbalance protocols as doing so will almost certainly lead to unexpected
> behavior (the stated lagghash may not be valid).
>
>     Regards
>     Steve
>

For what it's worth, this was the conclusion I came to, and at Isilon
we've made the same change being discussed here. For the case of
drivers that end up using a queue index for the flowid, you end up
with pathological behavior on the lagg; the flowid ends up getting
right shifted by (default) 16. So in the case of e.g. two bxe(4)
interfaces with 4 queues, you always end up choosing the interface in
the lagg at index 0.

This was enough to make us completely disable it. Customers started
noticing when they upgraded from the BSD7-based release (which
predates flowid) to the BSD10-based release. It is my impression that
this sort of situation is probably more common in FreeBSD, especially
since some drivers only set the flowid to an RSS hash when RSS is
defined, otherwise defaulting to a queue index.

Matt