All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Meng <bmeng.cn@gmail.com>
To: "Jason Wang" <jasowang@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	qemu-devel@nongnu.org
Cc: Bin Meng <bmeng.cn@gmail.com>
Subject: [PATCH v2 00/13] net: Pad short frames for network backends
Date: Mon, 15 Mar 2021 15:57:05 +0800	[thread overview]
Message-ID: <20210315075718.5402-1-bmeng.cn@gmail.com> (raw)

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, we change to pad short frames before sending it out to the
other end. This ensures a backend as an Ethernet sender does 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 cannot be supported as well.

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 v2:
- Do the padding in the slirp/tap codes, instead of net core
- Add a 'do_not_pad' flag to NetClientState to allow net clients to
  tell peer that no padding is needed, e.g.: virtio-net

Bin Meng (13):
  net: Add ETH_ZLEN define in eth.h
  net: Add a 'do_not_pad" to NetClientState
  net: slirp: Pad short frames to minimum size before send
  net: tap: Pad short frames to minimum size before send
  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

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

-- 
2.25.1



             reply	other threads:[~2021-03-15  7:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15  7:57 Bin Meng [this message]
2021-03-15  7:57 ` [PATCH v2 01/13] net: Add ETH_ZLEN define in eth.h Bin Meng
2021-03-15  9:13   ` Philippe Mathieu-Daudé
2021-03-15 10:15     ` Bin Meng
2021-03-15 10:24       ` Philippe Mathieu-Daudé
2021-03-15  7:57 ` [PATCH v2 02/13] net: Add a 'do_not_pad" to NetClientState Bin Meng
2021-03-15  9:17   ` Philippe Mathieu-Daudé
2021-03-15  9:18     ` Philippe Mathieu-Daudé
2021-03-15  9:22       ` Philippe Mathieu-Daudé
2021-03-15 10:17         ` Bin Meng
2021-03-15 10:21           ` Peter Maydell
2021-03-15  7:57 ` [PATCH v2 03/13] net: slirp: Pad short frames to minimum size before send Bin Meng
2021-03-16  2:25   ` Jason Wang
2021-03-15  7:57 ` [PATCH v2 04/13] net: tap: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 05/13] hw/net: virtio-net: Initialize nc->do_not_pad to true Bin Meng
2021-03-15  7:57 ` [PATCH v2 06/13] hw/net: e1000: Remove the logic of padding short frames in the receive path Bin Meng
2021-03-15  7:57 ` [PATCH v2 07/13] hw/net: vmxnet3: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 08/13] hw/net: i82596: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 09/13] hw/net: ne2000: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 10/13] hw/net: pcnet: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 11/13] hw/net: rtl8139: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 12/13] hw/net: sungem: " Bin Meng
2021-03-15  7:57 ` [PATCH v2 13/13] hw/net: sunhme: " Bin Meng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210315075718.5402-1-bmeng.cn@gmail.com \
    --to=bmeng.cn@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.