netdev - Re: Virtio_net support vxlan encapsulation package TSO offload discuss

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-next>] [day] [month] [year] [list]

Message-ID: <c2f735e4-eddf-f737-2afe-35a93289f8d4@redhat.com>
Date:   Tue, 8 Nov 2016 19:13:53 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     "Zhangming (James, Euler)" <james.zhangming@...wei.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: Virtio_net support vxlan encapsulation package TSO offload
 discuss

Cc Michael

On 2016年11月08日 16:34, Zhangming (James, Euler) wrote:
>
> In container scenario, OVS is installed in the Virtual machine, and 
> all the containers connected to the OVS will communicated through 
> VXLAN encapsulation.
>
> By now, virtio_net does not support TSO offload for VXLAN encapsulated 
> TSO package. In this condition, the performance is not good, sender is 
> bottleneck
>
> I googled this scenario, but I didn’t find any information. Will 
> virtio_net support VXLAN encapsulation package TSO offload later?
>

Yes and for both sender and receiver.

> My idea is virtio_net open encapsulated TSO offload, and transport 
> encapsulation info to TUN, TUN will parse the info and build skb with 
> encapsulation info.
>
> OVS or kernel on the host should be modified to support this. Using 
> this method, the TCP performance aremore than 2x as before.
>
> Any advice and suggestions for this idea or new idea will be greatly 
> appreciated!
>
> Best regards,
>
>    James zhang
>

Sounds very good. And we may also need features bits 
(VIRTIO_NET_F_GUEST|HOST_GSO_X) for this.

This is in fact one of items in networking todo list. (See 
http://www.linux-kvm.org/page/NetworkingTodo). While at it, we'd better 
support not only VXLAN but also other tunnels.

We can start with the spec work, or if you've already had some bits you 
can post them as RFC for early review.

Thanks