Re: [dpdk-dev] [RFC] eal: provide option to set vhost_user socket owner/permissions

[Aaron Conole <aconole@redhat.com>]

Thomas Monjalon <thomas.monjalon@6wind.com> writes:

> 2016-04-25 21:16, Yuanhan Liu:
>> On Mon, Apr 25, 2016 at 11:18:16AM +0200, Christian Ehrhardt wrote:
>> > The API doesn't hold a way to specify a owner/permission set for vhost_user
>> > created sockets.
>> 
>> Yes, it's kind of like a known issue. So, thanks for bringing it, with
>> a solution, for dicussion (cc'ed more people).
> [...]
>> > But I'd be interested if DPDK in general would be interested in:
>> > a) an approach like this?
>> 
>> You were trying to add a vhost specific stuff as EAL command option,
>> which is something we might should try to avoid.
>
> Yes, -1
>
>> > b) would prefer a change of the API?
>> 
>> Adding a new option to the current register API might will not work well,
>> either. It gives you no ability to do a dynamic change later. I mean,
>> taking OVS as an example, OVS provides you the flexible ability to do all
>> kinds of configuration in a dynamic way, say number of rx queues. If we
>> do the permissions setup in the register time, there would be no way to
>> change it later, right?
>> 
>> So, I'm thinking that we may could add a new API for that? It then would
>> allow applications to change it at anytime.
>
> A vhost API in the library?
> And for vhost PMD? What about devargs parameters?

I don't know the most sane solution here, other than to echo the
sentiment that a new API for this is probably appropriate. Where that
API lives, and how it looks should be hashed out. For now, I'm working
on a solution in OVS because no such API or facility exists in DPDK.

Actually, there are a number of edge cases with vhost-user sockets. I
don't want to get into all of them, but since we're discussing the API a
bit here, I'd like to also bring up the following:

  What is the desired behavior w.r.t. file cleanup when the application
  crashes, restarts, and tells DPDK to use that file again (which hasn't
  been cleaned up due to the crash)?
  At present, the vhost-user code errors out. But how does the
  application correct the situation without deleting arbitrary files on
  the filesystem?

>> > c) consider it an issue of consuming projects and let them take care?
>> 
>> It's not exactly an issue of consuming projects; we created the socket
>> file after all.
>
> Yes

Just want to reiterate at present there is no solution, so projects will
invent their own. I can point to Ubuntu and Red Hat customer bugs which
require silly workarounds like "after you started a bunch of stuff, go
to the directory and run chmod/chown."

I'm actually not opposed to any solution that seems sane. If DPDK takes
the stance that the file is specified by the application, and therefore
"file management" activities (removal, permissions, ownership, etc.) are
the responsibility of the application, so be it. If the stance is that
DPDK owns the management of the file, so be that as well. I think the
first case is easier for the library maintainers (do nothing), the
second is easier for the applications (use these semantics).

If it really is the responsibility of DPDK, then I think the only sane
approach is an API for managing this. That may require an additional
library framework to link the vhost-user PMD and rte_ethdev facilities
so that a common API could be provided.

Just my $.02.

Thanks,
Aaron