RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers

[Bill Auerbach]

> 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.

I will set things up not to run out of pbufs.  Having lots of memory makes
this easier.  Having a "high water" mark would be handy I suppose.

Oh, I see your next post.  I understand your point with the hooks - if you
leave a BD unfreed, you have to know to go back and release it when you do
have free pbufs.  As I have no OS (to speak of) and will be polling during
times that I have time to do so, the polling loop can check a state flag
like you do in pbuf_free and find, release and refill any unfreed BD buffers
if any have been left busy.

> @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.

I don't see this constraint for the MPC8349EA, but I do now see that the RX
buffer pointers have to be 64-byte aligned.  Oddly, the TX buffers have no
alignment requirements at all.

Thank you Jonathan.  Hopefully I'll learn lwIP well enough to help the next
new user.  This list has already proven itself to be an excellent resource.
And you guys are all so fast in your responses. :)  Thank you all.

Bill