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

[Bin Meng <bmeng.cn@gmail.com>]

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