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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"