[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 03/12] net: Pad short frames to minimum size before sendin
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v4 03/12] net: Pad short frames to minimum size before sending from SLiRP/TAP |
Date: |
Tue, 16 Mar 2021 16:10:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 |
On 3/16/21 1:04 PM, Bin Meng wrote:
> 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 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 <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v4:
> - squash slirp/tap commits into one
>
> Changes in v3:
> - use the pad_short_frame() helper
>
> net/slirp.c | 10 ++++++++++
> net/tap-win32.c | 10 ++++++++++
> net/tap.c | 10 ++++++++++
> 3 files changed, 30 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
- [PATCH v4 00/12] net: Pad short frames for network backends, Bin Meng, 2021/03/16
- [PATCH v4 01/12] net: eth: Add a helper to pad a short Ethernet frame, Bin Meng, 2021/03/16
- [PATCH v4 02/12] net: Add a 'do_not_pad" to NetClientState, Bin Meng, 2021/03/16
- [PATCH v4 03/12] net: Pad short frames to minimum size before sending from SLiRP/TAP, Bin Meng, 2021/03/16
- Re: [PATCH v4 03/12] net: Pad short frames to minimum size before sending from SLiRP/TAP,
Philippe Mathieu-Daudé <=
- [PATCH v4 04/12] hw/net: virtio-net: Initialize nc->do_not_pad to true, Bin Meng, 2021/03/16
- [PATCH v4 05/12] hw/net: e1000: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 06/12] hw/net: vmxnet3: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 07/12] hw/net: i82596: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 08/12] hw/net: ne2000: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 09/12] hw/net: pcnet: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 10/12] hw/net: rtl8139: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 11/12] hw/net: sungem: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16
- [PATCH v4 12/12] hw/net: sunhme: Remove the logic of padding short frames in the receive path, Bin Meng, 2021/03/16