Hi Or, On Wed, 20 Jan 2010 17:26:17 +0200 Or Gerlitz <ogerl...@voltaire.com> wrote:
> 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. Right, I can indeed achieve that with only a patch to OpenSM. Going with a specific Lustre port space is simple and less intrusive although you have to patch the kernel and OpenSM. OK, then going with the TCP port space, what we need in OpenSM is a combination of service id (TCP) _and_ TCP port _and_ target GUID. Something like: tcp port <lustre TCP port> target-port-guid <Lustre servers GUIDs> That way, as you point out, there's absolutely no need for a specific Lustre specific port space and kernel patch. I just need to extend the QoS parser logic to add the semantic above. I will look into this. Thanks, and sorry for the hassle. Sebastien. > > 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
