Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax

[Stefan Hajnoczi]

On Sat, Feb 18, 2012 at 8:57 AM, Zhi Yong Wu <address@hidden> wrote:
> On Fri, Feb 17, 2012 at 6:55 PM, Stefan Hajnoczi <address@hidden> wrote:
>> On Fri, Feb 17, 2012 at 6:54 AM, Zhi Yong Wu <address@hidden> wrote:
>>> I would like to know if some one is playing around with the patchset.
>>>
>>> If yes, can any one make one response? I am very interested in rebasing
>>> it, and then playing with it.
>>
>> AFAIK no one is working on it - the main thing that is missing here is
>> tests so that we don't break the existing "VLAN" feature and
>> command-line interface.
> If you are available, can you let us know what their difference among
> -net, -netdev and hub? their drawback? their advantage? thanks

-net is the old command-line option for defining both guest network
devices (e.g. e1000, virtio-net) and also host network devices (e.g.
tap, socket, user).  It uses the VLAN concept and does not use "peer"
IIRC.

-netdev/-device is the new way to specify networking.  You use -netdev
to define host network devices (e.g. tap, socket, user).  You use
-device to specify guest network devices (e.g. e1000, virtio-net-pci).
 This approach does not use the "VLAN" feature and instead uses
->peer.  That means nic->per == netdev and netdev->peer == nic.

There is a performance improvement with -netdev/-device because we do
not use "VLAN" forwarding in the network subsystem and I think it
enables tap offloads (checksum offload, GRO, TSO) but I don't remember
the detalis there.

The "hub" is the same as QEMU "VLANs" except it removes all the
special case code in the network subsystem and instead implements the
functionality in a normal NetClientState.  Now the hub is no longer
part of the network subsystem, its just a net device in QEMU.

The critical thing when transitioning to the hub device is that the
old "VLAN" command-line options must continue to work!  Users should
see no difference from before.  But internally the net subsystem will
only deal with NetClientState instead of VLANClientState plus
VLANState.  Everything will use ->peer.

Stefan