06/12/2017 01:40, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > 05/12/2017 16:13, Ananyev, Konstantin:
> > > > Keep in mind that the owner can be an application thread. > > > > If you prefer using a single function pointer (may help for > > > > atomic implementation), we can allocate an owner structure containing > > > > a name as a string to identify the owner in human readable format. > > > > Then we just have to set the pointer of this struct to rte_eth_dev_data. > > > > > > Basically you'd like to have an ability to set something different then > > > pointer to rte_eth_dev_data as an owner, right? > > > > No, it can be a pointer, or an id, I don't care. > > My question was about a pointer to a specific struct: rte_eth_dev_data. > As I understand you want it to be a pointer to something else? > Probably to some new struct rte_eth_dev_owner or so... I have no strong opinion. The requirement is to identify owners with something unique, and to be able to print a pretty name. > > > I think this is possible too, just not sure it will useful. > > > > > > > > What I meant - this api to set/get ownership should be sort of > > > > > internal to ethdev layer. > > > > > Let say it would be used for failsafe/bonding (any other compound) > > > > > device that needs > > > > > to own/manage several low-level devices. > > > > > So in normal situation user wouldn't need to use that API directly at > > > > > all. > > > > > > > Again, the application may use this API to declare its ownership. > > > > > > Could you explain that a bit: what would mean 'application declares an > > > ownership on device'? > > > Does it mean that no other application will be allowed to do any control > > > op on that device > > > till application will clear its ownership? > > > I.E. make sure that at each moment only one particular thread can modify > > > device configuration? > > > Or would it be totally informal and second application will be free to > > > ignore it? > > > > It is an information. > > It will avoid a library taking ownership on a port controlled by the app. > > Ok, let's step back a bit. > As I can see there are 2 separate issues/design choices inside rte_ethdev :) > : > 1) control API is not MT safe - at any given moment 2 (or more) threads > (/processes) > can try to change config of a given device. > Right now we leave that sync effort to the upper layer. > 2) Even with the same thread 2 (or more) DPDK entities (high level PMD/third > party lib, etc.) > can try to manage the same device. > I.E. the device can be managed by bonding device, but application > mistakenly > can try to manage it on its own instead of relying on the bonding device > to do so. > Again right now we leave it up to the upper layer to keep track which > device is managed > by what DPDK entity. > > So what problem are you guys trying to solve with your patch? > Is it 1) or 2) below or might be something else? We try to solve 2) By solving 2), the issue 1) is slightly different: Thread safety with control API will become the responsibility of the DPDK entity (app or lib) which owns the port. Hope it is clear now, thanks for the brainstorming.
