qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/6] Add netmap backend offloadings support


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 0/6] Add netmap backend offloadings support
Date: Thu, 16 Jan 2014 17:08:40 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jan 14, 2014 at 11:59:44AM +0100, Vincenzo Maffione wrote:
> (3) There is actually an important problem. In the previous patch version, 
> TCP/UDP traffic was
>     supported between two guests attached to a VALE switch if and only if 
> both guests use (or
>     don't) the same offloadings: e.g. two virtio-net guests or two e1000 
> guests. This is why
>     in this version I put the commit which adds the support for netmap as the 
> last one and
>     I temporarily disable the offloading feature (e.g. netmap_has_vnet_hdr() 
> returns false).
>     We are working at adding proper support also in the general case in which 
> there is
>     a mismatch between the NIC offloadings capabilities. As soon as we have 
> proper support,
>     we can enable it in net/netmap.c.
>     What do you think about that? What's the best way to manage this 
> temporary lack of
>     support?

What you described is known problem in QEMU.  You cannot unplug a
vnet_hdr-enabled tap netdev and plug in a non-vnet_hdr socket netdev
since the socket netdev and its remote side don't understand vnet_hdr.
This has stopped us from supporting changing NetClient peers at runtime.

When this issue was raised we figured we'll have to add code to QEMU to
emulate the offload in software (i.e. TSO, checksums, etc).  But no one
has implemented that yet (although vmxnet3 has VMware offload software
emulation IIRC).

So maybe the answer is to finally implement vnet_hdr offload emulation
inside QEMU?  Then netmap can negotiate with its remote side and fall
back to offload emulation if the remote side doesn't understand
vnet_hdr.

Keep in mind that virtio-net does not allow the host to disable an
offload feature that was already enabled, except after the device has
been reset.  This precludes a simple solution where we just tell the
guest to stop using vnet_hdr.

I don't want to merge the tap -> net API changes and netmap offload
enablement until there is a solution to this.

> Vincenzo Maffione (6):
>   net: change vnet-hdr TAP prototypes
>   net: removing tap_using_vnet_hdr() function

Happy with these two patches, we can merge them regardless of the rest
of this series.  Still giving Michael Tsirkin a chance to review since
the special tap vnet_hdr interface is used closely by vhost_net.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]