Thanks, great that you added more on CC for a wider discussion - I think that is the only right way to go.
Just to "defend" a bit - solution a) was created under the special circumstance that I wanted a workaround that would work today. But that is/was special to what I package with DPDK 2.2 + OVS 2.5 as of today - and therefore was the right place for a fast interim fix for me. I totally agree that the A in EAL was meant for abstraction and we might want to avoid vhost specific things in there that in the long run. I like your suggestion of a new API as a proper long term solution, but I don't feel deeply enough involved yet on the API level to give it any judgement. So I look forward for more opinions on it. P.S. the patch bot hit me hard with 2 pages of space/bracket issues, sorry for that - but it was only meant as RFC after all :-) Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Tue, Apr 26, 2016 at 6:16 AM, Yuanhan Liu <yuanhan.liu at linux.intel.com> wrote: > 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 >