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

[Yan Vugenfirer]

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.

Best regards,

Yan.

thanks
-- PMM