Re: [lwip-users] Porting LWIP into TI C6203 bug fix

[Kieran Mansley]

On Mon, 22 Dec 2003, Amit Kristal wrote:

> Hi all,
>
> I have been porting the lwip onto TI C6203 dsp.
> The porting required a change to pbuf_alloc() & I believe I have encountered
> two bugs in the tcp->tmr & tcp->cwnd:
>
> 1. Changes needed in pbuf_alloc():
>
> The DSP requires working 32bit aligned, meaning that memory should be
> alocated 32bit aligned & that ip_hdr / tcp_hdr will point to 32bit aligned
> addresses. YET the ethernet headr is 14 byte long... the solution was to
> work with MEM_ALIGNMENT= 4 & in pbuf_alloc() , in case of PBUF_LINK, after
> mem allocating, make payload point to a 16bit aligned adderss from which the
> ethrnet packet start, making the ip & tcp headers 32bit aligned in the mem.
> (PBUF_LINK_HLEN should be defined to 16)

The issue of non-32bit aligned access has come up a lot recently.  Having
the Ethernet header on a 16 bit boundary is a standard way of ensuring the
IP and TCP headers are 32 bit aligned (but does mean the ethernet header
is then misaligned, which may cause you problems).  If we don't already
have something like this in lwIP then we should think about adding it, but
I don't think pbuf_alloc is the right place - that code should be
independent of the physical network, and the munging of the payload
pointer should be done by the ethernet driver.

> 2. tcp->tmr bug fix
>
> I believe I have encountered a bug: tcp->tmr is 16bit yet tcp_ticks is
> 32bit. (same problem may be with tcp->rttest). This means that after ~9.1
> hours the tcp->tmr will wraparound while tcp_ticks keeps on going... (this
> causes problems when calculating inactive times). the simple solution is to
> change tcp->tmr to be 32bit. (changing tcp_ticks to 16bit is more work since
> we have to handle the wraparound that will happen after only 9 hours , with
> 32bit it will take enough years...)

This was fixed over a year ago, but thanks for pointing it out.  (Bug
#1838)

> 1. I get strange values when looking at stats.mem.used, is there a problem
> using it?

Sounds like it's not being initialised properly.  If anyone who uses this
code wants to submit a bug/patch, I'll take a look at checking a fix in.

> 3. Does Nagle algorithm currently implemented in the LWIP?

Yes.  I think so.

> 5. I'm working with version 0.5.3, is there a new one available?

Yes, and now savannah is back you should be able to get it from the
project homepage:

http://savannah.nongnu.org/projects/lwip/

Hope that helps

Kieran