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 A2E75A00C4; Thu, 28 Jul 2022 03:55:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 49F2840E25; Thu, 28 Jul 2022 03:55:42 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 3751D40156; Thu, 28 Jul 2022 03:55:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658973341; x=1690509341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X8CnYeHpc0BDB4gJDXS1DYIhTQsyrpx5ggNL62GBafk=; b=DuU5ogN7j0i1oiFpQlCrwGjaqdRqEREdbOdT1nuDKsey38G6TtZ82ULl 0O7Hb5+jYD7tPzNeSPoesP/T/6Ijs38S3ck5H+hyxoYf2ITazjQwEPaXg hHZA6A9bTLVhi6qDtl8A22gpoIS1dholJPtx/Yn8QZPQu8dD3wSI13FOm 9fPZNkj3A4FwIBRvnCqeyhBRgokhrRuME+7pb31GYwDlMlq0MdnlUHZ1H NZ8P3fqfPFF7ANWnrQwNOG3LitNo50D2tOjbLw4zg0bs4IM/vNS1KbRAn bfLJaAo80QQ05buHsxAQ+yqB5DUtpEWNQSjnPbq8lJ1t0A9D5ZiBQhCVO Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10421"; a="287148653" X-IronPort-AV: E=Sophos;i="5.93,196,1654585200"; d="scan'208";a="287148653" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2022 18:55:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,196,1654585200"; d="scan'208";a="659467266" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga008.fm.intel.com with ESMTP; 27 Jul 2022 18:55:39 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Wed, 27 Jul 2022 18:55:38 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Wed, 27 Jul 2022 18:55:37 -0700 Received: from fmsmsx612.amr.corp.intel.com ([10.18.126.92]) by fmsmsx612.amr.corp.intel.com ([10.18.126.92]) with mapi id 15.01.2375.028; Wed, 27 Jul 2022 18:55:37 -0700 From: "Hu, Jiayu" To: Jun Qiu , "dev@dpdk.org" CC: "stable@dpdk.org" Subject: RE: [PATCH] gro: fix gro with ethernet tail padding bytes Thread-Topic: [PATCH] gro: fix gro with ethernet tail padding bytes Thread-Index: AQHYoY8SYol3RnSxok+v4Aa1oguZe62S/Brg Date: Thu, 28 Jul 2022 01:55:37 +0000 Message-ID: <483ed738105b4547b082d5149687da94@intel.com> References: <20220727080036.27263-1-jun.qiu@jaguarmicro.com> In-Reply-To: <20220727080036.27263-1-jun.qiu@jaguarmicro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.500.17 dlp-product: dlpe-windows x-originating-ip: [10.108.32.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 Hi Jun, > -----Original Message----- > From: Jun Qiu > Sent: Wednesday, July 27, 2022 4:01 PM > To: dev@dpdk.org > Cc: Hu, Jiayu ; stable@dpdk.org > Subject: [PATCH] gro: fix gro with ethernet tail padding bytes >=20 > Exclude CRC fields, the minimum Ethernet packet length is 60 bytes. When > the actual packet length is less than 60 bytes, padding is added to the t= ail. > When GRO is performed on a packet containing a padding field, mbuf- > >pkt_len is the one that contains the padding field, which leads to the e= rror > of thinking of the padding field as the actual content of the packet. > We need to trim away this extra padding field during GRO processing. >=20 > Fixes: 0d2cbe59b719 ("lib/gro: support TCP/IPv4") > Cc: stable@dpdk.org >=20 > Signed-off-by: Jun Qiu > --- > lib/gro/gro_tcp4.c | 7 ++++++- > lib/gro/gro_udp4.c | 4 ++++ > 2 files changed, 10 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/gro/gro_tcp4.c b/lib/gro/gro_tcp4.c index > 7849a2bd1d..0110db5748 100644 > --- a/lib/gro/gro_tcp4.c > +++ b/lib/gro/gro_tcp4.c > @@ -198,7 +198,7 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt, > struct rte_tcp_hdr *tcp_hdr; > uint32_t sent_seq; > int32_t tcp_dl; > - uint16_t ip_id, hdr_len, frag_off; > + uint16_t ip_id, hdr_len, frag_off, ip_tlen; > uint8_t is_atomic; >=20 > struct tcp4_flow_key key; > @@ -233,6 +233,11 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt, > if (tcp_dl <=3D 0) > return -1; >=20 > + /* trim the tail padding bytes */ > + ip_tlen =3D rte_be_to_cpu_16(ipv4_hdr->total_length); > + if (pkt->pkt_len > (uint32_t)(ip_tlen + pkt->l2_len)) > + rte_pktmbuf_trim(pkt, pkt->pkt_len - ip_tlen - pkt->l2_len); Good catch. But there is a case needed to consider: if the packet with padding doesn't merge with any other packets, its padding bytes are trimmed too. If upper layer functions check the minimal packet length before check padding bytes in the packet, this change will cause they treat this packet as an illegal one. How does Linux kernel GRO handle padding packets? Another choice is to trim the padding bytes when the packet merges with another one. In this case, GRO will only trim padding bytes for reassembled packets. For example, you can trim padding in merge_two_tcp4_packets(). Thanks, Jiayu > + > /* > * Save IPv4 ID for the packet whose DF bit is 0. For the packet > * whose DF bit is 1, IPv4 ID is ignored. > diff --git a/lib/gro/gro_udp4.c b/lib/gro/gro_udp4.c index > dd71135ada..839f9748b7 100644 > --- a/lib/gro/gro_udp4.c > +++ b/lib/gro/gro_udp4.c > @@ -231,6 +231,10 @@ gro_udp4_reassemble(struct rte_mbuf *pkt, > if (ip_dl <=3D pkt->l3_len) > return -1; >=20 > + /* trim the tail padding bytes */ > + if (pkt->pkt_len > (uint32_t)(ip_dl + pkt->l2_len)) > + rte_pktmbuf_trim(pkt, pkt->pkt_len - ip_dl - pkt->l2_len); > + > ip_dl -=3D pkt->l3_len; > ip_id =3D rte_be_to_cpu_16(ipv4_hdr->packet_id); > frag_offset =3D rte_be_to_cpu_16(ipv4_hdr->fragment_offset); > -- > 2.25.1