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.

From: Leslie Watter (watter_at_[hidden])
Date: 2006-01-23 06:13:44

Hello Andrew,

Thanks for this explanation. It was very helpfull to me to understand
the function of BTL, specially about the correct sequence of the
function path.

I was wondering if this mail, can be included in a commentary inside
btl.h or an README file at the BTL base directory to help other people

For now, I don't have more questions, :)



2006/1/19, Andrew Friedley <afriedle_at_[hidden]>:
> Hello,
> Apologies for the late response. I've been learning the BTL interface
> myself recently, and was asked to come up with answers for you.
> Hopefully my response is useful, let me know if you have more questions.
> Andrew
> Leslie Watter wrote:
> > What I need? To know how and what functions is necessary to perform a minimalist
> > implementation of a new btl, registering it and make it usable.
> First, two component functions are required - mca_component_open and
> mca_component_close.
> Two structs need to be set up - one for the component, and one for each
> module. The component struct is called mca_btl_<btl>_component_t, and
> extends mca_btl_base_component_t. The module struct is called
> mca_btl_<btl>_module_t, and extends mca_btl_base_module_t.
> Only one instance of the component struct is created, while many module
> structs may be created (usually one per network interface).
> Inside these structs are several function pointers that must be filled
> in. For the component, the btl_init and btl_progress fields are
> required. For each module, the following functions are required:
> btl_add_procs
> btl_del_procs
> btl_register
> btl_finalize
> btl_alloc
> btl_free
> btl_prepare_src
> btl_send
> The remaining three - btl_prepare_dst, btl_put, and btl_get - are
> optional RDMA functions. Their presence is indicated by the btl_flags
> field in the module struct. If either MCA_BTL_FLAGS_PUT or
> MCA_BTL_FLAGS_GET are set, the respective put/get function must be set
> in the struct, as well as prepare_dst.
> See btl.h and tcp/btl_tcp.h for examples.
> > 1) Inicialization
> >
> > component open
> > component init
> > component create instances
> > btl tcp create
> > component create_listen
> > btl tcp setsocket options
> > component exchange
> >
> > btl tcp add procs
> > endpoint construct ( executed * number of endpoints )
> > btl tcp del procs
> > btl tcp register
> del procs should not be getting called here. Otherwise this looks correct.
> <big cut>
> > This is the sequence I have found executing the TCP BTL code. Please fell free
> > to correct the place of sections.
> Other than the del procs call, this looks correct. Tim Woodall had some
> additional comments about typical send cases:
> From the perspective of the PML<->BTL interface, the PML will in
> general call:
> 1) btl_alloc followed by btl_send for short control messages
> 2) btl_prepare_src followed by btl_send for send/recv semantics
> 3) btl_prepare_dst/btl_prepare_src/btl_put for rdma semantics
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Leslie H. Watter