netdev - Re: [RFC PATCH net-next] virtio_net: Support UDP Tunnel offloads.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <abd81d97-c692-a45c-8f08-c31d2e894e9e@redhat.com>
Date:   Mon, 19 Dec 2016 09:26:49 -0500
From:   Vlad Yasevich <vyasevic@...hat.com>
To:     Or Gerlitz <gerlitz.or@...il.com>, Jarno Rajahalme <jarno@....org>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        james.zhangming@...wei.com,
        "Michael S. Tsirkin <mst@...hat.com> (mst@...hat.com)" 
        <mst@...hat.com>, ailan@...hat.com
Subject: Re: [RFC PATCH net-next] virtio_net: Support UDP Tunnel offloads.

On 12/15/2016 02:07 AM, Or Gerlitz wrote:
> On Fri, Nov 18, 2016 at 1:01 AM, Jarno Rajahalme <jarno@....org> wrote:
>> This patch is a proof-of-concept I did a few months ago for UDP tunnel
>> offload support in virtio_net interface [..]
> 
> What's the use case you were considering for a guest running a UDP based VTEP?

Two cases that I've been aware of are nested virt or simply a guest acting
as router/bridge with possible different tunnel devices.

-vlad

> 
>> Real implementation needs to extend the virtio_net header rather than
>> piggy-backing on existing fields.  Inner MAC length (or inner network
>> offset) also needs to be passed as a new field.  Control plane (QEMU)
>> also needs to be updated.
>>
>> All testing was done using Geneve, but this should work for all UDP
>> tunnels the same.