On Mon, Aug 01, 2016 at 08:24:40AM -0400, Aaron Conole wrote:
> Aaron Conole <acon...@redhat.com> writes:
> 
> > Currently, when using Open vSwitch with DPDK and qemu guests, the 
> > recommended
> > method for joining the guests is via the dpdkvhostuser interface. This
> > interface uses Unix Domain sockets to communicate. When these sockets are
> > created, they inherit the permissions and ownership from the vswitchd 
> > process.
> > This can lead to an undesirable state where the QEMU process cannot use the
> > socket file until manual intervention is performed (via `chown` and/or 
> > `chmod`
> > calls).
> >
> > This patchset gives the ability to set the permissions and ownership of all
> > dpdkvhostuser sockets from the database, avoiding the manual intervention
> > required to connect QEMU and OVS via DPDK.
> >
> > The first patch adds chmod and chown calls to lib, with unit tests. The
> > second patch hooks those calls into the netdev_dpdk_vhost_user_construct
> > function, after the socket is created.
> >
> > Changes from v2:
> > * Added a new 2nd patch to series for chmod/chown on already opened files.
> >   There exist known implementations for other systems, including FreeBSD, 
> > but
> >   only linux is implemented.  ENOTSUP is set when these calls fail on 
> > non-linux
> >   systems.
> 
> Ping.  I was hoping to have this applied before the 2.6 branch was cut;
> is that possible?

The code in patch 2, which goes through every fd in /proc to find the
socket it needs because DPDK will not tell it the fd and will not set
the needed permissions, is appalling.  It may be the biggest kluge I've
seen this year.

This would be slightly less appalling if it used fstat() and
getsockname() instead of /proc.  Still not great.

This definitely needs comments to explain why it exists and what it's
doing.

This could be properly fixed in DPDK by adding a 1-line helper function
that returns the fd for a vhost-user server.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to