>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 : [EMAIL PROTECTED] Web Site : http://www.hymatom.fr ==================================== P Avant d'imprimer, penser à l'environnement -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
BEGIN:VCARD VERSION:2.1 N:BERNON;Frédéric;;M. FN:Frédéric BERNON ORG:HYMATOM SA;Recherche et Développement TITLE:Chef de projet informatique TEL;WORK;VOICE:04-67-87-61-10 TEL;WORK;FAX:04-67-70-85-44 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;23;Zone Industrielle=0D=0A175 rue de Massacan;VENDARGUES;;34740;FRANCE; LABEL;WORK;ENCODING=QUOTED-PRINTABLE:23=0D=0AZone Industrielle=0D=0A175 rue de Massacan=0D=0AVENDARGUES 34740=0D= =0AFrance URL;WORK:http://www.hymatom.fr ROLE:Chef de projet informatique EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20020404T083210Z END:VCARD
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
