[SPDK] An Overview of SPDK Applications

SPDK는 기본적으로 다른 애플리케이션에서 편하게 사용할 수 있도록 라이브러리와 헤더파일들을 제공하는 개발 키트의 역할을 한다. 라이브러리 외에도 기본적으로 SPDK가 제공하는 애플리케이션이 있는데 일부는 라이브러리를 테스트하기 위해서 사용되며, 많은 경우에는 완전히 제기능을 수행하는 고품질의 애플리케이션이 포함되어 있다. SPDK가 제공하는 애플리케이션들 중 주요 애플리케이션은 다음과 같다.

• iSCSI Target
• NVMe over Fabrics Target
• vhost Target
• SPDK Target (위의 3가지를 모두 제공하는 앱)

이외에도 여러가지 툴들과 함께 examples 디렉토리에 있는 여러가지 예제도 함께 제공한다.

위의 모든 SPDK target 들은 공통적인 프레임워크를 기반으로 구현이 되었기 때문에 여러가지 측명에서 유사성을 갖는다. 공통 프레임워크는 subsystem 이라는 컨셉을 정의하고 모든 기능을 자기가 원하는 subsystem에 구현한다. 모든 subsystem 은 같은 방식으로 초기화 되며 같은 teardown path 를 갖는다.

Configuring SPDK Applications

Command Line Parameters

SPDK가 기본으로 제공하는 애플리케이션들은 공통적인 커맨드 라인 옵션을 사용한다. 애플리케이션에 따라서는 공통 옵션 외에 필요한 다른 옵션을 추가적으로 사용하는 경우도 있다. 아래는 공통 옵션 목록이다.

Base Command Line Parameters

Configuration file

SPDK의 초기부터 현재까지 configuration file을 통한 초기화 및 설정을 지원하고 있다. 이후에는 JSON RPC를 통한 초기화로 변경될 예정이므로 JSON-RPC Methods를 숙지하고 있도록 하자.

--config 옵션과 --wait-for-rpc 는 둘 다 초기화에 사용되는 옵션이므로 함께 사용할 수 없다.

Limit coredump

SPDK는 기본적으로 코어 파일에 대한 파일 사이즈 제한을 RLIM_INFINITY 로 설정한다. --limit-coredump 를 사용할 경우 해당 제한을 제거한다.

Tracepoint group mask

SPDK가 제공하는 low overhead tracing framework는 각각의 tracepoint 들을 tracepoint group 들로 묵어서 추적한다. --tpoint-group-mask 를 사용할 경우 원하는 그룹에 속한 tracepoint 들에 대해서만 추적을 할 수 있다. 자세한 문서는 현재 작성중에 있다.

Deferred initialization

SPDK 애플리케이션들은 STARTUP 상태로 시작하고 RUNTIME 상태로 초기화를 마치게 된다. --wait-for-rpc 옵션을 사용하게 되면 초기화 진행 이전인 STARTUP 상태에서 중지하고 JSON RPC 서버를 구동한다. Client에서 SPDK subsystem에 대한 설정을 완료하고 나면 framework_start_init RPC 커맨드를 JSON RPC 서버에 보내고, 이를 통해 초기화를 시작하게 된다. 초기화가 정상적으로 수행되고 true 를 반환한 경우 RUNTIME 상태로 진행하고 다양한 커맨드를 사용할 수 있게 된다.

어떤 rpc 를 사용할 수 있는지 확인하기 위해서는 rpc_get_methods 를 current : true 를 인자로 사용하고 호출 하면 된다. 자세한 내용은 [JSON-RPC Methods 문서를](https://spdk.io/doc/jsonrpc.html) 참고하길 바란다.

Create just one hugetlbfs file

--single-file-segments 옵션을 사용할 경우 페이지 하나당 hugetlbfs 파일을 생성하지 않고, 소켓 하나당 hugetlbfs 파일을 생성한다. 8개 이상의 hugepage를 사용하는 Virtio driver 사용을 위해 필요하며 자세한 내용은 2MB hugepages 문서를 참고하자.

Multi process mode

--shm-id 옵션을 사용할 경우 멀티 프로세스 모드로 동작한다. 같은 shm-id 를 사용하는 애플리케이션 끼리 같은 메모리와 같은 NVMe 장치를 공유한다. 가장 먼저 시작한 프로세스가 primary 프로세스가 되고 이후에 실행된 앱들은 secondary process로 단순히 primary 에 attach 되어 동작하게 된다. primary 앱이 종료하는 경우 secondary 들은 계속해서 작업을 수행할 수 있으나, 새로운 secondary를 attach 할 수는 없게 된다. 같은 shm-id를 사용하고 싶은 경우 모두 같은 [--single-file-segments](https://www.notion.so/wurikiji/An-Overview-of-SPDK-Applications-578589df63134054bbe39e7b73f8aceb#0769617957fd43e482896203258fa6f7) 세팅을 해야 함을 명심하자.

Memory size

--mem-size사용하고자 하는 hugepage 메모리 크기를 지정한다. DPDK env를 사용할 경우에는 hugetlbfs의 전체 공간을 모두 사용하고 페이지 사이즈는 가장 큰 페이지 사이즈를 사용한다. 기본 단위는 megabyte 단위 이며 1024, 1024M, 1G 등의 크기를 옵션으로 줄 수 있다.

DPDK 18.05.1 부터는 런타임시에 크기를 조정할 수 있게 되었다.

Disable PCI access

NVMe와 IOAT를 포함한 PCI 장치를 사용하지 않도록 한다. VFIO 와 UIO 등의 커널 모듈의 사용도 필요하지 않게 된다.

PCI address blacklist and whitelist

blacklist 옵션이 사용될 경우 해당 PCI 장치를 무시한다. whitelist 옵션이 사용된 경우 해당 장치만을 사용한다. -B 와 -W 옵션 모두 한번 이상 중첩해서 사용할 수 있으나 동시에 둘 모두를 사용할 수는 없다.

Unlink hugepage files after initialization

DPDK를 기반으로 한 env의 경우 초기화 과정에서 orphaned hugetlbfs 파일들을 모두 제거한다. --huge-unlink를 사용할 경우 hugetlbfs 파일이 생성되는 즉시 삭제한다. --shm-id 옵션과 함께 사용할 수는 없다.

Debug log

--logflag 를 통해 출력하고자 하는 디버그 로그 타입을 정할 수 있다. 한번 이상 중첩해서 사용할 수 있으며, --help 를 통해 지원하는 모든 디버그 로그 타입을 확인할 수 있다. --logflag all 을 사용할 경우 모든 로그를 출력한다. 다만, SPDK를 debug 모드로 빌드 했을 시에만 동작한다.

CPU mask

--cpumask 는 아래와 같은 포맷을 통해 사용할 수 있다.

• 대소문자 구분하지 않는 16진수 문자열 앞에 0x를 붙여도 되고 붙이지 않아도 된다.
• , 로 구분한 CPU 리스트 혹은 - 를 통해 지정된 cpu range

아래는 옵션 뒤에 올 수 있는 cpu 리스트 예제이다. 모두 다 0,1,2,8,9,10,12 번 CPU를 사용하는 옵션이다.

0x1f07
0x1F07
1f07
[0,1,2,8-12]
[0,1,2,8,9,10,11,12]