I will add 1cent more...
This buffer region is important in more ways: some ARM9 (Atmel for one)
have some separate internal memory banks that if used for TX/TX can
acoplish DMA at almost zero overhead using different access hardware. I
understand that most DSP have memory banks with some kind of
optimization...
So, I vote for this issue to be carefully considered to be integrated
in future versions ;)
Alain
bill escreveu:
My
2 cents on this:
I
would add 3 #defines to lwipopts.h which define the lower and
upper address bounds of “special”DMA memory and a user defined
function name which takes a pbuf pointer parameter. I would add a
conditional
line of code in pbuf_free that checks the pbuf’s address to be within
the
special DMA address bounds (which would be the dma region of memory)
and call
the macro that defines the user-defined function to free it. The
pbuf_allocs in the low level driver would have to be replaced with a
user-defined
function that manages the DMA region’s buffers. This localizes the
changes to the implementation specific code in ethernetif.c and a one
liner in
pbuf_free to check if the address is special and was allocated in
ethernetif.
You’d then have to create new DMA region supporting alloc and free
functions. This is probably easier than trying to create a new pool
and
somehow force the starting address and size to be in the DMA region. I
have found that the less I muck around in the working lwIP code, the
less I
worry about adding instability to the stack.
I
am going to have to do this in my Altera NIOS II lwIP port
because I must have zero-copy transmit support. I ping ponged – the
last project was exclusively driven by maximizing TCP receive bandwidth
–
now I have to maximize TCP transmit bandwidth and receive bandwidth
doesn’t
matter.
I
haven’t implemented the above but I hope it was helpful
or spawns ideas.
Bill
From:
address@hidden
[mailto:address@hidden] On
Behalf
Of Piero 74
Sent: Tuesday, January 06, 2009 2:26 PM
To: lwip-devel
Subject: Re: [lwip-devel] again... Zero Copy Ethernet interface
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
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel
|