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

Date:   Tue, 8 Nov 2016 19:17:25 +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>,
        Vlad Yasevic <vyasevic@...hat.com>
Subject: Re: Virtio_net support vxlan encapsulation package TSO offload
 discuss



On 2016年11月08日 19:13, Jason Wang wrote:
> 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.

Cc Vlad who is working on extending virtio-net headers.

>
> 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