On 3/15/2012 2:23 PM, Jim Foraker wrote:
>
> On Tue, 2012-03-13 at 05:29 -0700, Hal Rosenstock wrote:
>> On 3/9/2012 2:27 PM, Jim Foraker wrote:
>>>
>>> On Fri, 2012-03-09 at 05:00 -0800, Hal Rosenstock wrote:
>>>> On 3/6/2012 5:18 PM, Jim Foraker wrote:
>>>>>
>>>>> Support for "m_key=" parameter,
>>>>
>>>> Shouldn't mkey be on a per port basis rather than a single mkey for all
>>>> ports ?
>>> In the long run, I agree. However, adding this support brings the
>>> diags up to speed with the "one mkey per subnet" model that OpenSM
>>> currently (sort of) supports.
>>
>> OpenSM mkey support is not complete for even that model. IMO the diags
>> should not just be in sync with the current OpenSM (a minimum bar for
>> this support) but support the general requirement. In the end, I suspect
>> there will be several mkey policies supported by OpenSM.
> I've got some tentative OpenSM patches which I'll hopefully be
> ready to post once we've hashed out the tools side.
Does the OpenSM side need to wait for that ?
-- Hal
> At the moment,
> they're centered around the "one mkey to rule them all" model too, but
> should make it easier to support other model(s).
>
>>
>>> We should do better down the road, but I
>>> don't think this patch gets in the way of that.
>>
>> I wouldn't think the approach for a per port MKey would use a single
>> MKey parameter and store it in the source port structure.
> I was referring specifically to this patch, and in particular the
> visible change, adding a "m_key" option to the config file.
> Dumping the mkey in the source port structure is absolutely a hack.
> The problem is that no real context is kept on the destination port in
> the current API, which near as I can tell means supporting mkeys
> (particularly multiple mkeys) cleanly requires either bumping the API
> version, or falling back on the deprecated saving of global state in the
> library. This would need to be cleaned up, but we could bunch that
> change with others as part of a future API rev.
>
>>
>> -- Hal
>>
>>>>> plus config file now installs user-read-only.
>>>>
>>>> This part is best as a separate patch.
>>> I agree. I was worried that applying the config change without the
>>> permissions change may open a potential vulnerability, but the answer
>>> there is just to have the permissions change earlier in the tree than
>>> the new parameter.
>>>
>>> Jim
>>>>
>>>> -- Hal
>>>>
>>>>> Signed-off-by: Jim Foraker <forak...@llnl.gov>
>>>>> ---
>>>>> Makefile.am | 2 +-
>>>>> etc/ibdiag.conf | 2 ++
>>>>> src/ibdiag_common.c | 2 ++
>>>>> 3 files changed, 5 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/Makefile.am b/Makefile.am
>>>>> index 950f95b..ef59bd2 100644
>>>>> --- a/Makefile.am
>>>>> +++ b/Makefile.am
>>>>> @@ -112,4 +112,4 @@ install-data-hook:
>>>>> fi
>>>>> $(top_srcdir)/config/install-sh -c -m 444
>>>>> $(top_srcdir)/scripts/IBswcountlimits.pm
>>>>> $(DESTDIR)/$(PERL_INSTALLDIR)/IBswcountlimits.pm
>>>>> $(top_srcdir)/config/install-sh -c -m 444
>>>>> $(top_srcdir)/etc/error_thresholds
>>>>> $(DESTDIR)/$(sysconfdir)/infiniband-diags
>>>>> - $(top_srcdir)/config/install-sh -c -m 444 $(top_srcdir)/etc/ibdiag.conf
>>>>> $(DESTDIR)/$(sysconfdir)/infiniband-diags
>>>>> + $(top_srcdir)/config/install-sh -c -m 400 $(top_srcdir)/etc/ibdiag.conf
>>>>> $(DESTDIR)/$(sysconfdir)/infiniband-diags
>>>>> diff --git a/etc/ibdiag.conf b/etc/ibdiag.conf
>>>>> index 77f3ce9..2a2334f 100644
>>>>> --- a/etc/ibdiag.conf
>>>>> +++ b/etc/ibdiag.conf
>>>>> @@ -15,3 +15,5 @@
>>>>> # Default = true
>>>>> #MLX_EPI=false
>>>>>
>>>>> +# define a default m_key
>>>>> +#m_key=0x00
>>>>> diff --git a/src/ibdiag_common.c b/src/ibdiag_common.c
>>>>> index 0901231..2089847 100644
>>>>> --- a/src/ibdiag_common.c
>>>>> +++ b/src/ibdiag_common.c
>>>>> @@ -155,6 +155,8 @@ void read_ibdiag_config(const char *file)
>>>>> } else {
>>>>> ibd_ibnetdisc_flags &= ~IBND_CONFIG_MLX_EPI;
>>>>> }
>>>>> + } else if (strncmp(name, "m_key", strlen("m_key")) == 0) {
>>>>> + ibd_mkey = strtoull(val_str, 0, 0);
>>>>> }
>>>>> }
>>>>>
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
