On Mon, Mar 8, 2021 at 11:48 AM Jason Wang <jasow...@redhat.com> wrote: > > > On 2021/3/4 3:11 上午, Philippe Mathieu-Daudé wrote: > > From: Bin Meng <bin.m...@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. > > > Do we need to care about other type of networking backends? E.g socket. >
I am not sure as I never used other backends. If someone who is more familiar with the network codes better than me can confirm other backends are also needed, we might do: if (sender->info->type != NET_CLIENT_DRIVER_NIC) > Or at least we should keep the padding logic if we can't audit all of > the backends. Regards, Bin
