lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] again... Zero Copy Ethernet interface


From: Piero 74
Subject: Re: [lwip-devel] again... Zero Copy Ethernet interface
Date: Tue, 6 Jan 2009 20:26:05 +0100

Hi all
Now I'm at home... i can discuss here again!

As Mike said, you only would need to relocate the memory where the pbuf pool is located. Unfortunately, with the current implementation that's not easy as the pbuf pool is one of the memp-pools. You could of course relocate all memp-pools to the DMA region but you have to check if that's big enough.

This is my first problem... i know very well setting for my linker (i used memory allocation in my application everywhere), and i saw that is so difficult to allocate in emac RAM only pbuf pool, because they are a part of pbuf pool.  The idea described here could be possible with my micro controller (i need to investigate in deep), my doubt is where i have to check if in use pbuf are became free (checking ref field??) , for move CONSUMER pointer of may circular DMA.... i suppose in ISR, when a new packet arrives, i can check older pbufs allocated before in circular DMA memory (note: my micro is an arm7 - nxp lpc2366)


Are you only concerned about making sure the RX packets are located in a specific region, or do you need the TX packets to also be in that region?

My understanding is zero copy for send operation is very difficoult with actual lwip implementation... so, at the first, i'll be happy to solve problem for RX packet 

It's been a while, but I also required that RX packets were all fixed in a very specific spot of memory, and I was able to make it work. I can go back to the code and try to dig out how I did it if that's what you're looking for.

Jared, if you can share your driver implementation with me, it will be useful for sure, thanks in advance!

As also mentioned in the past, outgoing zero copy is more difficult because lwIP wants to free the pbuf after the call to low_level_output and this could happen before the DMA transfer has occurred.  Maybe I have this wrong but I recall some complication in regards to sending data.

I cannot imagine a implementation for sending operation using zero copy...
i can see TWO problems:
- first, as already someone said above, i have to solve problem of lwip which wants to free pbuf after low_level_output... a solution could be (if a RTOS is used) waiting on semaphore until emac isr unlocks it, after DMA sending packet. In this way CPU will be avalaible for other tasks (threads) during DMA sending
- second (correlated to similar problem for rx), when lwip send a packet, this is allocated in pbuf RAM, in lwip heap, (if i'm right...), but, again, my DMA wants packet in specific region (emac RAM)... so, pbuf ram needs relocation in fixed memory region too, but i think is difficoult to change lwip code for this...

Thanks to all for interesting discussion here...
other comment will be appreciated.

Bye
Piero
 
 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]