The patch this email replies to changes the format of the torus-2QoS.conf file. The attached file works with the new format, and replaces the example file sent in reply to the original torus-2QoS patch series.
-- Jim
# We want the torus routing engine to attempt to find a # 5x5x5 torus in the fabric: torus 5 5 5 # We need to tell the routing engine what directions we # want the torus coordinate directions to be, by specifing # the endpoints (switch GUID only) of a link in each # direction. Here we specify positive coordinate directions: xp_link 0x200000 0x200019 # S_0_0_0 -> S_1_0_0 yp_link 0x200000 0x200005 # S_0_0_0 -> S_0_1_0 zp_link 0x200000 0x200001 # S_0_0_0 -> S_0_0_1 # If one of the above switches were to fail, the routing # engine would not have sufficient information to locate the # torus in the fabric. Specify a backup origin here: next_origin xp_link 0x20001f 0x200038 # S_1_1_1 -> S_2_1_1 yp_link 0x20001f 0x200024 # S_1_1_1 -> S_1_2_1 zp_link 0x20001f 0x200020 # S_1_1_1 -> S_1_1_2 # The torus routing engine uses the concept of a dateline, # where a coordinate wraps from its maximum back to zero, # in order to compute path SL values that provide routing # that is free from credit loops. # # If it is forced by a failed switch to use the backup # origin specification, that would cause the datelines # to move, which would change many path SL values, which # defeats one of the main benefits of this routing engine. # So, describe the position of the original datelines # relative to the backup origin as follows: x_dateline -1 y_dateline -1 z_dateline -1 # You can specify as many backup origins as you like, but # in practice, the torus routing engine is only guaranteed # to be able to route around a single failed switch without # introducing credit loops, so one backup origin is enough.
