[ofa-general] [RFC] [PATCH 0/5 v2] rdma/cm: add ability to specify type of service

Hal Rosenstock hal.rosenstock at gmail.com
Wed Sep 5 16:01:54 PDT 2007


On 9/5/07, Sean Hefty <sean.hefty at intel.com> wrote:
> >On the end stack side, has it been decided to ignore whether the SA
> >indicates whether or not it supports QoS ? Wouldn't it be useful to
> >have some warning message indicating this in the end node (that it
> >might not be getting the service quality desired) ?
>
> This is just my opinion, but...
>
> This ends up adding a fair amount of complexity in order to display a simple
> warning message.  The code is written to try for QoS, but use whatever is
> available if QoS support is not enabled.  If we wanted to display a warning,
> then I think that the user should have control over whether QoS support is
> enabled on the host side, along with policy controls over what action to take in
> case of a failure.  This support would need to be per ULP, and defined for each
> node on the fabric.  Displaying a warning without the user explicitly asking for
> QoS support can give the impression that something is wrong when things are
> operating correctly.
>
> The other complexity is that additional queuing becomes necessary for QoS
> enabled PR queries.  It's possible for ULPs to request paths before the local SA
> query code can determine whether or not the SA supports QoS.

It's not a requirement to wait for the QoS determination of the SA
before issuing the SA PR requests.

> I don't feel that
> a warning message is necessarily worth the extra complexity, especially when
> things like SA failover and IB routers get tossed into the mix.

Failover is pretty straightforward. The same query is made when SM LID changes.

As to IB routers, well, it seems a little early to envision how these
two interact.

A separate question:
Will the QoS code handle the new error status code which suggests a
different QoSClass or is it currently being handled like other errors
? Guess that could be a separate patch.

-- Hal

> - Sean
>



More information about the general mailing list