Multicast group pre-creation for TopSpin old stack

Multicast group pre-creation for TopSpin old stack

[Yevgeny Kliteynik]

Sasha,

There's a hack in the SM to deal with TopSpin's non-compliant
join compmask for IPoIB v4 multicast group ff12:401b:<pkey>::1
The group is pre-defined and maintained as a well-known multicast
group.

opensm/osm_prtn.c:

   232          /* workaround for TS */
   233          /* FIXME: remove this upon TS fixes */
   234          mc_rec.mgid = osm_ts_ipoib_mgid;
   235          memcpy(&mc_rec.mgid.raw[4], &pkey, sizeof(pkey));
   236          /* Scope in MCMemberRecord (if present) needs to be consistent with MGID */
   237          mc_rec.scope_state = ib_member_set_scope_state(scope, IB_MC_REC_STATE_FULL_MEMBER);
   238          ib_mgid_set_scope(&mc_rec.mgid, scope);
   239
   240          status = osm_mcmr_rcv_find_or_create_new_mgrp(p_sa, comp_mask, &mc_rec,
   241                                                        &p_mgrp);
   242          if (p_mgrp) {
   243                  p_mgrp->well_known = TRUE;
   244                  if (!p->mgrp)
   245                          p->mgrp = p_mgrp;
   246          }

As far as I can tell, this was added before git history.
Any idea if it's still needed?

-- Yevgeny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multicast group pre-creation for TopSpin old stack

[Sasha Khapyorsky]

Hi Yevgeny,

On 12:07 Sun 05 Sep     , Yevgeny Kliteynik wrote:
> 
> There's a hack in the SM to deal with TopSpin's non-compliant
> join compmask for IPoIB v4 multicast group ff12:401b:<pkey>::1
> The group is pre-defined and maintained as a well-known multicast
> group.
> 
> opensm/osm_prtn.c:
> 
>    232          /* workaround for TS */
>    233          /* FIXME: remove this upon TS fixes */
>    234          mc_rec.mgid = osm_ts_ipoib_mgid;
>    235          memcpy(&mc_rec.mgid.raw[4], &pkey, sizeof(pkey));
>    236          /* Scope in MCMemberRecord (if present) needs to be consistent with MGID */
>    237          mc_rec.scope_state = ib_member_set_scope_state(scope, IB_MC_REC_STATE_FULL_MEMBER);
>    238          ib_mgid_set_scope(&mc_rec.mgid, scope);
>    239
>    240          status = osm_mcmr_rcv_find_or_create_new_mgrp(p_sa, comp_mask, &mc_rec,
>    241                                                        &p_mgrp);
>    242          if (p_mgrp) {
>    243                  p_mgrp->well_known = TRUE;
>    244                  if (!p->mgrp)
>    245                          p->mgrp = p_mgrp;
>    246          }
> 
> As far as I can tell, this was added before git history.
> Any idea if it's still needed?

I don't know, just remember that we have asked about this during
partition manager development (somewhere in 2006), and have got an
answer like "it is probably needed".

Personally I've never seen this used. Maybe Hal may remember more.

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multicast group pre-creation for TopSpin old stack

[Hal Rosenstock]

On Mon, Sep 6, 2010 at 12:43 PM, Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> Hi Yevgeny,
>
> On 12:07 Sun 05 Sep     , Yevgeny Kliteynik wrote:
>>
>> There's a hack in the SM to deal with TopSpin's non-compliant
>> join compmask for IPoIB v4 multicast group ff12:401b:<pkey>::1
>> The group is pre-defined and maintained as a well-known multicast
>> group.
>>
>> opensm/osm_prtn.c:
>>
>>    232          /* workaround for TS */
>>    233          /* FIXME: remove this upon TS fixes */
>>    234          mc_rec.mgid = osm_ts_ipoib_mgid;
>>    235          memcpy(&mc_rec.mgid.raw[4], &pkey, sizeof(pkey));
>>    236          /* Scope in MCMemberRecord (if present) needs to be consistent with MGID */
>>    237          mc_rec.scope_state = ib_member_set_scope_state(scope, IB_MC_REC_STATE_FULL_MEMBER);
>>    238          ib_mgid_set_scope(&mc_rec.mgid, scope);
>>    239
>>    240          status = osm_mcmr_rcv_find_or_create_new_mgrp(p_sa, comp_mask, &mc_rec,
>>    241                                                        &p_mgrp);
>>    242          if (p_mgrp) {
>>    243                  p_mgrp->well_known = TRUE;
>>    244                  if (!p->mgrp)
>>    245                          p->mgrp = p_mgrp;
>>    246          }
>>
>> As far as I can tell, this was added before git history.
>> Any idea if it's still needed?
>
> I don't know, just remember that we have asked about this during
> partition manager development (somewhere in 2006), and have got an
> answer like "it is probably needed".
>
> Personally I've never seen this used. Maybe Hal may remember more.

It's been carried forward just in case anyone was still running the
old TS stack. It's always hard to determine the negative (when no one
is using it any longer) (with the latest OpenSM) but it may be high
time to deprecate this. Is anyone still using the old TS stack ? If
so, is it used with OpenSM ?

Maybe Roland has insight into whether the old TS stack might be being
used with (the latest) OpenSM.

-- Hal

>
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multicast group pre-creation for TopSpin old stack

[Roland Dreier]

 > It's been carried forward just in case anyone was still running the
 > old TS stack. It's always hard to determine the negative (when no one
 > is using it any longer) (with the latest OpenSM) but it may be high
 > time to deprecate this. Is anyone still using the old TS stack ? If
 > so, is it used with OpenSM ?
 > 
 > Maybe Roland has insight into whether the old TS stack might be being
 > used with (the latest) OpenSM.

Seems a fairly remote possibility but on the other hand I guess I could
see someone buying old Topspin equipment on ebay and wanting to use it
with modern software.  In any case, if carrying this workaround forward
costs anything, I think it could be dropped.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multicast group pre-creation for TopSpin old stack

[Sasha Khapyorsky]

On 17:13 Mon 06 Sep     , Roland Dreier wrote:
>  > It's been carried forward just in case anyone was still running the
>  > old TS stack. It's always hard to determine the negative (when no one
>  > is using it any longer) (with the latest OpenSM) but it may be high
>  > time to deprecate this. Is anyone still using the old TS stack ? If
>  > so, is it used with OpenSM ?
>  > 
>  > Maybe Roland has insight into whether the old TS stack might be being
>  > used with (the latest) OpenSM.
> 
> Seems a fairly remote possibility but on the other hand I guess I could
> see someone buying old Topspin equipment on ebay and wanting to use it
> with modern software.

As far as I could understand this TS multicast group only impacts IPoIB
communication between two TS stack clients. If so then it is likely that
just using old Topspin switch will not activate this flow anyway. Right?

> In any case, if carrying this workaround forward
> costs anything, I think it could be dropped.

Ok, I think we can remove this then.

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multicast group pre-creation for TopSpin old stack

[Roland Dreier]

 > As far as I could understand this TS multicast group only impacts IPoIB
 > communication between two TS stack clients. If so then it is likely that
 > just using old Topspin switch will not activate this flow anyway. Right?

I think it would affect IPoIB-ethernet gateway at least.  And also
probably in-band management of switches.  But as I said I don't think it
matters too much.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html