[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Transferring large data fast and pointing pbufsdirectly
From: |
Jonathan Larmour |
Subject: |
Re: [lwip-users] Transferring large data fast and pointing pbufsdirectly to Ethernet receive buffers |
Date: |
Wed, 12 Dec 2007 21:37:10 +0000 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070530) |
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
- RE: [lwip-users] The purpose of structure packing, (continued)
- RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Bill Auerbach, 2007/12/12
- Re: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Jonathan Larmour, 2007/12/12
- RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Bill Auerbach, 2007/12/12
- Re: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Jonathan Larmour, 2007/12/12
- RE: [lwip-users] Transferring large data fast and pointing pbufsdirectly to Ethernet receive buffers, Grubb, Jared, 2007/12/12
- RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Bill Auerbach, 2007/12/12
- Re: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, address@hidden, 2007/12/12
- RE: [lwip-users] Transferring large data fast and pointing pbufsdirectly to Ethernet receive buffers, Grubb, Jared, 2007/12/12
- Re: [lwip-users] Transferring large data fast and pointing pbufsdirectly to Ethernet receive buffers,
Jonathan Larmour <=
- RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Bill Auerbach, 2007/12/12
- RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Bill Auerbach, 2007/12/12
RE: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers, Bill Auerbach, 2007/12/12