On Thu, Aug 11, 2016 at 01:00:21PM -0400, Aaron Conole wrote:
> Ben Pfaff <b...@ovn.org> writes:
> > Neither of those is a simple "return server->listen_fd;" function. Any
> > chance that would be accepted? It would solve the problem just fine.
>
> I don't know, but I'll outline my plans, and if you agree, then I'll
> put them into action.
>
> First, I'll drop patch 2/3.
>
> Second, I'll take your suggestion below, and implement it in the
> netdev-dpdk area (as part of "patch 3/3", which will become 2/2).
>
> I'll submit the above by mid-day Friday, tested.
>
> Third, I'll cook up the DPDK server socket fd patch, and try to get that
> part of a future DPDK release. If accepted, then when OvS ports to that
> release, I will submit a patch removing your suggestion, and using the
> file descriptor instead (or whatever becomes of it).
>
> If this sounds acceptable, I'll start in on it ASAP.
This sounds good (well, acceptable) to me.
> >> If you think that patch 2/3 is that maloderous that it cannot be
> >> accepted, then there will always probably be this kind of disjointed
> >> file-system permissions gap for vhost-user server mode interfaces.
> >> Unless you have a better suggestion - I'm all ears then :)
> >
> > I do have one suggestion. Something like this:
> >
> > for (int i = 0; i < 10; i++) {
> > /* Find the first available file descriptor, then close it. */
> > int fd = socket(...);
> > close(fd);
> >
> > /* Create server socket. */
> > server = dpdk_create_server_socket(filename, ...);
> >
> > /* Check that fd is the new server socket fd.
> > * This is normally true unless some other thread created a fd
> > * concurrently. */
> > struct stat s;
> > struct sockaddr_un sun;
> > socklen_t sun_len = sizeof sun;
> > if (!stat(fd, &s) && S_ISSOCK(s.st_mode) &&
> > getsockname(fd, &sun, &sun_len) && !strcmp(filename, sun.sun_path))
> > {
> > /* Yay, we found the fd. */
> > return success;
> > }
> >
> > /* Race. Try again. */
> > dpdk_close_server_socket(server);
> > }
>
> Thanks, Ben. I am not opposed to going with this approach.
> Unfortunately, there are no truly good solutions I see here at
> the moment.
I'm not super-happy with my idea either, honestly. We are faced with a
choice of several bad solutions.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
