On Wed, 20 Jan 2010 10:03:47 +0200 Or Gerlitz <ogerl...@voltaire.com> wrote:
> sebastien dugue wrote: > >> So I guess you need to change the ports used within the new port space -- > >> but then > >> why can't you just stay in the TCP space but change the ports used? > >> > > > > No, with the new port space, there's no need to change ports. You only need > > to specify the target GUIDs. For example: > > lustre, target-portguid 0x1234,0x1235 : 1 # lustre traffic to MDSs > > lustre : 2 # default lustre traffic (to > > OSSs) > > Hope this helps clarify things a bit. > > > sorry, but it doesn't, as far as I understand there are three > possibilities for what the string "lustre" is being translated to > by the opensm QoS logic: > > (A) lustre port in the TCP port space > (B) lustre port space > (C) nothing (that is not a service, in the same manner that ipoib just > doesn't mean anything to opensm) I'm not sure I'm following you here. With the patches, the 'lustre' keyword is being translated to the lustre port space and only to that port space, never to the TCP port space. So if I'm understanding you correctly, it's B. > > Assuming C is not the case, then either A or B will yield the same > result and as such the new port space buys you nothing. 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?). What B buys you is the ability to map Lustre traffic to a specific target GUID onto an SL. An alternative would be to be able to map the TCP port space to a specific port and specific target GUIDs onto an SL in OpenSM's QoS configuration, but that's currently not possible. Sébastien. -- 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
