On 5/4/07, Goldschmidt Simon <address@hidden> wrote:
Hi all,
Talking about lwIP performance on this list, I have 2 issues which
I think could speed up lwIP (at least for me, they did):
I like the #define MEMCPY idea. My systems current system's implementation uses
a very generic byte copy routine, which is an order of magnitude slower than just a simple
dword type copy routine. Using my own memcpy either requires the use of some linker gymnastics,
or some stack code modification to use a differently named memcpy routine. The #define MEMCPY would
solve this problem for me in a fairly general way. It also makes sense from a lwIP perspective. I might not
have much of a system environment, so being able to #define MEMCPY to be something in my sys_arch.c
would be a fairly clean implementation.
- create a #define MEMCPY(dst,src,len) (defined to memcpy(dst,src,len)
as default) to be able to easily provide a faster memcpy than the one
included in the C library. Especially if src or dst are not aligned,
writing my own memcpy gave me much better performance. I could define
memcpy to my own version, but in my opinion, that's a dirty hack.
I also like the following idea, like I like TCP checksum offloading, etc. I think it would be
a nice feature, but don't view it as a central feature. Maybe I should start seeing these features
as more central to grabbing the last bit of performance out of a system starved for CPU time,
as most of mine are. I will say that I think this is a fairly common feature on most modern MACs.
At least, it's been a feature on those I've seen. I fondly remember the first time I saw this feature
in action. I was trying to debug a PowerPC FCC driver, and thought I was going nuts because all
of my incoming/outgoing payloads were in little endian :)
- (only for little endian processors and spectial MACs):
include some kind of define to tell the stack not to convert items in
protocol headers from host to network order if the MAC can do this.
This requires a rather advanced MAC, but still I think it's important
that we support this in order not to slow down MACs that have
accelerating
features.
Any comments?
Simon
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel