lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [lwip-devel] igmp implementation


From: Frédéric BERNON
Subject: RE : [lwip-devel] igmp implementation
Date: Wed, 11 Jul 2007 09:58:20 +0200

>I decide that the IGMP group list should be interface specific so I move the group list to the netif structure.
Yes, it should be, Steve Reynolds code didn't, but Mace Gael did (but there was several problems). The current design more based on Steve code.
 
>I then modified igmp.c to deal on the netif structure passed.
Ok.
 
>I also change igmp_init() to igmp_start() as it only work if the interface is up and running.  I them added the igmp_start to the netif_set_up() function (removing it from tcpip.c). 
I'm not agree: since the "up" can be call each time te DHCP bind the address, you don't have to reset it at this time. I think the job is to do on netif_add (and it will be better for adding/removing netif at any time).
 
>The fuction type igmp_mac_filter() does not need the action or group parameters as it rebuild the hash table based on the list in the netif sturcture past.  Is there any reason to keep these?
Yes: each join/leave group will be slower with this solution: some MAC have different filter feature, with not a hash table, but just a table, they don't have to process like this. Since it's MAC dependant, lwIP should provide all parameters, and let the port designer do the best solution for his hardware.
 
>NETIF_FLAG_IGMP
Seems not necessary. You can already use NETIF_FLAG_ETHARP to know if the interface is Ethernet/ARP. If the idea is to define that such or such interface has IGMP capability, so yes. But in this case, you should better implement the 3 IGMP level described in RFC.Be careful, netif's "flags" field is a u8_t.
 
But you don't talk about the "big" problem (not so big, but): the ip_input patch: even with a "per netif" group list, the current ip_input code only select one netif to do the processing. If two netif "join" the same group, what do you propose to handle that? I think it could be more intrusive (in the source code and in execution time). This point if the most important to my point of view. A better IGMP implementation will also support SO_REUSEADDR/PORT (see https://savannah.nongnu.org/task/?6995), since two sockets/services could need to receive the same information. Last, a socket level filter will be the last step (because, when a socket do a "leavegroup, there can be already packets in its recvmbox from this group, and they should be dropped, and not given to the application).
 
There is also some tips to change in igmp.c : it should better use memp than mem, the remove of "group" struct is not handled, etc...
 
Since I done the integration, I have planned to improve all that in some time. But I think that "close" the release is more important, and I thought do that after. Problem, we don't know when will ended the release. So feel free to continue if you can't wait. Perhaps we could open a task "Improve IGMP implementation"? I can easily test it since one of my lwIP products is using lot of multicast (sending/receiving...).
 
 
 
====================================
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@hiddenr
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 Bill Florac
Envoyé : mercredi 11 juillet 2007 06:37
À : lwip-devel
Objet : RE: [lwip-devel] igmp implementation

Follow-up,
 
I decide that the IGMP group list should be interface specific so I move the group list to the netif structure. I then modified igmp.c to deal on the netif structure passed.  I also change igmp_init() to igmp_start() as it only work if the interface is up and running.  I them added the igmp_start to the netif_set_up() function (removing it from tcpip.c).  The fuction type igmp_mac_filter() does not need the action or group parameters as it rebuild the hash table based on the list in the netif sturcture past.  Is there any reason to keep these?
 
While at it, I added a NETIF_FLAG_IGMP flag to the netif flags....
 
All may seem confusing but if this seem like the right direction, I'll submit the changes once I have done some testing.
 
Bill


From: address@hidden on behalf of Bill Florac
Sent: Tue 7/10/2007 2:08 PM
To: address@hidden
Subject: [lwip-devel] igmp implementation

I'm attempting to implement igmp off the latest build.  I see that I need to implement at igmp_mac_filter function.  My plan is to implement this in the ethernetif.c module.  It would be assigned to the netif structure in the low_level_init() function.  The function would then make the correct calls to the device driver (Atmel AT91 EMAC) to set or clear the correct hash key.

As we leave a group we need to make sure that know another joined group address resolves to the same hash key. If so, we don't want to clear the key. There are a number of ways to resolve this.  We could keep a some sort of reference count or we can test the entire group list as we leave a group. If we do a test, either the igmp_mac_filter() would need to have the list of groups or the calling function igmp_leavegroup() would have to have access to the hashkey() function (making it HW dependent).

Any thoughts how to best/better handle this?

Bill


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]