From: Jason Wang <jasowang@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [PATCH v5 00/12] net: Pad short frames for network backends
Date: Mon, 22 Mar 2021 15:08:58 +0800 [thread overview]
Message-ID: <859cd26a-feb2-ed62-98d5-764841a468cf@redhat.com> (raw)
In-Reply-To: <20210317062638.72626-1-bmeng.cn@gmail.com>
在 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.
Thanks
>
next prev parent reply other threads:[~2021-03-22 7:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 6:26 [PATCH v5 00/12] net: Pad short frames for network backends Bin Meng
2021-03-17 6:26 ` [PATCH v5 01/12] net: eth: Add a helper to pad a short Ethernet frame Bin Meng
2021-03-17 6:26 ` [PATCH v5 02/12] net: Add a 'do_not_pad" to NetClientState Bin Meng
2021-03-17 6:26 ` [PATCH v5 03/12] net: Pad short frames to minimum size before sending from SLiRP/TAP Bin Meng
2021-03-17 6:26 ` [PATCH v5 04/12] hw/net: virtio-net: Initialize nc->do_not_pad to true Bin Meng
2021-03-17 6:26 ` [PATCH v5 05/12] hw/net: e1000: Remove the logic of padding short frames in the receive path Bin Meng
2021-03-17 6:26 ` [PATCH v5 06/12] hw/net: vmxnet3: " Bin Meng
2021-03-17 6:26 ` [PATCH v5 07/12] hw/net: i82596: " Bin Meng
2021-03-17 6:26 ` [PATCH v5 08/12] hw/net: ne2000: " Bin Meng
2021-03-17 6:26 ` [PATCH v5 09/12] hw/net: pcnet: " Bin Meng
2021-03-17 6:26 ` [PATCH v5 10/12] hw/net: rtl8139: " Bin Meng
2021-03-17 6:26 ` [PATCH v5 11/12] hw/net: sungem: " Bin Meng
2021-03-17 6:26 ` [PATCH v5 12/12] hw/net: sunhme: " Bin Meng
2021-03-22 1:28 ` [PATCH v5 00/12] net: Pad short frames for network backends Bin Meng
2021-03-22 7:08 ` Jason Wang [this message]
2021-05-14 5:10 ` 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=859cd26a-feb2-ed62-98d5-764841a468cf@redhat.com \
--to=jasowang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).