On Thu, Mar 4, 2021 at 3:12 AM Philippe Mathieu-Daudé <phi...@redhat.com> wrote: > > This is Bin's series but using iovec structure in 1st patch > for zero copy. > > Bin's cover: > > 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.
Ping?
