On Thu, 21 Jan 2010 11:12:08 +0200
Or Gerlitz 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 qos parser whic
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
Hi Or,
On Wed, 20 Jan 2010 17:26:17 +0200
Or Gerlitz 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 (o
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 patch
On Wed, 20 Jan 2010 10:03:47 +0200
Or Gerlitz 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, ther
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 exampl
Hi Roland,
On Tue, 19 Jan 2010 17:12:43 -0800
Roland Dreier 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 bit confu
> 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 bit confused. The problem as I understand it is that Lustre
always uses the same TCP port, s
On Thu, 14 Jan 2010 09:25:31 -0800
Roland Dreier wrote:
>
> > > 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 p
> > 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 di
Hi Or,
On Thu, 14 Jan 2010 16:09:43 +0200
Or Gerlitz wrote:
> 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
> th
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
Hi Roland.
On Wed, 13 Jan 2010 09:04:19 -0800
Roland Dreier 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 for each
Hi Sean,
On Wed, 13 Jan 2010 08:56:30 -0800
"Sean Hefty" 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 port spa
> 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
> 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
s
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.
Signed-off-by: Sebastien Dugue
---
drivers/infiniband/core/cma.c |5 +
include/rdma/rdma_cm.h| 11 ++-
2 files cha
17 matches
Mail list logo
