On Fri, Sep 23, 2016 at 10:43:20AM +0200, Thomas Monjalon wrote:

quoted

2016-09-23 12:26, Yuanhan Liu:

quoted

On Thu, Sep 22, 2016 at 06:43:55PM +0200, Thomas Monjalon wrote:

quoted

quoted

quoted

quoted

quoted

quoted

quoted

There could be a similar need in other PMD.
If we can get an opaque identifier of the device which is not

the port id,

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

we could call some specific functions of the driver not

implemented in

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

the generic ethdev API.

That means you have to add/export the PMD API first. Isn't it

against what

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

you are proposing -- "I think we should not add any API to the

PMDs" ;)

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Yes you are totally right :)
Except that in vhost case, we would not have any API in the

PMD.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

But it would allow to have some specific API in other PMDs for

the features

quoted

quoted

quoted

quoted

quoted

quoted

quoted

which do not fit in a generic API.

So, does that mean you are okay with this patch now? I mean,

okay to introduce

quoted

quoted

quoted

quoted

quoted

quoted

a vhost PMD API?

It means I would be in favor of introducing API in drivers for very

specific

quoted

quoted

quoted

quoted

quoted

features.
In this case, I am not sure that retrieving an internal id is very

specific.

quoted

quoted

quoted

quoted

It's not, instead, it's very generic. The "internal id" is actually the
public interface to vhost-user application, like "fd" to file APIs.

Instead of introducing a few specific wrappers/APIs, I'd prefer to
introduce a generic one to get the handle, and let the application to
call other vhost APIs.

Yes it makes sense.
I was thinking of introducing a function to get an internal id from

ethdev,

quoted

quoted

quoted

in order to use it with any driver or underlying library.
But it would be an opaque pointer and you need an int.
Note that we can cast an int into a pointer, so I am not sure what is

best.

quoted

quoted

Yes, that should work. But I just doubt what the "opaque pointer" could

be

quoted

quoted

for other PMD drivers, and what the application could do with it. For a
typical nic PMD driver, I can think of nothing is valuable to export to
user applications.

But maybe it's valuable to other virtual PMD drives as well, like the TAP
pmd from Keith?

If so, we may go that way.

I would like to have more opinions/votes before proceeding.

Sure, fair enough. There is no rush.

My hope would be have this, or at least some way to access rte_vhost_get_queue_num(vid) from the PMD in 16.11. We can't integrate the PMD into OVS until we achieve this. Is this likely at this stage given the uncertainty around the API?

Thanks,
Ciara

quoted

quoted

Another thought is that, it may be a bit weird to me to introduce an API
to get an opaque pointer. I mean, it's a bit hard to document it, because
it has different meaning for different drivers. Should we list all of
them then?

I think it can be documented in API using this handler how it can
be retrieved. In your case, the vhost lib can explain that the vid
is retrieved from the PMD with this generic ethdev function.

Okay.

	--yliu