[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] Problem with custom buffers when MEM_ALIGNMENT=4 and ET
From: |
Mason |
Subject: |
Re: [lwip-devel] Problem with custom buffers when MEM_ALIGNMENT=4 and ETH_PAD_SIZE=2 |
Date: |
Tue, 25 Oct 2011 17:06:53 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 |
Simon Goldschmidt wrote:
> Mason <address@hidden> wrote:
>
>> --- pbuf.c.orig 2011-08-24 11:02:34.484375000 +0200
>> +++ pbuf.c 2011-10-25 16:03:44.015625000 +0200
>> @@ -376,7 +376,7 @@
>>
>> p->pbuf.next = NULL;
>> if (payload_mem != NULL) {
>> - p->pbuf.payload = LWIP_MEM_ALIGN((void *)((u8_t *)payload_mem +
>> offset));
>> + p->pbuf.payload = (u8_t *)payload_mem + offset;
>> } else {
>> p->pbuf.payload = NULL;
>> }
>
> I've recently changed that in git to:
>
> p->pbuf.payload = (u8_t *)payload_mem + LWIP_MEM_ALIGN_SIZE(offset);
>
> Does that work for you?
I'm using PBUF_RAW, so offset=0, so your modification and mine are equivalent.
I think there might be another problem when pbuf_layer = PBUF_LINK
Assume payload = 0x82751742, thus the IP header is at 0x82751742 + 0xd =
0x82751750
but the actual code will set payload to payload_mem + 16
But maybe we wouldn't use the PBUF_LINK layer in such a case?
>> Probably not appropriate, but again, I'm not sure what MEM_ALIGNMENT
>> really means.
>
> Your MEM_ALIGNMENT is correct: it's used for accessing U32 variables,
> not for cache aligment.
Thanks for clearing this up.
--
Regards.