[dpdk-dev] [PATCH v3 7/7] app/testpmd: adjust ethdev port ownership

Matan Azrad matan at mellanox.com
Mon Jan 22 12:22:16 CET 2018


Hi Gaetan

From: Gaëtan Rivet, Monday, January 22, 2018 12:17 PM
> Hi Matan,
> 
> On Sat, Jan 20, 2018 at 06:14:13PM +0000, Matan Azrad wrote:
> 
> <snip>
> 
> > > > > > > > @@ -1394,7 +1394,7 @@ struct cmd_config_speed_all {
> > > > > > > >  			&link_speed) < 0)
> > > > > > > >  		return;
> > > > > > > >
> > > > > > > > -	RTE_ETH_FOREACH_DEV(pid) {
> > > > > > > > +	RTE_ETH_FOREACH_DEV_OWNED_BY(pid, my_owner.id) {
> > > > > > >
> > > > > > > Why do we need all these changes?
> > > > > > > As I understand you changed definition of
> > > > > > > RTE_ETH_FOREACH_DEV(), so no testpmd should work ok default
> (no_owner case).
> > > > > > > Am I missing something here?
> > > > > >
> > > > > > Now, After Gaetan suggestion RTE_ETH_FOREACH_DEV(pid) will
> > > > > > iterate
> > > > > over all valid and ownerless ports.
> 
> To be clear: you did not implement what I suggested, but your own
> interpretation of it. Please do not write as if I validated this interpretation.
> 
> Essentially, the NO_OWNER semantic is completely different from a default
> owner. A default owner would protect ports from race conditions and force
> port ownership requests to go through proper channels protected by critical
> sections.
> 

Please explain it more.
Do you want any created port will be owned by default owner(app)?
So, how can other DPDK entity to take control on a port? 

> NO_OWNER means that anyone is free to take any ownerless port at any
> time. And as a result, your are thus forced here to fix this by modifying an
> existing application for any entity using your ownership API to function with
> it.
>

Yes, I think is should be explicit!
Because hotplug is in the game and  a port can be created\released any time,
Any dpdk entity should know about its ports and own them.

> This is very different from what I suggested. What I said was that I wanted
> the most common case to be taken care of, and for existing applications to
> continue working. It entails having a more complicated API, but I think this is
> a price we should pay.
> 

So, please define what is the common case you are talking about.
And if you have an idea how to adjust port ownership to take care of it, I will be happy to hear.

> You are implementing the most common case in testpmd (the app entity
> creating an owner and putting its valid ports within). Your API should ease
> that up as much as possible before considering forcing everyone to work
> with it.

I don't think it is complicated.

>                            ~*~
> 
> You implemented a way for the failsafe to capture existing ports.
> How does it work without the channels for requesting ports suggested
> above?

If the port is without an owner, it will just take ownership of it and will manage it, else will try to take ownership in the next hotplug alarm. 

> 
> Regards,
> --
> Gaëtan Rivet
> 6WIND


More information about the dev mailing list