Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP

[Bin Meng]

On Tue, Mar 9, 2021 at 8:30 PM Yan Vugenfirer <yvugenfi@redhat.com> wrote:
>
>
>
> On 9 Mar 2021, at 12:13 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Tue, 9 Mar 2021 at 09:01, Bin Meng <bmeng.cn@gmail.com> wrote:
>
>
> Hi Jason,
>
> On Tue, Mar 9, 2021 at 5:00 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
>
> Hi Jason,
>
> On Tue, Mar 9, 2021 at 4:57 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
>
> On 2021/3/9 4:35 下午, Bin Meng wrote:
>
> Hi Jason,
>
> On Tue, Mar 9, 2021 at 4:23 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2021/3/8 6:22 下午, Peter Maydell wrote:
>
> I think the key thing we need to do here is make a decision
> and be clear about what we're doing. There are three options
> I can see:
>
> (1) we say that the net API demands that backends pad
> packets they emit to the minimum ethernet frame length
> unless they specifically are intending to emit a short frame,
> and we fix any backends that don't comply (or equivalently,
> add support in the core code for a backend to mark itself
> as "I don't pad; please do it for me").
>
> (2) we say that the networking subsystem doesn't support
> short packets, and just have the common code always enforce
> padding short frames to the minimum length somewhere between
> when it receives a packet from a backend and passes it to
> a NIC model.
>
> (3) we say that it's the job of the NIC models to pad
> short frames as they see them coming in.
>
>
> I'm not sure how much value we can gain from (1). So (2) looks better to me.
>
> Bin or Philippe, want to send a new version?
>
> I think this series does what (2) asks for. Or am I missing anything?
>
>
>
> It only did the padding for user/TAP.
>
>
>
> (hit send too soon ...)
>
> Ah, so we want this:
>
> if (sender->info->type != NET_CLIENT_DRIVER_NIC)
>
> correct?
>
>
> No, option (2) is "always pad short packets regardless of
> sender->info->type". Even if a NIC driver sends out a short
> packet, we want to pad it, because we might be feeding it to
> something that assumes it does not see short packets.
>
>
> Some thought on this option - in such case with virtio-net, can we also get 
> an indication from the device that the packet will be padded?
> Currently we are padding short packets in Windows driver (this is MS 
> certification requirement), and it will be nice not do to this in the guest 
> if device will announce such capability.
>

This is more of a virtio-net specification question. virtio-net should
expose a register bit to control this behavior, just like a real world
NIC does.

Regards,
Bin