Re: [lwip-devel] [bug #34427] In RAW/NO_SYS mode, tcp_output may send out large number of ARQ REQ if destination ARP entry has expired

[Simon Goldschmidt]

Min Xu <address@hidden> wrote:
> On a somewhat unrelated note,

Please *don't* post unrelated notes to the bugtracker. Either create a 
dedicated entry or send it to one of the mailing lists to prevent bugtracker 
entries getting unreadable. 

> when I was implementing the driver to have a
> large receive buffer that's friendly to the CACHE (128 byte aligned), I
> found
> it necessary to:
> 
> 1: not use pbuf mempool: because cache needs to be turned on for
> performance,
> and because the cache is 128 bytes aligned, and because the cache lines
> containing the receive buffer must be invalidated since data is DMA
> transferred outside of CPU

That's true. However, using PBUF_ROM/REF types on input is not supported 
currently. Instead, I think we only would need a different alignment mechanism 
for the PBUF_POOL pool, correct?

> 2: pbuf structs (actually PBUF_ROM is the type I used on received packet)
> must
> add a new field to store the original packet buffer because ICMP PORT NOT
> REACHABLE calls pbuf_header to traverse back the header in udp, and
> pbuf_header would normally fail on PBUF_ROM types.  -- this is the same as
> suggested by Marc Wells 
> http://lists.gnu.org/archive/html/lwip-users/2003-03/msg00085.html

We do have an open task in the bugtracker for support of DMA-enabled (i.e. 
zero-copy) ethernet MACs. However, we didn't have enough input on that, yet, so 
I'm happy for any input.

> 3: I upgraded to ver 1.4.0 (from 1.3.1) because I thought there was a
> PBUF_CUSTOM type that allows me to call a routine when pbuf_free actually
> free'd the buffer, but it turns out this code is written on certain
> compilation condition and that it's not normally invoked on any pbuf
> types. 

Yep, this one is only used internally, yet. However, it shouldn't be a problem 
to allow external usage by just changing that define to be overridable...

In general, when writing a DMA netif driver, you have 3 options:
a) use PBUF_POOL pbufs (when DMA alignment is corrected):
- place the p->payload pointers into the DMA slots
- when a packet is marked as received, allocate a new PBUF_POOL (allowed from 
ISR) and replace the slot's pointer by the new p->payload
- to get the pbuf pointer of the received packet, simply substract the (static) 
difference from that payload pointer and you get a pointer to the struct pbuf.

b) use a CUSTOM pbuf (you only need to define LWIP_SUPPORT_CUSTOM_PBUF to 1 in 
pbuf.h for now - I'd change this to be overridable by applications)

c) use PBUF_REF - this does not work for the current size of struct pbuf. We 
could change this, but not without an option - 16 bytes for a pbuf is a nice 
size that shouldn't be extended if you don't need it.

> [..]
> So I believe that it would be nice if the LwIP stack has a conditional
> flag
> that would add these two fields (if others find that an additional 2 words
> would cause extra bloat in) pbuf_struct.

What is the 2nd field you're talking about?

Simon
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!               
Jetzt informieren: http://www.gmx.net/de/go/freephone