[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Ethernet Driver development guidelines.
From: |
Stephane Lesage |
Subject: |
[lwip-users] Ethernet Driver development guidelines. |
Date: |
Tue, 18 Mar 2008 12:57:13 +0100 |
User-agent: |
Thunderbird 2.0.0.12 (Windows/20080213) |
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
- [lwip-users] Ethernet Driver development guidelines.,
Stephane Lesage <=