Monday, November 19, 2018 6:10 PM, Stephen Hemminger: > Subject: Re: [dpdk-dev] [RFC] Ethernet drivers to add padding on egress > > On Thu, 15 Nov 2018 17:56:48 +0100 > Morten Brørup <[email protected]> wrote: > > > 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. > > > > Devices drivers should work like Linux and BSD! > They must pad packets to meet any restrictions by the underlying > technology. > > Please don't add another capability flag or other way for applications to see > this. > DPDK already has way to many hardware capability flags. > It should just happen.
I would like to change my previous comment, I fully agree w/ Stephan here. >
