public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
To: "Hefty, Sean" <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "linux-rdma
	(linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 10/15 ibacm] Add the ability to preload the destination GID and LID caches
Date: Wed, 26 Jun 2013 06:48:45 -0400	[thread overview]
Message-ID: <51CAC70D.5000205@dev.mellanox.co.il> (raw)
In-Reply-To: <1828884A29C6694DAF28B7E6B8A823736FD36C84-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>

On 6/25/2013 7:41 PM, Hefty, Sean wrote:
>> Preloading of these caches is supported via a file which is
>> produced by OpenSM by the dump_pr plugin which contains
>> sufficient SA PathRecord information. Details on this
>> file format and configuring OpenSM for this are found in
>> dump_pr_notes.txt in dump_pr.
>>
>> File format is specified in ibacm_opts.cfg as follows:
>> path_rec_fnt full_opensm_v1
>>
>> To preload these caches, ibacm service is started with -p option
>> which can also take optional path_rec_file which defaults to
>> ACM_CONF_DIR/ibacm_path_records.dump
> 
> I would rather use the config file versus adding command line parameters.

So add a new preload option in the config file for this ?

> This series will preload the cache, but it does not change the actual protocol ibacm uses for updates.   
> I want to verify that this is your intent.

Yes, that is my intent.

> I see within this patch that you override the address and route timeout values set by the user.  
> I think the code should honor those settings.

OK. The user can configure no address and/or route timeout if that is
what he wants so this mode of operation is possible currently without this.

> I wonder if it would make sense to treat file loading as a 'protocol' rather than a preload of the cache.  
> By changing the timeout value, this is essentially what occurs.  

Didn't you just write above not to change those timeout values ?

> If the cached data can timeout, then there's an option for what ibacm should do.  If it falls back to its
configured
> address/route protocols, then this is truly a preload of the cache.

That's what would happen now (for node not in cache or on timeout).

> An alternate option would be for ibacm to see if the input files 
> had been updated, and if so, reload its cache.

Yes, that seems like another valid alternative.

> One drawback I see with using this as a simple preload mechanism is that the entire cache would timeout at once if cache timeouts are enabled.

You're talking about the way it works as currently proposed in this
patch, right ?

-- Hal

> - Sean
> 

--
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:[~2013-06-26 10:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 11:02 [PATCH 10/15 ibacm] Add the ability to preload the destination GID and LID caches Hal Rosenstock
     [not found] ` <51C432BC.9020706-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2013-06-25 23:41   ` Hefty, Sean
     [not found]     ` <1828884A29C6694DAF28B7E6B8A823736FD36C84-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2013-06-26 10:48       ` Hal Rosenstock [this message]
     [not found]         ` <51CAC70D.5000205-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2013-06-26 18:46           ` Hefty, Sean

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=51CAC70D.5000205@dev.mellanox.co.il \
    --to=hal-ldsdmyg8hgv8yrgs2mwiifqbs+8scbdb@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@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