From owner-svn-src-head@freebsd.org Fri Jan 5 09:26: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 F3B8CEBFB2A for ; Fri, 5 Jan 2018 09:26:34 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 6980D7F806 for ; Fri, 5 Jan 2018 09:26:34 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x231.google.com with SMTP id c19so4497041lfg.3 for ; Fri, 05 Jan 2018 01:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=rmDe4Edit1j8FiZRrXvGO+jSiJqrtlXJI3/LUYwtXiY=; b=oSIcP7F8s+lJ97n0X2H3apIZmQif9tBqMzdAeHp7k8w9rodHCaEuFw+X+TG2eHnPn0 c+C8CzjBGJWzf0Tp89tLiJ7JYexXhGr+9p2/a0zbi2f66teIieeR3HXficj6qws38I5c 4KbqnxEfCe8L+2b1hk2xtrORAnynIOg6u4w9Bk3nexlB4lcvpJssjqFiQBw6BzkbGkcl uAzsj5/NO+EY3EpyQqQbX79PoUp4Kv/1hA4xW0OzZYqjGyjpGIngYA9YIjb+Y5iIa/38 RcdWYl8NWpBORJt2BI0+F0qrbCSuaIl8qeXkJBCFfsyH0ippig8+sXUhf6Decz+nCGEL Hy6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=rmDe4Edit1j8FiZRrXvGO+jSiJqrtlXJI3/LUYwtXiY=; b=gg47nbtMLERwkMBGzaofAt5NC/P6WzXatySyeDqQXG45lDJ9Bahs/Ui+HoE0dFN3vI NxW9BPF5xZMJbzQ9SFo5ggTuJoqJEsbk4v5BBQU2/6gEIlpn7T2xV4aJWPxdUselooxg 7701gB5wtkV30YVMh8sB9esWQr8HvMViMlt4poYp/oxqQA8phmf1xLsDCGbvVsG/MCZ5 M74QNK+G2BgA25OuNe6Rr5B0YdHlcIRgkgm3QaYT1rkwcX3/kYWQ1vQocLJIx3Bhx5cT bpf3dornnXCraQKYvaRrulEH+nt3a0s9bh7RPtFztcp64JesCx1bpoR8Vwy3T9FJkXi0 hx1Q== X-Gm-Message-State: AKGB3mKA7gjln3HBbTZUqmWc8cpJuDPsI98mW4lTnIcxlRQ2L4TFv6Xr Yx1LZsUUtjrWfvr3zST2T0oRfipsV7w= X-Google-Smtp-Source: ACJfBouABwWi7reGlvSMC8whSoiNrFr59WhvsQFuFwYKXQiAbZ6wwwe41ZaRFERckRlf8ftRQIgfQQ== X-Received: by 10.46.86.211 with SMTP id k80mr1402377lje.89.1515144392032; Fri, 05 Jan 2018 01:26:32 -0800 (PST) Received: from [10.10.1.111] ([185.97.61.1]) by smtp.gmail.com with ESMTPSA id f4sm948177lfl.17.2018.01.05.01.26.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 01:26:30 -0800 (PST) Subject: Re: svn commit: r327559 - in head: . sys/net To: Eugene Grosbein , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201801042005.w04K5liB049411@repo.freebsd.org> <5A4E9397.9000308@grosbein.net> <5A4EDC62.50508@grosbein.net> From: Steven Hartland Message-ID: Date: Fri, 5 Jan 2018 09:26:31 +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: <5A4EDC62.50508@grosbein.net> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 09:26:35 -0000 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     Steve