On Fri, Sep 7, 2018 at 1:34 PM, David Miller <da...@davemloft.net> wrote: > From: Willem de Bruijn <will...@google.com> > Date: Fri, 7 Sep 2018 11:50:02 -0400 > >> If you are not seeing these problems with other protocols, I must be >> misreading that code. > > Right, the ethernet header is only guaranteed to be 2 byte aligned on > transmit. > > Nothing ever gave larger alignment guarantees. > > This is the _only_ reasonable situation. > > If we made the ethernet header to be 4 byte aligned, that means the > ipv4 addresses in the ipv4 header are not 4 byte aligned so we would > do unaligned memory accesses when building the headers which are > either expensive or trap depending upon the architecture.
Understood. I thought SOCK_RAW made no assumptions with respect to the network layer headers. Previously, the buffer was allocated and then data was copied into it without giving thought to alignment. Sounds like I got lucky with the alignment and I should have expected 2-bytes from day 1. I've been using this device with only SOCK_RAW on a real time network, and I have not even tried to use SOCK_STREAM or SOCK_DGRAM. So, I just tried to use TCP on the device, and the buffer alignment is in fact 2-bytes inside my transmit function, and my DMA core does not work. So...I guess I need to bring my hardware into the 21st century or do a copy in the driver transmit function. Thanks for your time
