Hi Sasha,
I'm sending v2 of the patches:
- patch 1/6: move lft_buf from ucast_mgr to osm_switch
No change whatsoever, just rebased to the new master
- patch 2/6: Add "-A" or "--ucast_cache" option to opensm
No functional change, changed appearance of the help message
to match the recent OpenSM help changes.
- patch 3/6: adding osm_ucast_cache.{c,h} files.
+ All your patches integrated, many small fixes, including
all the fixes from the review.
+ Port array allocation reworked to save many reallocations
+ Better malloc() handling: checking for returning NULL,
no casting after malloc().
+ Back-2-back connections - cache is now disabled when there
are no switches, but it also takes care of the case when SM
port is disconnected and then connected with back-2-back link.
Besides adding check for zero switches in fabric, I found only
one back-2-back connection check that could be removed - in
function osm_ucast_cache_add_node().
- patch 4/6: adding new cache files to makefile.
No changes, just rebased.
- patch 5/6: integrating unicast cache into the discovery
and ucast manager.
This patch includes your changes (having ucast_cache_process
function that does all the job instead of integrating into
osm_ucast_mgr_process). Also, the cache is now a part of the
ucast manager struct, which simplifies a code and saves some
functions.
- patch 6/6: man entry for cached routing.
No changes, just rebased.
The job that still needs to be done:
- Check how the cache handles port moving during discovery.
Might be a bug there.
- Check how unicast manager handles fast reset of switches.
AFAIK SM will now write the LFT there - need to fix it
(unrelated to cache, general ucast mgr issue)
- Optimize LFT usage - simplify current switch LFT,
hold two LFTs (current and cached) only when these LFTs
are not identical.
-- Yevgeny
Yevgeny Kliteynik wrote:
Hi Sasha,
Sasha Khapyorsky wrote:
Hi Yevgeny,
On 03:29 Fri 10 Oct , Yevgeny Kliteynik wrote:
Thanks for the review and the patches. Didn't manage to address
all your comments yet - will do it tomorrow.
One question though: how to deal with the incremental patches that
you sent me? Should I apply them to my branch and then issue one
V2 patch instead of the old one, or will you apply the original
patch, followed by all the incremental (yours and mine)?
It is up to you. You can merge all in single V2 (guess it is simpler)
I'll send a v2 patches for 3/6 and 5/6 when I'm done fixing all the stuff.
-- Yevgeny
or leave it unchanged and I will apply later. Except integration patch
others are not critical IMHO.
Sasha
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
