Re: [RFC v3 2/2] ethdev: add API to set process to active or standby

[Thomas Monjalon <thomas@monjalon.net>]

26/12/2022 17:44, Ori Kam:
> From: Rongwei Liu <rongweil@nvidia.com>
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu wrote:
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu wrote:
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu wrote:
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu wrote:
> > > > > > > > > >
> > > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > > versions
> > > > > > > > >
> > > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > > support
> > > > > this?
> > > > > > > > >
> > > > > > > > There is a new member which was introduced into
> > > > > > > > rte_eth_dev_info but it
> > > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > > >
> > > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > > different ethdev structure and rte_flow structures across
> > > > > > > different DPDK
> > > > > ABI versions.
> > > > > > >
> > > > > > Besides this, there is no other ABI changes dependency.
> > > > > >
> > > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > > >
> > > > > OK. That's a relief. I understand the use case now.
> > > > >
> > > > > Why not simply use standard DPDK multiprocess model then.
> > > > > Primary process act as server for slow path API. Secondary process
> > > > > can come and go(aka can be updated at runtime) and use as client to
> > > > > update rules via primary-secondray communication mechanism.
> > > > >
> > > > Just image if process A and process B have ABI breakage like different
> > > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > > How can we quickly accommodate primary/secondary to be ABI
> > compatible
> > > across different versions?
> > > > It will be very huge effort and difficult to implement, at least in my
> > opinion.
> > > > What do you think?
> > >
> > > Yes. it difficult what ever approach we take, On other hand, ethdev
> > subsystem
> > > has other components like rte_tm and other offload etc, We can not simply
> > > have rte_eth_process_set_active() and things magical works across
> > different
> > > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > > another HW piece in NIC card for doing the metering but set by flow API.
> > > IMO, Customer can simply use standard multiprocess model if version are
> > > compatible without any special intelligence in application.
> > > Otherwise they can reload and start the application again or have special
> > > intelligence in application to cater the specific area of API they need to
> > > leverage based on server and client DPDK versions.
> > 
> > Thanks for the message.
> > IMO, we are trying to eliminate the version/ABI dependency with this new
> > added API.
> > For example, if meter action is in the flow rules:
> > 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> > 2. Process B starts with "rte_eth_process_set_active(false, flags)"
> > 
> > Just give Nvidia' hardware as example (other NIC vendors may not care if
> > group 0 or not)
> > If the process A' rules are in group 0, users should set them one by one to
> > process B.
> > Then either flush process A' rules or quit process A, then process B calls with
> > "rte_eth_process_set_active(true, flags)"
> > All is set.
> > It will avoid complex operations with client/server model and avoid user mis-
> > operation too.
> > We should avoid reload as much as possible since reloading is very time
> > consuming and may take up to few seconds.
> > In this time slot, there is no application to handle the traffic, and everything is
> > lost.
> > For end user especially cloud service providers, they are sensitive to the
> > traffic down time.
> 
> From my viewpoint the upgrade has nothing to do with DPDK as a library,
> the upgrade may be because of application upgrade.
> Unless I'm missing something, this API is not meant for API/ABI it is created
> to allow minimum downtime when doing upgrade of the application.
> Unless I'm missing something critical, since the upgrade in any case is not
> only for the DPDK but the entire app, there isn't any ABI/API issue.

Yes we can consider the case of an application upgrade with the same DPDK.
The patch needs to be reworded in this more realistic direction I think.
We can also improve the usage explanations.

That said, another high level question is about the scope of the feature.
In this patch, only ethdev is targetted.
Do you think we need the same migration mechanism in other classes
like vDPA, crypto, etc?