[PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX descriptor

Zhang, Qi Z qi.z.zhang at intel.com
Sat May 7 09:03:32 CEST 2022



> -----Original Message-----
> From: Zhou, YidingX <yidingx.zhou at intel.com>
> Sent: Saturday, May 7, 2022 12:43 PM
> To: Zhang, Qi Z <qi.z.zhang at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>;
> Xing, Beilei <beilei.xing at intel.com>
> Cc: Yang, Qiming <qiming.yang at intel.com>; stable at dpdk.org; Yeleswarapu,
> Ramamani <ramamani.yeleswarapu at intel.com>
> Subject: RE: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX
> descriptor
> 
> 
> 
> > -----Original Message-----
> > From: Zhang, Qi Z <qi.z.zhang at intel.com>
> > Sent: Saturday, May 7, 2022 10:09 AM
> > To: Zhou, YidingX <yidingx.zhou at intel.com>; Wu, Jingjing
> > <jingjing.wu at intel.com>; Xing, Beilei <beilei.xing at intel.com>
> > Cc: Yang, Qiming <qiming.yang at intel.com>; stable at dpdk.org;
> > Yeleswarapu, Ramamani <ramamani.yeleswarapu at intel.com>
> > Subject: RE: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and
> > RX descriptor
> >
> >
> >
> > > -----Original Message-----
> > > From: Zhou, YidingX <yidingx.zhou at intel.com>
> > > Sent: Saturday, May 7, 2022 5:34 PM
> > > To: Wu, Jingjing <jingjing.wu at intel.com>; Xing, Beilei
> > > <beilei.xing at intel.com>
> > > Cc: Yang, Qiming <qiming.yang at intel.com>; Zhang, Qi Z
> > > <qi.z.zhang at intel.com>; stable at dpdk.org; Yeleswarapu, Ramamani
> > > <ramamani.yeleswarapu at intel.com>
> > > Subject: [PATCH] net/iavf: fix mismatch between rx_pkt_burst and RX
> > > descriptor
> > >
> > > Some kernel drivers return the capability
> > > VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC when
> > IAVF_RXDID_COMMS_OVS_1 is not
> > > supported. This causes PMD to use rx_pkt_burst that handles the Flex
> > > Receive Descriptor format, but actually configures the RXDID into
> > > IAVF_RXDID_LEGACY_1, then the fields of rte_mbuf Will be filled with
> > > wrong values in rx_pkt_burst, which will eventually lead to coredump.
> > >
> > > This patch fixes mismatch between rx_pkt_burst and rx descriptor.
> > >
> > > Fixes: 12b435bf8f2f ("net/iavf: support flex desc metadata
> > > extraction")
> > > Cc: stable at dpdk.org
> > >
> > > Signed-off-by: Yiding Zhou <yidingx.zhou at intel.com>
> > > ---
> > >  drivers/net/iavf/iavf_rxtx.c | 20 ++++++++++++++------
> > >  1 file changed, 14 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/net/iavf/iavf_rxtx.c
> > > b/drivers/net/iavf/iavf_rxtx.c index 345f6aeebc..69584264de 100644
> > > --- a/drivers/net/iavf/iavf_rxtx.c
> > > +++ b/drivers/net/iavf/iavf_rxtx.c
> > > @@ -2908,6 +2908,18 @@ iavf_set_rx_function(struct rte_eth_dev *dev)
> > > bool use_avx512 = false;  bool use_flex = false;
> > >
> > > +if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC)
> > > +use_flex = true;
> >
> > No need this check, we can init use_flex as true;
> >
> 
> I'm not sure if use_flex can be init as true. is it possible that vf->vf_res-
> >vf_cap_flags doesn't contain VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC?

I think the following loop will reset to false if any rxq->rxdid is legacy or any unsupported rxdid happen
Otherwise, it should always be true. 

> 
> > > +
> > > +for (i = 0; i < dev->data->nb_rx_queues; i++) { rxq =
> > > +dev->data->rx_queues[i]; if (rxq->rxdid <= IAVF_RXDID_LEGACY_1 ||
> > > +!(vf->supported_rxdid & BIT(rxq->rxdid))) {
> >
> > Check if rxq->rxdid is in supported list is not necessary, this has
> > been guaranteed when we set it.
> >
> 
> According to debugging, this is not guaranteed.
> rxq->rxdid is set to IAVF_RXDID_COMMS_OVS_1 by default when vf-
> >supported_rxdid == 6 (just contains IAVF_RXDID_LEGACY_1 and
> IAVF_RXDID_FLEX_NIC).

OK, you can keep this.

Btw, please send to dev at dpdk.org not stable at dpdk.org

> 
> > Also its better to print some warning message here,  if we saw some
> > rxq-
> > >rxdid is flex and some rxq->rxdid is legacy as we have to set
> > >rx_burst as
> > legacy for all , this is something not be expected by user
> >
> >
> Agreed, I will do this in v2. Thanks.
> 



More information about the stable mailing list