lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SPAM? Re: [lwip-users] about alignment issues.


From: Jan Ulvesten
Subject: RE: SPAM? Re: [lwip-users] about alignment issues.
Date: Thu, 20 Apr 2006 11:29:14 +0200

>From Alteras lwIP port:

static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
((aligned (MEM_ALIGNMENT)));

Memory alignment can be forced on specific variables, at least for GNU
compilers. I guess other compilers have a similar syntax?

Why not use that like below?

#define MEM_ALIGNMENT_DIRECTIVE  __attribute__ ((aligned
(MEM_ALIGNMENT)));
static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE]
MEM_ALIGNMENT_DIRECTIVE;

MEM _ALIGNMENT_DIRECTIVE can be blank if not supported.


There are 5 places in the code where memory alignment has been included
in the definition in my source.

static u8_t ip_reassbuf...
static u8_t ip_reassbitmap....
static u8_t buf....
static u8_t ram....
static u8_t pbuf_pool_memory....


Jan Ulvesten
Senior Software Engineer
SICOM  AS
Tel   +47 72 89 56 55
Fax  +47 72 89 56 51
Mob +47 416 62 033
 

-----Original Message-----
From: Pedro Alves [mailto:address@hidden 
Sent: 17. april 2006 14:26
To: Mailing list for lwIP users
Subject: SPAM? Re: [lwip-users] about alignment issues.

Derek Guerdon wrote:

>On Fri, 14 Apr 2006 09:30:46 -0700, Curt McDowell wrote:
>  
>
>>Still, a union is not called for:
>>
>>struct {
>> struct pbuf pbuf;
>> u64_t payload[MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE) / sizeof(u64_t)];
>>} pbuf_pool_memory[PBUF_POOL_SIZE];
>>
>>Or, if it's more pleasing, we could define a "maximal" type somewhere
>>and use that for payload[].  "struct mem" does that in mem.c, except
it
>>should be defined in a header file to clean it up.
>>    
>>
>
>I think the latter is preferable for three reasons. First, even u64_t
>isn't required to be maximally aligned under ANSI-C (although in
>practice I've never seen a case where it wasn't). Second, there are
>some compilers without native unsigned 64-bit integer. Third,
>allocating an array of 'memory aligned types' allows targets with
>limited memory to avoid allocating unused memory.
>
>The declaration needs to be reworked a bit as the one given won't
>allocate enough space when MEM_ALIGNMENT is less than 8 (e.g. if
>MEM_ALIGNMENT is 4 and PBUF_POOL_SIZE is 1540, only 1536 bytes are
>allocated in payload).
>
>Something along these lines should work:
>MAX_ALIGN_T
>payload[(PBUF_POOL_BUFSIZE+sizeof(MAX_ALIGN_T)-1)/sizeof(MAX_ALIGN_T)];
>
>
>I'd like to offer my thanks to you for addressing these issues. I
>think they consumed the majority of the time I spent porting lwIP.
>Getting the alignment issues fixed will be a major improvement to the
>code base.
>  
>

Although I don't belong to the "unions are ugly school", I'm ok with a 
solution like this.
Actually, I think that flattening the pool some more would be even
better.

static struct pbuf mem[PBUF_POOL_SIZE];
typedef u32_t MAX_ALIGN_T;
typedef MAX_ALIGN_T 
pbuf_pool_payload_t[(PBUF_POOL_BUFSIZE+sizeof(MAX_ALIGN_T)-1)/sizeof(MAX
_ALIGN_T)];
pbuf_pool_payload_t pbuf_pool_payload[PBUF_POOL_SIZE];

void
pbuf_init_dummy_just_to_show(void)
{
  int i;
  for(i = 0; i < PBUF_POOL_SIZE; ++i) {
    mem[i].next = mem[i+1].next;
    mem[i].len = mem[i].tot_len = sizeof(pbuf_pool_payload_t);
    mem[i].payload = pbuf_pool_payload[i];
    mem[i].flags = PBUF_FLAG_POOL;
  }
}



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users





reply via email to

[Prev in Thread] Current Thread [Next in Thread]