← Documents Documentation/infiniband/tag_matching.rst GitHub 원문 ↗

Linux 6.18.37 · InfiniBand

Tag matching logic

MPI 메시지 봉투 순서, eager·rendezvous, posted receive와 unexpected message 목록의 태그 매칭을 설명합니다.

Source pathDocumentation/infiniband/tag_matching.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

tag_matching.rst:1-69

MPI 태그 매칭은 communicator와 tag·rank 규칙 및 가장 먼저 게시된 send/receive 쌍의 순서를 지킵니다. 구현은 하드웨어가 관리할 수 있는 posted receive 목록과 소프트웨어 unexpected 메시지 목록을 함께 사용하며, 데이터 크기와 게시 시점에 따라 eager 또는 rendezvous로 전달합니다.

문서 개요
항목내용
SourceDocumentation/infiniband/tag_matching.rst
분량69 source lines
프로토콜Eager, Rendezvous
목록Posted receive, Unexpected message

원문 분량과 핵심 적용 대상을 요약합니다.

핵심 흐름
메시지 봉투 필드 비교Expected/unexpected 분류Eager 또는 Rendezvous 선택HW posted 목록과 SW shadow 유지Cancel·이동 경쟁 감지

문서의 주요 동작 순서를 압축해 보여 줍니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ==================
2 Tag matching logic
3 ==================
4
5 The MPI standard defines a set of rules, known as tag-matching, for matching
6 source send operations to destination receives. The following parameters must
7 match the following source and destination parameters:
8
9 * Communicator
10 * User tag - wild card may be specified by the receiver
11 * Source rank – wild car may be specified by the receiver
12 * Destination rank – wild
13
14 The ordering rules require that when more than one pair of send and receive
15 message envelopes may match, the pair that includes the earliest posted-send
16 and the earliest posted-receive is the pair that must be used to satisfy the
17 matching operation. However, this doesn’t imply that tags are consumed in
18 the order they are created, e.g., a later generated tag may be consumed, if
19 earlier tags can’t be used to satisfy the matching rules.
20
21 When a message is sent from the sender to the receiver, the communication
22 library may attempt to process the operation either after or before the
23 corresponding matching receive is posted. If a matching receive is posted,
24 this is an expected message, otherwise it is called an unexpected message.
25 Implementations frequently use different matching schemes for these two
26 different matching instances.
27
28 To keep MPI library memory footprint down, MPI implementations typically use
29 two different protocols for this purpose:
30
31 1. The Eager protocol- the complete message is sent when the send is
32 processed by the sender. A completion send is received in the send_cq
33 notifying that the buffer can be reused.
34
35 2. The Rendezvous Protocol - the sender sends the tag-matching header,
36 and perhaps a portion of data when first notifying the receiver. When the
37 corresponding buffer is posted, the responder will use the information from
38 the header to initiate an RDMA READ operation directly to the matching buffer.
39 A fin message needs to be received in order for the buffer to be reused.
40
41 Tag matching implementation
42 ===========================
43
44 There are two types of matching objects used, the posted receive list and the
45 unexpected message list. The application posts receive buffers through calls
46 to the MPI receive routines in the posted receive list and posts send messages
47 using the MPI send routines. The head of the posted receive list may be
48 maintained by the hardware, with the software expected to shadow this list.
49
50 When send is initiated and arrives at the receive side, if there is no
51 pre-posted receive for this arriving message, it is passed to the software and
52 placed in the unexpected message list. Otherwise the match is processed,
53 including rendezvous processing, if appropriate, delivering the data to the
54 specified receive buffer. This allows overlapping receive-side MPI tag
55 matching with computation.
56
57 When a receive-message is posted, the communication library will first check
58 the software unexpected message list for a matching receive. If a match is
59 found, data is delivered to the user buffer, using a software controlled
60 protocol. The UCX implementation uses either an eager or rendezvous protocol,
61 depending on data size. If no match is found, the entire pre-posted receive
62 list is maintained by the hardware, and there is space to add one more
63 pre-posted receive to this list, this receive is passed to the hardware.
64 Software is expected to shadow this list, to help with processing MPI cancel
65 operations. In addition, because hardware and software are not expected to be
66 tightly synchronized with respect to the tag-matching operation, this shadow
67 list is used to detect the case that a pre-posted receive is passed to the
68 hardware, as the matching unexpected message is being passed from the hardware
69 to the software.
70

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

MPI 태그 매칭 규칙과 Eager·Rendezvous 프로토콜

