qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC PATCH v2 0/9] net: Handle short frames for SLiRP/TAP interfaces


From: Bin Meng
Subject: [RFC PATCH v2 0/9] net: Handle short frames for SLiRP/TAP interfaces
Date: Wed, 3 Mar 2021 17:21:37 +0800

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.

To provide better compatibility, for packets sent from SLiRP/TAP, we
change to pad short frames before sending it out to the other end.
This ensures SLiRP/TAP as an Ethernet sender do not violate the spec.
But with this change, the behavior of dropping short frames 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 are still supported and short frames can still pass through
SLiRP/TAP interfaces.

This commit 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 v2:
- only pad short frames for SLiRP/TAP interfaces

Bin Meng (9):
  net: Pad short frames to minimum size before send from SLiRP/TAP
  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

 include/net/eth.h |  1 +
 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/vmxnet3.c  | 10 ----------
 net/net.c         | 12 ++++++++++++
 10 files changed, 14 insertions(+), 96 deletions(-)

-- 
2.7.4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]