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

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

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).

> I don't even think an API change would make that much sense.
> 
> Projects consuming DPDK start to do 'their own workarounds' like openvswitch
> https://patchwork.ozlabs.org/patch/559043/
> https://patchwork.ozlabs.org/patch/559045/
> But for this specific example they are blocked/stalled behind a bigger
> rework (https://patchwork.ozlabs.org/patch/604898/).
> Also one could ask why each project would need their own workaround.
> 
> At the same time - as I want it for existing code linking against DPDK I
> wanted to avoid changing API/ABI. That way I want to provide something existing
> users could utilize. So I created a DPDK EAL commandline option based ideas in
> the former patches.
> 
> For myself I consider this a nice interim solution for existing released
> Openvswitch+DPDK solution. And I intend to put it as delta into the DPDK 2.2
> currently packaged in Ubuntu to get it working more smoothly with
> openvswitch 2.5.
> 
> 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.

> 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.

> 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.

And I'd like to hear what others would say.

Thanks.

	--yliu