13/07/2022 15:26, David Marchand: > On Tue, Jul 12, 2022 at 3:36 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > > > There is a layer violation in the vDPA API for getting the device name. > > Instead of providing the name at vDPA level, > > a function returns the low-level device object. > > Exposing a rte_device (as an opaque pointer) in upper device classes > seems a good thing to me. > With the API rework I proposed, we will have accessors to get this > object characteristics (like here, a name identifying it). > Having the vDPA API returns a pointer to a rte_device object makes it > possible to reuse those accessors, nothing more needed. > > If the rte_device object is extended in any (unforeseen at the moment) > way in the future, it would still be a matter of using the relevant > accessor. > No update needed in the vDPA API at this point in the future. > > > On the other hand, what you propose here seems to go the other way. > With each device classes needing to expose, through its own means / > API, the underlying rte_device characteristics.
I realize we don't have a guideline about this API aspect: should we expose underlying handles? I understand your point and I think it is valid. I suggest cancelling this deprecation for now. Once we have a guideline agreed in doc/guides/contributing/design.rst we can revisit some API. For instance, I've avoided to expose rte_device in gpudev, and the NUMA socket is directly reported in gpudev infos. Another approach would be to expose the pointer to rte_device.
