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

[address@hidden]

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.

I don't think this is too platform specific, so I would be open to 
integrate code for that into the main source (as Jifl already did 
something similar which is not yet integrated). But that would mean a 
clean patch ready for integration would have to be created by someone 
who cares...

Maybe we can just integrate what Jifl did, but I don't remember what it 
was... :-)


Simon



address@hidden wrote:
> alain...
> you are right...
> i'm using lpc2368 from
> nxp (arm7)
> in the next days i will try to discuss here about my driver
> implementation (dma manager using isr) and my actual ethernetif layer;
> and my doubts and ideas for implementing zero copy driver.
>
> thanks to all
> goodnight  :o)
>
> 2008/12/24, Alain M. <address@hidden>:
>   
> > I believe that what he wants is to use a processor (like some ARMs) that
> > have DMA only in a certain address range reserved for ethernet, but it
> > is not too small. The problem might be that a normal malloc is not in
> > that address range, so a special pbuff alloc is all that is needed...
> >
> > Alain
> >
> > bill escreveu:
> >     
> > > You'd have to have more than one, sure.  You might be able to ping-pong
> > > between 2 – but without copying you stand to lose packets if you don't
> > > finish with the first and the second one has come in and then a third is
> > > pending.
> > >
> > > Bill
> > >
> > > i suppose i could have a driver with more than one pbuf allocated... it
> > > could be more efficient... but, my problem, is the pbuf allocation memory:
> > >
> > > DMA MUST works in FIXED region in memory, and instead i have no control
> > > where pbuf payload are allocated... do you have a solution?
> > >
> > >       
> >
> > _______________________________________________
> > lwip-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-devel
> >
> >     
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel
>
>