On 5/14/07, Sean Hefty <[EMAIL PROTECTED]> wrote:
>This can be treated as a facility similar to what we have in ARP table
>for TCP/IP. Secondly this will help in debugging of some new up-coming
>partially infiniband complaint hardware.
But unless such a path actually exists to the remote node, I don't see that it's
useful. And if such a path exists, I would expect it to be returned by the SA.
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?
Can you clarify its use more wrt the subnet in general?
Again the same, in most cases Administrator knows that some path is
there between Node A and Node B, then why to introduce more delay in
making stack up by introducing extra packets (generated by
sa_cache_module). In later stages if something is changing, may be, it
will generated only few packets to update the cache.
Another point I want to know is,
When local_sa_cache module will be inserted? After SM comes up or
Before SM comes up?
I think its after SM is up, So this is introducing extra efforts for
Admin, He will have to wait for SM to come up and then insert sa_cache
module.
If Its inserted before SM is coming up (I am assuming SM is running on
some node not on switch) then First Forced schedule_update() is
waisted, and for the first application presence of cache is
meaningless. Why not to keep cache effective right from the start?
CMIIW
>yes, I want them to remain in the DB, my idea is similar to the hard
>coding of ARP table entries in TCP/IP.
>How do you see this can be achieved?
A simple flag or setting the update counter on the added path to the maximum
should be sufficient.
- 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
