Re: [PATCH net-next v4] openvswitch: enable NSH support

On Mon, 21 Aug 2017 10:10:38 +0000, Jan Scheurich wrote:

If I understand correctly, this is a default definition that can be
overridden by drivers so that we still cannot rely on the Ethernet
payload always being 32-bit-aligned. 

Not by drivers, by architectures. Only architectures that can
efficiently handle unaligned access (or on which the cost of handling
unaligned access is lower than the cost of unaligned DMA access) set
NET_IP_ALIGN to 0.

Furthermore, there seem to be machine architectures that cannot
handle misaligned 32-bit access at all (not even with a performance
penalty).

Those leave NET_IP_ALIGN to 2.

Or why else does OVS user space code take so great pain to model
possible misalignment and provide/use safe access functions?

I don't know how the ovs user space deals with packet allocation. In
the kernel, the network header is aligned in a way that it allows
efficient 32bit access.

Does Linux kernel code generally ignore this risk?

Given the fact that IPv4 addresses are 32bit, are accessed as such and
one can't say that IPv4 implementation on Linux is non-functional, the
answer is obvious :-)

 Jiri

quoted

If I understand correctly, this is a default definition that can be
overridden by drivers so that we still cannot rely on the Ethernet
payload always being 32-bit-aligned.

Not by drivers, by architectures. Only architectures that can efficiently
handle unaligned access (or on which the cost of handling unaligned access
is lower than the cost of unaligned DMA access) set NET_IP_ALIGN to 0.

Thanks, got it!

quoted

Furthermore, there seem to be machine architectures that cannot handle
misaligned 32-bit access at all (not even with a performance penalty).

Those leave NET_IP_ALIGN to 2.

Dito

quoted

Or why else does OVS user space code take so great pain to model
possible misalignment and provide/use safe access functions?

I don't know how the ovs user space deals with packet allocation. In the
kernel, the network header is aligned in a way that it allows efficient 32bit
access.

It seems that OVS has not had the same approach as Linux. There is no config parameter covering the alignment characteristics of the machine architecture. For packets buffers received from outside sources (e.g. DPDK interfaces) they make no assumptions on alignment and play safe. For packets allocated inside OVS, the Ethernet packet is typically stored so that the L3 header is 32-bit aligned, so that the misalignment precautions would be unnecessary. But I didn't check all code paths.