'Storage'에 해당되는 글 1건

  1. 2013.09.05 NVM Express 1.1 - INSTRODUCTION 1
2013. 9. 5. 22:57

NVM Express 1.1 - INSTRODUCTION

NVM Express 1.1에 스펙 리뷰를 진행하도록 하겠습니다.

 

1.1 Overview
NVM Express (NVMe) is a register level interface that allows host software to communicate with a non-volatile memory subsystem. This interface is optimized for Enterprise and Client solid state drives, typically attached to the PCI Express interface.

 

위에서 설명된 정의처럼, NVM Express(이하 NVMe)는 Non-volatile memory subsystem 즉, SSD와 같은 저장 장치와 호스트 소프트웨어(일반적으로 디바이스 드라이버를 의미)간에 통신하는 레지스터 레벨의 인터페이스라고 정의하고 있습니다. 좀더 요약하면 호스트와 디바이스간에 통신하는 방법에 대해 기술한 스팩이라고 할 수 있습니다.

 

 

 

NVMe 스펙 1.0은 2011년 3월 1에 처음 릴리즈되었으며, PCI Express bus 기반의 SSD를 타깃으하고 있습니다. SSD는 PCI Express bus에 이미 개발되었지만, 시장에서는 여전히 비표준 스펙의 인터페이스를 사용중이었습니다. 그래서 SSD 인터페이스의 표준화를 위해, 모든 제조사의 SSD와 통신할 수 있는 호스트 디바이스 드라이버가 필요하였지요. 또한 과거도 그렇고 현재까지 대부분 SSD는 SATA와  같은 버스 인터페이스를 사용하고 있습니다. SATA는 퍼스널 컴퓨터에서 SSD를 연결하는 가장 일반적인 방법이지만, 당시 SATA는 SSD와 비교해 상대적으로 저속의 Hard Disk를 위해 디자인되었습니다. SSD의 성능은 점점 개선되고 현재에 와서 병렬적으로 더 많은 처리량을 필요로 하고 있지만 근본적으로 SATA가 가진 인터페이스 디자인의 한계로 인해, 최대 처리량이 제한되는 한계점에 도달하였습니다.

이것이 바로 PCIe bus를 기반으로 하는 NVMe가 출현하게 된 배경이라고 할 수 있습니다.

 

 

1.4 Theory of Operation
NVM Express is a scalable host controller interface designed to address the needs of Enterprise and Client systems that utilize PCI Express based solid state drives. The interface provides optimized command submission and completion paths. It includes support for parallel operation by supporting up to 64K I/O Queues with up to 64K commands per I/O Queue. Additionally, support has been added for many Enterprise capabilities like end-to-end data protection (compatible with T10 DIF and SNIA DIX standards), enhanced error reporting, and virtualization.

 

NVMe의 두드러지는 특징 중 하나는 커맨드를 처리하기 위한 SUBMISSION QUEUE와 처리가 완료된 커맨드 정보를 저장하기 위한 COMPLEITION QUEUE가지고 MULTIPLE OUTSTANDING 방식으로 커맨드를 보내고 완료합니다. (Multiple Outstanding : 커맨드가 처리될 때까지 기다리지 않고 계속적으로 커맨드를 QUEUE에 넣는 방식)

 

그리고 각 큐의 최대 엔트리는 64K개까지 가질 수 있으며, 큐 역시 Submission, Completion 각각 64K개를 생성할 수 있습니다. 요약해서 대량의 커맨드를 보내고 처리할 수 있는 구조를 가졌지요.

 

아래의 NVMe의 핵심적인 속성을 설명하기 앞서, 기존의 인터페이스 아키텍쳐인 SATA 기반의 AHCI와비교해서 설명하도록 하겠습니다. 항상 새로운 아키텍쳐가 나오면 기존의 아키텍쳐와 비교해 어떤 장점이 있는지 살펴보는 자세는 매우 중요합니다. 그래야 최신 아키텍쳐를 보다 더 잘 이해할 수가 있거든요.

 

NVMe vs. AHCI

