[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: |
Mon, 8 Mar 2021 12:12:44 +0800 |
On Mon, Mar 8, 2021 at 11:48 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2021/3/4 3:11 上午, Philippe Mathieu-Daudé wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > The minimum Ethernet frame length is 60 bytes. For short frames with
> > smaller length like ARP packets (only 42 bytes), on a real world NIC
> > it can choose either padding its length to the minimum required 60
> > bytes, or sending it out directly to the wire. Such behavior can be
> > hardcoded or controled by a register bit. Similarly on the receive
> > path, NICs can choose either dropping such short frames directly or
> > handing them over to software to handle.
> >
> > On the other hand, for the network backends SLiRP/TAP, they don't
> > expose a way to control the short frame behavior. As of today they
> > just send/receive data from/to the other end connected to them,
> > which means any sized packet is acceptable. So they can send and
> > receive short frames without any problem. It is observed that ARP
> > packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send
> > these ARP packets to the other end which might be a NIC model that
> > does not allow short frames to pass through.
>
>
> Do we need to care about other type of networking backends? E.g socket.
>
I am not sure as I never used other backends. If someone who is more
familiar with the network codes better than me can confirm other
backends are also needed, we might do:
if (sender->info->type != NET_CLIENT_DRIVER_NIC)
> Or at least we should keep the padding logic if we can't audit all of
> the backends.
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 <=
- 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, 2021/03/09
- 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