Bill, i could have some problems:
- my emac dma works only in a dedicated 16kB ram, so, pbufs poll must be allocated in this memory area. I should want only PBUF_POOL allocated in this memory, but PBUF_POOL is a part of memp vars (i.e. memp_memory, memp_sizes....), so i cannot split pbufs in different memory area. i'm thinking that something is possible using custom pools... but i have no idea how i can use them to solve my problem. Anyway, my driver (which uses copy operation) works well... it will be an improvement for the future 2008/3/18, Bill Auerbach <[EMAIL PROTECTED]>: > > This was the point I missed, at first, in that discussion. You don't > need to worry about when the pbuf is freed. Simply replace the filled one > with an empty one (allocate a new one) and when lwIP is done with the > original one, it will free it, placing it in the pool for a future > allocation in your packet receiver. > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Piero > 74 > *Sent:* Tuesday, March 18, 2008 10:55 AM > *To:* Mailing list for lwIP users > *Subject:* Re: [lwip-users] Ethernet Driver development guidelines. > > > > Very interesting discussion ( > http://lists.gnu.org/archive/html/lwip-users/2007-12/msg00071.html) !!! > > Now i have not enough free time for rewrite driver, and i developed my > driver for nxp 236x microcontroller (which has emac controller with dma) > using copy from emac memory and pbuf in pool. > It can manage packet using fragments with size less of MTU, so, i use emac > memory in optimizing way. > But it could be very usefull to avoid copy operation in low level. > I see a problem: > My dma controller uses two index cycling on buffers (producerIndex and > ConsumerIndex)... > I should know when lwip free pbufs, and after move consumer index. > But LWIP doesn't inform low level about free operation in pbuf!! How > driver can be informed about this?? > > I think this thread could became a meeting point for discussion about > driver development and lwip changes for particular customization of memory > management.... > bye, > Piero > > 2008/3/18, Bill Auerbach <[EMAIL PROTECTED]>: > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > Behalf > > Of Stephane Lesage > > Sent: Tuesday, March 18, 2008 7:57 AM > > To: Mailing list for lwIP users > > Subject: [lwip-users] Ethernet Driver development guidelines. > > > > <snip> > > > 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 don't know Blackfin, but if it has buffer descriptors like the PowerPC, > then this thread answered the question for me for no-copy buffers that the > Ethernet controller can DMA into. Works great for me on a PPC. > > http://lists.gnu.org/archive/html/lwip-users/2007-12/msg00071.html > > > Bill > > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
