[lwip-users] Ethernet Driver development guidelines.

[Stephane Lesage]

Hi,

I'm currently using 1.2.0 on Blackfin processor with ADI's port.
But there are features missing (multicast, NBIO, better TCP time-out 
management) and I'm quite happy to see 1.3.0 is almost ready.
As I can't backport them, and can't wait Analog Devices releases a new 
Visual DSP version in 6 months, I will implement my own driver.

I want to use sockets (SYS_ARCH and tcpip_thread)
and I also want to benefit from the DMA hardware.

I've read the wiki, but my understanding of LwIP low-level is not 
completely clear and I need you to confirm some points:

1- When I call lwip_write() for example, it will send a message to the 
tcpip_thread and eventually block...
This will call ip_output _from the tcpip_thread_, which after proper 
routing, will call netif->output()
I just use etharp_output() here, which will call netif->link_output().
(eventually for the ARP request before the actual IP packet, right ?)

Now I just have to send the packet on my MAC hardware...
I'm using DMA descriptors, so I can just queue it...

But should I block until the packet has effectively been sent ???

My understanding is that the packet scheduling is done by the 
tcpip_thread with Packet In/Out messages and there is no mechanism to 
tell LwIP to release the pbuf when it's not needed anymore...
A bad idea could be releasing the pbuf myself, but this would work only 
for UDP and not for TCP as the stack needs it for retries until it 
receives the ACK.

So, if I block the tcpip_thread... This means it can't process packet 
inputs until released... And we can't work full-duplex with the hardware ?
And what about ARP requests ? If the host MAC address is unknown, 
etharp_output() needs to wait for the reply...
But it's already called from the tcpip_thread, so no mailbox 
mechanism... How is it processed ?

What am I missing ?

2- When I receive a packet... It should be passed to the tcpip_thread 
for processing.
So I define ETHARP_TCPIP_ETHINPUT, and
my_netif->input() = tcpip_ethinput()

Ok, but I can't call this from my IRQ...
Because it may be time consuming and I can't use mailbox functions in there.
So I must create another thread that my IRQ will wake-up, just to call 
my_netif->input() that will send a message to the tcpip_thread and wake 
it up to process it, and eventually wake-up an application thread which 
called lwip_read() for example...
That's a whole lot of threads... Is that the right way to proceed ?

3- Packet Buffers...

As everyone, I would like to achieve an ideal zero-copy mechanism...

a. DMA-TX: I can eventually manage chained-pbufs with multiple DMA 
descriptors... The condition is that intermediary pbufs are always full 
and multiple of 4 bytes. Is that possible ?
(I don't know if TCP merges packets before the Naggle algorithm delay is 
expired)

b. DMA-RX: I need a full 1514 bytes buffer for reception.
From what I read, it's not a good idea to have a big size for PBUF_POOL.
So I should not directly use pools.
An idea would be a static array of DMA buffers.
Then 1 bad solution is PBUF_REF, because no way to know when it's 
released...
Another solution is to allocate a pbuf from the pool in my RX thread and 
copy from the pre-allocated buffer. But I want to avoid the copy.

So the only way would be to malloc() PBUF_RAM buffers... A set of 
initial buffers + create a new one and insert it in my DMA list each 
time a packet is received.
Are people doing this ?


I'll release the sys_arch port and driver if people are interested.


Thanks in Advance for your help.

--
Stephane Lesage
ATEIS International