Re: [dpdk-dev] [PATCH 2/3] net/i40e: add runtime option to disable vector rx

["Zhang, Qi Z" <qi.z.zhang@intel.com>]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, May 22, 2019 10:05 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Ergin, Mesut A <mesut.a.ergin@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org;
> Yigit, Ferruh <ferruh.yigit@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Subject: Re: [dpdk-dev] [PATCH 2/3] net/i40e: add runtime option to disable
> vector rx
> 
> Hi,
> 
> 22/05/2019 13:01, Ananyev, Konstantin:
> > > As far as I can see, passing FDIR configuration via the rte_eth_conf struct:
> > >    struct rte_fdir_conf fdir_conf; /**< FDIR configuration.
> > > DEPRECATED */ was deprecated. I suspect in favor of the late binding
> > > design mentioned, but again, I don't know the history on that. IMO, this
> made devargs a better choice.
> >
> > Ok, then it looks like there is a flaw in ethdev level API that needs to be fixed:
> > We deprecated old way to request FD usage without introducing new one.
> > CC-ing to ethdev maintainers -
> > Guys is there a new way to request FD enablement, instead of deprecated
> fdir_config?
> > Seems like not, unless I missed something obvious.
> > If not, then we probably need either to re-deprecate fdir_config, or introduce
> some new method.
> > My first thought would be to add new  DEV_RX_OFFLOAD_* flag(s).
> > Does it make sense?
> 
> Sorry,I have not read the full thread so I may be out of topic.
> Please be aware that the flow director API is deprecated in favor of the more
> generic rte_flow API.
> 

What we need is a software mark when a flow is hit, it is stored in mbuf->fdir (there is another discussion to change the name "fdir" to a more generic one)
For intel driver, vector rx Path does not support software mark, so currently we use rte_eth_conf-> rte_fdir_conf->mode to prevent vector path be selected when fdir is required.
actually this is not make very sense, vector path is only necessary to be disabled when software mark is required, but not for general fdir
Now since it will be removed, it's a good chance to improve this, a new offload flag such as DEV_RX_OFFLOAD_FLOW_MARK looks like what we needed..

Regards
Qi