svn commit: r327559 - in head: . sys/net

[Steven Hartland]

On 05/01/2018 17:16, Eugene Grosbein wrote:
>
>>> That is, there is no guarantee of persistance of flowid of incoming packets
>>> as they can be received with distinct ports of lagg being distinct hardware
>>> computing flowid differently. Some ports may not support RSS at all.
>>> We should not use incoming hardware flowid for anything by default in case of TCP.
>> I don't believe your statement about persistence of flowid due to the use of variant ports is correct
>> as LACP states that packets from the same flow "should" under normal conditions (no failure) be received on the same port.
> It still does not guarantee that and you miss opportunity of network failures that can easily change flowid of incoming packets.
Correct, but that's not the normal behavior so the chances of seeing any 
impact of out of order packets is very small.
>
>> In the case where the HW doesn't support RSS, then flowid should either always be unset or be set by OS to consistent value hence that should function as expected.
>>
>> That said I don't disagree that all hostA -> hostB should use Manual hash, as I can't see anyway to use to HW hash,
>> however the ports in your example are wrong
> Yes, I stand corrected (just copied your example and adjusted it incompletly).
>
>>> Why do you mix flowid of incoming stream with flowid of outgoing stream?
>>>
>> I expect this was done so we don't have the overhead of calculating a packet hash for every outgoing packet
>> i.e. its an optimization, however I believe this is only possible for the destination host which always
>> has a valid flowid, and not for the source host.
> How do you know that flowid of incoming packet is preserved on outgoing path? It should not.
https://github.com/freebsd/freebsd/blob/master/sys/netinet/ip_output.c#L234

     Regards
     Steve