[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/12] net: Pad short frames for network backends
From: |
Bin Meng |
Subject: |
Re: [PATCH v5 00/12] net: Pad short frames for network backends |
Date: |
Fri, 14 May 2021 13:10:23 +0800 |
Hi Jason,
On Mon, Mar 22, 2021 at 3:10 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/3/17 下午2:26, Bin Meng 写道:
> > 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.
> >
> > Changes in v5:
> > - minor update on commit message
> > - update the eth_pad_short_frame() comment
> >
> > Changes in v4:
> > - change 'ethernet' to 'Ethernet'
> > - do not inline the helper
> > - check the padded buffer size to avoid buffer overflow
> > - squash slirp/tap commits into one
> >
> > Changes in v3:
> > - use 'without' instead of 'sans'
> > - add a helper to pad short frames
> > - add a comment to 'do_not_pad'
> > - use the pad_short_frame() helper
> >
> > Bin Meng (12):
> > net: eth: Add a helper to pad a short Ethernet frame
> > net: Add a 'do_not_pad" to NetClientState
> > net: Pad short frames to minimum size before sending from SLiRP/TAP
> > hw/net: virtio-net: Initialize nc->do_not_pad to true
> > hw/net: e1000: Remove the logic of padding short frames in the receive
> > path
> > hw/net: vmxnet3: Remove the logic of padding short frames in the
> > receive path
> > hw/net: i82596: Remove the logic of padding short frames in the
> > receive path
> > hw/net: ne2000: Remove the logic of padding short frames in the
> > receive path
> > hw/net: pcnet: Remove the logic of padding short frames in the receive
> > path
> > hw/net: rtl8139: Remove the logic of padding short frames in the
> > receive path
> > hw/net: sungem: Remove the logic of padding short frames in the
> > receive path
> > hw/net: sunhme: Remove the logic of padding short frames in the
> > receive path
> >
> > hw/net/e1000.c | 11 +----------
> > hw/net/i82596.c | 18 ------------------
> > hw/net/ne2000.c | 12 ------------
> > hw/net/pcnet.c | 9 ---------
> > hw/net/rtl8139.c | 12 ------------
> > hw/net/sungem.c | 14 --------------
> > hw/net/sunhme.c | 11 -----------
> > hw/net/virtio-net.c | 4 ++++
> > hw/net/vmxnet3.c | 10 ----------
> > include/net/eth.h | 17 +++++++++++++++++
> > include/net/net.h | 1 +
> > net/eth.c | 17 +++++++++++++++++
> > net/slirp.c | 10 ++++++++++
> > net/tap-win32.c | 10 ++++++++++
> > net/tap.c | 10 ++++++++++
> > 15 files changed, 70 insertions(+), 96 deletions(-)
>
>
> I've queued patch 1-4 for 6.0 and the reset for 6.1.
It seems the reset has not been applied for 6.1?
Regards,
Bin
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v5 00/12] net: Pad short frames for network backends,
Bin Meng <=