[lwip-users] question about structuring an lwIP emac adapter

[Siva Velusamy]

I'd like some suggestions on restructuring an ethernet adapter i wrote
to solve an issue similar to lwIP issue #11400.

Currently, the adapter is written to queue a pbuf in an internal queue
if it finds that the ethernet mac does not have any space in its send
FIFOs. However I found out today that it is quite possible that this
pbuf could be modified later by lwIP (v1.2.0).

This issue is very similar to lwIP issue #11400, except that instead
of packet being queued by the ARP layer, it is being queued by the
adapter. Also, instead of TCP changing data, the header was being
changed by the IP fragmentation code.

In lwIP 1.3.0pre, I see the following changes:
   - etharp.c now copies the pbuf if it is not of type ROM
   - ip_frag.c now has a new macro IP_FRAG_USES_STATIC_BUF. It appears
as if using this will avoid the issue I see, but I haven't ported the
adapter as yet.

So I'd like some thoughts on the following assumptions I'm making right now:

1. It is actually ok for the adapter to queue packets if they cannot
be sent right away. I do not feel comfortable creating one more queue
at the MAC adapter level, but it seems unavoidable since the MAC has a
TX FIFO of just 2k and could easily be overrun by just a single UDP
send of a packet > 2k in size.

2. The best way to structure this queuing code would be to follow
something similar to what etharp.c does to queue multiple fragments.
i.e., just alloc a new pbuf, and copy over the contents of this chain
into the new pbuf.


Thanks,
Siva
-- 
In the end, everything is a gag.
           Charlie Chaplin