On Mon, Nov 4, 2013 at 1:08 PM, Luigi Rizzo <ri...@iet.unipi.it> wrote: > > > > On Mon, Nov 4, 2013 at 12:54 PM, Anthony Liguori <anth...@codemonkey.ws> > wrote: >> >> On Mon, Nov 4, 2013 at 11:51 AM, Luigi Rizzo <ri...@iet.unipi.it> 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 <ri...@iet.unipi.it> >> >> 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.
Correct. Sorry for the confusion. Regards, Anthony Liguori > > cheers > luigi >
