Re: [dpdk-stable] [PATCH] net/ena: TX L4 offloads should not be set in RX path

[Luca Boccassi <bluca@debian.org>]

On Fri, 2018-01-26 at 14:51 +0100, Rafał Kozik wrote:
> Hello,
> 
> I send this patch to stable list by mistake. I misunderstood git-send
> configuration.
> Currently this patch is under review on dpdk-dev list
> http://dpdk.org/ml/archives/dev/2018-January/089053.html.
> 
> I am very sorry about the trouble I caused, I assure you that it will
> never happen again.
> 
> Kind regards,
> Rafal Kozik

Don't worry, it's no trouble at all.
Given it applies to older releases as well, keep stable in the CC list
so that when it gets merged we can backport it.

> 2018-01-26 14:39 GMT+01:00 Luca Boccassi <bluca@debian.org>:
> > On Thu, 2018-01-25 at 16:12 +0100, Rafal Kozik wrote:
> > > Information about received packet type detected by NIC should be
> > > stored in packet_type field of rte_mbuf. TX L4 offload flags
> > > should
> > > not be set in RX path. Only fields that could be set in of_flags
> > > during packet receiving are information if L4 and L3 checksum is
> > > correct.
> > > 
> > > Fixes: 1173fca25af9 ("ena: add polling-mode driver")
> > > Cc: stable@dpdk.org
> > > 
> > > Reported-by: Matthew Smith <mgsmith@netgate.com>
> > > Signed-off-by: Rafal Kozik <rk@semihalf.com>
> > > ---
> > >  drivers/net/ena/ena_ethdev.c | 10 ++++++----
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/net/ena/ena_ethdev.c
> > > b/drivers/net/ena/ena_ethdev.c
> > > index 83e0ae2..1e2af80 100644
> > > --- a/drivers/net/ena/ena_ethdev.c
> > > +++ b/drivers/net/ena/ena_ethdev.c
> > > @@ -275,16 +275,17 @@ static inline void
> > > ena_rx_mbuf_prepare(struct
> > > rte_mbuf *mbuf,
> > >                                      struct ena_com_rx_ctx
> > > *ena_rx_ctx)
> > >  {
> > >       uint64_t ol_flags = 0;
> > > +     uint32_t packet_type = 0;
> > > 
> > >       if (ena_rx_ctx->l4_proto == ENA_ETH_IO_L4_PROTO_TCP)
> > > -             ol_flags |= PKT_TX_TCP_CKSUM;
> > > +             packet_type |= RTE_PTYPE_L4_TCP;
> > >       else if (ena_rx_ctx->l4_proto == ENA_ETH_IO_L4_PROTO_UDP)
> > > -             ol_flags |= PKT_TX_UDP_CKSUM;
> > > +             packet_type |= RTE_PTYPE_L4_UDP;
> > > 
> > >       if (ena_rx_ctx->l3_proto == ENA_ETH_IO_L3_PROTO_IPV4)
> > > -             ol_flags |= PKT_TX_IPV4;
> > > +             packet_type |= RTE_PTYPE_L3_IPV4;
> > >       else if (ena_rx_ctx->l3_proto == ENA_ETH_IO_L3_PROTO_IPV6)
> > > -             ol_flags |= PKT_TX_IPV6;
> > > +             packet_type |= RTE_PTYPE_L3_IPV6;
> > > 
> > >       if (unlikely(ena_rx_ctx->l4_csum_err))
> > >               ol_flags |= PKT_RX_L4_CKSUM_BAD;
> > > @@ -292,6 +293,7 @@ static inline void ena_rx_mbuf_prepare(struct
> > > rte_mbuf *mbuf,
> > >               ol_flags |= PKT_RX_IP_CKSUM_BAD;
> > > 
> > >       mbuf->ol_flags = ol_flags;
> > > +     mbuf->packet_type = packet_type;
> > >  }
> > > 
> > >  static inline void ena_tx_mbuf_prepare(struct rte_mbuf *mbuf,
> > 
> > Hi,
> > 
> > has a similar/related fix been applied to dpdk/master?
> > 
> > --
> > Kind regards,
> > Luca Boccassi

-- 
Kind regards,
Luca Boccassi