[ovs-dev] RFC: the meaning of LINUX_DATAPATH and HAVE_IF_DL

Ben Pfaff blp at nicira.com
Fri Jan 24 00:55:59 UTC 2014


On Thu, Jan 23, 2014 at 04:45:34PM -0800, Luigi Rizzo wrote:
> On Thu, Jan 23, 2014 at 4:43 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Fri, Jan 24, 2014 at 01:29:32AM +0100, Daniele Di Proietto wrote:
> > > I'll just attach the patch (just for a quick preview, it is not ready
> > jet)
> > > that builds the userspace components for the kernel datapath in FreeBSD.
> > We
> > > provide some linux functionalities (netlink and epoll) through wrappers
> > > (not included here) so that LINUX_DATAPATH is true. What we may need is a
> > > better way to understand which features are present to exclude some
> > blocks
> > > inside LINUX_DATAPATH.
> >
> > From reading this, it looks like the BSD kernel datapath port also
> > uses Netlink as the communication channel to the kernel.  Is that
> > correct?
> >
> 
> correct. daniele implemented netlink generic sockets
> for FreeBSD as a kernel module as part of the work.

OK, that explains why there are interesting boundaries being crossed
here.

How about this:

        - Replace LINUX_DATAPATH by NETLINK_DATAPATH, since that seems
          to describe the relationship better.

        - Instead of (LINUX_DATAPATH && !HAVE_IF_DL), write just
          __linux__.  In the cases I looked at, the interface didn't
          seem too likely to be of interest outside Linux.

        - Where individual features seem to be sensibly testable, do
          that.

        - If the FreeBSD kernel datapath port makes it to upstream
          FreeBSD, or otherwise achieves some kind of widespread
          adoption, then we might eventually want to rename dpif-linux
          to dpif-netlink.



More information about the dev mailing list