public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>
To: Yevgeny Kliteynik
	<kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Cc: Linux RDMA <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/3 v2] opensm SA DB dump/restore: added option to load SA DB once
Date: Sun, 13 Dec 2009 18:23:05 +0200	[thread overview]
Message-ID: <20091213162305.GO5262@me> (raw)
In-Reply-To: <4B1B883D.3080508-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>

On 12:32 Sun 06 Dec     , Yevgeny Kliteynik wrote:
> >> @@ -1096,7 +1106,15 @@ int osm_sa_db_file_load(osm_opensm_t * p_osm)
> >>  		}
> >>  	}
> >>
> >> -	if (!rereg_clients)
> >> +	/*
> >> +	 * If restoring SA DB is required only once, SM should go
> >> +	 * into the usual mode right after that, which means that
> >> +	 * client re-registration should be required even after
> >> +	 * the restore - there is a chance that OSM died right after
> >> +	 * some MCMember joined MCast group, and his membership
> >> +	 * didn't make it into the SA DB file.
> >> +	 */
> >> +	if (!p_osm->subn.opt.sa_db_load_once && !rereg_clients)
> >>  		p_osm->subn.opt.no_clients_rereg = TRUE;
> > 
> > Hmm, if you are going to request clients reregistration unconditionally
> > then what is the reason to restore SA DB?
> > 
> > Maybe you wanted to switch this flag off *after* first sweep, but I'm
> > not sure following your comment.
> 
> We have a dump file with mcast members, and OSM is loading
> this file. Suppose OSM has successfully loaded the whole file.
> But this does not mean that there's no need to request client
> re-registration on all the hosts. Consider the following case:
>  - Heavy sweep - SM dumps current SA DB to a file
>  - Client asks to join some mcast group
>  - SM gets the request and processes it
>  - The request is OK - SM sets the 'dirty' flag and
>    responds to client
>  - Client gets the response
>  - SM dies
>  - SM is restarted - it loads the existing SA DB, which
>    does not includes the latest client's membership
>  - Loading of the whole SA DB is OK - no client re-register
>    request is issued
>  - Client remains disconnected from the mcast group

It is easy to think about such or similar scenarios. But OTOH if you
are going to request clients reregistration, why to preload SA DB?

> I want to be able to tell SM to request client re-register
> after loading the SA DB even if all was OK.

So my question is when preloading SA DB buys something for us when
clients will reregister anyway? Bugs?

> So there are 3 options to do it:
> 
> 1. Completely rely on 'no_clients_rereg' option only.
>    Do not alter this option, doesn't matter if the SA DB
>    reloading succeeded or not.
> 
> 2. Combine 'no_clients_rereg' option with loading SA DB
>    result: if loading succeeded, do whatever 'no_clients_rereg'
>    option says. If loading failed at some point, turn off
>    the 'no_clients_rereg' option (turn on re-registartion
>    requests, don't you just love the double-negative logic?)
> 
> 3. Add new option for this particular case.
> 
> I'm all for option 2, and this is what I'm implementing
> in V3 series patches.

IMHO this is better than what was proposed in the original patch. Think
that we can make it this way.

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-12-13 16:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-04 11:00 [PATCH 1/3 v2] opensm SA DB dump/restore: added option to load SA DB once Yevgeny Kliteynik
     [not found] ` <4AF15EBD.6010307-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2009-11-26 13:30   ` Sasha Khapyorsky
2009-12-06 10:32     ` Yevgeny Kliteynik
     [not found]       ` <4B1B883D.3080508-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2009-12-13 16:23         ` Sasha Khapyorsky [this message]
2009-12-13 21:38           ` Yevgeny Kliteynik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091213162305.GO5262@me \
    --to=sashak-smomgflxvozwk0htik3j/w@public.gmane.org \
    --cc=kliteyn-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox