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:

> Was there any progress on this topic?
> Can we close the request?
> 	http://dpdk.org/patch/12222/

No update in almost a year is probably a bad sign.

>From the OVS side, we've dropped our patches due to too many corner
cases handling this - instead we're opting to use vhost-user client
mode, and punt the issue to the 'other' side.  Additionally, I do agree
with the criticism that providing this via an EAL command line option is
wrong. So, I think it can be safely dropped.

That said, if this is something that folks really want to solve, I think
the sanest way is to allow the application to pass in a
file-descriptor.  The way unix domain sockets permissions work changes
based on far too many factors to ever provide an API that makes sense,
unless we also bake in tests for various OSes (and possibly even flavors
of OSes).

Instead, I think DPDK should allow the application to open the unix
domain socket in whatever manner it chooses, doing whatever tricks are
required to set permissions or other flags the way it wants, and then
pass the file descriptor into the framework.  This would allow doing
sane things like fork()ing, changing current owner and umask, opening
the socket, and passing the descriptor back through a pipe (which works
on FreeBSD and Linux to set the permissions).  It allows the application
to be concerned with the file-system details, and lets DPDK merely worry
about the important thing: passing packet data.

> 2016-04-27 16:08, Yuanhan Liu:
>> On Tue, Apr 26, 2016 at 09:33:48AM -0400, Aaron Conole wrote:
>> > >> > 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?
>> 
>> Yes, I supposed so.
>> 
>> > > And for vhost PMD?
>> 
>> Technically, vhost PMD is an application (or precisely, an user) of
>> vhost lib. So, it's supposed to invoke the new API.
>> 
>> > What about devargs parameters?
>> 
>> Yes, and it then invoke the API, as stated above.
>> 
>> > 
>> > 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?
>> 
>> Oops, yes, that's another one. We also had some discussion before:
>> 
>>     http://dpdk.org/ml/archives/dev/2015-December/030326.html
>> 
>> It ended up with an agreement that we should let the application to
>> handle it, due to it's a path provided by the application, though
>> it's DPDK does the creation.
>> 
>> > 
>> > >> > 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.
>> 
>> Exactly. But DPDK, as a library, could provides some handy APIs to make
>> the application developer's life be less painful. So, that also echoes
>> to what we have said before: we provide the tool, you use it, and it's
>> you to make sure it's right.
>> 
>> 	--yliu
>> 
>> > 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