[Qemu-devel] [PATCH v3] net: Adding netmap network backend
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.
To compile QEMU with netmap support, use the following configure
options:
./configure [...] --enable-netmap --extra-cflags=-I/path/to/netmap/sys
where "/path/to/netmap" contains the netmap source code, available at
http://info.iet.unipi.it/~luigi/netmap/
The same webpage contains more information about the netmap project
(together with papers and presentations).
Signed-off-by: Vincenzo Maffione
---
This patch follows a previous thread (whose subject was "netmap backend"),
in which a previous version was already revised. All the review comments
have been taken into consideration or applied.
This patch only contains the simplest netmap backend for QEMU.
In particular, this backend implementation is still not
able to make use of batching on the TX side (frontend -> backend),
which is where most of the TX performance gain comes from.
As you can see from the code, there is an ioctl(NIOCTXSYNC) for each
packet, instead of an ioctl(NIOCTXSYNC) for a batch of packets.
In order to make TX batching possible, we would need to do some
modifications to the generic net/net.c code, adding to the
frontend/backend datapath interface a way to send a batch (this can
be done using a QEMU_NET_PACKET_FLAG_MORE, without changing too
much the existing interface).
We will propose these features in future patches.
configure | 31
hmp-commands.hx | 4 +-
net/Makefile.objs | 1 +
net/clients.h | 5 +
net/net.c | 6 +
net/netmap.c | 423 ++
qapi-schema.json | 19 ++-
qemu-options.hx | 8 ++
8 files changed, 494 insertions(+), 3 deletions(-)
create mode 100644 net/netmap.c
diff --git a/configure b/configure
index 57ee62a..4046fe5 100755
--- a/configure
+++ b/configure
@@ -155,6 +155,7 @@ curl=""
curses=""
docs=""
fdt=""
+netmap=""
pixman=""
sdl=""
virtfs=""
@@ -777,6 +778,10 @@ for opt do
;;
--enable-vde) vde="yes"
;;
+ --disable-netmap) netmap="no"
+ ;;
+ --enable-netmap) netmap="yes"
+ ;;
--disable-xen) xen="no"
;;
--enable-xen) xen="yes"
@@ -1157,6 +1162,8 @@ echo " --disable-uuid disable uuid support"
echo " --enable-uuidenable uuid support"
echo " --disable-vdedisable support for vde network"
echo " --enable-vde enable support for vde network"
+echo " --disable-netmap disable support for netmap network"
+echo " --enable-netmap enable support for netmap network"
echo " --disable-linux-aio disable Linux AIO support"
echo " --enable-linux-aio enable Linux AIO support"
echo " --disable-cap-ng disable libcap-ng support"
@@ -2061,6 +2068,26 @@ EOF
fi
##
+# netmap headers probe
+if test "$netmap" != "no" ; then
+ cat > $TMPC << EOF
+#include
+#include
+#include
+#include
+int main(void) { return 0; }
+EOF
+ if compile_prog "" "" ; then
+netmap=yes
+ else
+if test "$netmap" = "yes" ; then
+ feature_not_found "netmap"
+fi
+netmap=no
+ fi
+fi
+
+##
# libcap-ng library probe
if test "$cap_ng" != "no" ; then
cap_libs="-lcap-ng"
@@ -3716,6 +3743,7 @@ echo "uname -r $uname_release"
echo "GUEST_BASE$guest_base"
echo "PIE $pie"
echo "vde support $vde"
+echo "netmap support$netmap"
echo "Linux AIO support $linux_aio"
echo "ATTR/XATTR support $attr"
echo "Install blobs $blobs"
@@ -3854,6 +3882,9 @@ fi
if test "$vde" = "yes" ; then
echo "CONFIG_VDE=y" >> $config_host_mak
fi
+if test "$netmap" = "yes" ; then
+ echo "CONFIG_NETMAP=y" >> $config_host_mak
+fi
if test "$cap_ng" = "yes" ; then
echo "CONFIG_LIBCAP=y" >> $config_host_mak
fi
diff --git a/hmp-commands.hx b/hmp-commands.hx
index caae5ad..ebe8e78 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1190,7 +1190,7 @@ ETEXI
{
.name = "host_net_add",
.args_type = "device:s,opts:s?",
-.params = "tap|user|socket|vde|dump [options]",
+.params = "tap|user|socket|vde|netmap|dump [options]",
.help = "add host VLAN client",
.mhandler.cmd = net_host_device_add,
},
@@ -1218,7 +1218,7 @@ ETEXI
{
.name = "netdev_add",
.args_type = "netdev:O",
-.params = "[user|tap|socket|hubport],id=str[,prop=value][,...]",
+.params =
"[user|tap|socket|hubport|netmap],id=str[,prop=value][,...]",
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Tue, Oct 29, 2013 at 11:12:25AM +0100, Vincenzo Maffione wrote:
Looks pretty good, I think we can merge the next revision.
> This patch only contains the simplest netmap backend for QEMU.
> In particular, this backend implementation is still not
> able to make use of batching on the TX side (frontend -> backend),
> which is where most of the TX performance gain comes from.
> As you can see from the code, there is an ioctl(NIOCTXSYNC) for each
> packet, instead of an ioctl(NIOCTXSYNC) for a batch of packets.
> In order to make TX batching possible, we would need to do some
> modifications to the generic net/net.c code, adding to the
> frontend/backend datapath interface a way to send a batch (this can
> be done using a QEMU_NET_PACKET_FLAG_MORE, without changing too
> much the existing interface).
> We will propose these features in future patches.
QEMU_NET_PACKET_FLAG_MORE sounds like a good idea.
> +#include "net/net.h"
> +#include "clients.h"
> +#include "sysemu/sysemu.h"
> +#include "qemu/error-report.h"
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please include system headers first, then QEMU headers. This way QEMU
headers cannot interfere with system headers if they define macros.
Also, should be "qemu/iov.h":
#include
#include
#include
#include
#include
#include "net/net.h"
#include "clients.h"
#include "sysemu/sysemu.h"
#include "qemu/error-report.h"
#include "qemu/iov.h"
> +/*
> + * Open a netmap device. We assume there is only one queue
> + * (which is the case for the VALE bridge).
> + */
> +static int netmap_open(NetmapPriv *me)
> +{
> +int fd;
> +int err;
> +size_t l;
> +struct nmreq req;
> +
> +me->fd = fd = open(me->fdname, O_RDWR);
> +if (fd < 0) {
> +error_report("Unable to open netmap device '%s'", me->fdname);
> +return -1;
This error message is not detailed enough, please include the errstr(3).
> +}
> +bzero(&req, sizeof(req));
Please use memset(&req, 0, sizeof(req)). Some compilers/tools warn that
bzero() is deprecated. For more info, see:
http://pubs.opengroup.org/onlinepubs/009695399/functions/bzero.html
> +pstrcpy(req.nr_name, sizeof(req.nr_name), me->ifname);
> +req.nr_ringid = NETMAP_NO_TX_POLL;
> +req.nr_version = NETMAP_API;
> +err = ioctl(fd, NIOCREGIF, &req);
> +if (err) {
> +error_report("Unable to register %s", me->ifname);
Lacking errno information here too.
> +goto error;
> +}
> +l = me->memsize = req.nr_memsize;
> +
> +me->mem = mmap(0, l, PROT_WRITE | PROT_READ, MAP_SHARED, fd, 0);
> +if (me->mem == MAP_FAILED) {
> +error_report("Unable to mmap");
Lacking errno information here too.
> +static ssize_t netmap_receive_iov(NetClientState *nc,
> +const struct iovec *iov, int iovcnt)
> +{
> +NetmapState *s = DO_UPCAST(NetmapState, nc, nc);
> +struct netmap_ring *ring = s->me.tx;
> +
> +if (ring) {
Feel free to reduce indentation by returning early:
if (!ring) {
return iov_size(iov, iovcnt); /* drop */
}
> +uint32_t i = 0;
> +uint32_t idx;
> +uint8_t *dst;
> +int j;
> +uint32_t cur = ring->cur;
> +uint32_t avail = ring->avail;
> +int iov_frag_size;
> +int nm_frag_size;
> +int offset;
> +
> +if (avail < iovcnt) {
> +/* Not enough netmap slots. */
> +netmap_write_poll(s, true);
> +return 0;
> +}
> +
> +for (j = 0; j < iovcnt; j++) {
> +iov_frag_size = iov[j].iov_len;
> +offset = 0;
> +
> +/* Split each iovec fragment over more netmap slots, if
> + necessary (without performing data copy). */
I don't understand this comment, we always perform data copy.
> +while (iov_frag_size) {
> +nm_frag_size = MIN(iov_frag_size, ring->nr_buf_size);
> +
> +if (unlikely(avail == 0)) {
> +/* We run out of netmap slots while splitting the
> + iovec fragments. */
> +return 0;
netmap_write_poll(s, true) missing?
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione 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.
Regards,
Anthony Liguori
>
> To compile QEMU with netmap support, use the following configure
> options:
> ./configure [...] --enable-netmap --extra-cflags=-I/path/to/netmap/sys
> where "/path/to/netmap" contains the netmap source code, available at
> http://info.iet.unipi.it/~luigi/netmap/
>
> The same webpage contains more information about the netmap project
> (together with papers and presentations).
>
> Signed-off-by: Vincenzo Maffione
> ---
> This patch follows a previous thread (whose subject was "netmap backend"),
> in which a previous version was already revised. All the review comments
> have been taken into consideration or applied.
>
> This patch only contains the simplest netmap backend for QEMU.
> In particular, this backend implementation is still not
> able to make use of batching on the TX side (frontend -> backend),
> which is where most of the TX performance gain comes from.
> As you can see from the code, there is an ioctl(NIOCTXSYNC) for each
> packet, instead of an ioctl(NIOCTXSYNC) for a batch of packets.
> In order to make TX batching possible, we would need to do some
> modifications to the generic net/net.c code, adding to the
> frontend/backend datapath interface a way to send a batch (this can
> be done using a QEMU_NET_PACKET_FLAG_MORE, without changing too
> much the existing interface).
> We will propose these features in future patches.
>
> configure | 31
> hmp-commands.hx | 4 +-
> net/Makefile.objs | 1 +
> net/clients.h | 5 +
> net/net.c | 6 +
> net/netmap.c | 423
> ++
> qapi-schema.json | 19 ++-
> qemu-options.hx | 8 ++
> 8 files changed, 494 insertions(+), 3 deletions(-)
> create mode 100644 net/netmap.c
>
> diff --git a/configure b/configure
> index 57ee62a..4046fe5 100755
> --- a/configure
> +++ b/configure
> @@ -155,6 +155,7 @@ curl=""
> curses=""
> docs=""
> fdt=""
> +netmap=""
> pixman=""
> sdl=""
> virtfs=""
> @@ -777,6 +778,10 @@ for opt do
>;;
>--enable-vde) vde="yes"
>;;
> + --disable-netmap) netmap="no"
> + ;;
> + --enable-netmap) netmap="yes"
> + ;;
>--disable-xen) xen="no"
>;;
>--enable-xen) xen="yes"
> @@ -1157,6 +1162,8 @@ echo " --disable-uuid disable uuid support"
> echo " --enable-uuidenable uuid support"
> echo " --disable-vdedisable support for vde network"
> echo " --enable-vde enable support for vde network"
> +echo " --disable-netmap disable support for netmap network"
> +echo " --enable-netmap enable support for netmap network"
> echo " --disable-linux-aio disable Linux AIO support"
> echo " --enable-linux-aio enable Linux AIO support"
> echo " --disable-cap-ng disable libcap-ng support"
> @@ -2061,6 +2068,26 @@ EOF
> fi
>
> ##
> +# netmap headers probe
> +if test "$netmap" != "no" ; then
> + cat > $TMPC << EOF
> +#include
> +#include
> +#include
> +#include
> +int main(void) { return 0; }
> +EOF
> + if compile_prog "" "" ; then
> +netmap=yes
> + else
> +if test "$netmap" = "yes" ; then
> + feature_not_found "netmap"
> +fi
> +netmap=no
> + fi
> +fi
> +
> +##
> # libcap-ng library probe
> if test "$cap_ng" != "no" ; then
>cap_libs="-lcap-ng"
> @@ -3716,6 +3743,7 @@ echo "uname -r $uname_release"
> echo "GUEST_BASE$guest_base"
> echo "PIE $pie"
> echo "vde support $vde"
> +echo "netmap support$netmap"
> echo "Linux AIO support $linux_aio"
> echo "ATTR/XATTR support $attr"
> echo "Install blobs $blobs"
> @@ -3854,6 +3882,9 @@ fi
> if test "$vde" = "yes" ; then
>echo "CONFIG_VDE=y" >> $config_host_mak
> fi
> +if test "$netmap" = "yes" ; then
> + echo "CONFIG_NETMAP=y" >> $config_host_mak
> +fi
> if test "$cap_ng" = "yes" ; then
>echo "CONFIG_LIBCAP=y" >> $config_host_mak
> fi
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index caae5ad..ebe8e78 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -1190,7 +1190,7 @@ ETEXI
> {
> .
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Mon, Nov 4, 2013 at 9:41 AM, Anthony Liguori wrote: > On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione > 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. 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. Both cases it seems to me a loss of a useful feature with no real return > configure | 31 > hmp-commands.hx | 4 +- > net/Makefile.objs | 1 + > net/clients.h | 5 + > net/net.c | 6 + > net/netmap.c | 423 ++ > qapi-schema.json | 19 ++- > qemu-options.hx | 8 ++ > 8 files changed, 494 insertions(+), 3 deletions(-) > create mode 100644 net/netmap.c cheers luigi
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo wrote: > > > > On Mon, Nov 4, 2013 at 9:41 AM, Anthony Liguori > wrote: >> >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione >> 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. 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. > > Both cases it seems to me a loss of a useful feature with no > real return > >> > configure | 31 >> > hmp-commands.hx | 4 +- >> > net/Makefile.objs | 1 + >> > net/clients.h | 5 + >> > net/net.c | 6 + >> > net/netmap.c | 423 > ++ >> > qapi-schema.json | 19 ++- >> > qemu-options.hx | 8 ++ >> > 8 files changed, 494 insertions(+), 3 deletions(-) >> > create mode 100644 net/netmap.c > > cheers > luigi
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On 10/29/2013 04:12 AM, Vincenzo Maffione 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. > Looking at just the interface: > +++ b/qapi-schema.json > @@ -2984,6 +2984,22 @@ > 'hubid': 'int32' } } > > ## > +# @NetdevNetmapOptions > +# > +# Connect two or more net clients through a VALE switch > +# > +# @ifname: optional name of the VALE port > +# > +# @devname: optional path of the netmap device What values are used if I omit these parameters? It's best to document what the defaults are (and if you have a hard time choosing sane defaults, it may be better to make the parameters mandatory). > +# > +# Since 1.2 This is wrong; you've already missed 1.7 freeze, so the earliest it can go in is 1.8. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote: > On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo wrote: ... > >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione > >> 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. > >
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo wrote: > On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote: >> On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo wrote: > ... >> >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione >> >> 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". Yes. This is the historic policy we have taken for any feature. I have no problem with netmap being used on FreeBSD hosts but I think it should not be enabled on Linux hosts. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Mon, Nov 4, 2013 at 12:54 PM, Anthony Liguori wrote: > On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo wrote: > > On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote: > >> On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo > wrote: > > ... > >> >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione < > v.maffi...@gmail.com> > >> >> 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". > > Yes. This is the historic policy we have taken for any feature. I > have no problem with netmap being used on FreeBSD hosts but I think it > should not be enabled on Linux hosts. > ok thanks for the clarification. S o I misunderstood , the policy is "if not upstream in linux, we do not want to support it _on linux_". A fundamental difference :) So in ./configure we must change to 'netmap="no"' in the initial section to disable it by default, and add a line 'netmap=""' in the FreeBSD section to enable autodetect there. cheers luigi
Re: [Qemu-devel] [PATCH v3] net: Adding netmap network backend
On Mon, Nov 4, 2013 at 1:08 PM, Luigi Rizzo wrote: > > > > On Mon, Nov 4, 2013 at 12:54 PM, Anthony Liguori > wrote: >> >> On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo wrote: >> > On Mon, Nov 04, 2013 at 10:20:12AM -0800, Anthony Liguori wrote: >> >> On Mon, Nov 4, 2013 at 10:08 AM, Luigi Rizzo >> >> wrote: >> > ... >> >> >> On Tue, Oct 29, 2013 at 3:12 AM, Vincenzo Maffione >> >> >> >> >> >> 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". >> >> Yes. This is the historic policy we have taken for any feature. I >> have no problem with netmap being used on FreeBSD hosts but I think it >> should not be enabled on Linux hosts. > > > ok thanks for the clarification. > S > o I misunderstood > , > the policy is > "if not upstream in linux, we do not want to support it _on linux_". > A fundamental difference :) > > So in ./configure we must change to 'netmap="no"' in the initial > section to disable it by default, and add a line 'netmap=""' in the > FreeBSD section to enable autodetect there. Correct. Sorry for the confusion. Regards, Anthony Liguori > > cheers > luigi >
