[ofw][patch] mcast destroy retry count - parameters

[Fab Tillier]

Hi Slava,

>From: ofw-bounces at lists.openfabrics.org
>[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Slava Strebkov
>Sent: Tuesday, June 17, 2008 3:21 AM
>
>Index: core/al/al_mcast.c
>===================================================================
>--- core/al/al_mcast.c     (revision 1261)
>+++ core/al/al_mcast.c  (working copy)
>@@ -271,8 +273,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_destroy_retry_timeout, g_mc_destroy_retry_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

Is there a reason user-mode clients should not use the same timeouts and retry count?  Just use the same code for kernel- and user-mode clients.  What's good enough for the kernel is good enough for user-mode clients.  It will keep the code easier to maintain, and will keep consistent functionality.

I also agree with Sean that having exponential backoff would make sense.  For that, I would suggest having the timeout value specified in the al_send_sa_req be a starting value, and have the lower layer implement the exponential backoff.  In fact, if the mad layer did the exponential backoff itself, I suspect you could eliminate the starting timeout value and start with something pretty aggressive.  In fact, I would even eliminate the retry count, and provide a "timeout" value, and the lower layer would calculate the number of retries needed.

-Fab