Sean Hefty wrote:
From what I understand while reading your proposal, is that it is
quite different then what what suggested in the original RFC. I don't
think it makes sense to implement the host side of this before there's
agreement on the over-all solution namely how the host side
Sean Hefty wrote:
I wonder how you think the suggested scheme for IPoIB plugs into the
existing QoS flow at the Linux network stack. Looking on the man pages
of tcp(7) and ip(7) I see that there's a SOL_SOCKET level option of
SO_PRIORITY and SOL_IP level option of IP_TOS.
I was looking at IB
Sean Hefty wrote:
Giving this a little more thought, IPoIB uses a single path to each IP
destination. You're asking about per socket ToS, which requires the
ability to handle multiple paths to each remote IP address. Both the
original RFC and my proposal for the host stack limit all IPoIB
Hi Yevgeny,
On 8/2/07, Yevgeny Kliteynik [EMAIL PROTECTED] wrote:
Hi Hal,
Hal Rosenstock wrote:
Hi Yevgeny,
On 7/21/07, Yevgeny Kliteynik [EMAIL PROTECTED] wrote:
Hi All
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
I wonder how you think the suggested scheme for IPoIB plugs into the
existing QoS flow at the Linux network stack. Looking on the man pages
of tcp(7) and ip(7) I see that there's a SOL_SOCKET level option of
SO_PRIORITY and SOL_IP level option of IP_TOS.
I was looking at IB routing, not IP
Application Service - Service ID (or range)
Service ID - desired QoS
QoS, SGID, DGID, PKey - SGID, DGID, TClass, FlowLabel, PKey
SGID, DGID, TC, FL, PKey - SLID, DLID, SL (set if crossing subnets)
SLID, DLID, SL - MTU, Rate, VL, PacketLifeTime
What's the reasoning to use TClass and Flowlabel
From what I understand while reading your proposal, is that it is quite
different then what what suggested in the original RFC. I don't think it
makes sense to implement the host side of this before there's agreement
on the over-all solution namely how the host side design/code plugs to
the
I wonder how you think the suggested scheme for IPoIB plugs into the
existing QoS flow at the Linux network stack. Looking on the man pages
of tcp(7) and ip(7) I see that there's a SOL_SOCKET level option of
SO_PRIORITY and SOL_IP level option of IP_TOS.
Giving this a little more thought,
Sean Hefty wrote:
2. Architecture
This is a higher level approach to the problem, but I came up with the
following QoS relationship hierarchy, where '-' means 'maps to'.
Application Service - Service ID (or range)
Service ID - desired QoS
QoS, SGID, DGID, PKey - SGID, DGID,
Sean Hefty wrote:
FYI - It is my intention to implement the host side portion of QoS
support. (It's one of my path forward objectives.) I plan on
implementing the host side as outlined below. If anyone has any
comments, I would like to get them as soon as possible.
Sean,
From what I
Sean Hefty wrote:
4. IPoIB -
IPoIB already query the SA for its broadcast group information. The
additional functionality required is for IPoIB to provide the
broadcast group SL, MTU, and RATE in every following PathRecord query
performed when a new UDAV is needed by IPoIB. We could
On 01:29 Fri 03 Aug , Yevgeny Kliteynik wrote:
OK, we can use names of QoS levels instead of sequential numbers.
Here are the details:
+ in qos-level new mandatory keyword 'name' will be added: name:
single_string
It could be even simpler:
qos-level name
...
+ in
Hi Hal,
Hal Rosenstock wrote:
Hi Yevgeny,
On 7/21/07, Yevgeny Kliteynik [EMAIL PROTECTED] wrote:
Hi All
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
Your comments are welcome.
A couple of quick questions:
How does this
Sasha Khapyorsky wrote:
Hi Yevgeny,
On 15:39 Thu 26 Jul , Yevgeny Kliteynik wrote:
* Comments may appear only in a separate line
Why? What is wrong with:
port-name: vs1/HCA-1/P1 # my best port
I can use this too, but then the pound sign, wherever it will
appear, would mean
Hi Yevgeny,
On 15:39 Thu 26 Jul , Yevgeny Kliteynik wrote:
* Comments may appear only in a separate line
Why? What is wrong with:
port-name: vs1/HCA-1/P1 # my best port
I can use this too, but then the pound sign, wherever it will
appear, would mean commentary start. No
FYI - It is my intention to implement the host side portion of QoS
support. (It's one of my path forward objectives.) I plan on
implementing the host side as outlined below. If anyone has any
comments, I would like to get them as soon as possible.
- Sean
Sean Hefty wrote:
2. Architecture
I think that defining a new file format is really going in the wrong
direction. XML would make a lot of sense (and you could use something
like RELAX NG to define the schema very readably and precisely). XML
has the advantage that many parsers, GUI editors, and other tools are
already widely
On 10:41 Tue 31 Jul , Roland Dreier wrote:
I think that defining a new file format is really going in the wrong
direction. XML would make a lot of sense (and you could use something
like RELAX NG to define the schema very readably and precisely). XML
has the advantage that many parsers,
Hi Yevgeny,
On 7/21/07, Yevgeny Kliteynik [EMAIL PROTECTED] wrote:
Hi All
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
Your comments are welcome.
A couple of quick questions:
How does this differ from the original RFC posted
HI Yevgeny
Yevgeny Kliteynik a écrit :
Hi All
Please find the attached RFC describing how QoS policy support could
be implemented in the OpenFabrics stack.
Your comments are welcome.
-- Yevgeny
RFC: OpenFabrics Enhancements for QoS Support
I think the RDMA CM needs two solutions, depending on which address
family is used. For IPv6, the existing interface is sufficient, and
works for both IB and iWarp. The RDMA CM only needs to include the TC
and FL as part of its PR query. For IPv4, to remain transport neutral,
I think we
On 7/27/07, Sean Hefty [EMAIL PROTECTED] wrote:
I think the RDMA CM needs two solutions, depending on which address
family is used. For IPv6, the existing interface is sufficient, and
works for both IB and iWarp. The RDMA CM only needs to include the TC
and FL as part of its PR query.
SDP uses CMA for building its connections.
The Service-ID for SDP is 0x0001, where are 4 hex digits
holding the remote TCP/IP Port Number to connect to.
SDP might be provided with SO_PRIORITY socket option. In that case the
value
provided should be sent to the CMA as the TClass
You can make PR requests with MGID as DGID though.
I thought about that, but the QoS field isn't defined for PR responses,
only requests (Get, GetTable).
- Sean
___
general mailing list
general@lists.openfabrics.org
I overlooked multicast in my reply. Unfortunately, the QoS field was
not added to MCMemberRecord.
Good point.
You can make PR requests with MGID as DGID though.
My bad here. We need to specify the SL, FL, and TC when creating the
multicast group, so the required QoS - TC, FL mapping needs
Sean Hefty wrote:
This file has *all* the possible keywords.
The administrator really doesn't have to use them all.
For instance, there are three different ways to define port groups:
- by guid list
- by node type
- by port names
You could stick with the guids only - this gives you all the
But again, the administrator doesn't *have* to use all these.
He can simply define sl2vl-tables, and then match service-id
(in qos-match-rules) to a certain sl (in qos-levels).
That's it.
No MTU, rate, packet lifetime or any other low level data.
Does the following file look better?
My take is
Hi Sasha,
Sasha Khapyorsky wrote:
Hi Yevgeny,
Some initial comments.
On 01:07 Sun 22 Jul , Yevgeny Kliteynik wrote:
Hi All
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
Your comments are welcome.
-- Yevgeny
On Thu, Jul 26, 2007 at 03:06:50AM +0300, Yevgeny Kliteynik wrote:
This file has *all* the possible keywords.
The administrator really doesn't have to use them all.
For instance, there are three different ways to define port groups:
- by guid list
- by node type
- by port names
You
This file has *all* the possible keywords.
The administrator really doesn't have to use them all.
For instance, there are three different ways to define port groups:
- by guid list
- by node type
- by port names
You could stick with the guids only - this gives you all the functionality
you
2.5. ULPs that use CM interface (like SRP) should have their own
pre-assigned Service-ID and use it while obtaining PR/MPR for
establishing connections. The SA receiving the PR/MPR should match it
against the policy and return the appropriate PR/MPR including SL,
MTU and RATE.
We need to
Yevgeny Kliteynik wrote:
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
Your comments are welcome.
Hi Yevgeny,
Some quick comments from first re-read
1) IPoIB - just to make sure I am on the right page:
the intention is that
Hi Yevgeny,
Some initial comments.
On 01:07 Sun 22 Jul , Yevgeny Kliteynik wrote:
Hi All
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
Your comments are welcome.
-- Yevgeny
RFC: OpenFabrics
Hi All
Please find the attached RFC describing how QoS policy support could be
implemented in the OpenFabrics stack.
Your comments are welcome.
-- Yevgeny
RFC: OpenFabrics Enhancements for QoS Support
===
Authors: . Eitan
34 matches
Mail list logo
