[ofw][patch] mcast garbage collector

[Fab Tillier]

Why not just use the variables always?  I would expect the values that are appropriate for kernel clients would also be appropriate for user mode clients (but not vice versa).

-Fab

From: Slava Strebkov [mailto:slavas at voltaire.com]
Sent: Sunday, June 15, 2008 5:13 AM
To: Fab Tillier; Sean Hefty; ofw at lists.openfabrics.org
Subject: RE: [ofw][patch] mcast garbage collector


This part allows specifying different values for timeout and retrying count.
Slava
________________________________
From: Fab Tillier [mailto:ftillier at windows.microsoft.com]
Sent: Thursday, June 12, 2008 8:53 PM
To: Sean Hefty; Slava Strebkov; ofw at lists.openfabrics.org
Subject: RE: [ofw][patch] mcast garbage collector

@@ -271,8 +274,14 @@
            sa_mad_data.p_attr = &h_mcast->member_rec;

            ref_al_obj( &h_mcast->obj );
-           status = al_send_sa_req(
-                       &h_mcast->sa_dereg_req, h_mcast->port_guid, 500, 0, &sa_mad_data, 0 );
+          status =
+#if defined( CL_KERNEL )
+                      al_send_sa_req(
+                      &h_mcast->sa_dereg_req, h_mcast->port_guid, g_mc_destr_retr_timeout, g_mc_dest_retr_count, &sa_mad_data, 0 );
+#else
+          al_send_sa_req(
+          &h_mcast->sa_dereg_req, h_mcast->port_guid, 500, 0, &sa_mad_data, 0 );
+#endif

This is separate from this patch, but can someone explain this part to me?  The only way joining multicast groups can work is if it's done in a singTle location, like the kernel.  Does al_send_sa_req() drop to the kernel and get filtered?

It drops to the kernel alright, but there is no filtering in IBAL.  If multiple clients register for the same multicast group, that group will get destroyed when the first client deregisters.  Makes it very hard to have multiple QPs on the same port in the same multicast group.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080615/9e1aebd3/attachment.html>