Hi networking driver maintainers, I suggest that the TX functions of Ethernet interface drivers accept packets with less than 60 byte payload, and transmit them on the medium as valid Ethernet frames, i.e. by padding the packets up to the minimum Ethernet packet size of 64 bytes incl. Ethernet FCS, instead of discarding them.
This feature makes it easier for application developers who are using DPDK as the lower layer in an IP stack, where lots of packets have less than 60 bytes Ethernet payload, e.g. TCP SYN and TCP ACK packets. This feature also makes it easier for application developers who are using DPDK library functions that split, merge or otherwise transform packets into packets of other sizes, e.g. Generic Segmentation Offload, IP Fragmentation and various tunnel encapsulation/decapsulation functions. Currently (without this feature), it is required by the application to check if packets originating from the IP stack or having passed through a split/merge/transform function are about to egress on an Ethernet interface, and in that case, if some of the packets are less than 60 bytes (excl. Ethernet FCS), add padding before passing them on to the driver's TX function. E.g. when using Generic Segmentation Offload, a packet carrying 1461 byte TCP payload (excl. 54 bytes Ethernet+IP+TCP headers) will be split into two packets of respectively 1514 byte (incl. 54 bytes Ethernet+IP+TCP headers) and 55 bytes (incl. 54 bytes Ethernet+IP+TCP headers), and the latter must be padded before it is transmitted on an Ethernet interface. In my opinion, it should be a requirement that the Ethernet interface drivers ensure correct padding when egressing the packet on the medium. Alternatively, it can be an optional feature, which could be exposed as an TX Capabilities flag of the driver. What do you think? I do not suggest any changes regarding ingress - runts (undersize Ethernet packets) received from the medium are invalid, and should be discarded and counted as errors. My RFC was triggered by this discussion: https://mails.dpdk.org/archives/dev/2018-November/119135.html PS: I acknowledge Keith's comment that I am pushing for a feature with wide ranging consequences - modifying all PMDs and possibly costing some performance - based on one assumption. Med venlig hilsen / kind regards Morten Brørup CTO SmartShare Systems A/S Tonsbakken 16-18 DK-2740 Skovlunde Denmark Office +45 70 20 00 93 Direct +45 89 93 50 22 Mobile +45 25 40 82 12 [email protected] www.smartsharesystems.com
