NXP LPC 17xx lwip port: use of pbuf for rx

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NXP LPC 17xx lwip port: use of pbuf for rx

Giuseppe Modugno
I'm using LPC1769 MCU. I'm using source code from NXP SDK that works.

I need to free some RAM to use mbedTLS libraries, so I was studying the
code better. I found that NXP Ethernet driver preallocates a number of
pbufs for RX DMA descriptors. The code uses:

     p = pbuf_alloc(PBUF_RAW, (u16_t) ENET_ETH_MAX_FLEN, PBUF_RAM);

When a new frame is received, a new pbuf is allocated with the same
instruction. The pbuf of received frame is finally freed.

With PBUF_RAM parameter, this code allocates pbuf with mem_malloc, that
is standard malloc in my case. However ENET_ETH_MAX_FLEN is 1552 bytes.
With so many alloc and free of 1552 bytes, I will have big fragmentation.

So I replace PBUF_RAM with PBUF_POOL, to use memory pools that don't
suffer from fragmentation. I tried and it works, but I don't know if
there's some drawbacks in doing so.


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: NXP LPC 17xx lwip port: use of pbuf for rx

Sergio R. Caprile
The recommendations are to use separate pools for rx and tx so they can
not starve each other. Since PBUF_RAM is used for tx, then rx is
expected to use PBUF_POOL. I bet you can also use separate pools but I
don't know how.

Last time I checked, PBUF_RAM allocates a single block of memory. That
is probably the reason why these guys use them for DMA descriptors.
PBUF_POOL, on the other hand, *might* (not necessarily *will* but it
will surely bite you if you don't prepare for it) allocate several
buffers in a chain to satisfy your request. That is, your pbuf will be a
chain of pbufs.
While you can memcpy len bytes to a PBUF_RAM pbuf p where p->tot_len >=
len; you certainly can not do it to a PBUF_POOL and must loop through
all pbufs q=q->next writing up to q->len bytes to each one. Hope I'm
clear...

So, you'd better check what your driver is doing.
Keeping the rx side to PBUF_RAM can cause tx and rx to compete for
buffers (unless...)
Moving the rx side to PBUF_POOL if the driver was not properly written
for that, can cause memory corruption when the pool gets fragmented and
returned pbufs are chained ones.


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: NXP LPC 17xx lwip port: use of pbuf for rx

Giuseppe Modugno
Il 29/03/2019 15:53, Sergio R. Caprile ha scritto:

> The recommendations are to use separate pools for rx and tx so they can
> not starve each other. Since PBUF_RAM is used for tx, then rx is
> expected to use PBUF_POOL. I bet you can also use separate pools but I
> don't know how.
>
> Last time I checked, PBUF_RAM allocates a single block of memory. That
> is probably the reason why these guys use them for DMA descriptors.
> PBUF_POOL, on the other hand, *might* (not necessarily *will* but it
> will surely bite you if you don't prepare for it) allocate several
> buffers in a chain to satisfy your request. That is, your pbuf will be a
> chain of pbufs.

I think I understood. However the LPC network driver allocates always
ENET_ETH_MAX_FLEN-length pbufs. If PBUF_POOL_BUFSIZE is greater or equal
ENET_ETH_MAX_FLEN (that is 1552 bytes) I don't think
pbuf_alloc(PBUF_RAW, (u16_t) ENET_ETH_MAX_FLEN, PBUF_RAM) could return a
pbuf chain.


> While you can memcpy len bytes to a PBUF_RAM pbuf p where p->tot_len >=
> len; you certainly can not do it to a PBUF_POOL and must loop through
> all pbufs q=q->next writing up to q->len bytes to each one. Hope I'm
> clear...
>
> So, you'd better check what your driver is doing.
> Keeping the rx side to PBUF_RAM can cause tx and rx to compete for
> buffers (unless...)
> Moving the rx side to PBUF_POOL if the driver was not properly written
> for that, can cause memory corruption when the pool gets fragmented and
> returned pbufs are chained ones.

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users