On Tue, Aug 08, 2017 at 04:59:10PM -0400, Lance Richardson wrote: > > > ----- Original Message ----- > > From: "Ben Pfaff" <b...@ovn.org> > > To: "Lance Richardson" <lrich...@redhat.com> > > Cc: d...@openvswitch.org > > Sent: Tuesday, August 8, 2017 4:49:52 PM > > Subject: Re: [ovs-dev] DNS support options > > > > On Tue, Aug 08, 2017 at 04:16:21PM -0400, Lance Richardson wrote: > > > > From: "Ben Pfaff" <b...@ovn.org> > > > > To: "Lance Richardson" <lrich...@redhat.com> > > > > Cc: d...@openvswitch.org > > > > Sent: Tuesday, August 8, 2017 3:48:15 PM > > > > Subject: Re: [ovs-dev] DNS support options > > > > > > > > On Tue, Aug 08, 2017 at 02:59:21PM -0400, Lance Richardson wrote: > > > > > > From: "Ben Pfaff" <b...@ovn.org> > > > > > > To: d...@openvswitch.org > > > > > > Sent: Tuesday, August 8, 2017 2:43:17 PM > > > > > > Subject: [ovs-dev] DNS support options > > > > > > > > > > > > Open vSwitch currently supports only IP addresses for specifying > > > > > > OpenFlow and OVSDB remotes. It would be nice to support DNS names. > > > > > > Open vSwitch can't afford to let DNS resolution block processing, so > > > > > > it > > > > > > needs some way to resolve DNS asynchronously. I've come up with the > > > > > > following solutions so far: > > > > > > > > > > > > * Implement it ourselves using threads. Probably, this > > > > > > would > > > > > > be > > > > > > a single worker thread that loops through calls to > > > > > > getaddrinfo(). > > > > > > > > > > > > * glibc has getaddrinfo_a(), an asynchronous version of > > > > > > getaddrinfo(). *BSD and Windows do not have this > > > > > > function, > > > > > > so > > > > > > we would still need to implement it ourselves (probably > > > > > > using > > > > > > threads) if we adopted this approach, so it might be more > > > > > > work > > > > > > than the first solution. > > > > > > > > > > > > * Use an external asynchronous DNS library. GNU adns looks > > > > > > like > > > > > > a good choice: > > > > > > http://www.chiark.greenend.org.uk/~ian/adns/. > > > > > > It has a port to Windows but I don't know whether it's > > > > > > up-to-date. > > > > > > > > > > > > > > > > With adns_beforepoll()/adns_afterpoll(), it looks like adns might be > > > > > easy > > > > > to integrate on top of lib/poll-loop.c. Not requiring a separate > > > > > thread > > > > > seems like a plus. > > > > > > > > Oops, I just realized that adns is GPL'd, which means that linking it > > > > against OVS would force OVS to be GPL'd, so it's probably not a good > > > > choice. > > > > > > > > Other possible choices: > > > > > > > > - c-ares (https://c-ares.haxx.se/). Main disadvantage seems to > > > > be that it's very "select" oriented. > > > > > > > > > > c-ares has an API to retrieve the set of socket descriptors that need to > > > be monitored for readability/writability, so integration shouldn't be much > > > work. A socket creation callback function can be registered as well, not > > > sure if it would be needed but it's nice that it's there. Looks like a > > > fairly active project with some contributors I recognize. > > > > This API? https://c-ares.haxx.se/ares_fds.html > > It seems inconvenient because it returns the fds as a fd_set, which the > > caller then has to scan for 1-bits. > > > > This is however a fairly petty grievance if it's the only downside. > > > > I was looking at this one: > > https://c-ares.haxx.se/ares_getsock.html
You're right, this function is a good solution. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
