[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-devel] Speed up lwIP
From: |
Goldschmidt Simon |
Subject: |
RE: [lwip-devel] Speed up lwIP |
Date: |
Fri, 4 May 2007 12:59:44 +0200 |
> Goldschmidt Simon 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):
> >
> > - 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.
>
> This makes sense. Note that care may be required on when to
> use MEMCPY instead of memcpy - GCC can optimise memcpy away
> sometimes, particularly with a constant, relatively small
> "len". That saves a function call. Maybe a second macro for
> that case? SMEMCPY for small memcpy?
>
Yes, that's a good idea.
> > - (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.
>
> Perhaps you can just tell lwIP you are big-endian when you
> aren't? Are there places where endianness is tested but not
> for protocol headers?
>
The problem is the MACs are only capable of some protocols. If you
tell lwIP you are big-endian, you will lose all htonl-like functions
or have to define your own (which is bad also, since you'd have 2
functions
having the same name). Either way, it's a hack since you're not
on a big-endian system (which is a shame, of course if you're developing
a networking system, but tell that altera...).
> OOI I've never seen such a MAC.
Guckst du hier: http://www.morethanip.com/mbps_10_100_1000_mac_acc.htm
This is an accelerating MAC for (altera?) FPGA systems (which I'm into,
at the moment). There are other ones, too. One would be the DMA-engine
I'm currently playing around with in my free-time... (And that, of
course, is the reason I'm making this roposal ;-)