Allow unaligned IP Packets

[mlsvrts]

Is your feature request related to a problem? Please describe.

Netx requires that the packet ip header is 4-byte aligned. This is problematic on systems that require 4-byte aligned DMA access, as I believe it makes a 'zero-copy' implementation impossible.

Describe the solution you'd like
An ifdef a long the lines of 'NETX_ALLOW_UNALIGNED_PACKETS'

Describe alternatives you've considered
Copying the packet :)

[fdesbiens]

Thank you for submitting this feature request, @mlsvrts. I will discuss it with the team.

[yuxinzhou5]

@mlsvrts just wanted to understand your use case: Is the alignment requirement a problem for packets being received, or packets being transmitted, or both? Is it on Ethernet, wifi, cellular? Is the DMA engine capable of writing incoming data with an offset (so the IP be 4-byte alignment)?

[mlsvrts]

So this is an issue for receiving packets; the DMA controller is only capable of writing to a word-aligned address, and there's no support for padding the Ethernet frame or anything like that.

(MAC FIFO -> DMA -> Word Aligned Address)

Because of this the IP header will always be unaligned (Ethernet header is 14 bytes), and I am forced to copy-and-shift the packet before passing it to NetX.

[yuxinzhou5]

@mlsvrts curious: What is the MCU or Ethernet MAC controller for this application?

If the driver is unable to do an offset when DMA data into the memory, we do recommend a data copy in the driver (as mentioned in the NetX Duo user guide.).

[fdesbiens]

@mlsvrts Do you have feedback for @yuxinzhou5?

[mlsvrts]

@yuxinzhou5 This is for a smart fusion 2, but I don't think it's uncommon for the DMA unit in embedded controllers to have this aligned access restriction.

I of course understand that copying the packet to a new address is perfectly functional, but I am not convinced that the performance gained by having an aligned IP header will outweigh the cost of the copy in all cases.

In particular, I think something like receive - modify - retransmit could require two complete packet copy operations to perform a very small amount of work, to the point where applications with limited resources might need to circumvent netx entirely for some packets.

[yuxinzhou5]

@mlsvrts Did you try running the stack as-is and letting the CPU handle this unaligned access?

Is Smart Fusion 2 based on Cortex M3? ARM reference manual indicates unaligned access is supported: https://developer.arm.com/documentation/ddi0337/e/Bus-Interface/Access-alignment

Since the Ethernet header is 14-bytes, the processor takes 2 cycles to load a 4-byte value in your case, which is not bad.

Given what we know, can you run the demo as-is, and see how the CPU handles the incoming packet in this case? I took a quick look at the _nx_ip_packet_receive() and didn't see any validations on alignment, but I won't be surprised if it is enforced in some other places.

On the transmit side, the packet allocation logic always put IP header at 4-byte alignment. Can your driver handle 2-byte starting address of the Ethernet frame?

[mlsvrts]

I have tested not fixing the packet alignment, if that's what you mean?

I can confirm that NetX will not process the packet correctly if the ipv4 header is not 4-byte aligned -- at a minimum ipv4 header checksum validation will fail. I haven't looked for other issues.

[yuxinzhou5]

Thanks for the quick answer. Are you able to do a quick test if you can run your project without fixing the packet alignment? Please set a breakpoint in nx_ipv4_packet_receive.c line 131 (

netxduo/common/src/nx_ipv4_packet_receive.c

Line 131 in 6c8e9d1

val = ip_header_ptr -> nx_ip_header_word_0;

), do a single step and read the value of "val". If the CPU can read the correct value from an unaligned address, "val" should contain the first 4 bytes of the IP header (in network byte order). Let's verify the CPU's behavior.

Adding a feature for unaligned access for general release requires modifying the architecture design. At the source code level, most of the packet process routines (which are spread over IPv4/v6, IGMP, ICMP(v4/v6), TCP, UDP, and all the components in the addon folder) would have to be modified and validated on several architectures and compiler settings. Given the scope of the work, we suggest packets be copied into aligned buffers before going into the NetX layer.

We are happy to discuss with you further if you have a specific use case with a narrower scope. You can email us [email protected]