From owner-svn-src-all@freebsd.org Fri Jan 5 15:13:08 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 E5497EAE95A for ; Fri, 5 Jan 2018 15:13:08 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B8866D3E7 for ; Fri, 5 Jan 2018 15:13:08 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x22f.google.com with SMTP id b141so3041555wme.1 for ; Fri, 05 Jan 2018 07:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=yOuDU7y+SRs6ekJyJB2nYX/g6bESQQaAuP9v/3448dA=; b=Fb/KPxOeRd7BP0xOJJqfW25VG3DK1BGMLRvnjRk0ZunGXiAlkdJzZbkXdLso32mLUO FjKqIhttVCr4h2UV4l4J+wn0Hc52hK7iwlEJGVzlF0bq/KQsd2Ka7dP7HWdx7bifZy5O apIeBwSpTyJ86f9cc/BUubsM42kGgkOpfclbFXdsY9SgRgVGolNP26AMobyk7N8DBf2k 8IDx73DL4D17lmPXOI6Q7QJZ38e8g2WE+MrKDqdkclU6/YxSPa3TtpR1S7KSY6Skq99b TOF3mkTFVd0SUWDKX9xThBcsLDm4Nu+/WTSg71C39WQJShsRsjHfkAHtJzOzQPmT5/Jx FDcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yOuDU7y+SRs6ekJyJB2nYX/g6bESQQaAuP9v/3448dA=; b=ROFcuUv/mwKfajXjop92XBSpeIRkako6yav+ju1Le4fIgqjWNg4waApNVBWPDtomef 0T+YlsE1wpYw8dxOCdHuJyKfc+uLLlBPq+5cJNMvW1qqWAOg+5buGeX5lN2jZ3D1dBrR qfTwj2st4yLHWZ5VHX/fK0Q/Nj/l+k45HNrlXc87Qr7ZvZPdWc84f4B33IBW4ZttRNiZ ZmA/M2sjXXF6bB+ZwE0pC+k9KMgq6mxIxAG4Q7GUGUB7WqaIG9ahs5NtuefAxEa6IdhH O9b3qEdPKWzDdWpcvyLTUOI9vKnpexFOYypuANcZ+ijTqqD3l+xYun3K9k04EpNhKATv Wuxg== X-Gm-Message-State: AKGB3mJjmiU5Egx2KEmPVAdJWRa606OUYB7ndKL2vB3SlLg+9k3dmqaD Ku+swZf7v5s46q+aFqsaY7iSXw== X-Google-Smtp-Source: ACJfBovlw5Hk4BGm0gXTwP5rBCnCSyO//rGFhXYos+qMFAs0r47xJIhQNS25M055WYZa/w1zOqmoCA== X-Received: by 10.28.147.81 with SMTP id v78mr2378271wmd.118.1515165186266; Fri, 05 Jan 2018 07:13:06 -0800 (PST) Received: from [10.10.1.111] ([185.97.61.1]) by smtp.gmail.com with ESMTPSA id w133sm3764971wmg.9.2018.01.05.07.13.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 07:13:05 -0800 (PST) Subject: Re: svn commit: r327559 - in head: . sys/net To: Eugene Grosbein , hiren panchasara Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org 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> <5A4F8088.2030700@grosbein.net> From: Steven Hartland Message-ID: <89bfbd34-62c9-3c9f-308e-0053617e63ce@multiplay.co.uk> Date: Fri, 5 Jan 2018 15:13:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5A4F8088.2030700@grosbein.net> Content-Language: en-US Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 15:13:09 -0000 On 05/01/2018 13:41, Eugene Grosbein wrote: > 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. The OS is deciding which outgoing, however its using the hash based on the flowid to do so, which is only valid after the first rx hence the problem; as this results in the hash calculation being different for the first packet. > >> 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. > But this is how it works ATM, it uses the flowid which is only valid after the first rx.