Re: [PATCH v2] doc: announce transition to vDPA device name function

[Thomas Monjalon <thomas@monjalon.net>]

13/07/2022 15:26, David Marchand:
> On Tue, Jul 12, 2022 at 3:36 PM Thomas Monjalon <thomas@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.