Date: Fri, 5 Jan 2018 09:26:31 +0000 From: Steven Hartland <steven@multiplay.co.uk> To: Eugene Grosbein <eugen@grosbein.net>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327559 - in head: . sys/net Message-ID: <c42bfb9e-e583-aca3-bf0d-4d92c0153d2f@multiplay.co.uk> In-Reply-To: <5A4EDC62.50508@grosbein.net> References: <201801042005.w04K5liB049411@repo.freebsd.org> <5A4E9397.9000308@grosbein.net> <f133b587-1f7e-4594-31d1-974775ad55be@freebsd.org> <5A4EDC62.50508@grosbein.net>
index | next in thread | previous in thread | raw e-mail
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 Stevehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c42bfb9e-e583-aca3-bf0d-4d92c0153d2f>