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

[Adrian Chadd]

On 19 January 2016 at 12:44, Hans Petter Selasky <hps at selasky.org> wrote:
> 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?

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
>
>