From owner-svn-src-all@freebsd.org Fri Jan 5 13:41:44 2018 Return-Path: Delivered-To: svn-src-all@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 6EE1FEA9F38; Fri, 5 Jan 2018 13:41:44 +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 D76F669870; Fri, 5 Jan 2018 13:41:43 +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 w05DfZ87038348 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Jan 2018 14:41:36 +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 w05DfWOK053856 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jan 2018 20:41:32 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: svn commit: r327559 - in head: . sys/net To: Steven Hartland , hiren panchasara References: <201801042005.w04K5liB049411@repo.freebsd.org> <5A4E9397.9000308@grosbein.net> <20180104224214.GD18879@strugglingcoder.info> <63c3c450-aeaf-bdd5-5e16-414146c9bb3a@multiplay.co.uk> <5A4EDE65.1010201@grosbein.net> <688c4d08-3dac-545f-1bed-b21270a03eca@multiplay.co.uk> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Eugene Grosbein Message-ID: <5A4F8088.2030700@grosbein.net> Date: Fri, 5 Jan 2018 20:41:28 +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: <688c4d08-3dac-545f-1bed-b21270a03eca@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 13:41:44 -0000 05.01.2018 16:34, Steven Hartland wrote: >>> I hope there's some improvements that can be made, for example if we can determine >>> the stream was instigated remotely then flowid would always be valid hence we can use it assuming it >>> matches the requested spec or if we can make it clear to the user that laggproto is not the one they requested, I'm open to ideas? >> We just need to clear flow id from incoming TCP segments and always generate new flow id for responses >> keeping old flow id for IP forwarding case. Please back out your change to not degrade IP forwarding performance. > Sorry I don't follow you. You seem to be inferring that we can easily generate a flowid without involving the sending hardware RSS has nothing to do with sending hardware. It's operating system's job to choose outgoing port, not hardware's job. > I can't see how that is possible as that's chicken and egg i.e. you can't get the HW interface > to generate the flowid without sending a packet and you can't send a packet > until you have a the flowid to decide which interface to send it from. Outgoing packet flow does not and should not depend on incoming flow, they are independent things in case of LACP. There is no "chicken and egg" problem at all.