> > On 12/5/08 6:49 AM, "Terry D. Dontje" <terry.don...@sun.com> wrote: > > Richard Graham wrote: > > Let me start the e-mail conversation, and see how far we get. > > > > Goal: The goal several of us have is to be able to use the btl’s > > outside of the MPI layer in Open MPI. The layer itself is generic, w/o > > specific knowledge of Upper Level Protocols, so is well suited for > > this sort of use. > > > > Technical Approach: What we have suggested is to start the process > > with the Open MPI code base, and make it independent of the mpi-layer > > (which it is now), and the run-time layer. > > > > Before we get into any specific technical details, > > the first question I have is are people totally opposed to the notion > > of making the btl’s independent of MPI and the run-time ? > > This does not mean that it can’t be used by it, but that there are > > well defined abstraction layers, i.e., are people against the goal in > > the first place ? > > > I am not against the idea of separating the BTLs out from OMPI. However, > it would help to know what we are really trying to accomplish this and > why using MPI is a non-starter. Is the issue to heavyweight of a > protocol or is it the infrastructure. I guess one question I have is if > we separate BTLs from OMPI do we lose valuable information needed to > establish and maintain the connections and could we run into some > chicken/egg problems. I assume the last issue is only of concern if we > remove the orte/opal dependencies.
Not quite sure about the MPI question. The btl's are ULP neutral communications primitives (by design), and we want to re-use these outside MPI. Run-time (actually for FT in MPI), and other ULP's. So OPAL dependencies will be maintained as these are what give us the portability layer. What needs to be a bit more generic is how these are used by ULP's, and specifically issues revolving around indexing. I am guessing that these are issues that will come up when addressing how to use other run-times in the context of OMPI. > What are alternative suggestions to the technical approach ? > The technical approach is really the implementation logistics, right? > That is how do we apply these changes to the trunk such that they get in > asap as to not require significant ongoing maintenance by the > implementors and not disturb the community members that are doing other > work. Yes. First, I am advocating a phased approach, to minimize disruption to the trunk. The first phase is renaming structures, and moving them in the code tree. The second is moving the btl and supporting code (mpools, rcache, allocator, ?, and have already gotten feedback that should consider moving the bml, which is very reasonable) to a new location in the code tree. These, I expect, should touch a lot of code, but it either compiles or it does not. No data structure changes or any other such changes will be made at this stage. The final phase is removing any dependencies on other layers. At this stage all I can think of is the notifier, but I am not doing the work, so there could be other changes. Here we need to talk as a community on how to best do this. It is clear that we need the notifier in this layer, and maybe we use an approach that Ralph has suggested and use #defines. At this stage I do foresee the need to make a change to the btl's, for general use - we need to add attributes that tell us if a given btl can bootstrap itself, and if forked processes can also use this btl in the children. The larger changes I was concerned about I think have more to do with enabling other run-time support within the ompi code base, and these will be addressed in a separate track, as Jeff has suggested. This is where I expect larger changes within ompi, but this has more to do with ompi than will others being able to use the btl's. > > Branch and patch - protects the community members the most until it > comes to the flag day of pushing the patch. But as you mention below > this has a heavy cost on the implementors and eventually a potentially > large blackout period. > > Incremental approach - If we believe this project will be large I > success we try and map out all the different pieces and try and figure > out ways we can compartmentalize each piece such that they can be > putback separately from each other. This is similar to the branch and > patch approach except we try and do several patchs that each can be > reasonably tested and putback separate from the others. The hope is that > each patch is not that large and thus easier for the implementors to > maintain and merge. But this will require a more thought out plan as to > how things are done which might be detrimental to any agile development. > > Scorched earth - Map a calendar time frame that we say from X to Y the > trunk will be under major renovation to move out the BTLs from OMPI. > This help the BTL movement developers but could put any other > development at risk. It also commits us completely to doing the BTL > separation so if things start falling a part it will definitely delay > the next release. > > I personally prefer the Incremental Approach but we will need to have a > very well thought out plan to get this to work. This approach could > devolve into the other two approaches without careful planning, which I > don't believe anyone would really like to to see. Same here. The goal is to keep the trunk fully functioning at all time, also from a performance perspective. Rich > > HTH, > > --td > > One suggestion has been to branch and patch. To me this is a long-term > > maintenance nightmare. > > > What are peoples thoughts here ? > > > > Rich > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org >
