[ofw][patch] mcast garbage collector

Slava Strebkov slavas at voltaire.com
Sun Jun 15 22:24:02 PDT 2008


User mode client request goes into kernel. It's enough to use variables
in kernel only. 

 

Slava

 

________________________________

From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
Sent: Monday, June 16, 2008 1:27 AM
To: Slava Strebkov; Sean Hefty; ofw at lists.openfabrics.org
Subject: RE: [ofw][patch] mcast garbage collector

 

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/20080616/b66f1e91/attachment.html>


More information about the ofw mailing list