Hi Or,
Or Gerlitz wrote:
Roland Dreier <rol...@kernel.org> wrote:
Jim Schutt <jasc...@sandia.gov> wrote:
no good reason to insist that the VL usage is the same for both
interswitch links, and switch-CA links. Do I need to change this?
I don't think changing this is a high priority, since it's a pretty small
slice of the world, and QoS on the edge links probably is important
to an even smaller slice, but IMHO it would be better to give QoS to
HCAs that only support 4 VLs by using a different SL2VL table for links to CAs.
Jim,
AFAIK, the way opensm applies an SL-to-VL mapping specification (e.g
dictated by the admin or maybe your routing engine) on a specific link
is by modulation on the number of active VLs for that link - e.g say
the ID mapping was required and there are two VLs for that link, so
we'll have SL-to-VL of 0->0 1->1 2->0 3->1 and so on. So in that
respect, I wasn't sure what's the change here for you.
Hmmm, can you tell me where such remapping happens?
What I know about so far is the code in sl2vl_update_table(),
which AFAICS truncates VL values in the SL2VL maps provided
by the routing engine to fit into the number of VLs supported
by a port.
Am I missing something else?
torus-2QoS will currently only use VL values 0 and 4 in the
SL2VL maps it generates for CA ports; i.e. any SL maps either
to VL 0 or VL 4, depending on QoS level.
So sl2vl_update_table() would truncate all those VL 4 values
to 0 in the case of ports that support fewer than 8 data VLs.
What I'm suggesting is that I need to make torus-2QoS generate
SL2VL maps that only reference VLs 0 or 1 for CA ports, in order
to allow it to support 2 QoS levels for CA ports that don't
support 8 data VLs.
-- Jim
Or.
--
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
