2001
DOI: 10.1007/3-540-45417-9_12
|View full text |Cite
|
Sign up to set email alerts
|

Support for MPI at the Network Interface Level

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1

Citation Types

1
2
0

Year Published

2003
2003
2014
2014

Publication Types

Select...
3
1
1

Relationship

0
5

Authors

Journals

citations
Cited by 5 publications
(3 citation statements)
references
References 6 publications
1
2
0
Order By: Relevance
“…Unexpected messages are guaranteed to traverse the entire posted receive queue. This data explains results in [29], which indicate that the performance advantage of MPI offload decreases as the number of processors increases. In- The average search length for the unexpected queue is relatively short for all applications except FT. For FT, the search length grows linearly with the number of processors.…”
Section: Maximum Search Lengthsupporting
confidence: 57%
See 1 more Smart Citation
“…Unexpected messages are guaranteed to traverse the entire posted receive queue. This data explains results in [29], which indicate that the performance advantage of MPI offload decreases as the number of processors increases. In- The average search length for the unexpected queue is relatively short for all applications except FT. For FT, the search length grows linearly with the number of processors.…”
Section: Maximum Search Lengthsupporting
confidence: 57%
“…For example, in [17] portions of a Portals [5] stack were offloaded. Similarly, the Quadrics network [20] offloads the MPI matching stack onto the network interface, and others have explored this approach for Myrinet [29]. A new software stack from Myricom for Myrinet, called MX [19], appears to do this as well.…”
Section: Related Workmentioning
confidence: 99%
“…There is a mention of MPI message matching offloading on Quadrics [17] and Myrinet [23] network interfaces using on-NIC thread and memory. For InfiniBand [2], TupleQ [16] has been proposed where a Shared Receive Queue (SRQ) is created for each <contextId, rank, tag> tuple to match messages in hardware and improve the Rendezvous protocol [18].…”
Section: Introductionmentioning
confidence: 99%