From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38676 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYl4G-0006Ry-HY for qemu-devel@nongnu.org; Tue, 13 Jul 2010 15:23:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYl4E-0000g6-6Y for qemu-devel@nongnu.org; Tue, 13 Jul 2010 15:23:00 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:39015) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYl4E-0000fw-2S for qemu-devel@nongnu.org; Tue, 13 Jul 2010 15:22:58 -0400 Received: by qwf6 with SMTP id 6so1012394qwf.4 for ; Tue, 13 Jul 2010 12:22:57 -0700 (PDT) Message-ID: <4C3CBD07.4020503@codemonkey.ws> Date: Tue, 13 Jul 2010 14:22:47 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1278962453-15774-1-git-send-email-miguel.filho@gmail.com> <4C3C04C4.8050804@web.de> <4C3C60A8.7070309@siemens.com> <4C3CB5C1.5010307@codemonkey.ws> <4C3CB9AB.1070607@web.de> In-Reply-To: <4C3CB9AB.1070607@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/8] vlan cleanup List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, avi@redhat.com, Miguel Di Ciurcio Filho , Markus Armbruster , Luiz Capitulino On 07/13/2010 02:08 PM, Jan Kiszka wrote: > Anthony Liguori wrote: > >> On 07/13/2010 07:48 AM, Jan Kiszka wrote: >> >>> Miguel Di Ciurcio Filho wrote: >>> >>> >>>> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka wrote: >>>> >>>> >>>>> Miguel Di Ciurcio Filho wrote: >>>>> >>>>> >>>>>> This series removes the vlan stuff without mercy. I've tried to >>>>>> make the steps >>>>>> as small as possible, but the last one is huge. I did some basic >>>>>> tests and >>>>>> networking is still working, so reviews are welcome :-D >>>>>> >>>>>> >>>>> Sorry, this is a bit too rude. This not only removes the vlan model, >>>>> something one may talk about, but also the innocent socket back-ends >>>>> and >>>>> the useful pcap dump support. >>>>> >>>>> Socket back-ends allow quick and easy unprivileged inter-VM network >>>>> setups. Nothing for production systems, but useful for testing purposes >>>>> on boxes where taps are not allowed or unhandy to configure. >>>>> >>>>> >>>>> >>>> I agree that it might be handy sometimes, but one could use VDE for >>>> that too. Runs on user-space and can be tunneled over SSH or netcat >>>> [1]. >>>> >>>> >>> Yes, I know. But it requires yet another process as hop. In contrast, >>> peer-to-peer sockets used to be as fast as taps in certain setup (now >>> taps became faster again). >>> >>> >> Dump is critical to maintain. >> >> sockets is not terribly useful without vlan. Honestly, I have a hard >> time agreeing that it's terribly useful to begin with. I don't buy an >> argument about "ease-of-use" because how to properly configure the >> sockets backend is not at all obvious. >> > Old style: > -net socket,listen=:12345 > plus > -net socket,connect=127.0.0.1:12345 > and you have linked two VMs. New style would be less handy (unless we > map -net on -netdev once vlans are gone), but still following the same > pattern. > For peer-to-peer. But -net socket + vlan also supports multiple point. And in this example, you're forwarding TCP over TCP which is pretty awful from a perf perspective. Last time I did a quick sniff test with -net socket, it was amazingly slow (like 10s of KB/s). > I bet there is only a minor bit missing to get "-netdev socket" working, > given that slirp apparently works. If I had time, I would look into this. > I'm sure you could, but the result is a tremendously crippled version of -net socket which leads me to wonder if it's still even worth supporting. Regards, Anthony Liguori > Jan > >