RE : [lwip-devel] Speed up lwIP

[Frédéric BERNON]

Some tips:

In a general way, to speed up the stack, replace direct or indirect calls to 
memp_malloc & pbuf_alloc. In my last measures, when I replace netbuf_ref (using 
pbuf_alloc, and indirectly, memp_malloc, and with need a pbuf_free) by a locale 
variable "struct pbuf mybuf" (that I directly use with lwip_sendto's netbuf, 
and I also remove the pbuf_free), I get +10% of performance on sendto. More, 
you avoid to get a "not enought memory" error, and avoid to have to check the 
return value...

Also use define to replace parameters wrapping or field access (see last 
netconn_xxx patchs):

err_t
api_msg_post(struct api_msg *msg)
{
  return tcpip_apimsg(msg);
}

Could be replace by :

#define api_msg_post(msg) tcpip_apimsg(msg)

You can also replace all sys_mbox_fetch calls per sys_arch_mbox_fetch (except 
in tcpip_thread) if you don't need to use "timeouts" at application level (you 
also avoid some problems)

sys_timeout also need to be optimize: most of time, a sys_timeout's handler 
recall sys_timeout. I think there is something to do on this point...
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Goldschmidt Simon
Envoyé : vendredi 4 mai 2007 13:00
À : lwip-devel
Objet : RE: [lwip-devel] Speed up lwIP



> 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 ;-)



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

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf