On Thu, Oct 21, 2021 at 1:04 PM Ilya Maximets <[email protected]> wrote: > >> So I assume the deprecated-declaration is required above because > >> rte_mp_disable() is experimental (if memory serves correct it triggers > >> deprecated) > >> > >> I'm surprised to see this is still experimental, if it was introduced in > >> 20.08 I would have expected it to have moved from this status. > >> > > > > It's not long compared to many :/ > > > > This will be done anyway in the register() fn, so iirc the idea on earlier > > reviews was just to make it explicit for the OVS user. If the API was > > removed in DPDK, I don't think it would impact OVS other than making it > > implicit. > > > >> Is there plans for this to become stable/non-experimental? > > > David, IIRC, you mentioned previously that these functions was introduced > for OVS and adoption in OVS is a prerequisite for them to become > non-experimental. > Is that right?
The consensus in DPDK is to wait for "some" releases before marking an API stable. We recently started to enforce a policy of automatic promotion to stable after two years without changes. Some maintainer are quicker to declare API stable and only wait one or two (minor) releases. For this API, I am judge and defendant in EAL. I could ask for promotion arguing that noone found issue with current API after more than a year. But having an external user is a better argument: the API is suitable for this user and can be frozen and maintained in its current form. This is why I insist on OVS adoption before considering marking stable. > If so, will the acceptance of this change to dpdk-latest branch be considered > enough for marking these functions non-experimental in DPDK? dpdk-latest sounds ok to me: getting patches in dpdk-latest branch means they would go to the master branch at some point (well, at the next bump of DPDK major version). I'll sell this on DPDK side as "OVS will use the API in a next release". I expect no objection on DPDK side based on this. > > If so, can it be done in 21.11 release assuming fast acceptance of this patch > in dpdk-latest (it's Acked, and testing, I guess, should be finished soon by > Ian)? The patch for DPDK is ready. I will send it and wait for acks. About timing, it will likely miss rc1 (originally due 10/15... current forecast is monday 10/25) unless I get quick feedback and acks. Merging it after rc1 is acceptable and not risky: this patch removes the warning at compilation time for external applications, and it versions symbols as stable 22.0 in shared EAL library. It won't change the API and won't affect DPDK validation effort (plus we don't care about ABI between rc). Of course, once DPDK marks this API stable, I'll follow up and post the necessary cleanup (removing #pragma) before pulling dpdk-latest to master and 2.17. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
