lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] Transferring large data fast and pointing pbufsdirectly


From: Grubb, Jared
Subject: RE: [lwip-users] Transferring large data fast and pointing pbufsdirectly to Ethernet receive buffers
Date: Wed, 12 Dec 2007 12:38:42 -0800

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. 

Jared

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Bill Auerbach
Sent: Wednesday, December 12, 2007 12:16
To: 'Mailing list for lwIP users'
Subject: RE: [lwip-users] Transferring large data fast and pointing
pbufsdirectly to Ethernet receive buffers

> Bill,
> 
> If you can describe the way the buffer descriptors and memory
allocation
> works, maybe there is a way to use 'custom memory pools' to simulate
> what you need.
> 
> Jared

BDs (Buffer Descriptors) are a sequential list of 2-word (8 byte)
entries
that contain status that the program and hardware update, the buffer
length,
and a pointer to the buffer.  The last BD has a bit marking the last and
the
PowerPC has a register to know the first. It can cycle through the BDs
using
buffers as needed.  It checks each BD status for the next free one and
stores the packet into memory pointed to by the BD.  The program clears
a
bit when it's done with a buffer and the PPC sets the bit when it's
filled a
buffer.  It's a pretty cool mechanism I've not seen before.  If I point
the
pbuf to the buffer and can mark the "done" bit when lwIP has processed
it, I
remove one level of copying.  Maybe no copying if the image can be
processed
sequentially (this looks to be possible).

Bill



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users




reply via email to

[Prev in Thread] Current Thread [Next in Thread]