RE : [lwip-users] "the ARP layer is not protected againstconcurrentaccess"

[Frédéric BERNON]

>The solution which Frédéric proposed is simpler, but sends ALL packets to the 
>tcpip_thread. Filtering them before passing on seemed more performant to me.

Yes, I've got the same idea yesterday :) Even if on a "classic" network, most 
of packets are IP & ARP, there is some others packets for STP or other Ethernet 
level protocols (in my network, there is something like 120 devices, and, in 5 
sec, there is something like 15 "low-level" packets).

This is always the same problem  : more code in "receive" thread (so footprint 
increase), to save processor time. I don't think this this a problem, and I can 
propose a "clean" patch if Simon is ok with this solution...

Simon?
  
====================================
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é : lundi 5 mars 2007 10:30
À : Mailing list for lwIP users
Objet : RE: [lwip-users] "the ARP layer is not protected 
againstconcurrentaccess"


Hi,

> Sounds like a reasonable suggestion to me.  I'm slightly
> concerned by you saying that the tcpip_input() function 
> wouldn't be needed anymore.
> Can you explain why?

That statement was only be true for 'new' drivers: they would call 
tcpip_input_w_arp() for IP packets and tcpip_arp_input() for ARP packets; 
tcpip_input() (without ARP) could only be used by old drivers. I wouldn't 
remove it, only not use it for new drivers (IF we want the two mechanisms to 
coexist; but I guess we have to in order to support ppp?). The solution which 
Frédéric proposed is simpler, but sends ALL packets to the tcpip_thread. 
Filtering them before passing on seemed more performant to me.

> 
> > AS far as I know (but I'm not using it by now), that
> wouldn't affect
> > raw API programs running without an OS, since they don't
> use messages,
> > anyway. This would simply be a matter of assigning another input
> > function for netifs (and maybe another input function, e.g. netif-
> > >arp_input()).
> 
> Any raw API users/experts care to comment on this aspect?
> Would be nice if we could come up with a simple solution that 
> addressed this problem for all APIs.

That's definitively what I want, too. And I started using the raw API to test 
this, but I cannot guarantee to see everything that matters since I'm only 
beginning to use this. So, comments are still welcome!

Simon.


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

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