Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend

[Luigi Rizzo]

On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote:
> On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo <address@hidden> wrote:
...
> >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione <address@hidden>
> >> wrote:
> >> > This patch adds support for a network backend based on netmap.
> >> > netmap is a framework for high speed packet I/O. You can use it
> >> > to build extremely fast traffic generators, monitors, software
> >> > switches or network middleboxes. Its companion software switch
> >> > VALE lets you interconnect virtual machines.
> >> > netmap and VALE are implemented as a non intrusive kernel module,
> >> > support NICs from multiple vendors, are part of standard FreeBSD
> >> > distributions and available in source format for Linux too.
> >>
> >> I don't think it's a good idea to support this on Linux hosts.  This
> >> is an out of tree module that most likely will never go upstream.
> >>
> >> I don't want to live through another kqemu with this if it eventually
> >> starts to bit-rot.
> >
> >
> > I believe this is very different from kqemu.
> >
> > For first, it is just a one-file backend (the patches
> > to other files are just because there is not yet a way
> > to automatically generate them; but i am sure qemu
> > will get there). Getting rid of it, should the code
> > bit-rot, is completely trivial.
> >
> > Second, there is nothing linux specific here. Unless configure
> > determines that the (possibly out of tree, as in Linux,
> > or in-tree, as in FreeBSD) netmap headers are
> > installed, it just won't build the backend.
> 
> Without being in upstream Linux, we have no guarantee that the API/ABI
> will be stable over time.  I suspect it's also very unlikely that any
> many stream distro will include these patches meaning that the number
> of users that will test this is very low.
> 
> I don't think just adding another backend because we can helps us out
> in the long term.  Either this is the Right Approach to networking and
> we should focus on getting proper kernel support or if that's not
> worth it, then there's no reason to include this in QEMU either.

anthony,
i'd still like you to answer the question that i asked before:

        are you opposed to netmap support just for linux, or you
        oppose to it in general (despite netmap being already
        upstream in FreeBSD) ?

Your reasoning seems along the lines "if feature X is not upstream
in linux we do not want to support it".

While I can buy it (hey, it may save a lot of maintenance effort),
it contrasts with the presence in qemu of a ton of conditional code
to support other host platforms, as well as multiple backends for
non-linux features (mostly audio drivers; some GUI too, think of
Cocoa).

Also the agendas of Qemu, linux, FreeBSD and other hosts may be
different (and it does not mean that there is One Right Way or that
others are wrong), so having "inclusion in linux" as a prerequisite
for support seems a bit restrictive.

Specifically, the networking requirements for qemu (a fast virtual
switch, tunnels etc.) are different from that of more typical apps
or the OS itself.

Also regarding API stability: qemu uses a lot of user libraries
whose APIs are a moving target without apparent problems.
If you are worried about API stability, netmap is just two
small headers, and no library. There isn't really much
that can go wrong there...

        cheers
        luigi

> Regards,
> 
> Anthony Liguori
> 
> > I am not sure if you do not want to support netmap _in general_
> > (despite it is already upstream in FreeBSD),
> > or you'd like to put extra checks in ./configure to actually
> > prevent its use on linux hosts.
> >