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 2F363A0093; Thu, 10 Mar 2022 13:52:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1E4E04113F; Thu, 10 Mar 2022 13:52:31 +0100 (CET) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) by mails.dpdk.org (Postfix) with ESMTP id 64C624113E for ; Thu, 10 Mar 2022 13:52:29 +0100 (CET) Received: by mail-il1-f182.google.com with SMTP id l1so3657800ilv.3 for ; Thu, 10 Mar 2022 04:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=BS/adRoSVVX/sZACOfxXj5kdLVh5gnWIHVZD6HJs21s=; b=oq+617ZdbV1lFE1UIlMJipFIlmWYQcpl7qJ3XJbo7lvpBZwjpIyomwj62IQTv7Y8vg vAtc0wIwA+8Sh5Yu2VN2w16eGe2RZpDxML7vZr3IzOQVkpqUNNmpNHO81L2vnh1sifSl 4gwz0pHJxLVyAxwodZrcQPnCS9y/70J6RzaI4MA957K4Er169O5uhWHWEWpmCV7WbVWg 5RS2ckqi8abLEOoDYh+NnSNU7ZQM8ahL6dH3U3Ore8hmK/nPaQg7y17dlH4RG5URa8IC NDPONJOhMtbQXGYK4YIyI0xVhRiaf1l1FIvW0669NiCBaJI9kpppUicPWsw7cwi154FJ PWCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=BS/adRoSVVX/sZACOfxXj5kdLVh5gnWIHVZD6HJs21s=; b=iEDrBA22U98q5qmFNUQaGqJjju/aLGV65VQe03QMZtwnWQPrOyC+1k4c4uDYEL2GGI gMcrSeHVqfb+Asqn1bbhWZnQqXJrVEudjQgE4pGDn3v6OeIwDM6a/8I94wl0kNPvsAAO yc1S3QC7Os4l/n5aR5AWWkKpSqfL4PAOd9kvyw4Ua8fTgW70dpPdNKFcPgX040E13j8K +WlwhldzFUAS0X9suLmDJh7ntZPFWLmYxkXXcy/DqsBzfuETVG/L9/y/66yygYQ3+9av zuYxD8RgqcHRlHzHpRhSMAP4Ai1wipdRoAPouIRSJXc1w8C6sZDmzDPZyCbEYQ+1mGav PqXg== X-Gm-Message-State: AOAM533CS93M8zw6sN+DYmE7uarRUI49yIv3iZz0Raj4TCWX/NQ/Dy0P w9UD9+41yqz9mBj/az7E3KHIi+EuVzw0lpmH3uZLqvXeP96Q7w== X-Google-Smtp-Source: ABdhPJxLk0oP775qJ8gT4gTW7Q8xQHXkjlzN2HXyYg7cEZDTXXXauYJ7lrWavaCpDktoTVxsakkiANKUJu0xkkeVzcw= X-Received: by 2002:a92:c522:0:b0:2c6:3ddf:1b75 with SMTP id m2-20020a92c522000000b002c63ddf1b75mr3441333ili.293.1646916748580; Thu, 10 Mar 2022 04:52:28 -0800 (PST) MIME-Version: 1.0 From: kumaraparameshwaran rathinavel Date: Thu, 10 Mar 2022 18:22:17 +0530 Message-ID: Subject: UDP-GRO not working To: dev@dpdk.org Cc: jiayu.hu@intel.com, olivier.matz@6wind.com, kraghav@vmware.com Content-Type: multipart/alternative; boundary="000000000000c61ad305d9dcafb7" 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 --000000000000c61ad305d9dcafb7 Content-Type: text/plain; charset="UTF-8" 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 unable to interpret the packet type correctly. 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. --000000000000c61ad305d9dcafb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ,=C2=A0

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, t= here is the following check in gro_udp4.c=C2=A0
/*
* Don't process non-fragment = packet.
*/<= /div>
if (!is_ipv= 4_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 la= yer, rte_gro.c=C2=A0

The below are the definitions,=C2=A0<= /div>

#define RTE_PTY= PE_L4_TCP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A00x00000100
#define RTE_PTYPE_L4_UDP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000200
#define=C2=A0RTE_PTYPE_L4_FRAG=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00000300
Below is the check in GRO layer,=C2=A0

#define IS_IPV4_TCP_PKT(ptype) (RTE_ETH_I= S_IPV4_HDR(ptype) && \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ((ptype & RTE_PTYPE_L4= _TCP) =3D=3D RTE_PTYPE_L4_TCP) && \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (RTE_ETH_IS_TU= NNEL_PKT(ptype) =3D=3D 0))

#define IS_IPV4_UDP_PKT(ptype) (RTE_ETH_IS_I= PV4_HDR(ptype) && \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ((ptype & RTE_PTYPE_L4_UDP= ) =3D=3D RTE_PTYPE_L4_UDP) && \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (RTE_E= TH_IS_TUNNEL_PKT(ptype) =3D=3D 0))

So, for a fragmented U= DP packet both=C2=A0RT= E_PTYPE_L4_TCP &=C2=A0RTE_PTYPE_L4_UDP=C2=A0would be set and the GRO layer would be unable to interpret the packe= t type correctly.=C2=A0

I am using rte_net_get_ptype API b= efore 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 subsy= stem.=C2=A0

I would like to contribute a patch for this bu= g if this indeed is an issue, I was thinking if the GRO subsystem is L4 fra= gmented then in the GRO layer invoked the appropriate handler, either gro_t= cp4_reassemble or gro_ud4_reassemble.=C2=A0

Please let m= e know if I am missing something here.=C2=A0

Thanks,
Param.
--000000000000c61ad305d9dcafb7--