From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 790D8A0542; Sun, 9 Oct 2022 19:41:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1A2E7400D5; Sun, 9 Oct 2022 19:41:55 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 49F9640042; Sun, 9 Oct 2022 19:41:53 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DD95332004ED; Sun, 9 Oct 2022 13:41:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 09 Oct 2022 13:41:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1665337311; x= 1665423711; bh=h4xSSqL1G0s7h/zK8EDg5uV+IbrzYQWl2KJu1g0s+Zk=; b=p w1JGKICIyTeFlMxZxShQktzAmOltH4cLa/ZbMM6UuXDipeAF3rhOvCEvyVAzJbhW GwHpE92slIEJ94hx3FGYsq7g6ZKF7ndhl6sp418qKODLvKCvizlSXstgzUKA/xWO z9kHKU6qcQkeR+j/Tl9b+dneRqVJ980y8uQpoq5r0BCsZZne31YVwyH6l9cRu/9V rZsEx0WwBu6sFkk+JXHKRcIXVA4Cqv42Z1mk4Cj4sVOa6/fMwHblCkDvYIiwbnlO 29M1llC9XqVQJT85mHkS3EFBTa5fTCVDSAYxzxcH7uFMonopPWtZPAhltBBWwMZm lrQ6AbdwCiFcYUZuepGpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1665337311; x= 1665423711; bh=h4xSSqL1G0s7h/zK8EDg5uV+IbrzYQWl2KJu1g0s+Zk=; b=W l7vS4TNj2fYkotDkAH44hrnxkZ3WdCuBA36DPe+WkudlZQ57vx98yteOMD/hAM9J GuNeHHKIOqfXr2jiONFTbWxY23yADVaRgYPegQlvL6M1dhAjuWBXUbaWxp1kbJnV NqBd3zFJ4QypRel79XZ/HjKpsBhPsYjdv3fCEDAsV7kEQE++1APhKFZGQjjY1wS1 EpFsuqBbIKtlysABZDxbPXyQUa4hZPag5ZaPs5G1S+RAtpxAIBmw9ntPkVNDKcxH XBCIkzdkoTE9Nj+0zvRMMFgWfRmTFJ9TPHlxwAA5MxnjuIFBSIhgCBgoSZgraadF z7eHs5+eF1OEVUESXW1OQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeejuddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 9 Oct 2022 13:41:50 -0400 (EDT) From: Thomas Monjalon To: Jun Qiu Cc: dev@dpdk.org, chas3@att.com, radu.nicolau@intel.com, stable@dpdk.org, "humin (Q)" Subject: Re: [PATCH 1/2] net/bonding: fix xmit l34 hash calculate for tcp Date: Sun, 09 Oct 2022 19:41:49 +0200 Message-ID: <2164244.ZfL8zNpBrT@thomas> In-Reply-To: <1151c8fa-d75f-7598-9fc9-80ded85fb5e6@huawei.com> References: <20220726061925.21073-1-jun.qiu@jaguarmicro.com> <1151c8fa-d75f-7598-9fc9-80ded85fb5e6@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > > In the following two cases, tcp_hdr + sizeof(*tcp_hdr) == pkt_end, > > and the TCP port is not taken into account in calculating the HASH > > value of TCP packets. TCP connections with the same source and > > destination IP addresses will be hashed to the same slave port, > > which may cause load imbalance. > > 1. TCP Pure ACK packets with no options, The header length is 20 > > and there is no data. > > 2. A TCP packet contains data, but the first seg of the mbuf > > contains only the header information (ETH, IP, TCP), and the > > data is in subsequent segs, which is usually the case in the > > indirect mbuf used for zero-copy. > > > > Fixes: 726158060d55 ("net/bonding: fix potential out of bounds read") > > Cc: stable@dpdk.org > > > > Signed-off-by: Jun Qiu > Acked-by: Min Hu (Connor) Applied, thanks.