On 01/19/16 21:23, Adrian Chadd wrote:
On 19 January 2016 at 12:24, Hans Petter Selasky <h...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
