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

[Steven Hartland]

On 05/01/2018 02:01, Eugene Grosbein wrote:
> 05.01.2018 4:52, Steven Hartland wrote:
>
>>> RSS by definition has meaning to received stream. What is "outbound" stream
>>> in this context, why can the hash calculatiom method change and what exactly
>>> does it mean "a stream being incorrectly split"?
>> Yes RSS is indeed a received stream but that is used by lagg for lacp and loadbalance protocols
>> to decide which port of the lagg to "send" the packet out of.
>> As the flowid is not known when a new "output" stream is instigated the current code
>> falls back to manual hash calculation to determine which port to send the initial packet from.
>> Once a response is received a tx then uses the flowid.
>> This change of hash calculation method can result in the initial packet being sent
>> from a different port than the rest of the stream; this is what I meant by "incorrectly split".
>>
>> See the following:
>> https://github.com/freebsd/freebsd/blob/master/sys/net/if_lagg.c#L2066
>> https://github.com/freebsd/freebsd/blob/master/sys/net/ieee8023ad_lacp.c#L846
> I still do not get what is "output stream" for you.
>
> If you are talking on forwarding (routing) transit packets at IP layer,
> they all have flowid from the beginning and first packet does not differ from others at all.
At the simplest level its a tcp stream that is started from the host. So 
given we have hostA (src) and hostB (dest), the output stream is one 
started by hostA with a destination of hostB where hostA is configured 
with lagg.

In this case with use_flowid we've confirmed we get the following (the 
interfaces used vary per flow of cause):
hostA - SYN (ix0)       -> hostB # Manual hash calculated
hostB - SYN,ACK (ix0)   -> hostA# flowid used
hostA - ACK (ix1)       -> hostB # flowid used
hostA - Data(ix1)       -> hostB # flowid used
hostB - ACK (ix0)       -> hostA # flowid used
...

Here hostA and hostB both had lagg0 comprising of ix0 and ix1.

I believe your referring to packets flowing through the physical 
interface, if so then this is too late as for LACP the flowid would need 
to be per-calculated for the first packet in order to make the decision 
on which port to send it on. Unless I'm missing something, this is a 
chicken and egg situation.

> If you are talking on locally originated (not transit) data streem from local TCP socket
> being sent in response to corresponding incoming TCP segments, then these outgoing
> packets should have their own fixed flow id by default in case of LACP
> and thhis flow id should not depend on (possibly ever changing) flow id of incoming TCP segments.
Nope in this case we have all the information needed, but I don't 
believe we can't tell that's the case.
> If you insist that flow id of outgoing packets does depend on ever changing incoming packet's flow id,
> then this is the bug that should be fixed and not lagg's defaults.
As detailed above once the session is established then the flowid 
remains fixed.

     Regards
     Steve