RE: [lwip-users] porting lwip to a mips system

[Taranowski, Thomas \(SWCOE\)]

Of course, you are right on the header length.  I suppose I was using
the new math to come up with 16. Now that you bring it up, it is sort of
weird that it's set to 16 by default.  I suppose there is some
historical reason for this value, but haven't really bothered to look
into it.  I left it at 16 in my port, and so far everything is kosher.

For what it's worth, I verified that I also have the same 2-byte
alignment issue you're seeing, using UDP and the MEM_ALIGNMENT set to 4.



 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
On
> Behalf Of Robert Goeffringmann
> Sent: Thursday, February 08, 2007 9:35 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] porting lwip to a mips system
> 
> Sorry if I'm being stupid, but isn't the link header size always
> 2 x 6 bytes mac + 2 bytes ethertype?
> 
> In any case, changing it to 16 doesn't have any influence on this at
all.
> The code in pbuf.c behaves exactly the same as with PBUF_LINK_HLEN=14,
due
> to that alignment code and the size of the ethernet header is
hardcoded in
> etharp.c.
> 
> Regards,
> Robert.
> 
> ----- Original Message -----
> From: "Taranowski, Thomas (SWCOE)" <address@hidden>
> To: "Mailing list for lwIP users" <address@hidden>
> Sent: Wednesday, February 07, 2007 12:14 AM
> Subject: RE: [lwip-users] porting lwip to a mips system
> 
> 
> Out of curiosity, why did you define the PBUF_LINK_HLEN to be 14?  If
> you are using 802.3, it should typically be 16.
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of Robert Goeffringmann
> Sent: Tuesday, February 06, 2007 12:45 PM
> To: address@hidden
> Subject: [lwip-users] porting lwip to a mips system
> 
> Hello!
> 
> I am currently trying to get lwip to work on a PlayStation 2.
> In this process, I've been facing some rather strange effects and I am
> wondering if things are actually meant to work this way...
> 
> The first issue I ran into was the sys_arch_protect function.
> My system works with multiple threads and implements the semaphore
> functions
> as well.
> First I tried to implement sys_arch_protect by disabling interrupts.
> This doesn't work because certain functions (e.g. pbuf_free in pbuf.c)
> will
> use sys_arch_protect (thereby disabling interrupts) and will then
(while
> 
> interrupts are still disabled) call functions which use semaphores for
> inter-thread protection (in this case, pbuf_free may call mem_free).
> And well... obviously you can't wait for a semaphore if you've
disabled
> interrupts in order to prevent thread switching.
> The way I understand it, pbuf_free could even be changed so that it
> doesn't
> need to disable interrupts if the pbuf it's being called on is a
memory
> buffer.
> Or did I overlook a good reason why it works like this?
> At some point I had the feeling that this situation occurs with other
> functions as well, but so far I couldn't find any.
> Anyways, if this can't be changed, I suppose it would be better to
> mention
> this behaviour in the sys_arch.txt. :)
> Now as I implemented sys_arch_protect using a recursive mutex, it
works.
> 
> 
> The problem I am facing right now is the alignment of packets.
> I've set MEM_ALIGNMENT to 4 in my lwipopts.h.
> Now, if my netif driver receives a packet, it invokes pbuf_alloc,
> receives a correctly aligned buffer, fills it with data and passes it
to
> 
> lwip.
> Works smoothly.
> 
> However, if an application sends tcp data (using the socket api, I
> didn't
> try anything else), all the packets that lwip sends to my netif driver
> for
> outputting are misaligned by 2 bytes. And looking at pbuf.c, this
> actually
> seems to be the intention...
> I defined PBUF_LINK_HLEN as 14 bytes.
> Now, when tcp_enqueue calls pbuf_alloc, pbuf_alloc first computes the
> size
> it needs for headers. In this case, that's:
>  20 (PBUF_TRANSPORT_HLEN) + 20 (PBUF_IP_HLEN) + 14 (PBUF_LINK_HLEN) =
54
> bytes.
> This is then rounded up to 56 bytes in order to match my MEM_ALIGNMENT
> of 4
> and pbuf->payload is set to that offset, so payload is correctly
> aligned.
> However, later these header sizes get substracted again and so the
> pbuf's
> payload
> points to an address which is 2 bytes off from the necessary alignment
> when
> it's passed to netif->linkoutput.
> This is especially annoying as I have to pass the data as doublewords
of
> 4
> bytes to the hardware's I/O port.
> So basically, I have to read it from memory in units of 2 bytes, put
it
> together to make dwords and pass it to the HW port.
> Even worse, though, if the pbuf is splitted, the splits occur in the
> middle
> of a dword, which makes it even more difficult.
> 
> Is this really the intention?
> 
> Thanks in advance :)
> Robert.
> 
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users