This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 677c2054960b21e3c1242424203af635b1717320 (commit) from 9544243693d62ae8086de31ef8b7fe669ae0984a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 677c2054960b21e3c1242424203af635b1717320 Author: Sumit Narayan <[email protected]> Date: Wed Dec 11 10:23:07 2013 -0600 Added text on bulk interface. ----------------------------------------------------------------------- Summary of changes: reports/na_ssm_update.txt | 33 ++++++++++++++++++++++----------- 1 files changed, 22 insertions(+), 11 deletions(-) Diff of changes: diff --git a/reports/na_ssm_update.txt b/reports/na_ssm_update.txt index 7b4151b..1024a8e 100644 --- a/reports/na_ssm_update.txt +++ b/reports/na_ssm_update.txt @@ -33,6 +33,8 @@ allows a variety of transport protocols to be integrated with Mercury as a Network Abstraction plugin, and without requiring any change in the user’s source code. +[[ Refer Figure: BlockDiagram.eps ]] + In the past three months, we have successfully been able to build a single-sided messaging (SSM) plugin for the Network Abstraction layer that communicates with other clients using SSM's TCP libraries. Since @@ -44,16 +46,24 @@ and hence our network communication was done over TCP. Given the abstraction that SSM provides, it will require very minimal effort on our part to run NA code over SSM's Infiniband. +[[ Refer Figure: MercuryNA.eps ]] + We have successfully been able to handle most of the data transfer operations required by Triton. Our client-server requests interface designs are based on the interfaces exported by BMI. Unexpected and expected messages could be received on both, servers and clients, -while only servers can receive expected messages. We have been able -to use SSM's APIs to provide the unexpected/expected send/receive -interfaces to the NA layer. We have also successfully accessed remote -memory using the ssm_get() and ssm_put() interfaces exported by the -SSM library. Below is the list of data transfer operations that we -can successfully do in Mercury over SSM transport today: +while only servers can receive expected messages. Unexpected and +expected messages are however limited to transfer of short messages +and make use of a two-sided approach. For transfer of larger amounts +of data, Mercury provides a bulk data interface that is built on top +of the remote memory access protocol defined in the NA layer. + +We have been able to use SSM's APIs to provide the unexpected/expected +send/receive interfaces to the NA layer. We have also successfully +accessed remote memory using the ssm_get() and ssm_put() interfaces +exported by the SSM library. Below is the list of data transfer +operations that we can successfully do in Mercury over SSM transport +today: - Unexpected send/receive - Expected send/receive (with remote offset aligned with the tagged @@ -75,11 +85,12 @@ using SSM: Network Abstraction (NA) Layer ============================== -Network Abstraction layer exports a set of APIs to be used by Mercury -for data transfer. These APIs were influenced by Portals, although it -will be hard to match them one-on-one. These interfaces are async, in -that they require the caller to provide a callback function which will -be called upon completion of the requested operation. +The main purpose of the Network Abstraction layer is to abstract the +network protocols that are exposed to the user. Network Abstraction +layer exports a set of APIs to be used by Mercury for data transfer. +These interfaces are async in nature, in that they require the caller +to provide a callback function which will be called upon completion of +the requested operation. NA-SSM Design ============= hooks/post-receive --