Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Mon, 04 Jun 2012 12:56:41 +0800 Anthony Liguori wrote: > On 05/25/2012 08:53 PM, Luiz Capitulino wrote: > > On Fri, 25 May 2012 13:01:37 +0100 > > Stefan Hajnoczi wrote: > > > >> I agree it would be nice to drop entirely but I don't feel happy doing > >> that to users who might have QEMU buried in scripts somewhere. One > >> day they upgrade packages and suddenly their stuff doesn't work > >> anymore. > > > > This is very similar to kqemu and I don't think we regret having dropped it. > > You couldn't imagine the number of complaints I got from users about dropping > kqemu. It caused me considerable pain. Complaints ranged from down right > hostile (I had to involve the Launchpad admins at one point because of a > particular user) to entirely sympathetic. > > kqemu wasn't just a maintenance burden, it was preventing large guest memory > support in KVM guests. There was no simple way around it without breaking > kqemu > ABI and making significant changes to the kqemu module. > > Dropping features is only something that should be approached lightly and > certainly not something that should be done just because you don't like a > particular bit of code. It's not just because I don't like the code. Afaik, there are better external tools that seem to do exact the same thing (and even seem to do it better) But as Markus said in the other thread, it's just advice, not strong objection.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Anthony Liguori writes: > On 05/29/2012 04:14 PM, Markus Armbruster wrote: >> Luiz Capitulino writes: >> >>> On Mon, 28 May 2012 12:17:04 +0100 >>> Stefan Hajnoczi wrote: >>> What we need to decide is whether it's okay to drop QEMU "VLANs" completely and change dump command-line syntax? >>> >>> I'd vote for dropping it. >>> I think vlan-hub doesn't hurt anyone because the code has been isolated and we keep backwards compatibility. So I'd personally still go the vlan-hub route for QEMU 1.x. >>> >>> Just to make it clear: I'm not against this series. I'm against having >>> the functionality in qemu. If we want to keep the functionality, then I >>> completely agree that this series is the way to go. >> >> I agree with Luiz: if we want to reimplement that much of networking >> within QEMU, this series does it in a much better way than VLANs, but >> I'd rather not do it at all. >> >> Just advice, not a strong objection. > > Doesn't the same logic apply to reimplementing file systems? > Shouldn't we drop qcow3 in favor of using btrfs? btrfs isn't ready for production, so this is a hypothetical question. > It's easy to make the NIH argument when it's a feature you don't care about. > > A lot of people use vlans. It's the only way -net socket is useful > too. Just because most KVM/libvirt users don't doesn't mean they > aren't an important feature to preserve. I specifically asked for evidence on actual use of VLANs, and which uses of VLANs can't be readily upgraded to better-performing external solutions. You asserting it is used "a lot" isn't a full answer, but it's (slightly) better than nothing. > I would strongly nack any attempt to remove vlans w/o providing some > mechanism for backwards compatibility which is exactly what this patch > series does. Roma locuta, causa finita.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On 05/25/2012 08:53 PM, Luiz Capitulino wrote: On Fri, 25 May 2012 13:01:37 +0100 Stefan Hajnoczi wrote: I agree it would be nice to drop entirely but I don't feel happy doing that to users who might have QEMU buried in scripts somewhere. One day they upgrade packages and suddenly their stuff doesn't work anymore. This is very similar to kqemu and I don't think we regret having dropped it. You couldn't imagine the number of complaints I got from users about dropping kqemu. It caused me considerable pain. Complaints ranged from down right hostile (I had to involve the Launchpad admins at one point because of a particular user) to entirely sympathetic. kqemu wasn't just a maintenance burden, it was preventing large guest memory support in KVM guests. There was no simple way around it without breaking kqemu ABI and making significant changes to the kqemu module. Dropping features is only something that should be approached lightly and certainly not something that should be done just because you don't like a particular bit of code. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On 05/29/2012 04:14 PM, Markus Armbruster wrote: Luiz Capitulino writes: On Mon, 28 May 2012 12:17:04 +0100 Stefan Hajnoczi wrote: What we need to decide is whether it's okay to drop QEMU "VLANs" completely and change dump command-line syntax? I'd vote for dropping it. I think vlan-hub doesn't hurt anyone because the code has been isolated and we keep backwards compatibility. So I'd personally still go the vlan-hub route for QEMU 1.x. Just to make it clear: I'm not against this series. I'm against having the functionality in qemu. If we want to keep the functionality, then I completely agree that this series is the way to go. I agree with Luiz: if we want to reimplement that much of networking within QEMU, this series does it in a much better way than VLANs, but I'd rather not do it at all. Just advice, not a strong objection. Doesn't the same logic apply to reimplementing file systems? Shouldn't we drop qcow3 in favor of using btrfs? It's easy to make the NIH argument when it's a feature you don't care about. A lot of people use vlans. It's the only way -net socket is useful too. Just because most KVM/libvirt users don't doesn't mean they aren't an important feature to preserve. I would strongly nack any attempt to remove vlans w/o providing some mechanism for backwards compatibility which is exactly what this patch series does. Regards, Anthony Liguori [...]
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Luiz Capitulino writes: > On Mon, 28 May 2012 12:17:04 +0100 > Stefan Hajnoczi wrote: > >> What we need to decide is whether it's okay to drop QEMU "VLANs" >> completely and change dump command-line syntax? > > I'd vote for dropping it. > >> I think vlan-hub doesn't hurt anyone because the code has been isolated >> and we keep backwards compatibility. So I'd personally still go the >> vlan-hub route for QEMU 1.x. > > Just to make it clear: I'm not against this series. I'm against having > the functionality in qemu. If we want to keep the functionality, then I > completely agree that this series is the way to go. I agree with Luiz: if we want to reimplement that much of networking within QEMU, this series does it in a much better way than VLANs, but I'd rather not do it at all. Just advice, not a strong objection. [...]
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Mon, 28 May 2012 12:17:04 +0100 Stefan Hajnoczi wrote: > What we need to decide is whether it's okay to drop QEMU "VLANs" > completely and change dump command-line syntax? I'd vote for dropping it. > I think vlan-hub doesn't hurt anyone because the code has been isolated > and we keep backwards compatibility. So I'd personally still go the > vlan-hub route for QEMU 1.x. Just to make it clear: I'm not against this series. I'm against having the functionality in qemu. If we want to keep the functionality, then I completely agree that this series is the way to go. Having glanced at this series I think it's beyond comparison with the current code...
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, May 25, 2012 at 10:56:28AM -0300, Luiz Capitulino wrote: > On Fri, 25 May 2012 15:47:28 +0200 > Paolo Bonzini wrote: > > > Il 25/05/2012 15:43, Luiz Capitulino ha scritto: > > >> Yeah, VDE probably includes something like an hub. But then we could > > >> drop even "-net socket", "-net udp", "-net dump", and only leave in > > >> vde+tap+slirp. Or even move slirp into VDE. :) That's a very different > > >> thing. > > > > > > Let's start with what is hurting us. > > > > But is it? The patch makes it quite clean. > > vlan is and the cleanest solution is to drop it. For the sake of the argument, here's what we'd need: 1. Patches to remove vlan completely from QEMU. 2. net/dump.c alternative. Packet capture could be done like this: -netdev tap,dump=capture.pcap,... You specify the "dump" option on a netdev giving a filename to use for the pcap file. The net/dump.c would need to be called from net.c or maybe net/queue.c. What we need to decide is whether it's okay to drop QEMU "VLANs" completely and change dump command-line syntax? I think vlan-hub doesn't hurt anyone because the code has been isolated and we keep backwards compatibility. So I'd personally still go the vlan-hub route for QEMU 1.x. Stefan
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 15:47:28 +0200 Paolo Bonzini wrote: > Il 25/05/2012 15:43, Luiz Capitulino ha scritto: > >> Yeah, VDE probably includes something like an hub. But then we could > >> drop even "-net socket", "-net udp", "-net dump", and only leave in > >> vde+tap+slirp. Or even move slirp into VDE. :) That's a very different > >> thing. > > > > Let's start with what is hurting us. > > But is it? The patch makes it quite clean. vlan is and the cleanest solution is to drop it. But that's just my opnion, I won't (and possibly can't) nack this.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Il 25/05/2012 15:43, Luiz Capitulino ha scritto: >> Yeah, VDE probably includes something like an hub. But then we could >> drop even "-net socket", "-net udp", "-net dump", and only leave in >> vde+tap+slirp. Or even move slirp into VDE. :) That's a very different >> thing. > > Let's start with what is hurting us. But is it? The patch makes it quite clean. Paolo
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 15:37:15 +0200 Paolo Bonzini wrote: > Il 25/05/2012 15:30, Luiz Capitulino ha scritto: > > On Fri, 25 May 2012 15:19:28 +0200 > > Paolo Bonzini wrote: > > > >> Il 25/05/2012 15:18, Luiz Capitulino ha scritto: > > > > Still not sure what you mean... > >>> I meant it's a similar case. kqemu was a special case and maintenance > >>> burden. > >>> We've dropped it and didn't regret. What's stopping us from doing the same > >>> thing with vlans? > >> > >> That we have an alternative, and that -net dump is actually useful. > > > > I haven't reviewed the series yet, but -net dump can work without this, > > can't it? > > -net dump requires putting a back-end, a front-end and the dump client > in the same VLAN. So it is quite useless without this. VDE allows this too :) > > It's always possible to have alternatives in qemu, the point is how far > > we're going on bloating it. > > > > we removed kqemu and didn't give an > > alternative. This time we are providing an alternative. > >>> Alternatives already exist, we don't have to provide them. > >> > >> Alternatives that require you to have root privileges (anything > >> involving libvirt or iptables) are not really alternatives. > > > > It seems to me that vde doesn't require root, but even if it does, moving > > this outside of qemu would also be feasible. > > Yeah, VDE probably includes something like an hub. But then we could > drop even "-net socket", "-net udp", "-net dump", and only leave in > vde+tap+slirp. Or even move slirp into VDE. :) That's a very different > thing. Let's start with what is hurting us. > Do distributions package VDE at all? I'm not sure. But note that openvswitch is a better alternative for linux.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Il 25/05/2012 15:30, Luiz Capitulino ha scritto: > On Fri, 25 May 2012 15:19:28 +0200 > Paolo Bonzini wrote: > >> Il 25/05/2012 15:18, Luiz Capitulino ha scritto: > > Still not sure what you mean... >>> I meant it's a similar case. kqemu was a special case and maintenance >>> burden. >>> We've dropped it and didn't regret. What's stopping us from doing the same >>> thing with vlans? >> >> That we have an alternative, and that -net dump is actually useful. > > I haven't reviewed the series yet, but -net dump can work without this, > can't it? -net dump requires putting a back-end, a front-end and the dump client in the same VLAN. So it is quite useless without this. > It's always possible to have alternatives in qemu, the point is how far > we're going on bloating it. > > we removed kqemu and didn't give an > alternative. This time we are providing an alternative. >>> Alternatives already exist, we don't have to provide them. >> >> Alternatives that require you to have root privileges (anything >> involving libvirt or iptables) are not really alternatives. > > It seems to me that vde doesn't require root, but even if it does, moving > this outside of qemu would also be feasible. Yeah, VDE probably includes something like an hub. But then we could drop even "-net socket", "-net udp", "-net dump", and only leave in vde+tap+slirp. Or even move slirp into VDE. :) That's a very different thing. Do distributions package VDE at all? Paolo
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 15:19:28 +0200 Paolo Bonzini wrote: > Il 25/05/2012 15:18, Luiz Capitulino ha scritto: > >> > > >> > Still not sure what you mean... > > I meant it's a similar case. kqemu was a special case and maintenance > > burden. > > We've dropped it and didn't regret. What's stopping us from doing the same > > thing with vlans? > > That we have an alternative, and that -net dump is actually useful. I haven't reviewed the series yet, but -net dump can work without this, can't it? It's always possible to have alternatives in qemu, the point is how far we're going on bloating it. > >> > we removed kqemu and didn't give an > >> > alternative. This time we are providing an alternative. > > Alternatives already exist, we don't have to provide them. > > Alternatives that require you to have root privileges (anything > involving libvirt or iptables) are not really alternatives. It seems to me that vde doesn't require root, but even if it does, moving this outside of qemu would also be feasible.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Il 25/05/2012 15:18, Luiz Capitulino ha scritto: >> > >> > Still not sure what you mean... > I meant it's a similar case. kqemu was a special case and maintenance burden. > We've dropped it and didn't regret. What's stopping us from doing the same > thing with vlans? That we have an alternative, and that -net dump is actually useful. >> > we removed kqemu and didn't give an >> > alternative. This time we are providing an alternative. > Alternatives already exist, we don't have to provide them. Alternatives that require you to have root privileges (anything involving libvirt or iptables) are not really alternatives. Paolo
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 15:14:39 +0200 Paolo Bonzini wrote: > Il 25/05/2012 15:07, Luiz Capitulino ha scritto: > > On Fri, 25 May 2012 14:59:25 +0200 > > Paolo Bonzini wrote: > > > >> Il 25/05/2012 14:53, Luiz Capitulino ha scritto: > > I agree it would be nice to drop entirely but I don't feel happy doing > > that to users who might have QEMU buried in scripts somewhere. One > > day they upgrade packages and suddenly their stuff doesn't work > > anymore. > >>> This is very similar to kqemu and I don't think we regret having dropped > >>> it. > >> > >> It's not. kqemu was putting maintainance burden, the aim of this patch > >> is exactly to isolate the feature to command-line parsing and a magic > >> net client. If you don't use -net, the new code is absolutely dead, > >> unlike kqemu. > > > > Let me quote Stefan on this thread: > > > > """ > > The point of this patch series is to remove the special-case net.c code > > for the legacy "vlan" feature. Today's code makes it harder to > > implement a clean QOM model and is a burden for the net subsystem in > > general > > """ > > Still not sure what you mean... I meant it's a similar case. kqemu was a special case and maintenance burden. We've dropped it and didn't regret. What's stopping us from doing the same thing with vlans? > we removed kqemu and didn't give an > alternative. This time we are providing an alternative. Alternatives already exist, we don't have to provide them.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Il 25/05/2012 15:07, Luiz Capitulino ha scritto: > On Fri, 25 May 2012 14:59:25 +0200 > Paolo Bonzini wrote: > >> Il 25/05/2012 14:53, Luiz Capitulino ha scritto: > I agree it would be nice to drop entirely but I don't feel happy doing > that to users who might have QEMU buried in scripts somewhere. One > day they upgrade packages and suddenly their stuff doesn't work > anymore. >>> This is very similar to kqemu and I don't think we regret having dropped it. >> >> It's not. kqemu was putting maintainance burden, the aim of this patch >> is exactly to isolate the feature to command-line parsing and a magic >> net client. If you don't use -net, the new code is absolutely dead, >> unlike kqemu. > > Let me quote Stefan on this thread: > > """ > The point of this patch series is to remove the special-case net.c code > for the legacy "vlan" feature. Today's code makes it harder to > implement a clean QOM model and is a burden for the net subsystem in > general > """ Still not sure what you mean... we removed kqemu and didn't give an alternative. This time we are providing an alternative. Paolo
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Il 25/05/2012 14:53, Luiz Capitulino ha scritto: >> > I agree it would be nice to drop entirely but I don't feel happy doing >> > that to users who might have QEMU buried in scripts somewhere. One >> > day they upgrade packages and suddenly their stuff doesn't work >> > anymore. > This is very similar to kqemu and I don't think we regret having dropped it. It's not. kqemu was putting maintainance burden, the aim of this patch is exactly to isolate the feature to command-line parsing and a magic net client. If you don't use -net, the new code is absolutely dead, unlike kqemu. Paolo
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 14:59:25 +0200 Paolo Bonzini wrote: > Il 25/05/2012 14:53, Luiz Capitulino ha scritto: > >> > I agree it would be nice to drop entirely but I don't feel happy doing > >> > that to users who might have QEMU buried in scripts somewhere. One > >> > day they upgrade packages and suddenly their stuff doesn't work > >> > anymore. > > This is very similar to kqemu and I don't think we regret having dropped it. > > It's not. kqemu was putting maintainance burden, the aim of this patch > is exactly to isolate the feature to command-line parsing and a magic > net client. If you don't use -net, the new code is absolutely dead, > unlike kqemu. Let me quote Stefan on this thread: """ The point of this patch series is to remove the special-case net.c code for the legacy "vlan" feature. Today's code makes it harder to implement a clean QOM model and is a burden for the net subsystem in general """
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 13:01:37 +0100 Stefan Hajnoczi wrote: > I agree it would be nice to drop entirely but I don't feel happy doing > that to users who might have QEMU buried in scripts somewhere. One > day they upgrade packages and suddenly their stuff doesn't work > anymore. This is very similar to kqemu and I don't think we regret having dropped it.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 08:47:18 +0800 Zhi Yong Wu wrote: > On Fri, May 25, 2012 at 4:53 AM, Luiz Capitulino > wrote: > > On Fri, 25 May 2012 01:59:06 +0800 > > zwu.ker...@gmail.com wrote: > > > >> From: Zhi Yong Wu > >> > >> The patchset implements network hub stead of vlan. The main work was done > >> by stefan, and i rebased it to latest QEMU upstream, did some testings and > >> am responsible for pushing it to QEMU upstream. > > > > Honest question: does it really pay off to have this in qemu vs. using one > > of > It's said that it can speed up packets delivery, but i have not do > every bechmark testings. > For more details, please refer to > http://thread.gmane.org/gmane.comp.emulators.qemu/133362 > > the externaly available solutions? > Is there external available solutions?:), What are they? Open vSwitch? I _guess_ that for non-linux unices we have only vde (do bsds have a tap interface that can be used like we use it in linux?). For Linux we also vde, openvswitch and macvtap in bridge mode.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Stefan Hajnoczi writes: > On Fri, May 25, 2012 at 12:18 PM, Markus Armbruster wrote: >> Stefan Hajnoczi writes: >> >>> On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote: On Fri, 25 May 2012 01:59:06 +0800 zwu.ker...@gmail.com wrote: > From: Zhi Yong Wu > > The patchset implements network hub stead of vlan. The main work was > done by stefan, and i rebased it to latest QEMU upstream, did some > testings and am responsible for pushing it to QEMU upstream. Honest question: does it really pay off to have this in qemu vs. using one of the externaly available solutions? >>> >>> For typical KVM setups this feature will be unused. >>> >>> However, the legacy QEMU "vlan" feature does have a few uses: >>> >>> 1. It's how the "dump" netdev can be connected up with a guest NIC and >>> host netdev. Create a hub, attach the guest NIC, attach the host >>> netdev, and attach the dump netdev. This allows the dump netdev to >>> see all traffic. >>> >>> 2. It lets you build virtual network segments. Several point-to-point >>> connections can be brought together. Start 3 VMs connected by the >>> "socket" netdev and have one of them use a hub. This may be >>> inefficient but I wouldn't be surprised if there are people out there >>> doing this. >> >> Those people will find other, superior ways to do this once this >> inefficient way is gone. We'd do them a favour, I'd say ;) >> >>> The point of this patch series is to remove the special-case net.c code >>> for the legacy "vlan" feature. Today's code makes it harder to >>> implement a clean QOM model and is a burden for the net subsystem in >>> general. This series takes the vlan functionality and puts it into a >>> normal netdev - it extracts the feature from net.c. >> >> Welcome improvement, but... >> >>> (If we didn't care about backwards compatibility we could just drop >>> vlans completely and rewrite the "dump" netdev to hook into the net.h >>> API somehow.) >> >> ... is backward compatiblity really worth the extra net client? >> >> Please excuse my ignorant question (I haven't studied the series): what >> kind of backward compatiblity exactly do we get here? Command line: >> -net option vlan still works? Or just semantic: whatever you could do >> with vlans you can now do with hubs? >> >> In case it's the latter: well, whatever you could do with vlans you can >> already do with external software, can't you? Why is it worthwhile to >> provide yet another way within QEMU? > > The aim is to keep the command-line vlan= syntax in tact. The hub > change is mostly internal. So it's an extra net client plus somewhat baroque magic to select this client when needed. And when the magic activates, performance suffers. The initiated will expect that, but it'll likely baffle mere users. We can document the issue, but mere users generally don't read documentation. > I agree it would be nice to drop entirely but I don't feel happy doing > that to users who might have QEMU buried in scripts somewhere. One > day they upgrade packages and suddenly their stuff doesn't work > anymore. The keywords is "might". Before we bend over backwards, I'd prefer to see some evidence of anyone actually profiting from it. Anyway, maintainer judgement call.
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, May 25, 2012 at 12:18 PM, Markus Armbruster wrote: > Stefan Hajnoczi writes: > >> On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote: >>> On Fri, 25 May 2012 01:59:06 +0800 >>> zwu.ker...@gmail.com wrote: >>> >>> > From: Zhi Yong Wu >>> > >>> > The patchset implements network hub stead of vlan. The main work was done >>> > by stefan, and i rebased it to latest QEMU upstream, did some testings >>> > and am responsible for pushing it to QEMU upstream. >>> >>> Honest question: does it really pay off to have this in qemu vs. using one >>> of >>> the externaly available solutions? >> >> For typical KVM setups this feature will be unused. >> >> However, the legacy QEMU "vlan" feature does have a few uses: >> >> 1. It's how the "dump" netdev can be connected up with a guest NIC and >> host netdev. Create a hub, attach the guest NIC, attach the host >> netdev, and attach the dump netdev. This allows the dump netdev to >> see all traffic. >> >> 2. It lets you build virtual network segments. Several point-to-point >> connections can be brought together. Start 3 VMs connected by the >> "socket" netdev and have one of them use a hub. This may be >> inefficient but I wouldn't be surprised if there are people out there >> doing this. > > Those people will find other, superior ways to do this once this > inefficient way is gone. We'd do them a favour, I'd say ;) > >> The point of this patch series is to remove the special-case net.c code >> for the legacy "vlan" feature. Today's code makes it harder to >> implement a clean QOM model and is a burden for the net subsystem in >> general. This series takes the vlan functionality and puts it into a >> normal netdev - it extracts the feature from net.c. > > Welcome improvement, but... > >> (If we didn't care about backwards compatibility we could just drop >> vlans completely and rewrite the "dump" netdev to hook into the net.h >> API somehow.) > > ... is backward compatiblity really worth the extra net client? > > Please excuse my ignorant question (I haven't studied the series): what > kind of backward compatiblity exactly do we get here? Command line: > -net option vlan still works? Or just semantic: whatever you could do > with vlans you can now do with hubs? > > In case it's the latter: well, whatever you could do with vlans you can > already do with external software, can't you? Why is it worthwhile to > provide yet another way within QEMU? The aim is to keep the command-line vlan= syntax in tact. The hub change is mostly internal. I agree it would be nice to drop entirely but I don't feel happy doing that to users who might have QEMU buried in scripts somewhere. One day they upgrade packages and suddenly their stuff doesn't work anymore. Stefan
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Stefan Hajnoczi writes: > On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote: >> On Fri, 25 May 2012 01:59:06 +0800 >> zwu.ker...@gmail.com wrote: >> >> > From: Zhi Yong Wu >> > >> > The patchset implements network hub stead of vlan. The main work was done >> > by stefan, and i rebased it to latest QEMU upstream, did some testings and >> > am responsible for pushing it to QEMU upstream. >> >> Honest question: does it really pay off to have this in qemu vs. using one of >> the externaly available solutions? > > For typical KVM setups this feature will be unused. > > However, the legacy QEMU "vlan" feature does have a few uses: > > 1. It's how the "dump" netdev can be connected up with a guest NIC and >host netdev. Create a hub, attach the guest NIC, attach the host >netdev, and attach the dump netdev. This allows the dump netdev to >see all traffic. > > 2. It lets you build virtual network segments. Several point-to-point >connections can be brought together. Start 3 VMs connected by the >"socket" netdev and have one of them use a hub. This may be >inefficient but I wouldn't be surprised if there are people out there >doing this. Those people will find other, superior ways to do this once this inefficient way is gone. We'd do them a favour, I'd say ;) > The point of this patch series is to remove the special-case net.c code > for the legacy "vlan" feature. Today's code makes it harder to > implement a clean QOM model and is a burden for the net subsystem in > general. This series takes the vlan functionality and puts it into a > normal netdev - it extracts the feature from net.c. Welcome improvement, but... > (If we didn't care about backwards compatibility we could just drop > vlans completely and rewrite the "dump" netdev to hook into the net.h > API somehow.) ... is backward compatiblity really worth the extra net client? Please excuse my ignorant question (I haven't studied the series): what kind of backward compatiblity exactly do we get here? Command line: -net option vlan still works? Or just semantic: whatever you could do with vlans you can now do with hubs? In case it's the latter: well, whatever you could do with vlans you can already do with external software, can't you? Why is it worthwhile to provide yet another way within QEMU?
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote: > On Fri, 25 May 2012 01:59:06 +0800 > zwu.ker...@gmail.com wrote: > > > From: Zhi Yong Wu > > > > The patchset implements network hub stead of vlan. The main work was done > > by stefan, and i rebased it to latest QEMU upstream, did some testings and > > am responsible for pushing it to QEMU upstream. > > Honest question: does it really pay off to have this in qemu vs. using one of > the externaly available solutions? For typical KVM setups this feature will be unused. However, the legacy QEMU "vlan" feature does have a few uses: 1. It's how the "dump" netdev can be connected up with a guest NIC and host netdev. Create a hub, attach the guest NIC, attach the host netdev, and attach the dump netdev. This allows the dump netdev to see all traffic. 2. It lets you build virtual network segments. Several point-to-point connections can be brought together. Start 3 VMs connected by the "socket" netdev and have one of them use a hub. This may be inefficient but I wouldn't be surprised if there are people out there doing this. The point of this patch series is to remove the special-case net.c code for the legacy "vlan" feature. Today's code makes it harder to implement a clean QOM model and is a burden for the net subsystem in general. This series takes the vlan functionality and puts it into a normal netdev - it extracts the feature from net.c. (If we didn't care about backwards compatibility we could just drop vlans completely and rewrite the "dump" netdev to hook into the net.h API somehow.) Stefan
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, May 25, 2012 at 4:53 AM, Luiz Capitulino wrote: > On Fri, 25 May 2012 01:59:06 +0800 > zwu.ker...@gmail.com wrote: > >> From: Zhi Yong Wu >> >> The patchset implements network hub stead of vlan. The main work was done by >> stefan, and i rebased it to latest QEMU upstream, did some testings and am >> responsible for pushing it to QEMU upstream. > > Honest question: does it really pay off to have this in qemu vs. using one of It's said that it can speed up packets delivery, but i have not do every bechmark testings. For more details, please refer to http://thread.gmane.org/gmane.comp.emulators.qemu/133362 > the externaly available solutions? Is there external available solutions?:), What are they? Open vSwitch? -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, 25 May 2012 01:59:06 +0800 zwu.ker...@gmail.com wrote: > From: Zhi Yong Wu > > The patchset implements network hub stead of vlan. The main work was done by > stefan, and i rebased it to latest QEMU upstream, did some testings and am > responsible for pushing it to QEMU upstream. Honest question: does it really pay off to have this in qemu vs. using one of the externaly available solutions?
[Qemu-devel] [PATCH v3 00/16] net: hub-based networking
From: Zhi Yong Wu The patchset implements network hub stead of vlan. The main work was done by stefan, and i rebased it to latest QEMU upstream, did some testings and am responsible for pushing it to QEMU upstream. Changelog from v2: 1.) add the support for hub own flow control [paolo] 2.) make the monitor output more reasonable hub info [jan kiszka] v2: 1.) cleanup some obsolete vlan info 2.) cleanup deliver/deliver_iov func pointers [paolo] 3.) support more flexible flow control [paolo] Stefan Hajnoczi (12): net: Add a hub net client net: Use hubs for the vlan feature net: Look up 'vlan' net clients using hubs hub: Check that hubs are configured correctly net: Drop vlan argument to qemu_new_net_client() net: Remove vlan qdev property net: Remove vlan code from net.c net: Remove VLANState net: Rename non_vlan_clients to net_clients net: Rename VLANClientState to NetClientState net: Rename vc local variables to nc net: Rename qemu_del_vlan_client() to qemu_del_net_client() Zhi Yong Wu (4): net: Make the monitor output more reasonable hub info net: cleanup deliver/deliver_iov func pointers net: determine if packets can be sent before net queue deliver packets hub: add the support for hub own flow control Makefile.objs |2 +- hw/cadence_gem.c|8 +- hw/dp8393x.c|6 +- hw/e1000.c | 10 +- hw/eepro100.c |8 +- hw/etraxfs_eth.c|8 +- hw/lan9118.c|8 +- hw/lance.c |2 +- hw/mcf_fec.c|6 +- hw/milkymist-minimac2.c |6 +- hw/mipsnet.c|6 +- hw/musicpal.c |6 +- hw/ne2000-isa.c |2 +- hw/ne2000.c |8 +- hw/ne2000.h |4 +- hw/opencores_eth.c |8 +- hw/pcnet-pci.c |4 +- hw/pcnet.c |6 +- hw/pcnet.h |6 +- hw/qdev-properties.c| 78 +-- hw/qdev.c |2 - hw/qdev.h |8 +- hw/rtl8139.c| 10 +- hw/smc91c111.c |6 +- hw/spapr_llan.c |4 +- hw/stellaris_enet.c |6 +- hw/usb/dev-network.c|8 +- hw/vhost_net.c | 24 +- hw/vhost_net.h |2 +- hw/virtio-net.c | 12 +- hw/xen_nic.c|7 +- hw/xgmac.c |6 +- hw/xilinx_axienet.c |6 +- hw/xilinx_ethlite.c |6 +- net.c | 606 ++- net.h | 85 net/dump.c | 28 ++- net/dump.h |2 +- net/hub.c | 298 +++ net/hub.h | 28 +++ net/queue.c | 42 ++-- net/queue.h | 25 +-- net/slirp.c | 32 +-- net/slirp.h |2 +- net/socket.c| 66 +++--- net/socket.h|2 +- net/tap-win32.c | 27 +- net/tap.c | 45 ++-- net/tap.h | 21 +- net/vde.c | 17 +- net/vde.h |3 +- qemu-common.h |3 +- slirp/if.c |5 - slirp/libslirp.h|1 - 54 files changed, 811 insertions(+), 826 deletions(-) create mode 100644 net/hub.c create mode 100644 net/hub.h -- 1.7.6
