Re: [PATCH v6 0/8] net: Pad short frames for network backends

[Bin Meng]

Hi Cédric,

On Wed, Mar 1, 2023 at 5:13 PM Cédric Le Goater <clg@kaod.org> wrote:
>
> Hello Bin,
>
> On 3/1/23 10:01, bmeng.cn@gmail.com wrote:
> > From: Bin Meng <bmeng@tinylab.org>
> >
> > 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 like 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.
> >
> > To provide better compatibility, for packets sent from QEMU network
> > backends like SLiRP/TAP, we change to pad short frames before sending
> > it out to the other end, if the other end does not forbid it via the
> > nc->do_not_pad flag. This ensures a backend as an Ethernet sender
> > does not violate the spec. But with this change, the behavior of
> > dropping short frames from SLiRP/TAP interfaces in the NIC model
> > cannot be emulated because it always receives a packet that is spec
> > complaint. The capability of sending short frames from NIC models is
> > still supported and short frames can still pass through SLiRP/TAP.
> >
> > This series should be able to fix the issue as reported with some
> > NIC models before, that ARP requests get dropped, preventing the
> > guest from becoming visible on the network. It was workarounded in
> > these NIC models on the receive path, that when a short frame is
> > received, it is padded up to 60 bytes.
>
> I guess we can drop this code in ftgmac100.c also then :
>
>      /* TODO : Pad to minimum Ethernet frame length */
>      /* handle small packets.  */
>      if (size < 10) {
>          qemu_log_mask(LOG_GUEST_ERROR, "%s: dropped frame of %zd bytes\n",
>                        __func__, size);
>          return size;
>      }
>
> Correct ? No need to resend. I can take care of it.
>

Yes, I think so. Thanks!

Regards,
Bin