From owner-svn-src-head@freebsd.org Fri Jan 5 02:01:35 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D499EA6326; Fri, 5 Jan 2018 02:01:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC4E26D44B; Fri, 5 Jan 2018 02:01:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w0521IDK033588 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Jan 2018 03:01:19 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: steven@multiplay.co.uk Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w05217c1035327 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jan 2018 09:01:07 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: svn commit: r327559 - in head: . sys/net To: Steven Hartland , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201801042005.w04K5liB049411@repo.freebsd.org> <5A4E9397.9000308@grosbein.net> From: Eugene Grosbein Message-ID: <5A4EDC62.50508@grosbein.net> Date: Fri, 5 Jan 2018 09:01:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 02:01:35 -0000 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. 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. 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.