On 8/19/2013 6:46 AM, Line Holen wrote:
> On 08/16/13 15:47, Hal Rosenstock wrote:
>> On 8/14/2013 6:26 AM, Line Holen wrote:
>>> Signed-off-by: Line Holen<[email protected]>
>>>
>>> ---
>>>
>>> diff --git a/opensm/osm_port_info_rcv.c b/opensm/osm_port_info_rcv.c
>>> index 7dcd15e..961b376 100644
>>> --- a/opensm/osm_port_info_rcv.c
>>> +++ b/opensm/osm_port_info_rcv.c
>>> @@ -85,7 +85,7 @@ static void pi_rcv_process_endport(IN osm_sm_t *
>>> sm, IN osm_physp_t * p_physp,
>>> osm_madw_context_t context;
>>> ib_api_status_t status;
>>> ib_net64_t port_guid;
>>> - uint8_t rate, mtu;
>>> + uint8_t rate, mtu, mpb;
>>> unsigned data_vls;
>>> cl_qmap_t *p_sm_tbl;
>>> osm_remote_sm_t *p_sm;
>>> @@ -126,6 +126,14 @@ static void pi_rcv_process_endport(IN osm_sm_t *
>>> sm, IN osm_physp_t * p_physp,
>>> }
>>> }
>>>
>>> + /* Check M_Key vs M_Key protect, can we control the port ? */
>>> + mpb = ib_port_info_get_mpb(p_pi);
>>> + if (mpb > 0 && p_pi->m_key == 0) {
>>> + OSM_LOG(sm->p_log, OSM_LOG_INFO,
>>> + "Port 0x%" PRIx64 " has unknown M_Key, protection level
>>> %u\n",
>>> + cl_ntoh64(port_guid), mpb);
>>> + }
>>> +
>> It looks to me like the only case here is when protect bits is 1 for
>> gets; all others fail. Is it more than that ?
> You are probably right -
I was referring to that only for protect bits of 1 does this seem to
have potential value for gets as gets with protect bits of 1 with wrong
Mkey return port info with 0 MKey. All other mpb cases fail.
> have to admit I haven't tried a higher
> protection level.
What protection level(s) have you tried ?
>>
>> Also, would this spam the OpenSM log ?
> It would print one additional message per heavy sweep.
> But if you have a system with unknown MKeys configured you would get
> many error
> messages as it is. With protection level 2 every MAD operation will
> generate
> an error I guess (either 3111 or 3120). And with protection level 1 set
> operations
> will fail, but this new message will let you know why it failed.
I think it would be a 3120 error (timeout) rather than bad status. I
think that is what is meant in the IBA spec by fail (fail = no
response). Have you see 3111 or other than 3120 errors for this ?
-- Hal
> Line
>
>>
>> -- Hal
>>
>>> if (port_guid != sm->p_subn->sm_port_guid) {
>>> p_sm_tbl =&sm->p_subn->sm_guid_tbl;
>>> if (p_pi->capability_mask& IB_PORT_CAP_IS_SM) {
>>>
>
>
--
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