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

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 8 Mar 2021 at 03:48, Jason Wang <jasowang@redhat.com> wrote:
> Do we need to care about other type of networking backends? E.g socket.
>
> Or at least we should keep the padding logic if we can't audit all of
> the backends.

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 think (3) is pretty clearly the worst of these, since it
requires every NIC model to handle it; it has no advantages
over (2) that I can see. I don't have a strong take on whether
we'd rather have (1) or (2): it's a tradeoff between whether
we support modelling of short frames vs simplicity of code.
I'd just like us to be clear about what point or points in
the code have the responsibility for padding short frames.

On
+    if (sender->info->type == NET_CLIENT_DRIVER_USER ||
+        sender->info->type == NET_CLIENT_DRIVER_TAP) {

vs
> if (sender->info->type != NET_CLIENT_DRIVER_NIC)

another option would be to add a 'bool pad_short_tx_frames' to
the NetClientInfo struct, and have those things which don't
pad set it to true.

thanks
-- PMM