Re: [PATCH] ib/mad: remove Device Mgmt from RMPP class list

[Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>]

On 07/25/13 01:05, Weiny, Ira wrote:
>> -----Original Message-----
>> From: Hefty, Sean
>> Subject: RE: [PATCH] ib/mad: remove Device Mgmt from RMPP class list
>>
>>>>>> See Annex 8; DevMgt class version 2 rather than 1 is currently
>> supported.
>>>>>
>>>>> Could older devices still return version 1?  If so the kernel
>>>>> should allow DevMgt without RMPP, correct?
>>>>
>>>> This check has been this way since 2.6.17.  I think it's reasonable
>>>> to say
>>> that
>>>> there aren't any devices using version 1 that are running with Linux.
>>>
>>> FWIW the ib_srpt module uses a class version of 1:
>>>
>>> Ib_srpt.c:
>>>
>>> ...
>>> 		reg_req.mgmt_class_version = IB_MGMT_BASE_VERSION;
>> ...
>>
>> So, then this just happens to work because of some other check?  If that's so,
>> then I agree with Hal, in that we can add the class version to the check.
>
> I think this works because the MAD stack triggers off of rmpp_version (in the
> agent) and RMPP_ACTIVE (in the individual MAD's).  Since rmpp_version
 > == 0 in this registration and likely all the MAD sent have a 0'ed out
 > RMPP Header (ie the MAD stack thinks all MADs are RMPP _in_active) I
> think  the stack passes all the MAD's without invoking the RMPP
 > processing.

Changing the mgmt_class_version in ib_srpt.c from 1 into 2 would break 
existing SRP device management clients (srp_daemon and ibsrpdm) since 
these set mgmt_class_version to 1.

I'm not sure changing the rmpp_version argument in the 
ib_register_mad_agent() call in ib_srpt.c would be sufficient to enable 
RMPP for DM MAD's. Wouldn't the clients (srp_daemon and ibsrpdm) have to 
be updated as well to set the rmpp_version in the MAD header as well ?

Bart.
--
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