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? _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"