> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Thursday, November 21, 2019 3:37 PM
> To: Zhang, Qi Z <qi.z.zh...@intel.com>
> Cc: dev@dpdk.org; Ye, Xiaolong <xiaolong...@intel.com>; Yigit, Ferruh
> <ferruh.yi...@intel.com>; arybche...@solarflare.com; or...@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v4] net/ice: add flow mark hint support
>
> 21/11/2019 02:19, Zhang, Qi Z:
> > From: Thomas Monjalon <tho...@monjalon.net>
> > > 19/11/2019 07:14, Qi Zhang:
> > > > Since not all data paths support flow mark, the driver needs a
> > > > hint from application to select the correct data path if flow mark
> > > > is required. The patch introduces a devarg "flow-mark-support" as
> > > > a workaround solution, since a standard way is still ongoing.
> > > >
> > > > Signed-off-by: Qi Zhang <qi.z.zh...@intel.com>
> > > > Acked-by: Qiming Yang <qiming.y...@intel.com>
> > > > ---
> > > > +- ``Flow Mark Support`` (default ``0``)
> > > > +
> > > > + This is a hint to the driver to select the data path that
> > > > + supports flow mark extraction by default.
> > > > + NOTE: This is an experimental devarg, it will be removed when
> > > > + any of below conditions is ready.
> > > > + 1) all data paths support flow mark (currently vPMD does not)
> > > > + 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be
> > > > + introduced
> > > as a standard way to hint.
> > >
> > > When the data path is selected?
> >
> > dev_start
> >
> > > I suppose such decision should be done when starting the port, after
> > > everything is configured.
> > > So you can check if a rte_flow rule was added for mark action.
> > > Why the user needs to use an explicit option?
> >
> > A rte_flow with mark can be issued at any time after dev_start when it
> > is need, in that case, we have to reject the flow, this has been
> > complained a lot base on previous feedback by users, since
> > inconsistent behavior (sometimes mark works, some time it does not) is
> > not expected
>
> OK so you confirm the problem is only when a configuration is changed at
> runtime without stopping the port.
>
> > Also this option is overwhelmed by option 1 if we plan to do a clean fix in
> driver.
>
> You want the application (or the user) to announce in advance which
> configuration could be applied during the runtime.
> I think we should consider the problem for any runtime configuration.
> We never clearly defined which configuration is allowed at runtime.
>
> Which other configs may be setup at runtime? MTU? VLAN? mirroring?
> tunneling checksum? promiscuous? supported packet types? IEEE1588?
So far, in rte_eth API, we do dev_started check at dev_configure, queue_setup
(if runtime queue setup is not supported by PMD).
All other control path API is case by case depends on hardware capability.
Take i40e as an example; we have to stop the port when setting MTU because we
have to reconfigure the hardware queue context, which needs to stop queue that
impacts data path.
While for VLAN / promiscuous, since it is the case that a rule is added into
the on-chip memory, so no need to stop the data path.
Maybe it's a good idea to define a rule that which control path is allowed at
runtime, which should not be.
But at least I think it's not necessary to prevent users from doing flow
configure at runtime.;
>
