[Users] Librdmacm - mckey

[Miljen Mikić]

Hi Hal,

 

thanks for your answer!

 

I understand that we cannot determine for sure how much time would it take to refresh the state, that's why my goal is to avoid any sleep(<SOME NUMBER OF SECONDS>) call in the code while keeping fingers crossed. Is there any API function that could inform us that multicast group is ready, e.g. some event that we could listen on?

 

Best regards,

Miljen Mikic

 

From: Hal Rosenstock [mailto:hal.rosenstock at gmail.com] 
Sent: Friday, March 31, 2017 2:16 PM
To: Miljen Mikić <miljen.mikic at mireo.hr>
Cc: users at lists.openfabrics.org
Subject: Re: [Users] Librdmacm - mckey

 

Hi,

 

In order to setup the multicast group tree (for mckey), SM must first route the MC tree and then program MulticastForwardingTables of switches that tree passes through. The amount of time depends on the topology (how many switches in subnet), processor speed of SM machine, and lastly delivering the modified forwarding tables to the IB switches involved in that multicast tree. This time is non deterministic.

 

IB multicast is inherently unreliable as it is based on UD transport. Are you looking for reliable multicast mechanism for IB or is it just the startup issue that's important for your application ?

 

-- Hal

 

On Fri, Mar 31, 2017 at 6:47 AM, Miljen Mikić <miljen.mikic at mireo.hr <mailto:miljen.mikic at mireo.hr> > wrote:

Hello,

 

I went through the source code of mckey utility (available e.g. here: https://github.com/ofiwg/librdmacm/blob/master/examples/mckey.c ). There is an interesting comment at the line 524:

 

/*

  *  Pause to give SM chance to configure switches. We don't want to

 *  handle reliability issue in this simple test program.

  */

  sleep(3);

 

If we remove sleep function call, mckey does not work properly anymore (receiver side does not get all messages that were sent). Does anyone know how long does it take for SM to „configure switches“, and what is the proper way to „handle reliability issue“?

 

Many thanks in advance.

 

Best regards,

Miljen Mikic

 


_______________________________________________
Users mailing list
Users at lists.openfabrics.org <mailto:Users at lists.openfabrics.org> 
http://lists.openfabrics.org/mailman/listinfo/users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/users/attachments/20170331/874234b9/attachment.html>