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 41DE5A00C2; Fri, 11 Mar 2022 18:15:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2720E40140; Fri, 11 Mar 2022 18:15:46 +0100 (CET) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mails.dpdk.org (Postfix) with ESMTP id A291040042 for ; Fri, 11 Mar 2022 18:15:44 +0100 (CET) Received: by mail-pj1-f54.google.com with SMTP id 15-20020a17090a098f00b001bef0376d5cso8693697pjo.5 for ; Fri, 11 Mar 2022 09:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VgNb9uZL+OtW20oGkeA8pTCAKVhEK/OQf/QXyCrqM7E=; b=aNyfEAodhlvn4p01V/fqnwVz0PMwLB32BaNxhx6H6HURMuarHskbjoxBV+/p4xxczC TeSZDexXfqVYcfQmBTvqFMxvxvdIJK3pfxU+sdtkj2ofxJf50NV2OHK35W9bm64xsGzJ bI1NIAPGCTOl4OZXVjukbkSXMX9xpXykug65jP8dKCjDBNAW/04SHUBz8+R96gPHyOJD TgP3J4YMZERP7i6zY1n+k6E4EHCmzvCwJTpVBtpBmiO/mjX14nDRifAnYllSHM750snH 9LzzR0fEe4nPVT0oTGSCmjD/jAuhDvzrm8kA4H0EBEIMIWf3+ea8TXmeDrbOZQA6VOgE ZZnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VgNb9uZL+OtW20oGkeA8pTCAKVhEK/OQf/QXyCrqM7E=; b=GMzQUHTldP57fKM18YJA5Qv0d20KF/DJ07TFJc26ng/a1hUYeIRJSh0x0yRdDfb4xv dT0eQ6Zdgvx+vaK4mAcfZEgjvzm/YlgbCd5jBXGVorKKJt9XdatrGoxWhJSkb6po1bF6 RdICGz6WoOEss6CMxly1meJkf9naPgSs9hH5ccOotXlgjAKRPBq+2Y1aUV/nxqv44ASW PJ3vqhUe1MzIx5sp2hpKvvmaqsDLjwD5FQ2Tfykd8CLUN1gTQfnPFYiIvtzX9CnD3fkO W7QM9iQDmRZtggUaDrBCso619GSP6E2msSxFr85ukLrxUNUYeMneicH8Ye3TCRr2yuwN TJ0A== X-Gm-Message-State: AOAM531E4MPtrePonC+UemSft+CdKRF2vhyRbtfZlP2Skb/anbrpV9uj 6JfK+T3CRcqUrck32YJUGhsp7g== X-Google-Smtp-Source: ABdhPJwMt0GO+YIxGI/KYamN72BoyvkA7T4zaYPJy5D5BTf4Gt1vD+nok6kv3n+ivZnbOPyMsPfrTQ== X-Received: by 2002:a17:90a:67c3:b0:1bc:9cdf:1ee9 with SMTP id g3-20020a17090a67c300b001bc9cdf1ee9mr11764564pjm.203.1647018943833; Fri, 11 Mar 2022 09:15:43 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id d20-20020a056a0010d400b004f7093700c4sm11281292pfu.76.2022.03.11.09.15.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 09:15:43 -0800 (PST) Date: Fri, 11 Mar 2022 09:15:40 -0800 From: Stephen Hemminger To: Kumara Parameshwaran Cc: "dev@dpdk.org" , "jiayu.hu@intel.com" , "olivier.matz@6wind.com" , Ferruh Yigit , Raghav Kempanna Subject: Re: UDP-GRO not working Message-ID: <20220311091540.6d1b67aa@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Thu, 10 Mar 2022 12:49:04 +0000 Kumara Parameshwaran wrote: > 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) == RTE_PTYPE_L4_TCP) && \ > (RTE_ETH_IS_TUNNEL_PKT(ptype) == 0)) > > #define IS_IPV4_UDP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \ > ((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP) && \ > (RTE_ETH_IS_TUNNEL_PKT(ptype) == 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 not able to interpret the packet type right. > > 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. Are you using RSS, perhaps the fragmented packet is arriving on a different queue. Since fragments don't have UDP header, often the arrive on a default queue.