linux-kernel - Re: [ofa-general] Further 2.6.23 merge plans...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Jul 2007 20:23:38 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	"Or Gerlitz" <or.gerlitz@...il.com>
Cc:	"Sean Hefty" <mshefty@...ips.intel.com>,
	linux-kernel@...r.kernel.org, general@...ts.openfabrics.org
Subject: Re: [ofa-general] Further 2.6.23 merge plans...

 > > But to be fair, it will be difficult to enable both QoS and local PR
 > > caching.  To me, this would be the strongest reason against using it.
 > > However, QoS places additional burden on the SA, which will make scaling
 > > even more challenging.
 > 
 > my understanding is that the local sa does a path-query where all the fields
 > except for the SGID are wildcard-ed. This means we expect the result to be a
 > table of all the paths from this port to every other port on the fabrics for
 > every pkey which this port is a member of etc, correct?
 > 
 > How do you plug here  the QoS concept of SID in the path query? are you
 > expecting the SA to realize what are all the services for which this port is
 > a "member"? does the proposed definision for QoS management at the SA
 > defines "services per gids" isn't it "what SL to user per Service"?

Or, thanks for rescuing this post.

I think this is an important question.  If we merge the local SA
stuff, then are we creating a problem for dealing with QoS?  Are we
going to have to revert the local SA stuff once the QoS stuff is
available?  Or is there at least a sketch of a plan on how to handle
this?

 - R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/