[bug #26133] Processor specific porting needs flexibility in terms of placement of various memory pools.

[Sylvain Beucler-4]

URL:
  <http://savannah.nongnu.org/bugs/?26133>

                 Summary: Processor specific porting needs flexibility in
terms of placement of various memory pools.
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: blackfin
            Submitted on: Thu 09 Apr 2009 02:03:28 PM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release:
            lwIP version: 1.3.0

    _______________________________________________________

Details:

Protecting them with simple macro will give them a chance to declare/define
at the upper level so lwip code changes as below

Files changed:
core\memp.c

Changes:
#if !defined(LWIP_RAM)
/* Adam original */
static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT];
#else
/* Christiaan alignment fix */
static u8_t* ram;
static struct mem ram_heap[1 + ( (MEM_SIZE + sizeof(struct mem) - 1) /
sizeof(struct mem))];  
#endif

memp.c: line 136:
From:
/** This is the actual memory used by the pools. */
static u8_t memp_memory[MEM_ALIGNMENT - 1
#define LWIP_MEMPOOL(name,num,size,desc) + ( (num) * (MEMP_SIZE +
MEMP_ALIGN_SIZE(size) ) )
#include "lwip/memp_std.h"
                 ];


To:
/** This is the actual memory used by the pools. */
static u8_t* memp_memory;
u8_t** ADI_TOOLS_memp_ptr = &memp_memory;
u32_t  ADI_TOOLS_memp_len = MEM_ALIGNMENT - 1
#define LWIP_MEMPOOL(name,num,size,desc) + ( (num) * (MEMP_SIZE +
MEMP_ALIGN_SIZE(size) ) )
#include "lwip/memp_std.h"
                  ;

pbuf.c: line76

From:
/*static u8_t pbuf_pool_memory[MEM_ALIGNMENT - 1 + PBUF_POOL_SIZE *
MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE + sizeof(struct pbuf))]; */


To:
static u8_t* pbuf_pool_memory;
u8_t** ADI_TOOLS_pbuf_pool_ptr = &pbuf_pool_memory;
/*u32_t  ADI_TOOLS_pbuf_pool_len =
  (PBUF_POOL_SIZE * MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE + sizeof(struct
pbuf)));*/





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Follow-up Comment #1, bug #26133 (project lwip):

Can you explain how this should be used?  I presume porters of lwIP will have
to allocate an area of memory and poke it into ADI_TOOLS_memp_ptr or
something.  It's not clear what advantage this brings, and would by the look
of it break the existing ports.

I think this would be better done with a function call.  Use lwip/memp_std.h
to calculate the length required (as you have done), then call a
(port-defined) architecture-specific function to allocate the pool memory with
that length as an argument.  This function would return a pointer to the
memory that could be assigned to memp_memory.  There would also need to be the
corresponding "free this memory" call I suppose.

Ideally this should be an optional feature, so the existing behaviour is the
default (as that is what most will want) and those that need it could specify
something like #define LWIP_MEMP_EXTERNALLY_ALLOCATED 1 (just a suggestion for
the name) in lwipopts.h

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Follow-up Comment #2, bug #26133 (project lwip):

I use this kind of trick to allocate the pool on an external SDRAM memory.
This is prefered to keep internal RAM usage low.

See attached patch which is really trivial.



(file #17897)
    _______________________________________________________

Additional Item Attachment:

File name: temp.diff                      Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Follow-up Comment #3, bug #26133 (project lwip):

I can provide a patch that places each pool in it's own static array.  By
preceding the additions with extern declaration one can move them to different
linker segments.  One or more pools can be moved.  I got a big increase moving
what I could to onchip memory.

Bill

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Piero 74]

hi

very interesting discussion.. i interested in patches for lwip memory
allocation. as we discussed in the past, to provide zero-copy driver
with some microcontrollers, (i have an arm7 i.e.), we should allocate
in different regions pbufs and pools (in particolar pbuf for rx
packets).
i know that in cvs head something has done to have the possibility to
DMA with tcp send, reducing pbuf chains, chancing enqueue... with a
big memory allocation control we should provide a zer-copy in easy
way!

bye
Piero
2009/4/9, Bill Auerbach <INVALID.NOREPLY@...>:

>
> Follow-up Comment #3, bug #26133 (project lwip):
>
> I can provide a patch that places each pool in it's own static array.  By
> preceding the additions with extern declaration one can move them to
> different
> linker segments.  One or more pools can be moved.  I got a big increase
> moving
> what I could to onchip memory.
>
> Bill
>
>     _______________________________________________________
>
> Reply to this item at:
>
>   <http://savannah.nongnu.org/bugs/?26133>
>
> _______________________________________________
>   Message sent via/by Savannah
>   http://savannah.nongnu.org/
>
>
>
> _______________________________________________
> lwip-devel mailing list
> lwip-devel@...
> http://lists.nongnu.org/mailman/listinfo/lwip-devel
>

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Follow-up Comment #4, bug #26133 (project lwip):

>Ideally this should be an optional feature, so the existing
>behaviour is the default (as that is what most will want) and >those that
need it could specify something like #define >LWIP_MEMP_EXTERNALLY_ALLOCATED 1
(just a suggestion for the >name) in lwipopts.h

Sure,This would be an optional feature for those who want to have finer
control on the placement rather than compiler chosen one.

One way is as below.

#ifdef LWIP_MEMP_EXTERNALLY_ALLOCATED
static u8_t* memp_memory;
u8_t** lwip_memp_ptr = &memp_memory;
u32_t  lwip_memp_len = xxx; // length of the memp memory
#else
 // default
#endif

and init routine will set the pointer to appropriate location
*lwip_memp_ptr = xxx;


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Update of bug #26133 (project lwip):

         Planned Release:                         => 1.4.0                  


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Update of bug #26133 (project lwip):

                 Summary: Processor specific porting needs flexibility in
terms of placement of various memory pools.  => Processor specific porting
needs flexibility in terms of placement of various memory pools and heap

    _______________________________________________________

Follow-up Comment #5:

Idea from Ioardan Neshev on lwip-devel (29-10-2009): Add define for linker
section to definition of 'ram_heap' (we need a _PRE and _POST define here for
compiler compatibility reasons, see dns.c:local_hostlist_static).

This define would make sense on memp_memory, too.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Sylvain Beucler-4]

Follow-up Comment #6, bug #26133 (project lwip):

https://savannah.nongnu.org/patch/?6822

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26133>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel