Re: [dpdk-dev] [PATCH v4] net/ice: add flow mark hint support

[Thomas Monjalon <thomas@monjalon.net>]

21/11/2019 13:40, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 21/11/2019 02:19, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@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.zhang@intel.com>
> > > > > Acked-by: Qiming Yang <qiming.yang@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.;

Yes I agree.
Based on the list of allowed runtime config changes,
we could think about a global solution to allow datapath optimization
taking application needs into account.