On Thu, 10 Mar 2022 12:49:04 +0000 Kumara Parameshwaran <kparamesh...@vmware.com> 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.
