Kanevsky, Arkady wrote:
I think providing QoS per vertical (that is ULP) is less prevelant
as providing QoS per horizontal, that is application, which uses
miltiple ULPs.
No problem, there's a way to define it per application too.
Administrator will just have to define qos-level, and set of
match-rules for this application that point to the defined
qos-level.
The cons here is that administrator will have to really
understand what ULPs and which ports this application is using,
but I can't think of any way to simplify this task.
Perhaps in the future we will have examples for common applications.
-- Yevgeny
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
Waltham, MA 02451 central phone: 781-768-5300
-----Original Message-----
From: Yevgeny Kliteynik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 18, 2007 8:19 AM
To: Sean Hefty
Cc: [EMAIL PROTECTED]; 'Hal Rosenstock';
[email protected]
Subject: Re: [ofa-general] RE: QoS for iSER
Sean Hefty wrote:
And as you've mentioned, some rules may overlap. For instance, if
the rule for all the RDS traffic will appear before the
iSER rule,
then iSER requests will be caught by the RDS rule.
That doesn't sound so good but I don't see a good alternative here
other than for this case to put the iSER rule first. The other
fallback is the more detailed configuration but RDS falls into the
generic range category which is problematic in terms of this (and
can't be differentiated by ServiceID unlike the other ULPs).
I'm not overly familiar with the details of RDS, but event if the
active side uses a dynamic service ID, I would expect the
passive side
to use something well known.
Couldn't agree more.
That's why I think that although there are cases where this
simplified way of defining SLs per ULP plus target TCP port
won't be useful, in many cases it would actually make the
administrator's life easier.
-- Yevgeny
- Sean
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
