sebastien dugue wrote: > No, because in OpenSM's QoS logic, there's no way to map the TCP port > space with specific target GUIDs onto an SL. You have keywords for SDP, SRP, > RDS, ISER, ... but not for the TCP port space (or am I missing something?).
going with this, what prevents you from patching opensm qos engine to support the lustre service under the tcp port-space and/or support a combination of service and target port-guid? all in all, first, I don't see what a kernel patch buys you and second, if it buys you something you should be able to gain the same effect with patching open-sm. thinking on this a bit more, since the rules are processed by order wouldn't the following scheme let you achieve the same effect? target-portguid 0x1234,0x1235 : 1 # traffic to MDSs lustre : 2 # default lustre traffic (to OSSs) 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