(테이블 출처 : http://www.extremetech.com/computing/161735-samsung-debuts-monster-1-6tb-ssd-with-new-high-speed-pcie-nvme-protocol)

 

 

1) Un-cacheable register access

 - 6 times or 9 times per command on AHCI vs. 2 times per command on NVMe

 

   AHCI의 경우, HBA(Host Bus Adapter)를 중심으로 Host와 Device간의 인터페이스를 하도록 디자인되어 있습니다. HBA는 PxCI, PxSA, PxCLB, PxCLB와 같이 커맨드를 처리하는 과정중에 순차적으로 확인하고 세팅하는 레지스터를 가지고 있습니다. 그래서 AHCI에서는 커맨드 하나를 이슈하고 완료하기위해 non-queued command는 6번, queued command는 9번의 HBA 레지스터 접근이 필요합니다. 만약 Command List에서 최초 32개 command가 모두 queued command라고 가정하면, 커맨드를 이슈하고 처리하는 데에 32 * 9의 오버헤드가 보여질 수 있다는 것을 의미합니다. 하지만 HDD의 속도는 매우 느리기 때문에 최초 32개의 command를 모두 큐잉하는 과정 중에 잠시 보였다가 이후부터는 HDD Seek Time Latency로 가려질 것입니다. 더구나 Sequential Read/Write에서는 위에서 언급한 오버헤드는 의미가 없다고 봐도 무방하지요. 다시 요약하면 느린 HDD의 성능을 고려하면 위의 오버헤드는 전혀 고려 대상이 아니었을 겁니다. HDD와 달리, NVMe는 고성능 Server향 SSD를 타깃으로 한 스펙입니다. Server향 SSD의 핵심적인 키워드는 응답 속도와 Random Read/Write의 성능인데, 기존의 AHCI와 같은 아키텍쳐로 충분한 Throuhput을 가질 수 있을까요? NVMe는 하나의 Queue가 가질 수 있는 최대 엔트리 갯수는 64K개, 그리고 그런 사이즈의 Queue를 64K개만큼 스펙상 이론적으로 생성 가능합니다. 위에서 언급한 레지스터 접근에 대해 다시 한 번 더 상기하면, AHCI는 커맨드 하나를 이슈하고 처리하는 데에 9번의 레지스터 접근(NCQ Command의 경우)을 해야한다고 언급하였습니다. 그에 반해 NVMe는 단 2번의 레지스터 접근으로 이슈하고 처리할 수 있지요. 즉, AHCI가 Command를 1번 이슈하고 처리할 동안 NVMe는 4번할 수 있다는 의미가 됩니다. 만약에 HBA를 기반으로 한 AHCI 아키텍쳐로 대량의 64K개의 큐 엔트리를 가지는 64K개의 큐에 커맨드를 이슈하고 처리한다면 64K * 64K * 4의 엄청난 버든이 발생할 수 밖에 없습니다. 그리고 클라이언트로부터 Random Read/Write가 아주 빈번하게 발생하는 상황이라면 매번 연산할 때마다 레이턴시가 보이기 때문에 고성능 SSD임에도 불구하고 처리량은 매우 제한적인 결과를 초래할 수 밖에 없게 되겠지요. 그래서 NVMe에서는 복잡한 레지스터 접근을 최소화하기 위해 HBA를 사용하지 않고 호스트 컨트롤러와 디바이스 컨트롤러가 직접 인터페이스하도록 설계를 하였습니다.

 

 

2) Command Queue

 - One command list and 32 commands per queue on AHCI vs.

   64K Cmd / 64K Queues on NVMe

 

NVMe에서는 이슈할 커맨드를 저장하는 SQ(Submission Queue)와 완료한 커맨드 정보를 저장하는 CQ(Completion Queue)로 나누어서 Command 처리를 합니다. 여기서 의문을 가져야 할 점이 있습니다. AHCI처럼 하나의 Command List로 커맨드를 이슈하고 완료하는 것을 각 32개의 Command Slot 마다 PxCI 레지스터로 확인할 수 있는데 굳이 SQ와 CQ로 나누어서 커맨드를 처리하려는 이유에 대해서 말입니다.

 

[AHCI Command List에서 command 처리/완료 확인 방식]

 

(위의 그림은 단지 AHCI Command List의 Command 처리/완료를 단일 큐에서 이루어지는 것을 설명하기 위해 간단히 도식화한 점을 유의하시기 바랍니다)

 

이유는 간단합니다. AHCI에서는 Command를 전달하고 처리할 때 HBA의 DMA가 그 역할을 담당하지만 NVMe는 디바이스쪽의 컨트롤러가 호스트의 Command를 패치해 옵니다. 이렇게 전혀 다른 방식으로 구동하는데 바로 HBA의 DMA가 버든이 적지 않을 거라는 예상이 가능합니다. 매번 32개의 Command Slot을 폴링 방식으로 확인하고 커맨드를 처리해야 할 의무가 있기 때문입니다. 만약에 Queue Entry가 64K개이고 Queue의 갯수가 64K개라는 Worst Case를 가정하면 엄청난 버든이 될 수 밖에 없겠지요. 따라서 NVMe에서는 처리할 커맨드를 SQ에다가 올려두면 디바이스쪽의 컨트롤러가 이를 패치하고 처리한 후에 완료했다는 정보만 호스트에게 알려주는 쉬운 자료구조로 디자인하였습니다.


The interface has the following key attributes:
 Does not require uncacheable / MMIO register reads in the command submission or

   completion path.
 A maximum of one MMIO register write is necessary in the command submission path.
 Support for up to 64K I/O queues, with each I/O queue supporting up to 64K commands.
 Priority associated with each I/O queue with well-defined arbitration mechanism.
 All information to complete a 4KB read request is included in the 64B command itself,

    ensuring efficient small I/O operation.
 Efficient and streamlined command set.
 Support for MSI/MSI-X and interrupt aggregation.
 Support for multiple namespaces.
 Efficient support for I/O virtualization architectures like SR-IOV.
 Robust error reporting and management capabilities.
 Support for multi-path I/O and namespace sharing.

 

 

일단 오늘은 여기까지 마무리하고 내일 다시 AHCI와 NVMe를 계속 비교하여 설명드리도록 하겠습니다.

 

 

Written by Simhyeon, Choe