Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking

[Markus Armbruster <armbru@redhat.com>]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Fri, May 25, 2012 at 12:18 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> writes:
>>
>>> On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote:
>>>> On Fri, 25 May 2012 01:59:06 +0800
>>>> zwu.kernel@gmail.com wrote:
>>>>
>>>> > From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>>>> >
>>>> > 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.