[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before se
From: |
Bin Meng |
Subject: |
Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP |
Date: |
Tue, 9 Mar 2021 17:01:03 +0800 |
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:
> > >>> 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?
> >
> >
> > 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?
Regards,
Bin
- [RFC PATCH v3 00/10] net: Handle short frames for SLiRP/TAP interfaces, Philippe Mathieu-Daudé, 2021/03/03
- [RFC PATCH v3 01/10] net: Use 'struct iovec' in qemu_send_packet_async_with_flags(), Philippe Mathieu-Daudé, 2021/03/03
- [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Philippe Mathieu-Daudé, 2021/03/03
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Jason Wang, 2021/03/07
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/07
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Peter Maydell, 2021/03/08
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Jason Wang, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Jason Wang, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP,
Bin Meng <=
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Peter Maydell, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Yan Vugenfirer, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/09
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Jason Wang, 2021/03/12
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Jason Wang, 2021/03/10
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/10
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Jason Wang, 2021/03/10
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Bin Meng, 2021/03/11
- Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP, Peter Maydell, 2021/03/11