1-40

MPI 표준은 송신 측의 send 연산과 수신 측의 receive를 연결하는 태그 매칭 규칙을 정의합니다. 매칭하려면 communicator, 사용자 태그, source rank, destination rank가 맞아야 합니다. 수신자는 사용자 태그와 source rank에 와일드카드를 지정할 수 있고 destination rank도 와일드 조건으로 표현될 수 있습니다.

MPI 메시지 봉투 매칭 필드
필드매칭 조건와일드카드
Communicator송신과 수신이 동일없음
User tag태그가 동일수신자가 지정 가능
Source rank송신자 순위가 동일수신자가 지정 가능
Destination rank목적지 순위가 동일와일드 조건 가능

송신 봉투와 수신 봉투가 비교하는 필드 및 와일드카드 허용 위치입니다.

둘 이상의 send/receive 메시지 봉투 쌍이 매칭될 수 있으면, 가장 먼저 게시된 send와 가장 먼저 게시된 receive를 포함하는 쌍을 사용해야 합니다. 그렇다고 태그가 생성 순서대로 소비된다는 뜻은 아닙니다. 먼저 생성된 태그가 규칙을 만족하지 못하면 나중 태그가 먼저 소비될 수 있습니다.

송신 메시지가 수신 측에 도착할 때 대응하는 receive가 이미 게시되어 있으면 expected message, 아직 없으면 unexpected message라고 합니다. 통신 라이브러리는 두 상황에 서로 다른 매칭 방식을 흔히 사용합니다.

MPI 구현은 라이브러리 메모리 사용량을 낮추기 위해 일반적으로 Eager와 Rendezvous 두 프로토콜을 사용합니다. Eager에서는 송신자가 send를 처리할 때 전체 메시지를 보내고, `send_cq`에 완료가 도착하면 송신 버퍼를 재사용할 수 있습니다.

Rendezvous에서는 송신자가 먼저 태그 매칭 헤더와 필요하면 일부 데이터만 보냅니다. 대응하는 수신 버퍼가 게시되면 응답자가 헤더 정보를 사용해 해당 버퍼로 직접 RDMA READ를 시작합니다. 송신 버퍼는 fin 메시지를 받은 뒤에야 재사용할 수 있습니다.

Eager와 Rendezvous 비교
항목EagerRendezvous
첫 통지전체 메시지 송신태그 헤더와 선택적 일부 데이터
수신 버퍼도착 데이터 처리게시된 뒤 RDMA READ 대상
주 데이터 이동초기 send응답자의 직접 RDMA READ
송신 버퍼 재사용`send_cq` 완료fin 메시지 수신
일반적 선택작은 데이터큰 데이터

전송 시작, 데이터 이동, 버퍼 재사용 조건의 차이입니다.

태그 매칭 프로토콜 선택
송신 봉투의 communicator·tag·rank 비교대응 receive 게시 여부로 expected/unexpected 분류작은 메시지는 Eager로 전체 데이터 전송큰 메시지는 Rendezvous 헤더 전달 후 RDMA READ완료 CQ 또는 fin을 확인한 뒤 송신 버퍼 재사용

메시지 도착 시점과 크기에 따른 개념적 처리 흐름입니다.

==================
Tag matching logic
==================

The MPI standard defines a set of rules, known as tag-matching, for matching
source send operations to destination receives.  The following parameters must
match the following source and destination parameters:

*        Communicator
*        User tag - wild card may be specified by the receiver
*        Source rank – wild car may be specified by the receiver
*        Destination rank – wild

The ordering rules require that when more than one pair of send and receive
message envelopes may match, the pair that includes the earliest posted-send
and the earliest posted-receive is the pair that must be used to satisfy the
matching operation. However, this doesn’t imply that tags are consumed in
the order they are created, e.g., a later generated tag may be consumed, if
earlier tags can’t be used to satisfy the matching rules.

When a message is sent from the sender to the receiver, the communication
library may attempt to process the operation either after or before the
corresponding matching receive is posted.  If a matching receive is posted,
this is an expected message, otherwise it is called an unexpected message.
Implementations frequently use different matching schemes for these two
different matching instances.

To keep MPI library memory footprint down, MPI implementations typically use
two different protocols for this purpose:

1.        The Eager protocol- the complete message is sent when the send is
processed by the sender. A completion send is received in the send_cq
notifying that the buffer can be reused.

