sebastien dugue wrote:
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.
I believe that you can have a 'lustre' keyword in opensm qos parser which
stands for the combination of tcp port space + lustre tcp port
On Thu, 21 Jan 2010 11:12:08 +0200
Or Gerlitz ogerl...@voltaire.com wrote:
sebastien dugue wrote:
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.
I believe that you can have a 'lustre' keyword in opensm
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
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,
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
Hi Roland,
On Tue, 19 Jan 2010 17:12:43 -0800
Roland Dreier rdre...@cisco.com wrote:
Well, without a specific port space, the default for Lustre is to use the
TCP port space so you cannot distinguish Lustre traffic from other traffic
using
that same port space.
I'm still a
Hi Sean,
On Wed, 13 Jan 2010 08:56:30 -0800
Sean Hefty sean.he...@intel.com wrote:
This patch adds a new port space for use by Lustre traffic.
This, along with patches to OpenSM and Lustre, allow to define a
specific QoS for lustre.
In general, I don't like the idea of application
Hi Roland.
On Wed, 13 Jan 2010 09:04:19 -0800
Roland Dreier rdre...@cisco.com wrote:
In general, I don't like the idea of application port spaces for QoS
support. Can't this be done using port numbers in the existing port
space?
I agree. If setting QoS requires a kernel patch
sebastien dugue wrote:
That can be done with port numbers, except that we cannot separate
traffic to Lustre MDS and traffic to Lustre OSS
Looking on these patches and going with you for a minute, I don't see how this
patch set serves you to assign a different QoS level (e.g SL) to MDS vs OSS
I agree. If setting QoS requires a kernel patch for each application, I
think we've messed up QoS somehow. There needs to be a way to control
QoS via configuration, rather than rebuilding.
Right, it's possible via configuration only, but you then cannot separate
the different
This patch adds a new port space for use by Lustre traffic.
This, along with patches to OpenSM and Lustre, allow to define a
specific QoS for lustre.
In general, I don't like the idea of application port spaces for QoS
support. Can't this be done using port numbers in the existing port
In general, I don't like the idea of application port spaces for QoS
support. Can't this be done using port numbers in the existing port
space?
I agree. If setting QoS requires a kernel patch for each application, I
think we've messed up QoS somehow. There needs to be a way to control
12 matches
Mail list logo
