Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] collectives / #1944 progress
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-07-02 08:28:35

Eugene --

Can you CMR over anything that still needs to go to v1.3 for the sm

I'll be filing a CMR to activate coll_sync later today.

(I admit I didn't pay close attention to see if everything is already
over there)

On Jul 2, 2009, at 8:06 AM, Jeff Squyres wrote:

> On Jul 1, 2009, at 10:23 PM, Eugene Loh wrote:
>> > For the future, we have a two pronged plan:
>> I suspect the standard procedure is that we all look quickly at this
>> e-mail message, file appropriately, and then resume our normal lives.
>> Yes? Or, is such a plan put somehow into place?
> I have time to allocate to this starting next week, but I then take
> a week of vacation the week after.
>> > 1. Clean up the sm btl:
>> > 1a. Remove all dead code.
>> What do you mean here? (Possibly you mean getting rid of sm pending
>> sends if we implement 1b properly, but I'm not sure.)
> You mentioned to Brian and me that there was a lot of "dead
> code" (#if'ed out or otherwise will-never-be-used). If that's
> incorrect, then forget this item.
>> > 1b. Resize free_list_max and fifo_size MCA params to effect good
>> > enough flow control.
>> > 1c. Possibly: convert from FIFO's to linked lists (for future
>> > maintenance purposes, not necessarily to fix problems).
>> Another idea is to have two kinds of FIFOs. One is just for
>> returning
>> fragments. The other is for in-coming message fragments. It would
>> even
>> seem as though one would no longer need "free lists", but just use
>> the
>> ack FIFO to manage fragments. (ALL of this is complicated by the
>> fact
>> that we have two kinds of fragments, eager and max, but fortunately
>> those details can be pushed onto the sorry fool who'll be
>> implementing
>> all this. I wonder who that'll be.)
> Likely me and/or Brian.
> --
> Jeff Squyres
> Cisco Systems

Jeff Squyres
Cisco Systems