Re: [lwip-devel] Fwd: Re: TCP errors going from 1.4.1 to 2.0.3

[Bill Auerbach]

>Ehrm, maybe I can understand why you return pbuf->payload as uncached, but 
>handling pbufs uncached as well seems totally unperformant. 

Because p and p->payload are usually in the same close region, accessing p as 
cached and  p->payload as noncached was causing problem.

>Have you actually *benchmarked* accessing everything uncached vs. cache 
>flushing before TX/after RX?

No, I haven't.  Partly because I couldn't get an error-free wireshark capture 
trying to flush/clear cache before RX and TX and leaving p and p->payload 
as-is.  Also, with a 4k data cache, any gain from the stack and program 
variables in cache would be lost as soon as 2 packets came in.  Since I'm 
copying from the payload to the application buffer it's only accessed once.

>If you insist, one idea could be to just "move" the pools in question to 
>uncached memory instead of changing pbuf.c. That might not work for PBUF_RAM 
>though...

Interesting - so memp_malloc would return uncached memory (which is just 
addresses with bit 31 set).

>I don't have current numbers (we're not really using that platform any more), 
>but I went for cache flushing in the last product with the NIOS II and didn't 
>have any problems.

Apparently I'm doing something wrong.  With 4 NIOS II lwIP 1.4.1 products done 
and tested for up to 7 years I'm puzzled that I'm only just seeing this now.  
I've just spent 2 hours again with cached pointers and flushing on Ethernet TX 
and RX and it mostly works - it's just not error free.  Maybe our hardware 
interface in the Altera is bad or something - us software guys get what we get. 
 I'm sure I'll be told it's fine - it's software. :-)

>How would your patch look like?

A #define in sys_arch like:

#define SYS_REMAP_PTR(p) ((void *) ((u32_t) p | (1 << 31)))

And in pbuf.c

#ifndef SYS_REMAP_PTR
#define SYS_REMAP_PTR(p) p
#endif

And 5 additions of p = SYS_REMAP_PTR(p)  (or p is p->payload in places).  This 
facility might also be used to do something like pointer checking.

Thanks for your comments,
Bill