Date: Tue, 19 Jan 2016 21:44:22 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Adrian Chadd <adrian.chadd@gmail.com> 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: <569EA026.5020906@selasky.org> In-Reply-To: <CAJ-Vmo=vi5fdGzx6Z6%2BD5szrpf0jcaOe7a_9u-o0V7%2B9YkE6qw@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > > 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?569EA026.5020906>