2.        The Rendezvous Protocol - the sender sends the tag-matching header,
and perhaps a portion of data when first notifying the receiver. When the
corresponding buffer is posted, the responder will use the information from
the header to initiate an RDMA READ operation directly to the matching buffer.
A fin message needs to be received in order for the buffer to be reused.

Posted receive와 Unexpected message 목록 구현

41-69

태그 매칭 구현은 posted receive list와 unexpected message list라는 두 종류의 매칭 객체를 사용합니다. 애플리케이션은 MPI receive 루틴으로 수신 버퍼를 posted receive list에 게시하고, MPI send 루틴으로 송신 메시지를 게시합니다. posted receive list의 머리는 하드웨어가 유지할 수 있으며 소프트웨어는 이 목록의 그림자 사본을 유지해야 합니다.

send가 시작되어 수신 측에 도착했을 때 미리 게시된 receive가 없으면 메시지는 소프트웨어로 전달되어 unexpected message list에 들어갑니다. 미리 게시된 receive가 있으면 필요할 경우 rendezvous 처리를 포함해 매칭을 수행하고 지정된 수신 버퍼에 데이터를 전달합니다. 이 구조는 수신 측 MPI 태그 매칭과 계산을 겹쳐 실행할 수 있게 합니다.

새 receive가 게시되면 통신 라이브러리는 먼저 소프트웨어 unexpected message list에서 일치 항목을 찾습니다. 항목이 있으면 소프트웨어 제어 프로토콜로 사용자 버퍼에 데이터를 전달합니다. UCX 구현은 데이터 크기에 따라 eager 또는 rendezvous를 사용합니다.

unexpected 목록에 일치 항목이 없고 하드웨어가 전체 pre-posted receive list를 유지하며 추가 공간도 있으면 새 receive를 하드웨어로 넘깁니다. 소프트웨어 그림자 목록은 MPI cancel 처리뿐 아니라, receive를 하드웨어로 넘기는 동시에 일치하는 unexpected 메시지가 하드웨어에서 소프트웨어로 이동하는 경쟁 상태를 감지하는 데도 사용됩니다.

태그 매칭의 두 목록
목록항목이 들어가는 조건주요 처리
Posted receive list애플리케이션이 receive 버퍼 게시도착 send와 하드웨어 또는 소프트웨어 매칭
Unexpected message listsend 도착 시 대응 receive가 없음새 receive 게시 때 소프트웨어가 먼저 검색
Software shadow list하드웨어 posted list를 반영MPI cancel과 HW/SW 이동 경쟁 감지

목록의 소유 위치, 삽입 조건, 사용 목적을 비교합니다.

Receive 게시와 메시지 도착의 양방향 매칭
Send 도착: pre-posted receive 검색있으면 즉시 매칭하고 사용자 버퍼로 전달없으면 unexpected message list로 이동Receive 게시: unexpected list를 먼저 검색있으면 크기에 따라 eager/rendezvous로 전달없고 HW 공간이 있으면 receive를 하드웨어 목록에 추가Software shadow가 cancel과 HW/SW 경쟁 상태 감시

send가 먼저 도착하는 경우와 receive가 먼저 게시되는 경우를 함께 나타냅니다.

Tag matching implementation
===========================

There are two types of matching objects used, the posted receive list and the
unexpected message list. The application posts receive buffers through calls
to the MPI receive routines in the posted receive list and posts send messages
using the MPI send routines. The head of the posted receive list may be
maintained by the hardware, with the software expected to shadow this list.

When send is initiated and arrives at the receive side, if there is no
pre-posted receive for this arriving message, it is passed to the software and
placed in the unexpected message list. Otherwise the match is processed,
including rendezvous processing, if appropriate, delivering the data to the
specified receive buffer. This allows overlapping receive-side MPI tag
matching with computation.

When a receive-message is posted, the communication library will first check
the software unexpected message list for a matching receive. If a match is
found, data is delivered to the user buffer, using a software controlled
protocol. The UCX implementation uses either an eager or rendezvous protocol,
depending on data size. If no match is found, the entire pre-posted receive
list is maintained by the hardware, and there is space to add one more
pre-posted receive to this list, this receive is passed to the hardware.
Software is expected to shadow this list, to help with processing MPI cancel
operations. In addition, because hardware and software are not expected to be
tightly synchronized with respect to the tag-matching operation, this shadow
list is used to detect the case that a pre-posted receive is passed to the
hardware, as the matching unexpected message is being passed from the hardware
to the software.