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

From: Bin Meng <bmeng.cn@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Dmitry Fleytman" <dmitry.fleytman@gmail.com>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP
Date: Tue, 9 Mar 2021 16:35:41 +0800	[thread overview]
Message-ID: <CAEUhbmU-KDUBADcX+bZHjH0thhddTSQ=Qtb56GztdRzPKE4Xhw@mail.gmail.com> (raw)
In-Reply-To: <edce617c-3591-a172-ad18-3bf138af26e0@redhat.com>

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:
> > 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.
>
>
> 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?

Regards,
Bin