Embedded IP stack: is it okay/accepted to have asynchronous sending?

I am trying to implement a very small IP stack for 8-bit AVR MCUs. I don't want it to support TCP, because it's really too big and I don't need it, but rather UDP (and, of course, ARP and ICMP).

I want the stack code to fit into 16 kiB of ROM and 1 kiB of RAM, of course letting as much space as possible for the application. I am u开发者_StackOverflow中文版sing an ENC28J60-based board for PHY/MAC management, which has an internal 8 kiB RX/TX circular buffer. As packets arrive into this chip, it writes them one after the other into the RX buffer but won't overwrite the oldest one. The oldest one is pointed to by a pointer which must be updated to point to the next packet when the user is done reading it. It also sends an interrupt on one of its pins when a new packet has arrived.

For the RX part, I want to work just like lwIP does: signal that a new packet is ready when we receive an interrupt (save its address and size) but proceed it only when the user calls our IP stack function. This should work okay; if the user does not call our function often enough, the new arriving packets will be dropped and that's it. The user provides the stack with an UDP callback.

Now, the problem is about TX. Let's say I want to send an UDP packet to some IP for which I don't know the link address. An ARP request has to be sent before my packet is sent. What if an UDP packet comes in before the ARP reply? It has to be processed by my UDP callback, but what if I want to send something from this callback? I'm still waiting for an ARP reply here. For sure this blocking mechanism is not right.

My question is: is it okay/accepted to have asynchronous sending? Thus if I want to send something, I provide the send function with a callback and its get called when the UDP packet may be sent. This way, everything is event-driven.

As to whether it's "acceptable" to have asynchronous sending, I can't imagine why it would be a problem, so long as you can implement that in your code size requirements.

As to the best way to implement such a scheme, I don't know how big a packet size you want to support (I'm guessing a lot less than the theoretical maximum of 64K), but I would allocate a ring of send buffers, and whenever the process responsible for actually sending to the hardware ran its loop/interrupt/whatever, it would check each live buffer for its ARP status (has ARP entry, ARP request outstanding, ARP request timed out, no ARP entry or request outstanding) and take the appropriate action (respectively: push to hardware with appropriate MAC, skip this time, discard, send ARP request). You could trigger this send routine to run every time the ARP table is updated so that you could meet any necessary real-time requirements (although some people would argue that Ethernet is not and will never be a truly real-time capable system, but that's a topic for another forum that doesn't mind flamewars).

Can you have two callbacks(basically async paths), one for receiving from IP layer and one for sending to IP?

Also, if you are implementing layers, I think the IP send / route function should take care of the ARP reply at that level.