Mike,

On Fri, Feb 18, 2011 at 11:22 AM, Mike Heinz <michael.he...@qlogic.com> wrote:
> Hal,
>
> I'm in the process of smoke-testing changes to meet Roland's "quibbles" - I'm 
> going to change the code to pass the structure instead of a char*.
>
> Also, I just want to point out that even in the case where no enhanced trap 
> is used, any change will still be seen by the SM the next time it sweeps. 
> There will still be lag involved, but I don't think it's insurmountable.

That's not true for all SMs. It's true for a "heavy" but not a "light"
sweep. There's no requirement to rediscover NodeDescriptions all the
time periodically.

I should have my comments (on your now updated patches) by COB Tuesday
as Monday is a holiday.

-- Hal

> -----Original Message-----
> From: Hal Rosenstock [mailto:hal.rosenst...@gmail.com]
> Sent: Thursday, February 17, 2011 11:19 PM
> To: Roland Dreier
> Cc: Mike Heinz; linux-rdma@vger.kernel.org
> Subject: Re: [PATCH 0/2] Improved node descriptions
>
> On Thu, Feb 17, 2011 at 6:20 PM, Roland Dreier <rol...@kernel.org> wrote:
>> On Thu, Feb 17, 2011 at 1:30 PM, Michael Heinz <michael.he...@qlogic.com> 
>> wrote:
>>> This patch addresses the problem by providing a function to build the node
>>> description. If the provided source string for the description contains an
>>> '@' character, the function will substitute the current utsname.
>>>
>>> This ensures that even after a fabric has been completely initialized, if
>>> a node's hostname changes, that change will be reflected in the next sweep
>>> of the SM, but also maintains compatibility with existing code since the
>>> behavior is unchanged if the description string does not contain an '@'
>>> character.
>>
>> This looks like a reasonable approach to me, although of course the SM
>> has no way of knowing it should update a port's node description if a
>> hostname changes.
>
> It does; There's an enhanced trap for this now.
>
>> Aside from some minor quibbles
>>  - next time please use different subjects for each patch in the thread
>>  - the prototype of ib_build_node_desc() seems to force every call
>>   site to have a cast; maybe the function should take a pointer to
>>   struct ib_smp instead?
>>  - the internals of ib_build_node_desc() look a bit ugly, is there any
>>   way to make it a little cleaner?
>> I do like this.  Does anyone have any feelings about applying this
>> for 2.6.39?  Is this shipping in OFED?
>
> I need a little time to review this.
>
> -- Hal
>
>>  - R.
>> --
>> 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
>>
>
>
> This message and any attached documents contain information from QLogic 
> Corporation or its wholly-owned subsidiaries that may be confidential. If you 
> are not the intended recipient, you may not read, copy, distribute, or use 
> this information. If you have received this transmission in error, please 
> notify the sender immediately by reply e-mail and then delete this message.
>
--
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

Reply via email to