05.01.2018 22:42, 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. >> It should be: >> >> hostA - SYN (ix0) -> hostB # Manual hash (1) calculated >> hostB - SYN,ACK (ix0) -> hostA# hardware flowid (2) received >> hostA - ACK (ix1) -> hostB # Manual hash (1) calculated >> hostA - Data(ix1) -> hostB # hardware flowid (2 or 3) received >> hostB - ACK (ix0) -> hostA # Manual hash (1) calculated
Hmm, yes, here I was mistaken. hostA - SYN (ix0) -> hostB # Manual hash (1) calculated hostB - SYN,ACK (ix0) -> hostA # hardware flowid (2) received hostA - ACK (ix1) -> hostB # Manual hash (1) calculated hostA - Data(ix1) -> hostB # Manual hash (1) calculated hostB - ACK (ix0) -> hostA # hardware flowid (2 or 3) received >> 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. > 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. _______________________________________________ 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"
