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

[Pisano, Edward A]

Hi all,
It's interesting that this e-mail thread came up when it did.  I just
noticed that I, too, see the same 2 byte offset issue with the payload
after the headers have been removed.  

I'd be interested in hearing how you address it.

I'm interfacing with a device that is most efficiently accessed with
32bits of data per transaction.  And it is more efficient for me to
retrieve that data from memory on 32bit boundaries.  Having the received
payload offset by 2 bytes makes for several inefficient options to get
the data into alignment for 32bit boundary operations or to just bite
the bullet and access memory 16bits at a time, shift and concatenate it
myself.

I'm using the xemac driver from XiLinx to interface lwIP to their EMAC
core.  It has a hardcoded value of 14 in it for, what appears to be,
removing the Ethernet Frame (6 byte dest. Addr + 6 byte src. Addr + 2
byte type) from the payload on received packets.  Although,
PBUF_LINK_HLEN is defined as 16, it only appears to be used for
transmitted packets.

Regards,
Ed
-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Taranowski, Thomas (SWCOE)
Sent: Thursday, February 08, 2007 8:19 PM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] porting lwip to a mips system

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


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