21/11/2019 13:40, Zhang, Qi Z: > From: Thomas Monjalon <tho...@monjalon.net> > > 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.;
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.
