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

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

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