[ofw] RE: SM timeout

[Hal Rosenstock]

Hi Fab,

On Thu, Oct 2, 2008 at 3:21 PM, Fab Tillier
<ftillier at windows.microsoft.com> wrote:
> Hi Hal,
>
>> On Thu, Oct 2, 2008 at 2:19 PM, Fab Tillier
>> <ftillier at windows.microsoft.com> wrote:
>>> Hi Slava,
>>>
>>>> When IB switch is heavy loaded, host will not receive reply from SM. It
>>>> results with IB_TIMEOUT and IPoIB adapter is shown as disconnected.
>>>> Suggested solution for IB_TIMEOUT problem.
>>>  Why not eliminate the port info query?  The following fields of the
>>> port info records are used:
>>>
>>> - base_lid
>>> - link_width_active
>>> - link_speed_active
>>>
>>> Why not get these from the port attributes and eliminate the query
>>> altogether?  The ib_port_attr_t structure has:
>>>
>>> - lid (base_lid)
>>> - active_speed (link_speed_active)
>>
>> Is this assuming a homogeneous subnet in terms of rate ?
>
> No, in this case only the local information is needed, in order to report the link speed to the OS properly, and to create an endpoint for loopback traffic.
>
>>> If you look at what vstat does, it issues a local MAD to the HCA for the
>>> port info record to get the information missing from the port attributes.
>>> Fixing the port attributes would simplify everybody's life.
>>
>> Do you mean PortInfo attribute (SM class) rather than PortInfoRecord
>> (SA class/query) ?
>
> Yes, PortInfo attribute, which is embedded in the PortInfoRecord.
>
>> If this comes from the SMA, what happens when MKey protection is enabled ?
>
> Dunno, just saying this is what vstat does.
>
> Ideally the port info attribute would be embedded in the CA attributes, so that the information would be available (read only) to local clients.  That or the SMA should distinguish between local requests and requests that come from the wire.  Point being that the mkey stuff shouldn't come into play for local clients.

If it's done with a local MAD, I don't think there is an exception for
the local case (either in the spec or in the implementation although
I'm only conjecturing about the latter rather than determining this
empirically). Guess we'll worry about this when MKey protection comes
down the pike (and I've been hearing rumblings about this again).

-- Hal

> -Fab
>