[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] [bug #34427] In RAW/NO_SYS mode, tcp_output may send ou
From: |
Simon Goldschmidt |
Subject: |
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 |
Date: |
Thu, 29 Sep 2011 08:11:23 +0200 |
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