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