On 03/23/15 at 04:58P, Jack Vogel wrote: > I think that line was there at one time outside the RSS define,
I believe this was added by Adrian as part of RSS work and was not there before. I may be wrong. > I'd have to > take a look at > the code a bit more, or maybe Eric will.... I'll wait for the comments. Cheers, Hiren > > Jack > > > On Mon, Mar 23, 2015 at 4:42 PM, hiren panchasara < > hi...@strugglingcoder.info> wrote: > > > Correcting Eric's email and subject line. > > > > On 03/23/15 at 04:39P, hiren panchasara wrote: > > > sco...@freebsd.org > > > Bcc: > > > Subject: Full 32bit flowid from igb(4) [was: Re: Unbalanced LACP link] > > > Reply-To: > > > In-Reply-To: <20150319175145.gh53...@strugglingcoder.info> > > > > > > On 03/19/15 at 10:51P, hiren panchasara wrote: > > > > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > > > > On 17 March 2015 at 11:33, Jason Wolfe <nitrobo...@gmail.com> wrote: > > > > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky < > > h...@selasky.org> wrote: > > > > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > > > > >>> > > > > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > > > > >>> significant? In a description it says "Shift flowid bits to > > prevent > > > > > >>> multiqueue collisions". > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Maybe your ethernet hardware is not properly setting the m_flowid > > ... > > > > > >> > > > > > >> --HPS > > > > > >> > > > > > > > > > > > > Flip use_flowid back to 1 and try setting > > > > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift > > to 0 > > > > > > as Hiren suggested. r260179 added this shift, which has caused us > > > > > > balancing issues with the i350/igb. > > > > > > > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=260179 > > > > > > > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > > > > flowid' under normal conditions, does that mean this shift should > > be 0 > > > > > > by default to ensure we don't break balancing for devices that only > > > > > > set the CPU/MSIX queue? > > > > > > > > > > Or we can just see if there's anything wrong with putting the full 32 > > > > > bit RSS flowid in received packets that have them. > > > > > > > > It'd be nice to have but for now I am proposing following to fix a > > known > > > > broken case because of an optimization: > > > > https://reviews.freebsd.org/D2098 > > > > > > Turns out, setting flowid_shift to 0 is not the correct solution. Please > > > look at the review above for more details. > > > > > > Looking at the code, we have a way to get full flowid but it's hidden > > > under "ifdef RSS": > > > rxr->fmp->m_pkthdr.flowid = le32toh(cur->wb.lower.hi_dword.rss); > > > > > > Using just this line gives me good hash on I350 igb(4) chipset that we > > > have. > > > > > > Is it possible to expose this outside RSS? Would this break other > > > things/chips? > > > > > > Cheers, > > > Hiren > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
pgpUCFeqqStJr.pgp
Description: PGP signature
