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 72D4DA00C3; Tue, 16 Aug 2022 03:21:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1A60440691; Tue, 16 Aug 2022 03:21:34 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 4705A4067C; Tue, 16 Aug 2022 03:21:31 +0200 (CEST) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4M6CtQ4x5tzXdY2; Tue, 16 Aug 2022 09:17:18 +0800 (CST) Received: from [10.78.23.197] (10.78.23.197) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 16 Aug 2022 09:21:29 +0800 Message-ID: <1151c8fa-d75f-7598-9fc9-80ded85fb5e6@huawei.com> Date: Tue, 16 Aug 2022 09:21:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: [PATCH 1/2] net/bonding: fix xmit l34 hash calculate for tcp To: Jun Qiu , CC: , , References: <20220726061925.21073-1-jun.qiu@jaguarmicro.com> From: "humin (Q)" In-Reply-To: <20220726061925.21073-1-jun.qiu@jaguarmicro.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.78.23.197] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected 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 Acked-by: Min Hu (Connor) 在 2022/7/26 14:19, Jun Qiu 写道: > 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 > --- > drivers/net/bonding/rte_eth_bond_pmd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c > index 73e6972035..3bf978e2df 100644 > --- a/drivers/net/bonding/rte_eth_bond_pmd.c > +++ b/drivers/net/bonding/rte_eth_bond_pmd.c > @@ -768,7 +768,7 @@ burst_xmit_l34_hash(struct rte_mbuf **buf, uint16_t nb_pkts, > ((char *)ipv4_hdr + > ip_hdr_offset); > if ((size_t)tcp_hdr + sizeof(*tcp_hdr) > - < pkt_end) > + <= pkt_end) > l4hash = HASH_L4_PORTS(tcp_hdr); > } else if (ipv4_hdr->next_proto_id == > IPPROTO_UDP) {