Hi all,
Sorry for late reply as I was not in the office.
Please anybody just tell me about the idea of _distributed SA_ in
short. Is it a pre-planed activity which is yet to be implemented with
the OFED? or its just an extension of the sa cache pre-loading
discussion?
And again distributed SA is
Please anybody just tell me about the idea of _distributed SA_ in
short. Is it a pre-planed activity which is yet to be implemented with
the OFED? or its just an extension of the sa cache pre-loading
discussion?
I'm thinking of a distributed component that can perform a limited set
of SA
On Wed, 2007-06-06 at 00:06, Sean Hefty wrote:
One could ask the IBTA for this if it is the right thing to do.
Checking with the IBTA makes sense. Longer term, adding a distributed SA
application class, or expanding the existing SA class may be useful, if the
IBTA
wants to define SA
You'd need to use a vendor class 2 if you wanted to use RMPP as the SA
does. However, there is some rearranging you would need to do if you
compare the relevant MAD formats.
Reading into the spec more, it seems our current choice is limited to
using a vendor class. Application classes are
On Tue, 2007-06-05 at 15:39, Sean Hefty wrote:
You'd need to use a vendor class 2 if you wanted to use RMPP as the SA
does. However, there is some rearranging you would need to do if you
compare the relevant MAD formats.
Reading into the spec more, it seems our current choice is limited
On 5/31/07, Sean Hefty [EMAIL PROTECTED] wrote:
Ok, Soon I will post a patch related to this.
How static PR file will be generated? Needs to be discussed.
Please look at my latest changes to the local SA in when generating the patches.
git://git.openfabrics.org/~shefty/rdma-dev.git sa_cache
On Thu, 2007-05-31 at 06:36, Devesh Sharma wrote:
On 5/31/07, Sean Hefty [EMAIL PROTECTED] wrote:
Ok, Soon I will post a patch related to this.
How static PR file will be generated? Needs to be discussed.
Please look at my latest changes to the local SA in when generating the
patches.
Do you have some pointer/doc related to the design of current SA_CACHE
moduleIt will make things faster to understandif not then
I will require your support to understand the things, Though I have
some top level view.
I don't have any design docs. But I will happily answer any
On Thu, 2007-05-31 at 13:16, Sean Hefty wrote:
Do you have some pointer/doc related to the design of current SA_CACHE
moduleIt will make things faster to understandif not then
I will require your support to understand the things, Though I have
some top level view.
I don't
Would there be some sort of weak authorization needed to do this (like
some key of some sort) ?
I was thinking of matching the SA class MAD format, which includes the SM_Key
field. I wouldn't use the SA class, since we'd could be defining a new method,
and a different attribute / method map than
On Thu, 2007-05-31 at 13:31, Sean Hefty wrote:
Would there be some sort of weak authorization needed to do this (like
some key of some sort) ?
I was thinking of matching the SA class MAD format, which includes the SM_Key
field. I wouldn't use the SA class, since we'd could be defining a new
You'd need to use a vendor class 2 if you wanted to use RMPP as the SA
does. However, there is some rearranging you would need to do if you
compare the relevant MAD formats.
Vendor class 2 just adds the OUI, correct? I guess you could either
move the SA specific header by 4-bytes, or use a
On Thu, 2007-05-31 at 13:54, Sean Hefty wrote:
You'd need to use a vendor class 2 if you wanted to use RMPP as the SA
does. However, there is some rearranging you would need to do if you
compare the relevant MAD formats.
Vendor class 2 just adds the OUI, correct?
Yes, so there are 4 less
Yes, so there are 4 less bytes available.
..and we may want to shift everything down another 4 bytes for
alignment, if that's needed. It could be very convenient to have the
exact same layout as the SA MADs. This would let an app issue a normal
SA GetTable query, store away the response,
Ok, Soon I will post a patch related to this.
How static PR file will be generated? Needs to be discussed.
Please look at my latest changes to the local SA in when generating the patches.
git://git.openfabrics.org/~shefty/rdma-dev.git sa_cache
I'm not sure about the best way to communicate PRs
Ok, but, by that time we can keep the framework ready?
I plan on re-submitting the cache for 2.6.23. Beyond that I won't have the time
to work on enhancements for a few weeks. I will happily review any patch
submissions though.
How this will be managed? This will add extra startup time in the
On 24 May 2007 11:30:24 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Thu, 2007-05-24 at 08:22, Devesh Sharma wrote:
On 23 May 2007 10:35:13 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 10:27, Devesh Sharma wrote:
On 21 May 2007 13:52:11 -0400, Hal Rosenstock
On Thu, 2007-05-24 at 08:22, Devesh Sharma wrote:
On 23 May 2007 10:35:13 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 10:27, Devesh Sharma wrote:
On 21 May 2007 13:52:11 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Mon, 2007-05-21 at 01:58, Devesh Sharma
Yes It will, and hence reduce the initial SA traffic generated on a
big cluster...just imagin, the cluster is quite big and every node is
trying to build its cache initially. It will create large burst of SA
packets.
In general I agree with the notion of enhancing the cache to allow it to
load
On 21 May 2007 13:52:11 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Mon, 2007-05-21 at 01:58, Devesh Sharma wrote:
On 18 May 2007 06:21:05 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Thu, 2007-05-17 at 08:28, Devesh Sharma wrote:
On 17 May 2007 06:42:16 -0400, Hal Rosenstock
On Wed, 2007-05-23 at 10:27, Devesh Sharma wrote:
On 21 May 2007 13:52:11 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Mon, 2007-05-21 at 01:58, Devesh Sharma wrote:
On 18 May 2007 06:21:05 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Thu, 2007-05-17 at 08:28, Devesh Sharma
On 18 May 2007 06:21:05 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Thu, 2007-05-17 at 08:28, Devesh Sharma wrote:
On 17 May 2007 06:42:16 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Thu, 2007-05-17 at 01:21, Devesh Sharma wrote:
On 5/17/07, Sean Hefty [EMAIL PROTECTED] wrote:
On Thu, 2007-05-17 at 08:28, Devesh Sharma wrote:
On 17 May 2007 06:42:16 -0400, Hal Rosenstock [EMAIL PROTECTED] wrote:
On Thu, 2007-05-17 at 01:21, Devesh Sharma wrote:
On 5/17/07, Sean Hefty [EMAIL PROTECTED] wrote:
But initially this will generate a packet for each path, while sys
On Thu, 2007-05-17 at 01:21, Devesh Sharma wrote:
On 5/17/07, Sean Hefty [EMAIL PROTECTED] wrote:
But initially this will generate a packet for each path, while sys
admin knows that path is there and he can hard-code the entries for
it. Other thing is that why Admin will care about
But initially this will generate a packet for each path, while sys
admin knows that path is there and he can hard-code the entries for
it. Other thing is that why Admin will care about creating such record
while SA is itself taking care, right?
In your original message you asked about adding
On 5/17/07, Sean Hefty [EMAIL PROTECTED] wrote:
But initially this will generate a packet for each path, while sys
admin knows that path is there and he can hard-code the entries for
it. Other thing is that why Admin will care about creating such record
while SA is itself taking care, right?
26 matches
Mail list logo
