OpenSM: reporting traps 129, 130, 131

Hi Sasha,

I noticed that OpenSM doesn't send InformInfo on traps 129/130/131. This is what osm_trap_rcv.c is doing:

322: static void trap_rcv_process_request(IN osm_sm_t * sm, 323:                                 IN const osm_madw_t * p_madw)
...
435:            if (ib_notice_is_generic(p_ntci) &&

436:                (p_ntci->g_or_v.generic.trap_num == CL_HTON16(129) ||
437:                 p_ntci->g_or_v.generic.trap_num == CL_HTON16(130) ||

438:                 p_ntci->g_or_v.generic.trap_num == CL_HTON16(131))) { 439:                    /* If this is a trap 129, 130, or 131 - then this is a
440:                     * trap signaling a change on a physical port. 441:                     * Mark the physp_change_trap flag as TRUE. 442:                     */
443:                    physp_change_trap = TRUE;
...

539:    /* If we reached here due to trap 129/130/131 - do not need to do 540:       the notice report. Just goto exit. We know this is the case 541:       if physp_change_trap is TRUE. */
542:    if (physp_change_trap == TRUE)
543:            goto Exit;

Any particular reason why there's no reporting of these traps?

-- Yevgeny

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 2 lines

Any particular reason why there's no reporting of these traps?

AFAIK it's been this way for at least the last 5 or 6 years.

A practical consideration in changing this is that these traps are the ones for which babbling port was implemented since they do not obey the trap rate so there's a large downside to adding the reports for these. If that is to be done, then perhaps this should be done based on some option.

Quoted 4 lines · Hal Rosenstock

Quoted 2 lines

Any particular reason why there's no reporting of these traps?

AFAIK it's been this way for at least the last 5 or 6 years.

Yes, this is what I found too tracking down git/svn history.

Quoted 5 lines

A practical consideration in changing this is that these traps are the ones for which babbling port was implemented since they do not obey the trap rate so there's a large downside to adding the reports for these. If that is to be done, then perhaps this should be done based on some option.

I don't think that we need new option for this, instead we should care that OpenSM is not overloaded by such trap floods.

Sasha

Quoted 14 lines · Sasha Khapyorsky

Quoted 4 lines · Hal Rosenstock

Quoted 2 lines

Any particular reason why there's no reporting of these traps?

AFAIK it's been this way for at least the last 5 or 6 years.

Yes, this is what I found too tracking down git/svn history.

Quoted 5 lines

A practical consideration in changing this is that these traps are the ones for which babbling port was implemented since they do not obey the trap rate so there's a large downside to adding the reports for these. If that is to be done, then perhaps this should be done based on some option.

Quoted 2 lines

I don't think that we need new option for this, instead we should care that OpenSM is not overloaded by such trap floods.

We've cared for several years now (babbling port policy was introduced into the master on 7/6/09)

but this issue still persists. Are you
saying no reports for these traps until the trap rate is obeyed ?

-- Hal

Quoted 3 lines

Sasha

We've cared for several years now (babbling port policy was introduced into the master on 7/6/09) but this issue still persists. Are you saying no reports for these traps until the trap rate is obeyed ?

Quoted 4 lines · Hal Rosenstock

We've cared for several years now (babbling port policy was introduced into the master on 7/6/07) but this issue still persists. Are you saying no reports for these traps until the trap rate is obeyed ?

If existing trap rate filtering in OpenSM is sufficient we can add reporting (if somebody needs this).

I just don't think that we need to introduce temporary options.

Sasha