[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a164aeb5-f7ee-1d49-7df8-b988831241b3@linux.alibaba.com>
Date:   Mon, 29 Oct 2018 11:51:45 +0800
From:   Jianfeng Tan <jianfeng.tan@...ux.alibaba.com>
To:     Jason Wang <jasowang@...hat.com>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, mst@...hat.com
Subject: Re: [PATCH] net/packet: fix packet drop as of virtio gso
On 10/29/2018 10:40 AM, Jason Wang wrote:
>
> On 2018/10/28 上午7:42, Jianfeng Tan wrote:
>>
>> On 10/8/2018 11:14 AM, Jason Wang wrote:
>>>
>>>
>>> On 2018年09月29日 23:41, Jianfeng Tan wrote:
>>>> When we use raw socket as the vhost backend, a packet from virito with
>>>> gso offloading information, cannot be sent out in later validaton at
>>>> xmit path, as we did not set correct skb->protocol which is further 
>>>> used
>>>> for looking up the gso function.
>>>
>>> Hi:
>>>
>>> May I ask the reason for using raw socket for vhost? It was not a 
>>> common setup with little care in the past few years. And it was slow 
>>> since it lacks some recent improvements. Can it be replaced with e.g 
>>> macvtap?
>>
>> Hi Jason,
>>
>> Apologize for late response. We are in container environment, in 
>> which case veth is used mostly. Either tap or macvtap cannot be put 
>> into an isolated netns. 
>
>
> I think it can? See 17af2bce88d31e65ed73d638bb752d2e13c66ced.
This commit gives an example of creating a macvtap on to of a veth 
interface, which is interesting to try. The shortcoming, if I understand 
it correctly, it still needs the network plugin to create the macvtap 
interface for containers.
>
>
>> Another thing could be macvlan as the backend of vhost, which is not 
>> supported either. So unfortunately, improving raw socket is the only 
>> choice I suppose.
>
>
> Btw, you can setup macvtap on top of veth. Does this help?
Good idea. Will have a try.
Thanks,
Jianfeng
>
> Thanks
>
>
>>
>> Thanks,
>> Jianfeng
Powered by blists - more mailing lists
 
