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 416DFA00BE; Thu, 9 Jun 2022 17:24:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E1C0C40689; Thu, 9 Jun 2022 17:24:28 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 8514240220 for ; Thu, 9 Jun 2022 17:24:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654788267; x=1686324267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hVXdMB2y3U9l2WtwJ7azzDA0TRfiVXWVOcpyME4M70U=; b=JKnpM5Z1GnPoaqxq0n6XM8SnWTubF0PnRZ3PcPYusZbjhVqVXeXU4VLu 7f4XjWSCIhfbbn4W8EEky/NnPrD4e7/5/j5UHuob0NIDFeBmMMlExE3Rw Kn+rU9P4FdXOgTIT0vmib/vhjEHcvSts+zB1TCNadf6+jeozsBlz+2FHq PDf1jbWSh9HhsOfn8dpxKLJY6jAa0jaVrSwiMd7HXHAzShZkYpiSyQD71 5SH3PynRBEUA0KcjMAmbeExP0KlIWiWld39+f0HFbFh+DaTYMk1UqVP3W Outd+N4/ZcS3N6r70aPagabyy2JkF+5+1R86IRge99mLaU/2IVteQttfA w==; X-IronPort-AV: E=McAfee;i="6400,9594,10373"; a="274840546" X-IronPort-AV: E=Sophos;i="5.91,287,1647327600"; d="scan'208";a="274840546" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2022 08:24:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,287,1647327600"; d="scan'208";a="610299452" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga008.jf.intel.com with ESMTP; 09 Jun 2022 08:24:26 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Thu, 9 Jun 2022 08:24:25 -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.2308.27; Thu, 9 Jun 2022 08:24: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.2308.027; Thu, 9 Jun 2022 08:24:25 -0700 From: "Hu, Jiayu" To: kumaraparameshwaran rathinavel CC: "dev@dpdk.org" , "olivier.matz@6wind.com" , "kraghav@vmware.com" , "Thomas Monjalon" Subject: RE: UDP-GRO not working Thread-Topic: UDP-GRO not working Thread-Index: AQHYe9iNH6GnlO334UWl32Vb3dSCUq1HLPPA Date: Thu, 9 Jun 2022 15:24:24 +0000 Message-ID: <90e9292b309949ddbc23b3281673ef6d@intel.com> References: <13031173.dW097sEU6C@thomas> In-Reply-To: <13031173.dW097sEU6C@thomas> 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.239.127.36] 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 Param, > -----Original Message----- > From: Thomas Monjalon > Sent: Thursday, June 9, 2022 4:11 PM > To: Hu, Jiayu > Cc: dev@dpdk.org; olivier.matz@6wind.com; kraghav@vmware.com; > kumaraparameshwaran rathinavel > Subject: Re: UDP-GRO not working >=20 > Jiayu, please could you comment the explanation below? >=20 >=20 > 10/03/2022 13:52, kumaraparameshwaran rathinavel: > > Hi , > > > > I tried using the UDP GRO feature in DPDK recently and it did not see > > working. I understand the GRO for UDP is applicable only for > > fragmented packets, there is the following check in gro_udp4.c > > /* > > * Don't process non-fragment packet. > > */ > > if (!is_ipv4_fragment(ipv4_hdr)) > > return -1; > > > > > > There looks to be some conflict in the definition of RTE_PTYPE in > > rte_mbuf_ptype.h and the usage of this in GRO layer, rte_gro.c > > > > The below are the definitions, > > > > #define RTE_PTYPE_L4_TCP 0x00000100 > > #define RTE_PTYPE_L4_UDP 0x00000200 > > #define RTE_PTYPE_L4_FRAG 0x00000300 > > > > Below is the check in GRO layer, > > > > #define IS_IPV4_TCP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \ > > ((ptype & RTE_PTYPE_L4_TCP) =3D=3D RTE_PTYPE_L4_TCP) && \ > > (RTE_ETH_IS_TUNNEL_PKT(ptype) =3D=3D 0)) > > > > #define IS_IPV4_UDP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \ > > ((ptype & RTE_PTYPE_L4_UDP) =3D=3D RTE_PTYPE_L4_UDP) && \ > > (RTE_ETH_IS_TUNNEL_PKT(ptype) =3D=3D 0)) > > > > So, for a fragmented UDP packet both RTE_PTYPE_L4_TCP & > > RTE_PTYPE_L4_UDP would be set and the GRO layer would be unable to > > interpret the packet type correctly. Yes, it's an issue. IS_IPV4_TCP_PKT will recognize a UDP/IPv4 fragment as a= TCP/IPv4 packet, and the packet will not go into any UDP based gro function. Thanks = for pointing that out. Thanks, Jiayu > > > > I am using rte_net_get_ptype API before the packet is being sent to > > the GRO subsystem as the DPDK PMD for the NIC I am using would not set > > the packet types as required by the GRO subsystem. > > > > I would like to contribute a patch for this bug if this indeed is an > > issue, I was thinking if the GRO subsystem is L4 fragmented then in > > the GRO layer invoked the appropriate handler, either > > gro_tcp4_reassemble or gro_ud4_reassemble. > > > > Please let me know if I am missing something here. > > > > Thanks, > > Param. > > >=20 >=20 >=20 >=20