Grubb, Jared wrote: > This sounds very similar to the buffer descriptors on the Atmel > AT91SAM7X chips that I'm using. Like Jonathan was saying, there are some > changes being tossed around for changing the way pbuf's work that should > make something like this more elegant. > > For now, this is how I solved the problem: > > I use in lwipopts: > #define PBUF_POOL_SIZE 100 // Allows for about 8 full-size > (1500 byte) packets > #define PBUF_POOL_BUFSIZE 128 // The receive descriptors are fixed > at 128 bytes > > I fill the buffer descriptor table with 32 empty pbuf's from this pool > (setting the table entry to point to the pbuf payload itself, so a > couple words after the start of the pointer I get back from pbuf_alloc). > As packets come in, I pull them out of the descriptor table, chain them > together, and then send it up the stack (no copy necessary). I replace > their entries with fresh pbuf's from the pool. When the pbuf is freed > after the application is done, then it gets put back in the pool.
Ditto. Although I added my own hook in the pbuf free code so that I can replenish any bd's where the allocation failed (ran out of pool pbufs). I also have an override hook in the pbuf alloc code so that I can allocate the pool pbufs myself too - that way a driver can specify a pool that has to be from a specific memory area, or to fit alignment constraints (in my case because I use the same driver for AT91SAM7X and AT91SAM9260). I would of course prefer to get this sorted out in lwIP. And all this is with the unofficial constraint I impose that pbufs not be reused. @Bill: I've just had a look at a power FEC driver I have here. As far as I can tell, the BDs have to come from the CPM/DPRAM shared memory, but the buffers they point to do not. They can be anywhere. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
