[ofw] wrong usage of ib_member_set_state

[Smith, Stan]

Please forward MC test program(s); will be glad to test drive them.

Stan.

From: Tzachi Dar [mailto:tzachid at mellanox.co.il]
Sent: Tuesday, October 04, 2011 12:29 AM
To: Smith, Stan; ofw at lists.openfabrics.org; Hal Rosenstock
Subject: RE: wrong usage of ib_member_set_state

There are programs that do multicast. I can send them to you, or that you can do the checkin and I'll check it after that.

Thanks
Tzachi

From: Smith, Stan [mailto:stan.smith at intel.com]
Sent: Monday, October 03, 2011 6:06 PM
To: Tzachi Dar; ofw at lists.openfabrics.org; Hal Rosenstock
Subject: RE: wrong usage of ib_member_set_state


From: Tzachi Dar [mailto:tzachid at mellanox.co.il]
Sent: Saturday, October 01, 2011 10:56 AM
To: Smith, Stan; ofw at lists.openfabrics.org; Hal Rosenstock
Subject: RE: wrong usage of ib_member_set_state


this looks like the right way to go.



the one thing to notice is that multicast should realy be tested before the commit.



How would you suggest IPoIB multicast be tested?



BTW, I loaded a patched IPoIB on a 34 node HPC cluster which uses DHCP for IPoIB address assignment on the 33 compute nodes (head node is static IPv4).

All  compute nodes were assigned a proper IPoIB IPv4 address and IPoIB continues to function correctly in this environment.



Stan.



Thanks

Tzachi

________________________________
From: Smith, Stan [stan.smith at intel.com]
Sent: Thursday, September 29, 2011 8:20 PM
To: Tzachi Dar; ofw at lists.openfabrics.org; Hal Rosenstock
Subject: RE: wrong usage of ib_member_set_state
Hello Tzachi,
  What did you decide to do about replacing ib_member_set_state() with ib_member_set_join_state() and then removing the 'ib_member_set_state()' definition from ib_types.h?

Thanks,

Stan.

From: ofw-bounces at lists.openfabrics.org [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Tzachi Dar
Sent: Tuesday, September 27, 2011 12:19 PM
To: ofw at lists.openfabrics.org; Hal Rosenstock
Subject: [ofw] wrong usage of ib_member_set_state


on windows we have the following 3 functions:



AL_INLINE void AL_API
ib_member_set_state(
 IN OUT   uint8_t* const    p_scope_state,
 IN  const uint8_t      state )
{
 CL_ASSERT( state <= 0x0F );
 /* State is LS 4-bits. */
 *p_scope_state &= 0x0F;
 *p_scope_state |= (state & 0x0F);
}





AL_INLINE void AL_API
ib_member_set_join_state(
 IN OUT   ib_member_rec_t    *p_mc_rec,
 IN  const uint8_t      state )
{
 p_mc_rec->scope_state &= 0xF0;
 p_mc_rec->scope_state |= (state & 0x0F);
}



AL_INLINE uint8_t AL_API
ib_member_set_scope_state(
 IN  const uint8_t      scope,
 IN  const uint8_t      state )
{
 /* Scope is MS 4-bits, state is LS 4-bits */
 return ((scope << 4) | (state & 0xF));
}





Ipoib is using ib_member_set_state().



As far as I can tell this will cause the scope to be zero (on table 3, the value of 0 is reserved). Is this what we relay wanted to have?



Thanks

Tzachi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20111004/cc08c7ef/attachment.html>