[dpdk-dev] [RFC] Ethernet drivers to add padding on egress

[Shahaf Shuler]

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 <mb at smartsharesystems.com> 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. 

>