Re: RE packet: fix reserve calculation - net/packet/af_packet.c

On Fri, Sep 7, 2018 at 1:34 PM, David Miller [off-list ref] wrote:

From: Willem de Bruijn <willemb@google.com>
Date: Fri, 7 Sep 2018 11:50:02 -0400

quoted

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