Hi Sasha,
On 26/Nov/09 16:15, Sasha Khapyorsky wrote:
On 13:01 Wed 04 Nov , Yevgeny Kliteynik wrote:
Optimizing SA DB dump - added "dirty" flag to denote
that the SA DB was modified, so that the DB will be
dumped only when the flag is on.
[v2 - no changes, just rebased and resolved conflicts]
[snip]
+
+ subn->p_osm->sa.dirty = TRUE;
}
In general I don't like an idea of spreading this global "dirty" flag
over various OpenSM areas (it makes the code dirty). But even if it is
needed couldn't we minimize number of such occurrences?
See below
For example those specific ones in osm_multicast.c are duplicated in
osm_sa_mcmember_record.c
This is fixed in the new patch
(and also will cause 'dirty' flag setup on the
SA DB from file loading).
Fixed - the flag is cleared at the end of loading SA DB
Could we consolidate all multicast related
cases with re-routing requesting for example?
SA DB contains 3 types of data:
- informinfo records
- service records
- mcmember records
So the "dirty" flag (or "modified", if you wish) must be set
in 6 places:
- add/remove informinfo record
- add/remove service records
- add/remove mcmember records
Another possible place for setting this flag is mcgroup
create/delete (this is what's sometimes duplicated by the
add/remove mcmember records), but I think that this is not
needed:
The mcgroups w/o mcmembers can be created in two ways:
1. By creating well-known mcgroup for a partition.
In this case when new instance of OSM is launched,
the same mcgroup should be creted anyway from the
partition configuration, so no need to force its
duplication in the SA DB file.
2. By loading mcgroup from SA DB file.
In this case it's either mcgroup w/o members, which
is what's handled by (1), or it's mcgroup with members,
butthe members just weren't loaded yet.
So in both cases, no need to force SA DB dump.
I'll post a new patch shortly - please review and let me
know if you have better ideas.
-- Yevgeny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
