4.1 Submission Queue & Completion Queue Definition
섹션 4.1, 4.1.1 및 4.1.2는 PCIe를 통한 NVMe에만 적용된다. NVMe over Fabrics 구현의 경우 섹션 2.4와 NVMe over Fabrics 사양의 해당 섹션의 하위 섹션을 참조하십시오.
큐에 대한 Entry의 submitter는 현재 Tail Entry Pointer를 사용하여 다음 열린 queue slot을 식별한다. submitter는 열린 queue slot에 새로운 Entry를 배치한 후 Tail Entry Pointer를 증가시킨다. Tail Entry Pointer 증가량이 큐 크기를 초과할 경우 Tail Entry는 0으로 roll 된다. submitter는 Full Queue 조건이 충족되지 않는 한 계속해서 free Queue slot에 Entry를 배치할 수 있다(섹션 4.1.2 참조).
참고: submitter는 queue wrap 조건을 고려해야 한다.
queue의 Entry consumer는 현재 Head Entry Pointer를 사용하여 consumed 한 다음 Entry를 포함하는 slot을 식별한다. Consumer는 queue에서 다음 Entry를 consumer한 후 Head Entry Pointer를 증가시킨다. Head Entry Pointer 증가량이 queue size를 초과할 경우 Head Entry Pointer는 0으로 rolling된다. consumer는 Empty Queue 조건이 충족되지 않는 한 queue에서 Entry를 계속 소비할 수 있다. (섹션 4.1.1 참조)
Submission Queue 및 관련 Complement Queue의 생성 및 삭제는 host SW에 의해 올바르게 순서화 되어야 한다. Host SW는 관련 Submission Queue를 생성하기 전에 Complement Queue를 생성해야 한다. Submission Queue는 관련 Complement Queue가 생성된 후 언제든지 생성될 수 있다. Host SW는 Complement Queue를 삭제하기 전에 관련된 모든 Submission Queue를 삭제해야 한다. Submission Queue host SW에 제출된 모든 명령을 중단하려면 해당 큐에 대한 Delete I/O Submission Queue 명령을 발행해야 한다(섹션 7.4.3 참조).
Host SW는 해당하는 Entry Pointer의 새 값을 controller에 전달하기 위해 Submission Queue Tail Doorbell(섹션 3.1.25 참조) 및 Complete Queue Head Doorbell(섹션 3.1.26 참조)을 작성한다. Host SW가 Submission Queue Tail Doorbell 또는 Complete Queue Head Doorbell 레지스터에 잘못된 값을 작성하고 비동기 이벤트 요청 명령이 끝나지 않은 경우, 비동기 이벤트가 Invalid Doorbell Write Value의 상태 코드와 함께 Admin Completion Queue에 게시된다. 관련된 queue는 Host SW에 의해 삭제되고 다시 생성되어야 한다. 이 오류가 발생하는 Submission Queue의 경우, 컨트롤러가 이전에 완전히 소비된 command일 수 있으며, 추가 command는 소비되지 않는다. 이 상태는 Host SW가 전체 Submission Queue에 Entry를 추가하거나 빈 Completion Queue에서 Entry를 제거하려고 시도함으로써 발생할 수 있다.
Host SW는 메모리의 Complete Queue Entry Phase Tag(P) 비트를 확인하여 새로운 Complete Queue 엔트리가 게시되었는지 여부를 확인한다. Complete Queue Tail Pointer는 controller가 내부적으로만 사용하며 Host에는 표시되지 않는다. 컨트롤러 CQ Entry의 SQHD(SQ Head Pointer) 필드를 사용하여 SQHD의 새 값을 호스트에 전달한다. 새 SQHD 값은 Submission Queue Entry가 사용되었음을 나타내지만 command의 실행 또는 완료를 나타내지는 않는다. (4.6 참조)
Host가 관련된 Submission Queue Tail Doorbell을 write할 때 Submission Queue Tail Pointer가 Submission Queue Entry가 해당 Submission Queue Entry가 배치된 slot으로 이동 또는 통과했음을 나타내는 새로운 값으로 컨트롤러에 제출된다. Submission Queue Tail Doorbell write는 하나 이상의 Submission Queue Entry가 submission되었음을 나타낼 수 있다.
SQ Entry는 SQ Head Pointer가 SQ Entry가 배치된 슬롯을 지나 이동했음을 나타내는 CQ Entry가 게시될 때 controller에 의해 소비되었다. CQ Entry는 하나 이상의 SQ Entry가 소비되었음을 나타낼 수 있다.
controller가 CQ Entry를 다음 free CQ slot에 기록할 때 CQ Entry가 CQ에 게시된다. 컨트롤러 하나 이상의 CQ Entry가 게시되었음을 나타내기 위해 host에 interrupt를 생성할 수 있다.
Host가 관련 CQ Head Doorbell을 CQ Head Pointer가 해당 CQ Entry가 배치된 슬롯을 지나 이동했음을 나타내는 새 값으로 쓸 때 Host가 CQ Entry를 소비했다. CQ Head Doorbell을 쓰면 하나 이상의 완료 Queue Entry가 사용되었음을 나타낼 수 있다.
SQ또는 CQ Entry가 사용되면 해당 Entry가 배치된 slot은 free이며 재사용이 가능하다. 해당 Entry가 submission되었지만 해당 Entry가 사용되기 전에 SQ Entry를 변경하면 정의되지 않은 동작이 발생한다. 해당 Entry가 게시되었지만 해당 Entry가 사용되기 전에 CQ Entry를 변경하면 정의되지 않은 동작이 발생한다.
CQ에 빈 slot이 없는 경우(꽉 차 있는 경우), 컨트롤러 slot이 사용 가능해질 때까지 CQ에 status를 게시하지 않는다. 이 경우, 컨트롤러 slot이 사용 가능해질 때까지 영향을 받는 CQ와 연관된 추가적인 SQ의 처리를 중단할 수 있다. 컨트롤러 다른 Queue에 대한 처리를 계속해야 한다.
Entry Pointer
- Current Tail entry Pointer
Open되어있는 다음 slot을 찾기 위해 사용됨
새로운 entry를 넣은 후 Tail entry Pointer를 +1
Tail entry Pointer가 queue 크기를 넘어가면 0으로 초기화 됨
◈ queue가 가득 차지 않는 이상 계속해서 slot에 entry 추가 가능
- Current Head entry Pointer
다음에 소비하려는 slot을 가리킴
Queue에서 다음 entry를 사용한 후 Head entry Pointer를 +1
Head entry Pointer가 queue 크기를 넘어가면 0으로 초기화 됨
◈ queue가 비어 있지 않는 이상 계속해서 entry 소비 가능
Entry Phase Tag (P) bit
새로운 CQ Entry가 놓여졌는지 확인하기 위해 사용
CQ Tail Pointer는 host에서는 알지 못하고 controller 내부적으로만 사용됨
Controller는 CQ entry의 SQHD(SQ Head Pointer)필드를 사용하여 새로운 SQHD 값을 host에 전달함
새로운 SQHD 값은 SQ entry들이 소비되었다는 것을 나타내지만 명령어가 실행되었거나 완료되었는지 나타내지 않음
SQ Operation Example
CQ Operation Example
Phase Tag Operation Example
4.1.1 Empty Queue
Head Entry Pointer가 Tail Entry Pointer와 같을 때 Queue는 Empty이다. 그림 103은 Empty Queue 조건을 정의한다.
4.1.2 Full Queue
Head가 Tail보다 하나 더 많을 때 Queue는 Full이다. Full일 때 Queue의 Entry 수는 Queue 사이즈보다 하나 적다. 그림 104는 Full Queue 조건을 정의한다.
참고: Queue가 Full인지 여부를 판단할 때 Queue Wrap 조건을 고려해야 한다.
Queue의 생성 및 삭제
- Creation of Queue
Host SW는 CQ를 먼저 생성한 뒤 SQ를 생성해야 함
CQ가 생성된 후, SQ는 언제든지 생성 가능함
- Deletion of Queue
Host SW는 CQ와 관련된 SQ를 먼저 삭제해야 함
Host SW의 SQ의 모든 command들을 중단시키려면 그 Queue에 Delete I/O SQ를 명령해야 함
Doorbell
Host SW는 새로운 command가 entry로 들어왔다는 것을 controller에 전달하기 위해
Submission Queue Tail Doorbell 및 Complete Queue Head Doorbell을 write함
Host SW가 두 Doorbell 레지스터에 잘못된 값을 write하고 비동기 이벤트 request command가 끝나지 않은 경우,
Admin Completion Queue에 "Invalid Doorbell Write Value"상태 코드가 작성됨
관련된 Queue는 Host SW에 의해 삭제 및 재 생성되며,
controller는 이전에 처리 중이던 command까지만 끝내고 추가적인 command에 대해서는 처리하지 않는다.
해당 오류는 Host SW가 가득 찬 상태인 SQ에 엔트리를 추가하거나 빈 CQ에서 엔트리를 제거하려고 하면 발생함
4.1.3 Queue Size
Queue Size는 Queue의 slot 수를 나타내는 16비트 0's based 필드에 표시된다. Queue의 최소 크기는 2slot이다. I/O Submission Queue 또는 I/O Complete Queue의 최대 크기는 64 Ki 슬롯으로 정의되며 CAP.MQES 필드에 보고되는 controller가 지원하는 최대 큐 크기에 의해 제한된다. Admin SQ와 Admin CQ의 최대 크기는 4 Ki slot으로 정의된다. Head and Tail Entry Pointer 정의 때문에 각 큐의 slot 하나를 사용할 수 없다.
4.1.4 Queue Identifier
각 큐는 큐가 생성될 때 할당되는 16비트 ID 값을 통해 식별된다.
4.1.5 Queue Priority
긴급 우선순위 클래스 중재 메커니즘을 가진 가중 라운드 로빈이 지원되는 경우 host SW는 긴급, 높음, 중간 또는 낮음의 큐 우선순위 서비스 클래스를 할당할 수 있다. Weighted round robin이 지원되야 urgent priority class arbitration mechanism을 사용할 수 있다.
Queue 관련 용어
4.2 Submission Queue Entry – Command Format
각 명령의 크기는 64byte이다.
command Dword 0, namespace Identifier, metadata Pointer, PRP Entry 1, PRP Entry 2, SGL Entry 1, metadata SGL Segment Pointer는 모든 Admin command와 NVM command에 대해 공통적인 정의를 가지고 있다. metadata Pointer, PRP Entry 1, PRP Entry 2, metadata SGL segment Pointer는 모든 command에서 사용되는 것은 아니다. 명령어 Dword 0은 그림 105에 정의되어 있다.
Admin Command Set과 NVM Command Set에 대한 64byte 명령어 포맷은 그림 106에 정의되어 있다. 향후 정의될 I/O Command Set 추가적인 command는 대체 command 크기나 포맷을 사용할 수 있다.
SGL은 PCIe 구현을 통한 NVMe의 관리 명령에 사용되어서는 안된다.
Command Dword0
Command Format - Admin and NVM Command Set
모든 Admin 및 NVM command에 대해 일반적으로 정의되는 필드 외에도 Admin 및 NVM Vendor Specific command는 Data Transfer의 Dword number 및 Metadata Transfer 필드의 Dword number를 지원할 수 있다. 지원되는 경우 Admin Vendor Specific command 및 NVM Vendor Specific command에 대한 command format은 그림 107에 정의되어 있다. 자세한 내용은 섹션 8.7을 참조하십시오.
Command Format - Admin and NVM Vendor Specific Command (Optional)
4.3 Physical Region Page Entry and List
PRP(Physical Region Page) Entry는 PRP(Physical Region Page에 대한 Pointer이다. PRP는 controller와 메모리 사이의 데이터 전송을 위한 scatter/gather 메커니즘으로 사용된다. controller와 host 사이의 효율적인 out of order 순서로 데이터 전송을 가능하게 하기 위해, PRP 엔트리들은 고정된 크기이다.
PRP(Physical Region Page)의 size는 Host SW에 의해 CC.MPS로 구성된다. 그림 108은 Page base address와 offset으로 구성된 PRP Entry Layout을 보여준다. Offset 필드의 크기는 CC.MPS로 구성된 Physical Region Page 크기에 의해 결정된다.
PRP Entry
- “64bit” 물리 메모리 주소를 가리키는 pointer이다.
- PRPs는 controller와 memory사이에 데이터 전송을 위한 scatter/gather 메커니즘을 사용한다.
- 효율적인 out of order의 순서로 data를 전송하기 위해 entry는 고정된 사이즈로 사용된다.
- offset(n)은 CC.MPS에 의해 결정된다.
Physical Region Page List(PRP List)는 연속적인 메모리의 single page내의 PRP Entry들의 집합이다. PRP List는 command 자체 내에서 기술될 수 없었던 추가적인 PRP Entry들을 기술한다. command 내에서 기술된 임의의 PRP Entry들은 PRP List에서 복제되지 않는다. 전송할 데이터 양이 여러 PRP List Memory Page를 필요로 하는 경우, Memory Page의 종료 전 Last PRP Entry는 PRP List의 다음 세그먼트를 나타내는 다음 PRP List의 Pointer가 되어야 한다. 그림 110은 각 PRP 엔트리가 물리적으로 연속된 메모리 페이지를 식별하는 PRP List의 레이아웃을 보여준다. 그림 111은 각 PRP 엔트리가 서로 다른 메모리 페이지를 식별하는 PRP List의 레이아웃을 보여준다.
command 정의에 따라, command 내에 포함된 제1 PRP Entry는 Memory Page 내에서 0이 아닌 오프셋을 가질 수 있다. 제1 PRP List Entry(즉, 추가 PRP Entry를 포함하는 Memory Page로의 제1 Pointer)는 일반적으로 command 내에 PRP Entry 2 위치에 포함된 경우 dword 정렬되어야 하며 또한 Memory Page 내에서 0이 아닌 offset을 가질 수 있다.
PRP List에 포함된 PRP Entry는 0h의 Memory Page offset을 가져야 한다. 두 번째 PRP List가 command내에 존재하는 경우 0h의 Memory Page offset을 가져야 한다. 두 경우 모두 PRP List는 CC.MP의 값을 기준으로 정렬된 Memory Page이다. controller가 이러한 PRP List에 대해 0이 아닌 offset을 수신할 경우 컨트롤러 PRP offset free의 오류를 반환해야 한다.
PRP List는 엔트리 0부터 시작하는 패킹된 엔트리들로 최소 크기가 되어야한다. 더 많은 PRP List Page가 필요한 경우, PRP List의 Last Entry는 다음 PRP List Page의 Page Base address를 포함한다. 다음 PRP List Page는 Memory Page 정렬이어야 한다. command에 의해 요구되는 총 PRP Entry 수는 command Parameter 및 Memory Page 크기에 의해 암시된다.
PRP List
연속적인 메모리의 single page를 가지는 PRP entry들의 집합이다.
PRP List는 host 물리 메모리의 동일한 위치에서 host SW에 의해 유지관리 되며, Delete I/O SQ/CQ command 또는 컨트롤러가 재설정 되지 않는 이상 PRP List는 수정되지 않는다.
PRP Entry는 “0h”의 offset을 가져야 한다.
PRP_SIZE는 64bit(8byte)
PAGE_SIZE는 host page size(default: 4KB)
-> 하나의 memory page 안에 총 512(4012B/8B)개의 entry 포함될 수 있음
하나의 entry가 physical memory page(4KB)를 가리키므로 2048KB(2MB)의 데이터를 전송할 수 있음
PRP(Physical Region Page) 적용
NVMe command가 2개의 PRP 엔트리들만 사용할 때
첫 번째 PRP Entry는 Memory Page로 offset을 가진다.
- NVMe command가 첫번째 Entry는 PRP, 두번째 Entry는 PRP List로 사용할 때
각 PRP List의 마지막 PRP Entry는 다음 PRP List Pointer(Base Address)를 나타냄
PRP List에 포함된 PRP Entry는 0h의 offset을 가져야 함
4.4 Scatter Gather List(SGL)
SGL(Scatter Gather List)은 데이터 버퍼를 설명하는 데 사용되는 메모리 주소 공간의 데이터 구조이다. Identify Controller 데이터 구조에서 controller가 지원하는 SGL 타입을 나타낸다. 데이터 버퍼는 source buffer 또는 destination buffer이다. SGL은 하나 이상의 SGL 세그먼트를 포함한다. SGL에서 Data Block 및 Bit Bucket descriptor의 총 길이는 전송 요청된 데이터의 양과 같거나 이를 초과해야 한다.
SGL 세그먼트는 Physical Memory의 연속 영역에서 data buffer 및 다음 SGL 세그먼트의 전부, 일부, 또는 전혀 기술하지 않는, Qword 정렬된 데이터 구조체이다. SGL 세그먼트는 하나 이상의 SGL descriptor의 array로 구성된다. 마지막 SGL 세그먼트만이 SGL segment descriptor 또는 마지막 SGL segment descriptor일 수 있다.
Last SGL segment는 SGL segment descriptor 또는 SGL last segment descriptor를 포함하지 않는 SGL segment이다.
Controller data block byte 또는 dword 정렬 및 세분화를 지원할 수 있다. controller가 데이터 구조 식별(Identify Controller data structure, 그림 251 참조)의 SGL Support Filed에 표시된 대로 dword 정렬 및 세분화만 지원하는 경우 모든 데이터 블록 descriptor의 Address 및 Length field의 값은 하위 2비트를 00b로 정리해야 한다. 이 요구사항은 data 그리고/또는 metadata memory 영역을 나타내는 데이터 블록 descriptor에 적용된다.
Keyed SGL 데이터 블록 descriptor는 host memory acces의 일부로 사용되는 키를 포함하는 데이터 블록 descriptor이다. Keyed SGL 데이터 블록 descriptor에서 지정할 수 있는 최대 길이는 (16 MiB – 1)이다.
Transport SGL Data Block descriptor는 NVMe Transport와 관련된 전송 메커니즘 및 데이터 버퍼를 사용하여 NVMe Transport에 의해 전송되는 데이터 블록을 지정하는 Data Block descriptor이다.
SGL Identifier Descriptor Sub Type 필드는 descriptor에 대한 추가 정보를 지시할 수 있다. 예로, Sub Type은 Address 필드가 절대 주소가 아닌 오프셋임을 지시할 수 있다. Sub Type은 NVMe Transport 특정 정보를 지시할 수도 있다.
SGL(Scatter Gather List)
“DMA 전송에 있어서 데이터가 물리 메모리 상에 일렬로 정렬되어 있는 것은 아주 중요한 요소이다.”
Scatter/Gather : 커널 영역에서 흩어져 있는 메모리(Scatter)를 논리적으로 모아서(Gather) 연속된 물리적 메모리처럼 사용하는 것을 의미함
Scatter List : 흩어져 있는 메모리(Scatter)의 모음(array)
Direct Memory Access 전송 : 컴퓨터 메모리 Device로 데이터를 전송하는 단일 HW 작업
SGL : 데이터 버퍼(source buffer/ destination buffer)를 표현하기 위한 memory 주소 공간의 자료구조
last SGL segment는 last SGL segment descriptor를 포함하지 않는다.
Keyed SGL Data Block descriptor : host memory access의 일부로 사용되는 Key를 포함하는 Data Block descriptor
Transport SGL Data Block descriptor : NVMe Transport에 의해 전송되는 데이터 블록을 지정하는 Data Block descript
SGL segment는 하나 이상의 SGL descriptor를 가짐
SGL Descriptor Format은
03:00 SGL Descriptor Sub Type
07:04 SGL Descriptor Type
모두 0으로 설정된 SGL Descriptor는 Address 필드가 0h로 된 SGL Data Block Descriptor이며
Length 필드가 0h로 된 SGL Descriptor로 사용될 수 있다.
컨트롤러 다음과 같은 경우 명령을 중단해야 한다:
• SGL segment에는 segment의 마지막 descriptor 이외 SGL segment descriptor 또는 SGL Last segment descriptor가 포함된다.
• 마지막 SGL 세그먼트에는 SGL 세그먼트 기술자 또는 SGL 마지막 세그먼트 기술자가 포함된다;
• SGL 디스크립터는 지원되지 않는 형식을 가지고 있다;
• SGL Data Block 디스크립터는 하위 비트 두 개 중 하나가 1b로 설정된 Address 또는 Length 필드를 포함하며 컨트롤러는 Identify Controller 데이터 구조의 SGL Support 필드에 표시된 대로 dword 정렬 및 granularity만 지원합니다. 그림 251을 참조하십시오.
Summary
- SGL segment에 segment의 last descriptor 이외
SGL segment descriptor / SGL last segment descriptor가 포함되는 경우 - last SGL segment에 SGL segment descriptor/last SGL segment descriptor를 포함하는 경우
- SGL descriptor 지원되지 않는 format인 경우
SGL 세그먼트는 하나 이상의 SGL Descriptor를 포함한다. 그림 113은 일반적인 SGL 디스크립터 포맷을 정의한다.
그림 114에서 정의한 SGL Descriptor Type 필드는 SGL Descriptor Type을 지정한다. SGL Descriptor Type 필드가 reserved value 또는 unsupported value로 설정되어 있으면 SGL Descriptor Type 오류가 있는 것으로 처리된다. SGL Descriptor Sub Type 필드가 reserved value 또는 unsupported value로 설정되어 있으면 SGL Descriptor Type 오류가 있는 것으로 처리된다.
모두 0으로 설정된 SGL Descriptor는 Address 필드가 0h로 지워진 SGL Data Block Descriptor이며 Length 필드가 0h로 지워진 SGL Descriptor로 사용될 수 있다.
그림 115는 SGL Descriptor Sub Type 값을 정의하고 각 SGL Descriptor Sub Type이 적용되는 SGL Descriptor Type을 나타낸다.
그림 116에 정의된 SGL Data Block Descriptor는 Data block을 설명한다.
SGL Bit Block Descriptor
Address [07:00]
SGL Identifier Descriptor Sub Type Field가 0h(0x0)인 경우
address field는 data block의 64bit memory 시작 주소를 나타냄
SGL Identifier Descriptor Sub Type Field가 1h(0x1)인 경우
address field는 전송되어야 할 memory 주소의 offset을 나타냄
Length [11:08]
Data block의 Byte단위 길이를 나타냄
Reserved [14:12]
SGL Identifier [15]
[03:00] : SGL Descriptor Sub Type
[07:04] : SGL Descriptor Type
SGL Bit Bucket Descriptor인 경우
Length [11:08]
Discard되는 source data의 길이
destination data buffer인 경우, controller가 discard 할 source data의 길이를 나타냄.
source data buffer인 경우, “0h”이다.
SGL Identifier [15]
[03:00] : SGL Descriptor Sub Type
[07:04] : SGL Descriptor Type
4.4.1 SGL Example
그림 122는 SGL을 사용한 데이터 read 요청의 예를 보여준다. 예제에서 logical block size는 512B이다. access하는 logical block의 총 길이는 13KiB이고 이 중 11KiB만 호스트에 전송된다. 명령어의 NLB(Number of Logical Blocks) 필드는 controller에서 access하는 logical block의 총 길이가 13KiB임을 나타내는 26을 지정해야 한다. 메모리 내에서 logical block data가 전송되는 위치를 기술하는 SGL 세그먼트는 3개이다.
3개의 SGL 세그먼트는 각각 3KiB, 4KiB 및 4KiB의 길이를 갖는 총 3개의 Data Block Descriptor를 포함한다. Destination SGL의 Segment 1은 NVM으로부터 logical block data의 2KiB를 전송하지 않도록(즉, 무시) 지정하는 2KiB의 길이를 갖는 Bit Bucket Descriptor를 포함한다. Destination SGL의 Segment 1은 또한 Descriptor가 가리키는 세그먼트가 last SGL segment임을 지정하는 Last Segment Descriptor를 포함한다.
SGL Example - Read Request
전체 logical block size(512B) 중 11KiB만 host에 전송됨
4.5 Metadata Region(MR)
Metadata는 logical block의 일부로서 Namespace에 대해 지원될 수 있다(Application에 노출되는 더 큰 logical block인 확장된 logical block 생성). Metadata는 logical block Data와 interleave되거나 (즉, DPTR 필드를 사용함) 데이터의 별도의 버퍼로서(즉, MPTR 필드를 사용함) 전송될 수 있다. Metadata는 logical block Data와 별도의 Metadata buffer 사이에서 분할되지 않아야 한다. write를 위해, Metadata는 관련된 logical block과 함께 atomic으로 기록되어야 한다. 섹션 8.2를 참조
Namespace가 Metadata를 별도의 데이터 버퍼로 전송하기 위해 포맷된 경우에는 Metadata Region을 사용한다. 이때 Metadata Region의 위치는 command내 Metadata Pointer로 표시된다.
컨트롤러 logical block size 및 연관된 Metadata size의 여러 물리적 포맷들을 지원할 수 있다. 상이한 물리적 포맷들 사이에 성능 차이가 있을 수 있다. 이것은 Identify Namespace 데이터 구조의 일부로서 표시된다.
Namespace가 End To End 데이터 보호를 사용하도록 포맷된 경우(섹션 8.3 참조) MetaData의 처음 8byte 또는 마지막 8byte가 보호 정보로 사용된다(포맷 NVM 명령의 일부로 지정됨).
4.6 Completion Queue Entry
CQ Entry는 적어도 16byte의 크기이다.
그림 123은 CQ Entry Data Structure의 처음 16byte 레이아웃을 설명한다.
Dword 0의 내용은 명령어마다 다르다. 명령어가 Dword 0을 사용한다면 이 Dword의 정의는 관련 명령어 정의에 포함된다.
명령어가 Dword 0을 사용하지 않으면 필드가 reserved된다. Dword 1은 reserved된다. Dword 2는 그림 124에 정의되어 있고 Dword 3은 그림 125에 정의되어 있다. 앞으로 정의될 추가 I/O command set는 대체 CQ Entry 크기 또는 형식을 사용할 수 있다.
CQ Entry가 여러 번 쓰기를 통해 구성된 경우 해당 CQ Entry의 마지막 쓰기에서 Phase Tag Bit가 update된다.
CQ Entry
SQ Identifier [31:16]
SQ의 ID Field, 둘 이상의 SQ가 하나의 CQ를 공유할 때 Host SW가 사용함
완료된 command를 알기 위해서는 CID(Command ID)와 함께 결합하여 사용
SGL Head Pointer [15:00]
현재 SQ Head Pointer를 나타냄
가장 최근에 소비된 SQ Entry들을 Host에 알려주며 CQ Entry가 생성될 때의 SQ Head Pointer값을 return 하므로 Entry를 읽는 중 SQ Head Pointer가 움직이는 상황을 인지할 수는 없음
Status Field [31:17]
Command가 완료되었을 때 Status 값
0h 이면 성공적으로 command 완료, 실패했다면 vendor에 따라 특정 status code 반환함
Phase Tag [16]
CQ Entry가 new인지 식별하며, ‘0’으로 초기화 되어야 한다.
CQ에 Entry를 입력하면 controller는 Phase Tag를 invert시켜야 함
Phase Tag 값은 CQ를 통과할 때 마다 invert됨
Command Identifier(CID) [15:00]
완료되는 Command의 Identifier
Command가 SQ에 전달될 때 Host SW에 의해 할당된다.
SQ Identifier와 CID의 조합은 완료되는 Command를 식별할 수 있다.
4.6.1 Status Field Definition
Status Field는 그림 126에 정의된 CQ Entry에 표시된 command의 status를 정의한다.
Status Field의 값이 0h이면 fatal or non-fatal 오류 조건 없이 성공적으로 command가 완료되었음을 나타낸다. 특별한 언급이 없는 한, 여러 가지 이유로 명령이 성공적으로 완료되지 않으면 반환되는 특정 상태 코드가 vendor에 의해 선택된다.
CQ Entry : Status Field [DW3]
Do Not Retry (DNR) [31]
‘1’로 설정하면 NVM subsystem의 모든 controller에
동일한 command가 재전송되면 해당 재전송된 command는 실패할 것으로 예상됨
‘0’으로 해제되면 재전송된 동일한 command가 성공할 수 있음
command가 중단되거나, SCT와 SC가 0h로 해제되면 해당 DNR을 ‘0’으로 해제해야 한다.
More(M) [30]
‘1’로 설정하면 Get Log Page 명령으로 가져올 수 있는 Error Information Log의 일부를 살펴볼 수 있음
‘0’으로 지워지면 이 command에 대한 추가 상태 정보가 없음.
Command Retry Delay (CRD) [29:28]
DNR이 ‘0’이고 Host에서 ACRE(Advanced Command Retry Enable)을 1h으로 설정한 경우
- 1) 00b CRD값은 command retry 지연시간이 0임을 나타낸다
- 2) 0이 아닌 CRD값은 Identify Controller 데이터 구조에서 CRD를 나타내는 필드를 나타낸다.
DNR이 ‘1’이고 Host에서 ACRE를 0h로 설정한 경우 CRD는 “reserved” 된다.
SCT와 SC가 0h인 경우 CRD는 00b로 설정해야 한다.
Status Code Type(SCT) [27:25]
CQ Entry의 Status code type + Controller가 반환하는 status type
Status Code(SC) [24:17]
command에 대한 error 및 status 정보를 식별하는 status code
-
00h ~ 7Fh :Admin Command Set / multiple command set에 적용 가능 -
80h ~ BFh :I/O command set specific status code -
C0h ~ FFh :: vendor specific SC4.6.1.1 Status Code Type(SCT)
CQ Entry는 보고되는 Completion Type에 대한 상태 코드 유형을 나타낸다. 그림 127은 상태 코드 유형 값 및 설명을 지정한다.
Generic Command Status : CQ Entry의 Command and Submission Queue Identifier에 의해 지정된 command가 완료되었음을 나타낸다. 이러한 상태 값은 모든 command type에 걸쳐 일반적이며 success, opcode not supported, invalid 필드와 같은 조건을 포함한다.
Command Specific Status : 특정 command opcode에 고유한 상태 값을 나타낸다. 이 값들은 추가적인 처리가 필요함을 나타낼 수 있다. 잘못된 FirmWare 이미지 또는 초과된 최대 큐 수와 같은 상태 값이 이 유형으로 보고된다.
Media and Data Integrity Errors :NVM 또는 데이터 무결성 유형 오류에서 발생하는 모든 미디어 고유 오류는 이러한 유형이어야 한다.
Path Related Status :CQ Entry에서 Command and Submission Queue Identifier에 의해 지정된 command가 완료되었음을 나타낸다. 이 status 값은 모든 command type에 걸쳐 일반적이다. 이 값들은 추가 프로세스가 필요함을 나타내며 다음과 관련된 상태 값을 나타낼 수 있다:
- a) 호스트와 명령을 처리하는 컨트롤러 사이의 연결
- b) 비대칭 Namespace access report를 지원하는 특성 명령을 처리하는 controller와 지정된 namespace 간의 관계 특성.
4.6.1.2 Status Code(SC)
CQ Entry SC Field는 보고되는 완료보다 더 자세한 상태 정보를 나타낸다.
각 Status Code 세트의 값은 세 가지 범위로 나뉜다.
00h ~ 7Fh : Admin Command Set 또는 여러 명령 집합에 적용 가능;
80h ~ BFh : I/O Command Set Specific Status Code;
C0h ~ FFh : vendor specific SC
달리 지정되지 않는 한 여러 상태 코드가 적용되면 컨트롤러는 반환되는 상태 코드를 선택한다.
4.6.1.2.1 Generic Command Status Definition
Status Code Type이 Generic Command Status CQ Entry는 여러 가지 유형의 command에서 일반적으로 사용되는 명령과 관련된 상태 값을 나타낸다.
4.6.1.2.2 Command Specific Status Definition
CQ Entry에 Status code type command 특정 오류가 있는 경우 특정 command opcode에 고유한 오류를 나타낸다.
00h ~ 7Fh의 상태 코드는 admin command error에 대한 것이다.
80h ~ BFh의 상태 코드는 선택한 I/O command set에 고유하다.
4.6.1.2.3 Media and Data Integrity Errors Definition
Media and Data Integrity Errors의 Status Code Type는 CQ Entry는 NVM 미디어와 관련된 오류 또는 Data Integrity Errors로 인해 command와 관련된 오류를 나타냅니다.
4.6.1.2.4. Path Related Status Definition
Path Related Status의 CQ Entry Status Code Type(그림 134참조)은 여러 다른 유형의 명령에 걸쳐 일반적이며 명령을 처리하는 host와 controller 간 또는 controller와 namespace 간의 특정 연결에 적용되는 command와 관련된 상태 값을 나타낸다. 이 상태가 반환되는 명령은 host가 둘 이상의 controller를 사용할 수 있는 경우 동일한 NVM 서브시스템의 다른 컨트롤러에서 재시도될 수 있다. multipath 환경에서는 이 type의 오류를 사용 가능한 경우 다른 경로를 사용하여 재시도해야 한다.
4.7 Controller Memory Buffer
CMB(Controller Memory Buffer)는 컨트롤러의 범용 읽기/쓰기 메모리 영역입니다. 컨트롤러는 CAP.CMBS를 '1'로 설정하여 CMB를 지원함을 나타낸다. 호스트는 CMBMSC.CRE를 '1'로 설정하여 CMB를 사용할 의도를 나타낸다. 이 비트가 '1'로 설정되면 컨트롤러는 CMBLOC 및 CMBSZ 레지스터를 통해 CMB의 속성을 표시한다.
CMB는 다양한 용도로 사용될 수 있다. 컨트롤러는 CMBSZ 레지스터에 support flags를 설정하여 메모리를 어떤 용도로 사용할 수 있는지를 표시한다.
CMB에 대한 외부 메모리 읽기 및 쓰기 요청을 위해 CMB의 PCI Express 주소 범위가 사용된다. CMB의 PCI Express Base Address는 CMBLOC.BIR로 표시된 PCI Base Address Register(BAR)와 CMBLOC.OFST로 표시된 offset으로 정의된다. CMB의 크기는 CMBSZ.SZ로 표시된다.
컨트롤러는 CMB의 controller address 범위를 이용하여 host가 제공한 주소로 CMB를 참조한다. CMB의 PCI Express 주소 범위와 controller address 범위는 다를 수 있으나, 두 범위 모두 크기는 동일하며 각 범위 내의 같은 offset은 일대일 대응을 갖는다. host는 CMBMSC register를 통해 controller address 범위를 구성한다.
Host는 CMBMSC.CMSE bit를 통해 CMB의 controller memory 공간을 활성화한다. Controller memory공간이 활성화되면 host가 CMB의 controller address 범위를 참조하는 주소를 제공하면 컨트롤러는 이 주소에 대한 메모리 읽기 또는 쓰기 요청을 CMB로 전송한다.
CMB의 controller memory 공간이 비활성화되면, 컨트롤러 CMB의 controller address 범위를 참조하기 위해 host가 제공한 주소를 고려하지 않으며, 메모리 읽기 및 쓰기 요청은 다른 곳(예를 들어, CMB 이외의 메모리)으로 향한다.
controller의 메모리 요청의 잘못된 방향을 방지하기 위해 host SW가 CMB의 controller memory 공간을 활성화하기 전에 host SW가 DMA에 사용하려는 주소와 겹치지 않도록 CMB의 controller address 범위를 구성해야 한다.
이 사양의 이전 버전에서는 CMB를 지원하는 controller의 경우 CMB의 controller address 범위가 PCI Express 주소 범위와 동일하도록 고정되어 있으며 controller가 활성화될 때마다 CMB의 controller memory 공간이 항상 활성화된다. 이러한 controller가 가상 시스템에 할당될 때 controller memory 요청이 잘못 전달되는 것을 방지하기 위해 host SW(hypervisor/hostOS)는 CMB의 PCI Express 주소 범위의 변환을 활성화하지 않아야 하며 이 주소 범위가 가상 시스템이 DMA에 사용할 수 있는 사전 변환된 주소 범위와 겹치지 않도록 해야 한다.
Host SW는 CMB가 본 명세서의 1.3 이전 버전만 지원하는 가상 시스템에 controller가 할당될 때 CMB가 작동하도록 CMBMSC를 구성할 수 있다. 가상 시스템이 의도하지 않게 CMBMSC를 0h로 지우는 것을 방지하기 위해 CMBSMC의 내용은 controller 재설정 및 기능 수준 재설정에 걸쳐 보존된다.
Host Memory의 SQ들은 Queue Entry들을 fetch하기 위해 controller가 host Memory로부터 읽어오는 PCIe를 수행할 것을 요구한다. Controller Memory의 SQ들은 host SW가 전체 SQ Entry를 controller의 내부 메모리 공간에 직접 기입하는 것을 가능하게 하며, 이는 controller로부터 host로의 하나의 판독을 회피한다. 이 접근법은 command 실행에서의 latency(대기 시간)를 감소시키고, 다수의 스위치들을 포함할 수도 있는 PCIe fabric topology에서의 효율을 향상시킨다. 유사하게, PRP Lists 또는 SGL들은 PCIe fabric 전체에 걸쳐 별개의 fetch들을 필요로 하며, 이는 PRP 또는 SGL을 controller memory buffer에 기록함으로써 avoid될 수 있다. Controller memory buffer의 CQ들은 peer to peer 또는 다른 애플리케이션들을 위해 사용될 수도 있다. 소량의 데이터를 기록하는 경우, controller가 host Memory로부터 데이터 및/또는 metadata를 fetch하는 것보다 host가 controller memory buffer에 기록하는 것이 유리할 수도 있다.
controller memory buffer의 내용은 다음과 같이 정의되지 않는다:
• '0'에서 '1'로 전환되는 CMBMSC.CMSE bit;
• controller reset
• function level reset
Host SW는 참조되기 전에 controller memory buffer의 memory를 초기화해야 한다(예: CQ는 phase Tag를 올바르게 사용하기 위해 Host SW에 의해 초기화되어야 한다).
controller memory 기반의 Queue는 host memory 기반의 queue와 동일한 방식으로 사용되는데 차이점은 사용되는 메모리 주소가 host memory가 아니라 controller 자체의 메모리 내에 있다는 것이다. Admin 또는 I/O queue는 controller memory buffer에 배치될 수 있다. CMBLOC.CQMMS 비트(그림 84 참조)가 '0'으로 지워진 경우 특정 queue에 대해 해당 비트와 관련된 모든 메모리는 controller memory buffer 또는 controller memory buffer 외부에 있어야 한다.
CMBLOC.CQPDS 비트(그림 84 참조)가 '0'으로 지워지면 controller memory buffer의 모든 queue에 대해 queue는 physically contiguous여야 한다.
controller memory buffer에서 PRP list와 SGL을 지원할 수 있다. CMBLOC.CDPMLS bit(그림 84 참조)가 '0'으로 지워진 경우, 하나의 명령어와 연관된 특정 PRP list 또는 SGL의 경우, PRP list 또는 SGL과 연관된 모든 memory는 전적으로 controller memory buffer에 위치하거나 controller memory buffer 외부에 위치해야 한다.
command와 관련된 PRP List 및 SGL은 해당 command가 controller memory buffer의 SQ에 있는 경우 controller memory buffer에 배치될 수 있다.
다음과 같은 경우:
- a) CMBLOC.CDPCILS 비트(그림 84 참조)는 '0'으로 지워진다
- b) command가 controller memory buffer의 SQ에 없다.
그러면 해당 command와 관련된 PRP list 및 SGL은 controller memory buffer에 배치되지 않는다.
컨트롤러는 controller memory buffer에서 data 및 metadata를 지원할 수 있다. CMBLOC.CDMMMS 비트(그림 84 참조)가 '0'으로 clear되면 특정 command와 관련된 모든 data 및 metadata는 CMB에 전적으로 위치하거나 CMB 외부에 위치해야 한다.
CMB 사용에 대한 요구 사항이 host에 의해 위반되면 컨트롤러 관련 command를 잘못된 CMB 사용 상태로 실패한다.
CMB를 위해 할당된 주소 영역은 4KiB로 정렬되어야 한다. 컨트롤러 8KiB 경계에서 CMB를 할당하는 것이 좋다. 컨트롤러 최대 payload 크기, support byte 활성화 및 임의 byte 정렬까지 burst 트랜잭션을 지원해야 한다. Host는 SQ Tail Doorbell Register를 update하기 전에 command에 필요한 모든 CMB write가 전송되었는지 확인해야 한다. SQ Tail Doorbell Register의 메모리 쓰기 요청은 CMB에 대한 사전 쓰기가 완료되었는지 확인하기 위해 완화된 순서 비트를 '1'로 설정하지 않아야 한다.
Controller Memory Buffer
컨트롤러의 read/write memory 영역
Host가 컨트롤러 메모리 공간을 활성화하여 CMB의 PCIe 주소를 제공해주면 컨트롤러는 메모리 read/ write요청을 CMB로 전송한다.
4.8 Persistent Memory Region
PMR(Persistent Memory Region)은 범용 PCI Express 읽기/쓰기 영구 메모리의 옵션 영역으로 다양한 용도로 사용될 수 있다. 컨트롤러 CAP.PMRS를 1 로 설정하여 PMR을 지원함을 나타내며, controller가 PMRCAP register에 support flag를 설정하여 PMR과의 command data 및 metadata 전송을 지원하는지 여부를 나타낸다. PMR과의 command data 및 metadata 전송이 지원되는 경우 특정 command과 관련된 모든 data 및 metadata는 전체적으로 PMR 또는 PMR 외부에 있어야 한다.
PMR의 PCI Express 주소 범위는 PMR에 대한 외부 메모리 읽기 및 쓰기 요청에 사용된다. PMR의 PCI Express 주소 범위 및 크기는 PMRCAP.BIR로 표시되는 PCI BAR(Base Address Register)에 의해 정의된다. PMR은 BAR에 의해 노출되는 전체 주소 영역을 소비하고 PCI Express 프로그래밍 모델의 필요한 모든 기능을 지원한다.
controller PMR의 컨트롤러 주소 범위를 사용하여 host가 제공한 주소로 PMR을 참조한다. PMR의 PCI Express 주소 범위와 controller 주소 범위는 다를 수 있지만 두 범위 모두 크기는 동일하며 각 범위 내의 같은 offset은 일대일 대응을 갖는다. host는 PMRMSCU 및 PMRMSCL register를 통해 controller 주소 범위를 구성한다.
host는 PMRMRSCL.CMSE bit를 통해 PMR의 controller memory 공간을 활성화한다. Controller memory 공간이 활성화되고 host가 PMR의 controller 주소 범위를 참조하는 주소를 제공하면 컨트롤러는 이 주소에 대한 메모리 읽기 또는 쓰기 요청을 PMR에 지시한다.
PMR의 controller memory 공간이 disable되면, 컨트롤러 PMR의 controller 주소 범위를 참조하기 위해 host 제공된 임의의 주소를 고려하지 않으며, 메모리 읽기 및 쓰기 요청은 다른 곳(예를 들어, PMR 이외의 메모리로)으로 향한다.
PMR이 준비되는 동안 PMR에 기록된 데이터의 내용은 전력 사이클 전반에 걸쳐 지속되고, Controller level을 재설정하고 PMR을 비활성화한다. PMR에 대한 쓰기를 영구적으로 만들기 위해 사용되는 메커니즘은 implementation specific이다. 예를 들어, 하나의 구현예에서 이것은 다른 구현예에서 비휘발성 메모리에 대한 쓰기가 완료된 동안 다른 구현예에서 쓰기가 비휘발성 쓰기 버퍼에 저장되었고 나중의 어느 시점에서 비휘발성 메모리에 기록되었음을 의미할 수 있다.
PMR 구현은 maximum sustained write throughput을 갖는다. PMR 구현은 또한 PMR PCIe write requests로부터의 write를 버퍼링하기 위해 사용되는 optional write elasticity buffer를 가질 수 있다. PMR sustained write throughput이 PCIe link throughput보다 작을 때, 그러한 write elasticity buffer는 PCIe write request burst throughput이 PCIe fabric 내로의 역순 없이 PMR sustained write throughput을 초과할 수 있게 한다.
비휘발성 media에서 Write elasticity buffer로부터 데이터를 전송하는 데 필요한 시간은 elasticity buffer에 기록된 데이터의 양을 (Persistent Memory Region Sustained Write Throughput)으로 나눈 값이다(섹션 3.1.22 참조). Write elasticity buffer의 전체 내용을 전송하는 시간은 Persistent Memory Region Elasticity Buffer Size (섹션 3.1.21 참조)를 Persistent Memory Region Sustained Write Throughput으로 나눈 값이다.
host는 PMRCTL.EN을 '1'로 설정하여 PMR을 활성화한다. 일단 활성화되면, 컨트롤러는 PMRSTS.NRDY를 '0'으로 지움으로써 PMR이 준비되었음을 표시한다. 컨트롤러가 PMR을 활성화하는 것이 필요하지 않는다. PMR의 내용을 복원하고 저장하는 것이 완료되는 데 시간이 걸릴 수 있다. host가 PMRCTL.EN의 값을 수정할 때, host는 PMRSTS.NRDY에 대해 PMRTO에 지정된 시간 간격 이상 대기해야 변경 사항을 반영할 수 있다.
PMR이 준비되지 않은 경우, PMR은 성공적으로 판독하여 정의되지 않은 값을 반환하고 PMR이 정상적으로 기록하는 동안에는 메모리를 업데이트 하지 않는다(즉, 기록된 PMR 주소의 내용은 변경되지 않음). Sanitize 작업 후 PMR 판독에 의해 반환되는 정의되지 않은 값은 임의의 캐시 또는 비휘발성 미디어로부터의 임의의 이전 사용자 데이터의 복구가 불가능하도록 한다.
PMR이 읽기 전용이 되거나 신뢰할 수 없게 되면 SMART/Health Information Log에 중요한 경고가 보고되며, 이는 NVMe 인터페이스 비동기 이벤트를 트리거하는 데 사용될 수 있다. 비동기 이벤트 보고는 PMR 상태가 변경된 후 지정되지 않은 시간에 발생할 수 있으므로 호스트는 PMRSTS.HSTS에서 정상 작동이 마지막으로 보고된 이후 PMR에 대한 모든 작동이 영향을 받은 것으로 가정해야 한다.
PMRCAP.PMRWBM은 지원되는 PMR write 장벽 메커니즘을 열거한다. 적어도 하나의 메커니즘이 지원되어야 한다. implementation은 선택적으로 "zero-length read"를 포함하여 PMR에 대한 임의의 크기의 PCI Express read가 PMR에 대한 모든 이전 메모리 쓰기(즉, 게시된 PCI Express request)가 완료되고 지속되는 것을 보장하는 메커니즘을 지원할 수 있다. implementation은 선택적으로 PMRSTS 레지스터의 읽기를 활용하는 쓰기 장벽 메커니즘을 지원할 수 있다. 지원되는 경우, PMRSTS 레지스터의 읽기는 호스트가 다음을 수행할 수 있게 한다:
- PMR에 이전에 발행된 메모리 쓰기가 완료되었는지 확인한다.
- 해당 쓰기와 관련된 PMR 업데이트가 오류 없이 완료되고 지속적인지 여부를 확인한다.
PMR 메모리 write error는 중독된 PCI Express TLP, NVM subsystem 내부 오류 또는 PMR 상태 문제의 결과일 수 있다.
지원되는 PMR write 장벽 메커니즘에 관계없이, host는 PMR에 대한 판독 값이 유효한 데이터를 반환했는지 확인하기 위해 주기적으로 PMRSTS를 판독할 수 있다. 예를 들어, PMRSTS 레지스터에 대한 판독 값이 PMR이 정상적으로 동작하고 있음을 나타내는 일련의 판독 값이 뒤따르고 마지막으로 PMR이 신뢰할 수 없음을 나타내는 두 번째 판독 값이 PMRSTS 레지스터에 대한 판독 값 중 하나 이상이 유효하지 않은 데이터를 반환했을 수 있다. 이러한 PMRSTS 레지스터의 폴링은 host가 중독된 TLP를 처리하고/하거나 중독된 TLP 오류 보고가 활성화된 경우 불필요할 수 있다.
PMR sustained write throughput과 함께 PMR write elasticity buffer size는 host가 persistent memory region write장벽 메커니즘과 연관된 읽기가 완료되는 시간을 결정할 수 있게 한다.
영구 메모리 영역의 PRP, SGL list, CQ 및 SQ에 대한 지원은 이 규격의 범위를 벗어난다. 호스트가 PRP, SGL list, CQ 또는 SQ에 PRP를 사용하려고 하면 컨트롤러가 command에 잘못된 필드의 상태 코드를 사용하여 명령을 중단할 수 있다.
Persistent Memory Region
PCIe read/write memory option 영역
컨트롤러는 CAP.PMRS 1로 설정하고 Host는 PMRCTL.EN 1로 설정하여 PMR을 지원함을 나타낸다.
PMRCAP 레지스터에 다양한 flags를 설정하여 PMR과의 command data 및 metadata 전송을 지원하는지 여부를 나타낸다.
[ PMR Register ]
Host는 PMRCTL.EN을 1 로 설정하여 PMR을 활성화한다.
활성화되면 컨트롤러는 PMRSTS.NRDY를 0 으로 지워 PMR이 준비됨을 표시한다.
4.9 NVM Sets
NVM 집합은 다른 NVM 집합의 NVM과 (논리적으로 그리고 잠재적으로 물리적으로) 분리된 NVM 집합이다. 하나의 NVM 집합 내에 하나 이상의 네임스페이스가 생성될 수 있으며 이러한 네임스페이스는 NVM 집합의 특성을 상속한다. 네임스페이스는 하나의 NVM 집합 내에 완전히 포함되며 둘 이상의 NVM 집합에 걸쳐 있을 수 없다.
그림 135는 3개의 NVM 세트의 예를 보여준다. NVM 세트 A는 3개의 네임스페이스(NSA1, NSA2 및 NSA3)를 포함한다. NVM 세트 B는 2개의 네임스페이스(NSB1 및 NSB2)를 포함합니다. NVM 세트 C는 하나의 네임스페이스(NSC1)를 포함한다. 표시된 각 NVM 세트에는 아직 네임스페이스에 할당되지 않은 NVM으로 구성된 '할당되지 않은' 영역도 포함된다.
그림 136에 설명된 대로 NVM Set 인식 관리 command의 subsystem set이 있다.
[ Identify ]
Identify Namespace 데이터 구조에는 연관된 NVM Set Identifier가 포함된다.
NVM Set List 데이터 구조에는 각 NVM Set에 대한 속성이 포함된다.
[ Namespace Management ]
생성 작업에는 호스트 지정 필드로 NVM Set Identifier가 포함된다.
[ Get Features and Set Features ]
읽기 복구 수준 기능은 연결된 NVM 집합 식별자를 지정한다.
예측 가능한 대기 시간 모드 구성 기능은 관련 NVM 세트 식별자를 지정한다.
예측 가능한 대기 시간 모드 창 기능은 관련 NVM 세트 식별자를 지정한다.
host는 CNS 값이 04h 인 Identify 명령을 사용하여 존재하는 NVM set 및 그 속성을 결정하여 NVM set list를 검색한다(그림 254 참조). 각 NVM set에 대해 속성은 다음과 같다:
• NVM 세트와 연관된 식별자;
• NVM 세트에 쓰기 위한 최적의 크기;
• NVM 세트의 총 용량
• NVM 세트의 할당되지 않은 용량
NVM Set Identifier는 동작이 연관된 NVM Set을 지정하는 16-bit 값이다. NVM Set aware Admin 명령에 NVM Set Identifier가 지정될 수 있다(그림 136 참조). 0h의 NVM Set Identifier 값은 reserved이며, 올바른 NVM Set Identifier가 아니다. 달리 명시되지 않는 한, host가 NVM Set Identifier를 요구하는 명령에 대해 0h로 지워진 NVM Set Identifier를 지정하면 해당 명령은 명령 내의 Invalid Field의 상태 코드와 함께 중단된다.
각 NVM set는 정확히 하나의 내구성 그룹과 연결된다(섹션 8.17 참조).
Namespace가 연결된 NVM Set은 Identify Namespace 데이터 구조에 보고된다(그림 249 참조). host가 Namespace Admin Command을 사용하여 Namespace를 생성할 때 host는 Namespace가 생성될 NVM Set의 NVM Set Identifier를 지정한다. 생성된 Namespace는 NVM Set의 특성(예: NVM에 대한 optimal write size)을 상속한다.
NVM set가 지원되는 경우 NVM subsystem의 모든 컨트롤러는 다음과 같다:
- Controller Data Structure Identifier의 컨트롤러 속성 필드에 NVM Set에 대한 지원을 표시한다.
- NVM Set Identifier를 사용하는 모든 명령에서 NVM Set Identifier를 지원한다;
- Identify Command에 대한 NVM Set List 지원한다.
- Namespace Data Structure Identifier에 네임스페이스가 연결된 NVM Set Identifier를 나타낸다.
- support Endurance group;
- 각 NVM Set에 대해 연관된 Endurance Group을 속성으로 표시한다.
4.10 Namespace List
그림 137에 정의된 네임스페이스 list는 네임스페이스 ID의 순서가 매겨진 목록이다. 사용되지 않은 항목은 0으로 채워진다.
Identifier 0 [03 : 00]
이 필드는 목록에서 가장 낮은 Namespace ID를 포함하거나 목록이 비어 있는 경우 0h를 포함한다.
Identifier 1 [07 : 04]
이 필드는 목록에서 두 번째로 낮은 Namespace ID를 포함하거나 목록에 두 개 미만의 항목이 포함된 경우 0h를 포함한다.
…
Identifier N [N*4+3 : N*4]
이 필드에 목록에 N+1 최하위 Namespace ID가 포함되어 있거나 목록에 N개 미만의 Entry가 포함되어 있는 경우 0h이다.
4.11 Controller List
그림 138에 정의된 컨트롤러 list은 오름차순 컨트롤러 ID의 순서 목록이다. 컨트롤러 식별자는 그림 251의
Identify data structure의 byte [79:78]로 정의되어 있다. 사용되지 않은 항목은 0으로 채워진다.
Number of Identifiers [01 : 00]
이 필드는 List의 Controller Entry 수 를 포함한다.
List에는 최대 2,047개의 식별자가 있을 수 있다. 0h 값은 List에 Controller가 없음을 나타낸다.
Identifier 0 [03 : 02]
이 필드는 List에서 두 번째로 낮은 Namespace ID를 포함하거나 List 에 두 개 미만의 Entry가 포함된 경우 0h를 포함한다.
Identifier 1 [05 : 04]
이 필드에 List에 N+1 최하위 Namespace ID가 포함되어 있거나 List에 N개 미만의 Entry가 포함되어 있는 경우 0h이다.
…
Identifier N [N*2+3 : N*2+2]
이 필드에는 List에 N+1 Controller에 대한 NVM Subsystem 고유 Controller Identifier가 포함된다 (존재하는 경우).
4.12 Fused Operations
Fused Operation은 두 개의 단순한 Command를 “Fused"하여 보다 복잡한 Command를 가능하게 한다. 이 기능은 선택 사항이며, 이 기능에 대한 지원은 그림 251의 Identify Controller Data Identifier의 FUSE Field에 나와 있다. Fused Operation에서 요구 사항은 다음과 같다:
• command는 atomic 단위로 순차적으로 수행되어야 한다. 컨트롤러는 이 두 command사이에 다른 작업이 수행되지 않은 것처럼 행동해야 한다;
• 두 command 중 하나에 오류가 발생한 지점에서 작업이 종료된다. 시퀀스의 첫 번째 command가 실패한 경우 시퀀스의 두 번째 command는 중단된다. 시퀀스의 두 번째 command가 실패한 경우 첫 번째 command의 완료 상태는 시퀀스 고유이다;
• LBA 범위는 사용되는 경우 두 command에 대해 동일해야 한다. LBA 범위가 일치하지 않는 경우 command에 Invalid Field in Command 상태로 command을 중단해야 한다;
• command는 동일한 SQ에서 서로 옆에 삽입되어야 한다. 첫 번째 command가 SQ의 마지막 슬롯에 있는 경우 두 번째 command는 둘러싸여 있는 주변의 일부로 SQ의 첫 번째 슬롯이 되어야 한다. SQ Tail Doorbell Pointer update는 두 command 모두를 하나의 Doorbell update의 일부로 표시해야 한다.
• fused operations를 중단하려면 host는 command에 대해 별도로 중단command을 제출해야 한다.
• 각 command에 대해 CQ Entry가 컨트롤러에 의해 게시된다.
command가 Fused Operation의 일부인지 여부는 그림 105에 표시된 Command Dword 0의 FUSE(Fused Operation) 필드에 표시된다.
FUSE 필드는 또한 각 command가 Fused Operation의 첫 번째 command인지 Fused Operation의 두 번째 command인지를 나타낸다.
FUSE 필드가 0이 아닌 값으로 설정되어 있고 컨트롤러가 요청된 Fused Operation을 지원하지 않는 경우 컨트롤러는 command에서 Invalid Field in Command 상태로 command를 중단해야 한다.
4.13 Command Arbitration
NVMe over PCIe 구현의 경우 호스트에서 작성한 SQ Tail Doorbell이 SQ Tail Pointer를 해당 SQ Entry를 포함하는 슬롯을 통과하면 command가 컨트롤러에 제출된다.
NVMe over Fabrics Implementation의 경우 command Submission의 정의는 NVMe over Fabrics 사양의 섹션 1.4.14를 참조하십시오.
컨트롤러는 vendor specific 알고리즘을 사용하여 후속 처리를 위해 제출된 command를 컨트롤러로 전달한다.
컨트롤러 및/또는 Namespace Status가 command에 의해 Access되거나 수정되는 경우(예: feature 설정이 access 또는 수정되거나 Logical Block이 access 또는 수정되는 경우) command가 처리되고 있다.
command에 대한 CQ Entry가 해당 Complete Queue에 게시되면 command가 완료된다. 완료되면 해당 command에 의해 수행된 모든 컨트롤러 상태 및/또는 Namespace Status 수정이 이후에 제출된 모든 command에 전역적으로 표시된다.
Candidate Command는 제출된 command로서, 컨트롤러가 처리할 준비가 되었다고 판단하는 컨트롤러에 전달되었다. 컨트롤러는 각 SQ에 대해 제출된 command의 poll로부터 처리할 command(들)를 선택한다.
Fused 동작을 구성하는 command는 컨트롤러에 의해 함께 그리고 순서대로 처리되어야 한다. 컨트롤러는 임의의 순서로 처리할 후보 command들을 선택할 수 있다. 처리를 위해 command들이 선택되는 순서는 commands가 완료되는 순서를 의미하지 않는다.
Arbitration은 컨트롤러가 다음 후보 command를 처리하기 시작하는 Submission Queue를 결정하는 데 사용되는 방법이다. 중재를 사용하여 Submission Queue를 선택하면 중재 brust 설정은 중재가 다시 수행되기 전에 해당 Submission Queue에서 컨트롤러가 처리를 시작할 수 있는 최대 command 수를 결정한다. Fused action은 컨트롤러에 의해 하나 또는 두 개의 command로 간주될 수 있다.
모든 컨트롤러는 round robin command arbitration mechanism을 지원해야 한다. 컨트롤러는 긴급 우선 순위 클래스 및/또는 Vendor 특정 중재 메커니즘과 함께 WRR(가중치가 부여된 라운드 로빈)을 선택적으로 구현할 수 있다.
Controller Capabilities register (CC.AMS)의 중재 메커니즘 지원 필드는 컨트롤러에 의해 지원되는 선택적 중재 메커니즘을 나타낸다.
비휘발성 메모리를 효율적으로 사용하기 위해서는 SQ에서 여러 command를 병렬로 실행하는 것이 유리한 경우가 많다. 긴급 우선 순위 클래스가 있는 가중 라운드 로빈 또는 라운드 로빈 중재를 사용하는 SQ의 경우 host SW가 arbitration burst 설정을 구성할 수 있다. arbitration burst 설정은 특정 SQ에서 컨트롤러가 한 번에 시작할 수 있는 Command의 최대 수를 나타낸다.
Host SW는 지연 시간 요구 사항을 고려하여 중재 burst 설정을 컨트롤러가 권장하는 값에 최대한 가깝게 구성하는 것이 좋다(그림 251의 Identify Controller 데이터 구조의 권장 중재 burst 필드에 지정). 섹션 5.21.1.1을 참조하십시오.
4.13.1 Round Robin Arbitration
라운드 로빈 중재 메커니즘이 선택되면, 컨트롤러는 Admin Submission Queue를 포함한 모든 Submission Queue 간에 라운드 로빈 command 중재를 구현해야 한다. 이 경우, 모든 Submission Queue는 동등한 우선순위로 처리된다. 컨트롤러는 Arbitration Burst 설정에 기초하여 라운드당 각 Submission Queue에서 처리할 다수의 후보 command를 선택할 수 있다.
비휘발성 메모리를 효율적으로 사용하기 위해 Submission Queue에서 여러 command를 병렬로 실행하는 것이 유리하다.
- 따라서 command Arbitration 필요
Round Robin Command Arbitration은 모두 동등한 우선순위로 SQ 처리 !
4.13.2 Weighted Round Robin with Urgent Priority Class Arbitration
이 중재 메커니즘에는 3개의 Urgent Priority Class와 3개의 가중치가 부여된 라운드 로빈 우선순위 레벨이 있다. SQ A가 SQ B보다 엄격한 우선순위가 높은 경우, SQ A의 모든 후보 command은 SQ B의 후보 command가 처리를 시작하기 전에 처리를 시작해야 한다.
가장 높은 엄격한 우선 순위 클래스는 Admin Submission Queue에 제출된 command을 포함하는 Admin Class이다. 이 클래스는 다른 Submission Queue에 제출된 command보다 가장 높은 엄격한 우선 순위를 가진다.
다음으로 엄격한 우선 순위가 높은 클래스는 urgent Class이다. urgent priority 클래스에 할당된 모든 I/O Submission Queue는 Admin Submission Queue 다음으로, 가중치가 부여된 라운드 로빈 우선 순위 수준으로 command가 전송되기 전에 서비스된다. Host SW는 urgent와 Non urgent I/O Submission Queue 간에 공정성 프로토콜이 없으므로 가중치가 부여된 라운드 로빈 우선 순위 수준에서 I/O Submission Queue를 굶길 가능성이 있으므로 urgent priority 클래스에 Submission Queue를 할당할 때 주의해야한다.
가장 낮은 엄격한 우선 순위 클래스는 Weighted Round Robin Class이다. 이 Class는 Weighted Round Robin 중재를 사용하여 남은 대역폭을 공유하는 3가지 가중치 라운드 로빈 우선 순위 레벨(High, Medium, Low)로 구성된다.
Host SW는 Set Features 명령을 통해 High, Medium, Low 서비스 클래스의 가중치를 제어한다. 라운드 로빈은 동일한 가중치 라운드 로빈 레벨에 할당된 여러 SQ내에서 중재하는 데 사용된다. 라운드당 각 SQ에서 처리를 시작할 수 있는 후보 command 수는 Arbitration Burst 설정 또는 나머지 WRR credit 중 작은 값이다.
그림 140에서 Priority decision point는 처리를 시작할 때 다음으로 선택된 가장 높은 우선순위 후보 command를 선택한다.
비휘발성 메모리를 효율적으로 사용하기 위해 Submission Queue에서 여러 command를 병렬로 실행하는 것이 유리하다.
따라서 command Arbitration 필요
4.13 Vendor Specific Arbitration
Vendor는 vendor 고유의 중재 메커니즘을 구현하도록 선택할 수 있다. 그 메커니즘은 본 명세서의 범위 밖에 있다.
