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 AFBC8A00C3; Mon, 15 Aug 2022 03:27:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 417654021D; Mon, 15 Aug 2022 03:27:29 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 351B3400EF; Mon, 15 Aug 2022 03:27:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660526848; x=1692062848; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sxMwZAgFew8tFN8RL6+rNCO7W4pHTbU6YU/2bQM5td8=; b=D2SsbVQsCBK2gAEjp/in71p7l7hYs8lGg41ubXIbO9ryhVr7lHR++bsY d1/knOxAYZs8xaAoWlBf7e+L8nj3dr1z9cm63CyHOHKhE3CdLB6O74Lmk Fw1AVP9QNPovBgcMechFEv0ICyxN1YB0NrY0yhEjHuJZGJptfbzJ5MPwk f8C36Jx0arsbRWiAdmiYv9PI9HZ4q2I9WBbRlKfwFahOEq0lJPpleideZ RuefTZwM+BEnocWKPDAVqUE99YBqb+bMyR6ludXXImsAof8k4vlD8CWUz rYkikxYMT+43ekPbtIFaMGkLsAS6y9l7ucEqMiP3Y8qpIOwFrZrdZ4amA g==; X-IronPort-AV: E=McAfee;i="6400,9594,10439"; a="289437958" X-IronPort-AV: E=Sophos;i="5.93,237,1654585200"; d="scan'208";a="289437958" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2022 18:27:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,237,1654585200"; d="scan'208";a="635307341" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orsmga008.jf.intel.com with ESMTP; 14 Aug 2022 18:27:26 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Sun, 14 Aug 2022 18:27:25 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Sun, 14 Aug 2022 18:27:25 -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; Sun, 14 Aug 2022 18:27:25 -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/BrggAEZDYCAGzNqMA== Date: Mon, 15 Aug 2022 01:27:25 +0000 Message-ID: References: <20220727080036.27263-1-jun.qiu@jaguarmicro.com> <483ed738105b4547b082d5149687da94@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.132] 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 > -----Original Message----- > From: Jun Qiu > Sent: Thursday, July 28, 2022 7:02 PM > To: Hu, Jiayu ; dev@dpdk.org > Cc: stable@dpdk.org > Subject: RE: [PATCH] gro: fix gro with ethernet tail padding bytes >=20 > I don't think the stack(software) cares if the length of a packet is less= than 60, > especially when receiving it. > In the linux kernel, if the packet length does not match the IP total-len= gth, > the packet is flushed to the stack instead of GRO. The previous GRO cache > packets are also flushed into the stack. >=20 > If you trim padding in merge_two_tcp4_packets(), then both "pkt_head" > and "pkt_tail" need to decide whether to trim or not, which can be a bit = tricky > to handle. OK. This patch is OK for me. Acked-by: Jiayu Hu Thanks, Jiayu >=20 >=20 > -----Original Message----- > From: Hu, Jiayu > Sent: Thursday, July 28, 2022 9:56 AM > To: Jun Qiu ; dev@dpdk.org > Cc: stable@dpdk.org > Subject: RE: [PATCH] gro: fix gro with ethernet tail padding bytes >=20 > Hi Jun, >=20 > > -----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 > > > > Exclude CRC fields, the minimum Ethernet packet length is 60 bytes. > > When the actual packet length is less than 60 bytes, padding is added t= o the > tail. > > 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 error > > 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. > > > > Fixes: 0d2cbe59b719 ("lib/gro: support TCP/IPv4") > > Cc: stable@dpdk.org > > > > Signed-off-by: Jun Qiu > > --- > > lib/gro/gro_tcp4.c | 7 ++++++- > > lib/gro/gro_udp4.c | 4 ++++ > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > > 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; > > > > struct tcp4_flow_key key; > > @@ -233,6 +233,11 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt, > > if (tcp_dl <=3D 0) > > return -1; > > > > + /* 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); >=20 > Good catch. >=20 > But there is a case needed to consider: > if the packet with padding doesn't merge with any other packets, its padd= ing > bytes are trimmed too. If upper layer functions check the minimal packet > length before check padding bytes in the packet, this change will cause t= hey > treat this packet as an illegal one. How does Linux kernel GRO handle pad= ding > packets? >=20 > 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 reassembl= ed > packets. For example, you can trim padding in merge_two_tcp4_packets(). >=20 > Thanks, > Jiayu >=20 > > + > > /* > > * 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; > > > > + /* 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