Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9d64ef0e-5e92-98f7-4620-c50561dad3a8@norrbonn.se>
Date:   Thu, 19 Jan 2023 14:12:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: vhost-net
Content-Language: en-US
To:     Jason Wang <jasowang@redhat.com>
Cc:     "Michael S. Tsirkin" <mst@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>
References: <75a2cb16-9e39-4123-de8e-b846c9b482f0@norrbonn.se>
 <CACGkMEu-hZ2x8EnstJ_FQ7tWMj=zLf7GAcwyHuAzvQQncTqEYg@mail.gmail.com>
From:   Jonas Bonn <jonas@norrbonn.se>
In-Reply-To: <CACGkMEu-hZ2x8EnstJ_FQ7tWMj=zLf7GAcwyHuAzvQQncTqEYg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Jason,

Thanks for your feedback.

On 17/01/2023 05:26, Jason Wang wrote:
> On Mon, Jan 16, 2023 at 4:59 PM Jonas Bonn <jonas@norrbonn.se> wrote:
>>
>> For an IFF_TUN device, should vhost-net not be adding an implicit
>> ethernet header in _build_xdp()?
> 
> Probably.
> 
> Actually, this makes me think that we should disable XDP for TUN?

After playing around with this for a week, I agree.  It appears that as 
soon as the XDP paths come into play there are requirements on having 
valid ethernet headers in place; the TUN interface doesn't even have a 
MAC address to validate against so packets in the TCP paths get dropped. 
  UDP packet validation apparently only cares about the ethernet "proto" 
field so these can be made to go through with less rigorous ethernet 
addressing.

That said, when the XDP path is bypassed, the TUN device works fine with 
vhost-net.

> 
>> Can this be done without backward
>> compatibility implications?
>>
> 
> The path is used by vhost-net only, so I think we are fine.
> 
> Patch is more than welcomed.

I'll try to put something together.

/Jonas