Date: Tue, 19 Jan 2016 12:47:18 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: Ryan Stone <rysto32@gmail.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r294327 - in head/sys: dev/cxgb dev/cxgbe dev/e1000 dev/hyperv/netvsc dev/ixgbe dev/mxge netinet sys Message-ID: <CAJ-VmokCLr7jESQqDYPRUgbo2vQD-1_kC6YhCjqAm3tMz29RUg@mail.gmail.com> In-Reply-To: <569EA026.5020906@selasky.org> References: <201601191533.u0JFXSxf037804@repo.freebsd.org> <CAFMmRNz3uXim3H3-sGuBUBs45Jy8p260ywothgp4iFkUcnvnEw@mail.gmail.com> <569E6A38.8080108@selasky.org> <CAFMmRNx3zC=mz=TC2Aq5==a5vh0Fqzv1domrCL2uUHnjybZSkQ@mail.gmail.com> <CAJ-Vmoki0yCU-mmPGfrGyJ_ar_=KKkto_ioomo_Ri_HCWR70cg@mail.gmail.com> <569E909B.60506@selasky.org> <CAJ-Vmo=1vTmKnoM=wVX=vv99mnkW-Q2CKkxZUNTUBkw_CU6ahQ@mail.gmail.com> <569E9B66.1070200@selasky.org> <CAJ-Vmo=vi5fdGzx6Z6%2BD5szrpf0jcaOe7a_9u-o0V7%2B9YkE6qw@mail.gmail.com> <569EA026.5020906@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 January 2016 at 12:44, Hans Petter Selasky <hps@selasky.org> wrote: > On 01/19/16 21:23, Adrian Chadd wrote: >> >> On 19 January 2016 at 12:24, Hans Petter Selasky <hps@selasky.org> wrote: >>> >>> On 01/19/16 21:05, Adrian Chadd wrote: >>>> >>>> >>>> Erm, ok. So I'm confused about the state of how the streams are >>>> tracked. So not all mbufs are in a stream, but they're in some single >>>> LRO mbuf list? >>>> >>> >>> Hi, >>> >>> The streams are typically tracked using the hardware generated Toeplitz >>> hash >>> value. The mbufs are sorted according to the hash value and the hash >>> type. >>> The list of mbufs is scanned, flushing the LRO entries every time we see >>> a >>> change in the hash value or hash type. OK? >> >> > > Hi, > >> Sure, but TCP fragments and non-fragments can hash to different >> values, so suddenly you get interleaved packets. > > > Fragmented TCP packets should not be subject to LRO. Depending on the NIC we > will get the same hash value or not. I think that's fine. If you want to use > this feature the NIC should not hash the TCP port numbers when it sees a > fragmented packet including the starting fragment. That will give the best > result. > > What does the RSS code expect currently? The NIC doesn't mis-tag something, so it knows to rehash things in the netisr input path. And yes, I've seen streams with both fragments and non-fragments at the same time. Then you end up with some packets with different hash types. The IP input path will reassemble fragments, and then you'll rehash the packet with the correct L3 or L4 calculation as appropriate. In this setup you may have the fragments show up at a different hash value to the non-fragments, so you'll handle all the non-fragments first, then the fragments show up later. So hopefully the LRO code handles seeing that hole in the TCP stream and will eject the whole stream up. >> You can't rely on the toeplitz hash 100% hashing /all packets in a >> stream/ reliably, because it's highly dependent upon the NIC config. > > >> This is why I did all that effort in the RSS code to handle things. > > --HPS > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokCLr7jESQqDYPRUgbo2vQD-1_kC6YhCjqAm3tMz29RUg>