qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Dmitry Fleytman" <dmitry.fleytman@gmail.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Bin Meng" <bmeng.cn@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP
Date: Wed,  3 Mar 2021 20:11:57 +0100	[thread overview]
Message-ID: <20210303191205.1656980-3-philmd@redhat.com> (raw)
In-Reply-To: <20210303191205.1656980-1-philmd@redhat.com>

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.

The following 2 commits seem to be the one to workaround this issue
in e1000 and vmxenet3 before, and should probably be reverted.

  commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)")
  commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size (60 bytes)")

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Message-Id: <1614763306-18026-2-git-send-email-bmeng.cn@gmail.com>
[PMD: Use struct iovec for zero-copy]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 include/net/eth.h |  1 +
 net/net.c         | 14 ++++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/net/eth.h b/include/net/eth.h
index 0671be69165..7c825ecb2f7 100644
--- a/include/net/eth.h
+++ b/include/net/eth.h
@@ -31,6 +31,7 @@
 
 #define ETH_ALEN 6
 #define ETH_HLEN 14
+#define ETH_ZLEN 60     /* Min. octets in frame sans FCS */
 
 struct eth_header {
     uint8_t  h_dest[ETH_ALEN];   /* destination eth addr */
diff --git a/net/net.c b/net/net.c
index 159e4d0ec25..d42ac9365eb 100644
--- a/net/net.c
+++ b/net/net.c
@@ -620,6 +620,7 @@ static ssize_t qemu_send_packet_async_with_flags(NetClientState *sender,
                                                  const uint8_t *buf, int size,
                                                  NetPacketSent *sent_cb)
 {
+    static const uint8_t null_buf[ETH_ZLEN] = { };
     NetQueue *queue;
     int ret;
     int iovcnt = 1;
@@ -628,6 +629,10 @@ static ssize_t qemu_send_packet_async_with_flags(NetClientState *sender,
             .iov_base = (void *)buf,
             .iov_len = size,
         },
+        [1] = {
+            .iov_base = (void *)null_buf,
+            .iov_len = ETH_ZLEN,
+        },
     };
 
 #ifdef DEBUG_NET
@@ -639,6 +644,15 @@ static ssize_t qemu_send_packet_async_with_flags(NetClientState *sender,
         return size;
     }
 
+    /* Pad to minimum Ethernet frame length for SLiRP and TAP */
+    if (sender->info->type == NET_CLIENT_DRIVER_USER ||
+        sender->info->type == NET_CLIENT_DRIVER_TAP) {
+        if (size < ETH_ZLEN) {
+            iov[1].iov_len = ETH_ZLEN - size;
+            iovcnt = 2;
+        }
+    }
+
     /* Let filters handle the packet first */
     ret = filter_receive_iov(sender, NET_FILTER_DIRECTION_TX,
                              sender, flags, iov, iovcnt, sent_cb);
-- 
2.26.2



  parent reply	other threads:[~2021-03-03 19:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 19:11 [RFC PATCH v3 00/10] net: Handle short frames for SLiRP/TAP interfaces Philippe Mathieu-Daudé
2021-03-03 19:11 ` [RFC PATCH v3 01/10] net: Use 'struct iovec' in qemu_send_packet_async_with_flags() Philippe Mathieu-Daudé
2021-03-03 19:11 ` Philippe Mathieu-Daudé [this message]
2021-03-08  3:48   ` [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP Jason Wang
2021-03-08  4:12     ` Bin Meng
2021-03-08 10:22     ` Peter Maydell
2021-03-09  8:23       ` Jason Wang
2021-03-09  8:35         ` Bin Meng
2021-03-09  8:57           ` Jason Wang
2021-03-09  9:00             ` Bin Meng
2021-03-09  9:01               ` Bin Meng
2021-03-09 10:13                 ` Peter Maydell
2021-03-09 10:17                   ` Bin Meng
2021-03-09 12:30                   ` Yan Vugenfirer
2021-03-09 12:33                     ` Bin Meng
2021-03-12  6:25                     ` Jason Wang
2021-03-11  3:01                   ` Jason Wang
2021-03-11  3:12                     ` Bin Meng
2021-03-11  3:33                       ` Jason Wang
2021-03-11  7:35                         ` Bin Meng
2021-03-11  9:43                     ` Peter Maydell
2021-03-11  9:58                       ` Bin Meng
2021-03-11 10:22                         ` Peter Maydell
2021-03-11 10:27                           ` Bin Meng
2021-03-12  6:22                             ` Jason Wang
2021-03-12  6:28                               ` Bin Meng
2021-03-12  6:50                                 ` Jason Wang
2021-03-12  6:53                                   ` Bin Meng
2021-03-12  7:02                                     ` Jason Wang
2021-03-03 19:11 ` [RFC PATCH v3 03/10] hw/net: e1000: Remove the logic of padding short frames in the receive path Philippe Mathieu-Daudé
2021-03-03 19:11 ` [RFC PATCH v3 04/10] hw/net: vmxnet3: " Philippe Mathieu-Daudé
2021-03-03 19:12 ` [RFC PATCH v3 05/10] hw/net: i82596: " Philippe Mathieu-Daudé
2021-03-03 19:12 ` [RFC PATCH v3 06/10] hw/net: ne2000: " Philippe Mathieu-Daudé
2021-03-03 19:12 ` [RFC PATCH v3 07/10] hw/net: pcnet: " Philippe Mathieu-Daudé
2021-03-03 19:12 ` [RFC PATCH v3 08/10] hw/net: rtl8139: " Philippe Mathieu-Daudé
2021-03-03 19:12 ` [RFC PATCH v3 09/10] hw/net: sungem: " Philippe Mathieu-Daudé
2021-03-03 19:12 ` [RFC PATCH v3 10/10] hw/net: sunhme: " Philippe Mathieu-Daudé
2021-03-08  1:51 ` [RFC PATCH v3 00/10] net: Handle short frames for SLiRP/TAP interfaces 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=20210303191205.1656980-3-philmd@redhat.com \
    --to=philmd@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=bmeng.cn@gmail.com \
    --cc=dmitry.fleytman@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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).