Date: Sat, 6 Jan 2018 01:20:20 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Matt Joras <mjoras@freebsd.org> Cc: Steven Hartland <steven@multiplay.co.uk>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, scottl@freebsd.org Subject: Re: svn commit: r327559 - in head: . sys/net Message-ID: <5A4FC1E4.9060301@grosbein.net> In-Reply-To: <CADdTf%2BjJVn_X6UNywnis-KXq6Dua7B8F=2kuND_N6bJ1ZH0D_A@mail.gmail.com> References: <201801042005.w04K5liB049411@repo.freebsd.org> <5A4E9397.9000308@grosbein.net> <f133b587-1f7e-4594-31d1-974775ad55be@freebsd.org> <5A4EDC62.50508@grosbein.net> <c42bfb9e-e583-aca3-bf0d-4d92c0153d2f@multiplay.co.uk> <5A4F824C.1060405@grosbein.net> <97d173fb-4f47-609d-8319-07282a283473@multiplay.co.uk> <CADdTf%2Bi47-X1HVb=JBFi53wOgbX1x1euHr53-YyqNDDFNF9PLw@mail.gmail.com> <5A4FB6BC.6090506@grosbein.net> <CADdTf%2BjJVn_X6UNywnis-KXq6Dua7B8F=2kuND_N6bJ1ZH0D_A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A4FC1E4.9060301>