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