Re: [PATCH v2 03/13] net: slirp: Pad short frames to minimum size before send

[Jason Wang <jasowang@redhat.com>]

在 2021/3/15 下午3:57, 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, 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 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>
> ---
>
>   net/slirp.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/net/slirp.c b/net/slirp.c
> index be914c0be0..ad2db03182 100644
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -31,6 +31,7 @@
>   #include <pwd.h>
>   #include <sys/wait.h>
>   #endif
> +#include "net/eth.h"
>   #include "net/net.h"
>   #include "clients.h"
>   #include "hub.h"
> @@ -115,6 +116,17 @@ static ssize_t net_slirp_send_packet(const void *pkt, size_t pkt_len,
>                                        void *opaque)
>   {
>       SlirpState *s = opaque;
> +    uint8_t min_buf[ETH_ZLEN];
> +
> +    if (!s->nc.peer->do_not_pad) {
> +        /* Pad to minimum Ethernet frame length */
> +        if (pkt_len < ETH_ZLEN) {
> +            memcpy(min_buf, pkt, pkt_len);
> +            memset(&min_buf[pkt_len], 0, ETH_ZLEN - pkt_len);
> +            pkt = min_buf;
> +            pkt_len = ETH_ZLEN;
> +        }
> +    }


Let's introduce a helper for this padding then it could be reused by at 
least TAP?

Thanks


>   
>       return qemu_send_packet(&s->nc, pkt, pkt_len);
>   }