Global Option for All Drivers

CONFIG_NET_GUARD_SIZE is global option.  It is added to the allocated size of each driver packet buffer. Currently it is a very small value, defaulting to only two bytes. So it is not a memory hog and should be added to the packetsize for all drivers for commonality.  But why?

It should (eventually) be larger and common for all drivers. We need to look at how it is used today and how it might be used tomorrow. There is a probably a lot more involved than you might be initially considering.

Packet Receipt

For packet receipt, it is necessary for some hardware, but not for others. Often the hardware will DMA a 2 byte FCS at the end of the packet or possibly other hardware-specific info.  But that is only part of the whole story.  CONFIG_NET_GUARDSIZE is not just for hardware packet receipt.

Packet Transmission

There are several issues for packet transmission. These are less well defined and need further study, but we need to keep all of the driver packet definitions in place until we understand how we are going to handle these things:

Memory Overrun Bugs

There was in the past, a bug that caused write past the end of the buffer by a couple of bytes during TX message formatting. I don't know if that bug still exists, but the minimum, two-byte CONFIG_NET_GUARDSIZE was sufficient to eliminate the bug. That is why it has the name GUARD: Its primary purpose is to protect from overrunning the packet buffer and corrupting the following memory.

I do no know if we have any such bugs today. Perhaps they still do? Perhaps they do not? Having such a guard is a good thing for reliability in any case.

Variable size IP/TCP headers

There is a limitation in the way IP packets are formatted now. Basically they are formatted like this:

  1. When the packet is received a pointer to the location of the payload is set (d_appdata). This is an offset into the packet buffer For TCP, that accounts for the MAC/Ethernet header, the minimum IPv4/IPv6 header size, and the minimum TCP header size.
  2. The TCP payload data is written at that location using a constant MSS,
  3. The minimum sized IPv4/IPv6 headers and the minimum sized TCP header are added below the payload, and finally
  4. The MAC/Ethernet header as add at the very beginning of the buffer.

The problem, of course, is that IPv4/IPv6 and TCP headers are not constant. Using the minimum size for these headers precludes using IPv4/IPv6 or TCP header options. There are currently only a few places where options are required and these have to be handled as special cases. This needs to be formalized into the common packet formatting logic. Otherwise, the network will never be able to handle advanced features like tunneling or NAT.

I am thinking that this should be like:

  1. When the packet is received a pointer to the location of the payload is set (d_appdata). This is an offset into the packet buffer For TCP, that accounts for the MAC/Ethernet header, the maximum IPv4/IPv6 header size, and the maximum TCP header size.
  2. The TCP payload is written at that location,
  3. The correctly sized IPv4/IPv6 headers and the correctly sized TCP header are added below the payload, and finally
  4. The MAC/Ethernet header as added.


The start offset of the packet in the packet is no longer zero, but some variable offset into the packet buffer.  That new start offset would have to be passed to driver in order to send the packet.

The key to making this all work is:

Variable MSS

Closely related to this is the MSS which is the maximum size of the payload. Currently that is a constant because it assumes the minimum header lengths. It should be variable, depending on the actual header sizes.