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

[Eugene Grosbein]

CC'ng scottl@ as author of the change in question.

06.01.2018 0:39, Matt Joras wrote:

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

Then why does if_lagg shifts 16 bits by default? Is seems senseless.
This was introduced with r260070 by scottl:

> Multi-queue NIC drivers and multi-port lagg tend to use the same lower
> bits of the flowid as each other, resulting in a poor distribution of
> packets among queues in certain cases.  Work around this by adding a
> set of sysctls for controlling a bit-shift on the flowid when doing
> multi-port aggrigation in lagg and lacp.  By default, lagg/lacp will
> now use bits 16 and higher instead of 0 and higher.
> 
> Reviewed by:    max
> Obtained from:  Netflix
> MFC after:      3 days

This commit message does not point to an example of NIC driver that would set
non-zero bits 16 and higher for flowid so that shift result would be non-zero.
Do we really have such a driver?

Anyway, this lagg's default seems to be very driver-centric.

For example, Intel driver family also do not use such high bits for flowid
just like mentioned bxe(4).

We should change flowid_shift default to 0 for if_lagg(4), shouldn't we?