On Tue, Jan 12, 2021 at 5:24 PM Stokes, Ian <[email protected]> wrote: > > DPDK 20.08 introduced a new API that associates a non-EAL thread to a free > > lcore. This new API does not change the thread characteristics (like CPU > > affinity). > > Using this new API, there is no assumption on lcore X running on cpu X > > anymore which leaves OVS free from running its PMD thread on any cpu. > > Possibly just the wording above, " which leaves OVS free from running it's > PMD on any cpu". > I thought OVS was allowed to run its PMDs on any core anyway as long as they > were <= RTE_MAX_LCORE.
true, but with a '<' RTE_MAX_LCORE (which makes me realise my NEWS update must be fixed). > Does above mean free to run on any core greater than RTE_MAX_LCORE?. Yep. I'll reword. > > > The DPDK multiprocess feature is not compatible with this new API and is > > disabled. > > > > I think that's OK, I'm trying to think where this is a use case, since PDUMP > was removed I'm not aware of any other case. > I would assume we are still allowed to run another DPDK applications on the > same host as long as the --file-prefix was specified? Indeed. > > For example I've come across people testing with TESTPMD and virtio vdevs on > the same host as OVS DPDK in the past. > > Out of interest, did you give this patch a run with the OVS DPDK unit tests? At the time I posted this series, I had run it through "normal" unit tests, but I am not sure I checked the system-dpdk testsuite. I ran it now, hit issues unrelated to my patch and sent fixes. > > .RE > > . > > diff --git a/lib/dpdk.c b/lib/dpdk.c > > index 319540394b..defac3f7de 100644 > > --- a/lib/dpdk.c > > +++ b/lib/dpdk.c > > @@ -14,6 +14,10 @@ > > * limitations under the License. > > */ > > > > +#ifndef ALLOW_EXPERIMENTAL_API > > +#define ALLOW_EXPERIMENTAL_API > > +#endif > > + > > So a bit of a wider question, how does the community feel about allowing > experimental API into the code base? I reworked this with a #pragma trick (see v6) that makes it possible to select the experimental API we judge acceptable in OVS. > > What is the feeling with the API in DPDK, will there be further modification > to calls such as rte_mp_disable? There were none since introduction of the API. Besides, we are now considering the --in-memory flag for OVS, which implicitely disables MP. https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/#2733808 > > Will the experimental tag be removed in a future releases (e.g. 21.02). It could be marked stable based on OVS usage/feedback. No other opensource project uses this API which is (my) DPDK concern and the reason why it is still experimental atm. > > In the past we made an exception for the rte_meter library and experimental > API because it was replacing original rte_meter functionality OVS already > used and I think it was an honest oversight to remove the experimental tag > for the 19.11 release for those functions. The rte_meter episod served as an example. We now have the tools and guidance in DPDK to preserve an experimental alias if we need for rte_thread_register() and associates. https://doc.dpdk.org/guides/contributing/abi_policy.html?highlight=experimental#abi-changes > > But this could open up the door to accepting experimental APIs in other areas > of the OVS code base from DPDK also. > > I raised this at the conference in December, genuinely interested to hear > peoples thoughts? I don't think there is an absolute answer to this question. We can only judge case per case. In this specific case, we are in a chicken-egg situation. rte_thread_register() API was added for OVS in DPDK. But OVS won't consume it unless DPDK marks it stable. And DPDK expects feedback to mark stable. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
