svn commit: r294327 - in head/sys: dev/cxgb dev/cxgbe dev/e1000 dev/hyperv/netvsc dev/ixgbe dev/mxge netinet sys

[Hans Petter Selasky]

On 01/19/16 21:23, Adrian Chadd wrote:
> On 19 January 2016 at 12:24, Hans Petter Selasky <hps at 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