> > > > > > >
> > > > > > > Vector RX functions are not at feature parity with non-vector
> > > > > > > ones and
> > > > > > > currently the vector RX path is enabled by default. Hence, the
> > > > > > > only
> > > > > > > option to force selection of non-vector variants and be able to
> > > > > > > retain
> > > > > > > functionality is to disable vector PMD globally at compile time
> > > > > > > via the
> > > > > > > config file option.
> > > > > > >
> > > > > > > This patch introduces a new runtime device config option named
> > > > > > > disable-vec-rx to allow users to limit the driver to make a
> > > > > > > choice among
> > > > > > > non-vector RX functions, on a per device basis. This runtime
> > > > > > > option
> > > > > > > defaults to a value of zero, allowing vector RX functions to be
> > > > > > > selected (current behavior). When disable-vec-rx=1 is specified
> > > > > > > for a
> > > > > > > device, even if all the other requirements to select a vector RX
> > > > > > > function are satisfied, the driver will still pick one out of the
> > > > > > > appropriate non-vector RX functions.
> > > > > >
> > > > > > Not sure I understand the logic of that patch.
> > > > > > If i40e RX PMD selects wrong RX function that doesn't provide
> > > > > > requested by user functionality (which one?) -
> > > > > > then it is a bug in i40e RX function selection code that needs to
> > > > > > be fixed.
> > > > > > No point to introduce some new config options for that.
> > > > > > Konstantin
> > > > > >
> > > > > Current design of RX function selection for the PMDs make it an
> > > > > initialization time deal. However, the first rte_flow request (thus
> > > > > the need
> > > > > to enable FD / RTE_FDIR_MODE_PERFECT) may come in at any point in
> > > > > time, well after the RX function was selected (e.g., OVS does this
> > > > > when the
> > > > > first packet that can be offloaded arrives). The design in this patch
> > > > > gives
> > > > > such applications a choice to restrict possible RX functions to
> > > > > non-vector
> > > > > paths proactively.
> > > >
> > > > If you plan to use FD mode on your device, why not enable it
> > > > at setup phase via rte_eth_dev_configure()?
> > > > Then proper rx function would be selected.
> > > >
> > >
> > > FDIR_MODE was designed to bind late automatically -- it is set when the
> > > first
> > > filter rule is parsed, and unset when the last rule is removed.
> >
> > Why is that, if you can define it at configuration stage, and RX function
> > selection is based on it?
>
> I don't know why it was designed that way -- maybe maintainers know the
> historical context.
What I am trying to say - if particular feature (FD) enablement/disablement
affects RX/TX function selection, then there should be an ability to
enable/disable
that feature at configuration state (dev_config/queue_setup).
Function to change value of that feature at runtime (after
dev_start/queue_start)
should return an error if new value can't be supported with already selected
RX/TX
function.
If that's is not the case, then it sounds like a bug/gap in i40e driver that
needs to be fixed.
>
> >
> > > As there are likely
> > > other features not yet supported by the vector path, it felt more
> > > appropriate
> > > to have a generic flag for applications to not choose vector path.
> >
> > Once again - if some vector RX doesn't support particular requested at
> > config
> > feature, it wouldn't be selected. If it is not the case, then it is a bug in
> > rx function selection code and should be fixed, instead of introducing
> > workaround flags.
> >
>
> In any case, this has to be tied to a command line option, either on the
> application
> side (i.e. OVS)
> or DPDK devargs side, since we don't want to hard code it to limit
> RX functions to non-vector ones application-wide at compile time.
I am not forcing you to use hard-coded values, I am saying that we need to
follow standard API to enable/disable HW/PMD features.
If there is a problem in that API/implementation - we need to fix it,
not introduce some hackery workarounds (new devargs or so).
Obviously i40e RX function variations (vector/scalar/etc.)
are PMD specific details that user shouldn't know about.
Let say tomorrow someone can add support for FD into i40e vector-RX,
or completely new RX function will be introduced for i40e that will
void current selection logic.
Again i40e is not the only PMD that supports FD, so we need generic and well
defined way to enable/disable it.
>
> 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?
Konstantin
>
> > > In fact, the
> > > proposed option is the dual of already shipping use-latest-supported-vec
> > > flag that lets the apps do the opposite (i.e. choose the "most" vectorized
> > path).
> >
> > I don't think that's the same thing.
> > From my perspective 'use-latest-supported-vec' is to overcome HW
> > limitations.
> >
>
> That's fine, we seem to have different opinions on them. To me, both are
> runtime configuration options that let users select what RX functions they
> prefer to use with their HW.
>
> > In your case, as I can see, all you need is to declare to HW/PMD that you
> > plan
> > to use FD HW capabilities and proper RX function will be selected
> > automatically
> > (pretty much as with other HW offloads, TX cksum, RX multi-seg, etc.).
> >
>
> Offload configurations you mentioned can be passed on to DPDK from the
> application via offloads field in rte_eth_conf, FD cannot.
>
> >
> > >
> > > > >
> > > > > > >
> > > > > > > Signed-off-by: Mesut Ali Ergin <mesut.a.er...@intel.com>
> > > > > > > ---
> > > > > > > doc/guides/nics/i40e.rst | 14 +++++++++
> > > > > > > drivers/net/i40e/i40e_ethdev.c | 70
> > > > > > +++++++++++++++++++++++++++++++++++++++++-
> > > > > > > drivers/net/i40e/i40e_ethdev.h | 1 +
> > > > > > > drivers/net/i40e/i40e_rxtx.c | 4 +++
> > > > > > > 4 files changed, 88 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
> > > > > > > index a97484c..532cc64 100644
> > > > > > > --- a/doc/guides/nics/i40e.rst
> > > > > > > +++ b/doc/guides/nics/i40e.rst
> > > > > > > @@ -183,6 +183,20 @@ Runtime Config Options
> > > > > > >
> > > > > > > -w 84:00.0,use-latest-supported-vec=1
> > > > > > >
> > > > > > > +- ``Disable RX Vector Functions `` (default ``vector RX
> > > > > > > enabled``)
> > > > > > > +
> > > > > > > + When config file option for the vector PMD is enabled, vector
> > > > > > > RX
> > > > functions
> > > > > > may
> > > > > > > + be the default choice of the driver at device initialization
> > > > > > > time, if
> > certain
> > > > > > > + conditions apply. However, vector RX functions may not always
> > > > > > > be at
> > > > > > feature
> > > > > > > + parity with non-vector ones. In order to allow users to
> > > > > > > override
> > vector
> > > > RX
> > > > > > > + function selection behavior at runtime, the ``devargs``
> > > > > > > parameter
> > > > > > > + ``disable-vec-rx`` is introduced, such that
> > > > > > > +
> > > > > > > + -w DBDF,disable-vec-rx=1
> > > > > > > +
> > > > > > > + would force driver to limit its choices to non-vector RX
> > > > > > > function
> > variants
> > > > for
> > > > > > > + the device specified by the DBDF.
> > > > > > > +
> > > > > > > Vector RX Pre-conditions
> > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > For Vector RX it is assumed that the number of descriptor rings
> > > > > > > will be
> > a
> > > > power
> > > > > > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > > b/drivers/net/i40e/i40e_ethdev.c
> > > > > > > index cab440f..19fbd23 100644
> > > > > > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > > > > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > > > > > @@ -44,6 +44,7 @@
> > > > > > > #define ETH_I40E_SUPPORT_MULTI_DRIVER "support-multi-driver"
> > > > > > > #define ETH_I40E_QUEUE_NUM_PER_VF_ARG "queue-num-per-vf"
> > > > > > > #define ETH_I40E_USE_LATEST_VEC "use-latest-supported-vec"
> > > > > > > +#define ETH_I40E_DISABLE_VEC_RX "disable-vec-rx"
> > > > > > >
> > > > > > > #define I40E_CLEAR_PXE_WAIT_MS 200
> > > > > > >
> > > > > > > @@ -410,6 +411,7 @@ static const char *const valid_keys[] = {
> > > > > > > ETH_I40E_SUPPORT_MULTI_DRIVER,
> > > > > > > ETH_I40E_QUEUE_NUM_PER_VF_ARG,
> > > > > > > ETH_I40E_USE_LATEST_VEC,
> > > > > > > + ETH_I40E_DISABLE_VEC_RX,
> > > > > > > NULL};
> > > > > > >
> > > > > > > static const struct rte_pci_id pci_id_i40e_map[] = {
> > > > > > > @@ -1263,6 +1265,68 @@ i40e_use_latest_vec(struct rte_eth_dev
> > *dev)
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > +static int
> > > > > > > +i40e_parse_disable_vec_rx_handler(__rte_unused const char *key,
> > > > > > > + const char *value,
> > > > > > > + void *opaque)
> > > > > > > +{
> > > > > > > + struct i40e_adapter *ad;
> > > > > > > +
> > > > > > > + ad = (struct i40e_adapter *)opaque;
> > > > > > > +
> > > > > > > + switch (atoi(value)) {
> > > > > > > + case 0:
> > > > > > > + /* Selection of RX vector functions left untouched*/
> > > > > > > + break;
> > > > > > > + case 1:
> > > > > > > + /* Disable RX vector functions as requested*/
> > > > > > > + ad->rx_vec_allowed = false;
> > > > > > > + break;
> > > > > > > + default:
> > > > > > > + PMD_DRV_LOG(WARNING, "Value should be 0 or 1, set
> > it as
> > > > > > 1!");
> > > > > > > + break;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +int
> > > > > > > +i40e_disable_vec_rx(struct rte_eth_dev *dev)
> > > > > > > +{
> > > > > > > + struct i40e_adapter *ad =
> > > > > > > + I40E_DEV_PRIVATE_TO_ADAPTER(dev->data-
> > >dev_private);
> > > > > > > + struct rte_kvargs *kvlist;
> > > > > > > + int kvargs_count;
> > > > > > > +
> > > > > > > +
> > > > > > > + if (!dev->device->devargs)
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + kvlist = rte_kvargs_parse(dev->device->devargs->args,
> > valid_keys);
> > > > > > > + if (!kvlist)
> > > > > > > + return -EINVAL;
> > > > > > > +
> > > > > > > + kvargs_count = rte_kvargs_count(kvlist,
> > ETH_I40E_DISABLE_VEC_RX);
> > > > > > > + if (!kvargs_count) {
> > > > > > > + rte_kvargs_free(kvlist);
> > > > > > > + return 0;
> > > > > > > + }
> > > > > > > +
> > > > > > > + if (kvargs_count > 1)
> > > > > > > + PMD_DRV_LOG(WARNING, "More than one argument
> > \"%s\"
> > > > > > and only "
> > > > > > > + "the first invalid or last valid one is
> > > > > > > used !",
> > > > > > > + ETH_I40E_DISABLE_VEC_RX);
> > > > > > > +
> > > > > > > + if (rte_kvargs_process(kvlist, ETH_I40E_DISABLE_VEC_RX,
> > > > > > > + i40e_parse_disable_vec_rx_handler,
> > ad) < 0) {
> > > > > > > + rte_kvargs_free(kvlist);
> > > > > > > + return -EINVAL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + rte_kvargs_free(kvlist);
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > #define I40E_ALARM_INTERVAL 50000 /* us */
> > > > > > >
> > > > > > > static int
> > > > > > > @@ -1795,6 +1859,9 @@ i40e_dev_configure(struct rte_eth_dev
> > *dev)
> > > > > > > ad->tx_simple_allowed = true;
> > > > > > > ad->tx_vec_allowed = true;
> > > > > > >
> > > > > > > + /* Check if users wanted to disable vector RX functions */
> > > > > > > + i40e_disable_vec_rx(dev);
> > > > > > > +
> > > > > > > /* Only legacy filter API needs the following fdir config. So
> > when the
> > > > > > > * legacy filter API is deprecated, the following codes should
> > also be
> > > > > > > * removed.
> > > > > > > @@ -12790,4 +12857,5 @@
> > > > RTE_PMD_REGISTER_PARAM_STRING(net_i40e,
> > > > > > > ETH_I40E_FLOATING_VEB_LIST_ARG
> > "=<string>"
> > > > > > > ETH_I40E_QUEUE_NUM_PER_VF_ARG
> > > > > > "=1|2|4|8|16"
> > > > > > > ETH_I40E_SUPPORT_MULTI_DRIVER "=1"
> > > > > > > - ETH_I40E_USE_LATEST_VEC "=0|1");
> > > > > > > + ETH_I40E_USE_LATEST_VEC "=0|1"
> > > > > > > + ETH_I40E_DISABLE_VEC_RX "=0|1");
> > > > > > > diff --git a/drivers/net/i40e/i40e_ethdev.h
> > > > b/drivers/net/i40e/i40e_ethdev.h
> > > > > > > index 9855038..906bfe9 100644
> > > > > > > --- a/drivers/net/i40e/i40e_ethdev.h
> > > > > > > +++ b/drivers/net/i40e/i40e_ethdev.h
> > > > > > > @@ -1248,6 +1248,7 @@ int i40e_config_rss_filter(struct i40e_pf
> > > > > > > *pf,
> > > > > > > struct i40e_rte_flow_rss_conf *conf, bool add);
> > > > > > > int i40e_vf_representor_init(struct rte_eth_dev *ethdev, void
> > > > *init_params);
> > > > > > > int i40e_vf_representor_uninit(struct rte_eth_dev *ethdev);
> > > > > > > +int i40e_disable_vec_rx(struct rte_eth_dev *dev);
> > > > > > >
> > > > > > > #define I40E_DEV_TO_PCI(eth_dev) \
> > > > > > > RTE_DEV_TO_PCI((eth_dev)->device)
> > > > > > > diff --git a/drivers/net/i40e/i40e_rxtx.c
> > > > > > > b/drivers/net/i40e/i40e_rxtx.c
> > > > > > > index 1489552..7e66f59 100644
> > > > > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > > > > @@ -1736,6 +1736,10 @@ i40e_dev_rx_queue_setup_runtime(struct
> > > > > > rte_eth_dev *dev,
> > > > > > > */
> > > > > > > ad->rx_bulk_alloc_allowed = true;
> > > > > > > ad->rx_vec_allowed = true;
> > > > > > > +
> > > > > > > + /* Check if users wanted to disable vector RX functions
> > */
> > > > > > > + i40e_disable_vec_rx(dev);
> > > > > > > +
> > > > > > > dev->data->scattered_rx = use_scattered_rx;
> > > > > > > if (use_def_burst_func)
> > > > > > > ad->rx_bulk_alloc_allowed = false;
> > > > > > > --
> > > > > > > 2.7.4
