Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

Michael S. Tsirkin
2010-01-27T09:28:05Z

On Tue, Jan 26, 2010 at 02:50:28PM -0600, Anthony Liguori wrote:
> On 01/26/2010 02:47 PM, Anthony Liguori wrote:
>> On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
>>> This patch adds raw socket backend to qemu and is based on Or Gerlitz's
>>> patch re-factored and ported to the latest qemu-kvm git tree.
>>> It also includes support for vnet_hdr option that enables gso/checksum
>>> offload with raw backend. You can find the linux kernel patch to support
>>> this feature here.
>>> http://thread.gmane.org/gmane.linux.network/150308
>>>
>>> Signed-off-by: Sridhar Samudrala<sri@us.ibm.com>
>>
>> See the previous discussion about the raw backend from Or's original
>> patch. There's no obvious reason why we should have this in addition
>> to a tun/tap backend.

I thought this was cleared already: vepa support is the requirement
here. Existing tap solution requires management of host linux
networking which some users would rather avoid.

>> The only use-case I know of is macvlan but macvtap addresses this
>> functionality while not introduce the rather nasty security problems
>> associated with a raw backend.

I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can work with any network card in promisc mode.

> Not to mention that from a user perspective, raw makes almost no sense
> as it's an obscure socket protocol family.
>
> A user wants to do useful things like bridged networking or direct VF
> assignment. We should have -net backends that reflect things that make
> sense to a user.
>
> Regards,
>
> Anthony Liguori

I agree to that. People don't even seem to agree whether it's a raw
socket or a packet socket :) We need a better name for this option: what
it really does is rely on an external device to loopback a packet to us,
so how about -net loopback or -net extbridge?

--
MST