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

From: Peter Maydell <peter.maydell@linaro.org>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: "Dmitry Fleytman" <dmitry.fleytman@gmail.com>,
	"Jason Wang" <jasowang@redhat.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 10:13:28 +0000	[thread overview]
Message-ID: <CAFEAcA89xLMogR5-tUH-LW37Lr+py3LXQRgaO9_P8r8w-0gfzA@mail.gmail.com> (raw)
In-Reply-To: <CAEUhbmUY89OEpBpxCZzya=KKb1U5KBO=rPArn8yre7fmZe1q5A@mail.gmail.com>

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.

thanks
-- PMM