05/12/2017 16:13, Ananyev, Konstantin: > > Hi Thomas, > > > Hi, > > > I will give my view on locking and synchronization in a different email. > > Let's discuss about the API here. > > > 05/12/2017 12:12, Ananyev, Konstantin: > > >> From: Matan Azrad [mailto:ma...@mellanox.com] > >> > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com] > > > > > > If the goal is just to have an ability to recognize is that device is > > > > > managed by > > > > > another device (failsafe, bonding, etc.), then I think all we need is > > > > > a pointer > > > > > to rte_eth_dev_data of the owner (NULL would mean no owner). > > > > > > > > I think string is better than a pointer from the next reasons: > > > > 1. It is more human friendly than pointers for debug and printing. > > > > > > We can have a function that would take an owner pointer and produce nice > > > pretty formatted text explanation: "owned by fail-safe device at port X" > > > or so. > > > I don't think it is possible or convenient to have such function. > > Why do you think it is not possible?
Because of applications being the owner (discussion below). > > 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. > 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. > If it will be the second one - I personally don't see much point in it. > If it the first one - then simplest and most straightforward way would be - > introduce a mutex (either per device or just per whole rte_eth_dev[]) and > force > each control op to grab it at entrance release at exit. No, a mutex does not provide any information. > > And anwyway, it may be interesting from an application point of view > > to be able to list every devices and their internal owners. > > Yes sure application is free to call 'get' to retrieve information etc. > What I am saying for normal operation - application don't have to call that > API. > I.E. - we don't need to change testpmd, etc. apps because that API was > introduced. Yes the ports can stay without any owner if the application does not fill it.
