KR20220071858A - 네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체 - Google Patents

네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체 Download PDF

Info

Publication number
KR20220071858A
KR20220071858A KR1020210058761A KR20210058761A KR20220071858A KR 20220071858 A KR20220071858 A KR 20220071858A KR 1020210058761 A KR1020210058761 A KR 1020210058761A KR 20210058761 A KR20210058761 A KR 20210058761A KR 20220071858 A KR20220071858 A KR 20220071858A
Authority
KR
South Korea
Prior art keywords
nic
cpu
data
tcp
command
Prior art date
Application number
KR1020210058761A
Other languages
English (en)
Other versions
KR102479757B1 (ko
Inventor
박경수
데온드레 마틴 탄 응
Original Assignee
한국과학기술원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국과학기술원 filed Critical 한국과학기술원
Publication of KR20220071858A publication Critical patent/KR20220071858A/ko
Application granted granted Critical
Publication of KR102479757B1 publication Critical patent/KR102479757B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/38—Universal adapter
    • G06F2213/3808—Network interface controller

Abstract

본 발명에 따른 파일 입출력 연산 오프로딩 방법은, 파일 기반 컨텐트 전송 서버의 CPU(Central Processing Unit) 및 연산 기능을 갖는 NIC(Network Interface Card)에서의 네트워크 및 파일 입출력 연산 오프로딩 방법으로, 상기 CPU가, 데이터 플레인(data plane) 연산을 상기 NIC에 오프로드하는 오프로드 단계; 및 상기 NIC가 상기 데이터 플레인 연산을 수행하고, 상기 CPU는 오프로드된 상기 데이터 플레인 연산을 제외한 컨트롤 플레인(control plane) 연산을 수행하는 수행 단계;를 포함하고, 상기 데이터 플레인 연산은 컨텐츠 가져오기, 데이터 버퍼 관리, 데이터 패킷 분할, TCP/IP 체크섬 계산, 데이터 패킷 생성 및 전송 중 적어도 하나의 연산 포함하며, 상기 컨트롤 플레인 연산은 TCP 프로토콜의 연결 관리, 데이터 전송의 안정성 관리, 데이터 전송의 혼잡 관리, 흐름 제어 및 에러 제어 중 적어도 하나의 연산을 포함한다.

Description

네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체{OFFLOADING METHOD AND SYSTEM OF NETWORK AND FILE I/O OPERATION, AND A COMPUTER-READABLE RECORDING MEDIUM}
본 발명은 파일 기반 컨텐트 전송 서버의 병목인 파일 I/O와 네트워크 I/O를 CPU에서 오프로딩하고, 연산 기능이 있는 보조디바이스(예: SmartNIC)에서 수행하게 함으로써 단위 CPU 용량당 컨텐트 전송 성능을 크게 향상시킬 수 있는 네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체에 관한 것이다.
최근 고대역폭 I/O 기기의 발전은 고품질 온라인 컨텐츠의 빠른 전송을 약속한다. 하지만, 불행하게도 오늘날의 프로그래밍 모델은 여전히 CPU 중심 접근방식에 얽매여 있는데, 이 접근방식은 병목현상이 현대 I/O 장치의 진정한 잠재력을 심각하게 제한하는 맹점이 있다. CPU 주기의 85% 이상이 온라인 컨텐츠 전송시 디스크 및 네트워크 I/O 연산과 같은 단순하지만 반복적인 연산에 사용된다.
한편, 최근의 컴퓨팅 하드웨어 추세는 I/O 장치 용량의 발전이 CPU 용량의 성장을 실질적으로 앞질렀다. 지난 20년간 네트워크 인터페이스 카드(Network Interface Card; NIC)의 대역폭과 디스크 I/O 속도가 2∼4배 정도 향상되었다. 이와 반대로, CPU 용량의 향상 속도는 느려졌고 프로세서에 대한 무어의 법칙이 10여 년 전에 끝났다는 것이 널리 받아들여지고 있다. 이러한 경향은 현대 운영체제의 기반이 되는 CPU 중심의 프로그래밍 모델을 재고할 것을 요구한다. 현재의 OS API는 CPU에 직접 연결된 메인 메모리로 I/O 장치의 모든 데이터를 가져와야 연산을 수행할 수 있다. 이러한 이유로 비디오 컨텐츠 전송 서버 같은 경우 CPU는 전체 주기의 85% 이상이 간단한 I/O 연산(패스트 디스크의 컨텐츠를 읽고 고대역폭 NIC를 통해 전송)에 사용되므로 비디오 컨텐츠 제공과 같은 I/O 집약적인 애플리케이션의 성능 병목 현상이 빈번히 발생한다. I/O 장치의 현대적 혁신을 효과적으로 활용하기 위해 현재의 프로그램 구조는 I/O 연산을 수행하기 위한 CPU와 그 메모리 시스템에 대한 의존성을 완화해야 한다.
다행히 최근 SmartNIC 또는 Computational SSD와 같은 프로그래밍 가능한 I/O 기기가 출현하여 CPU의 개입 없이 CPU의 계산 부담을 줄이는 데 도움을 주고 있다. PCI-e 표준은 CPU의 개입없이 두 PCI-e 장치간에 P2PDMA(Peer-to-Peer DMA)를 허용하므로, NIC가 CPU에서 디스크 I/O 연산을 완전히 오프로드하는 서버 시스템을 생각할 수 있다. 실제로 DCS 및 DCS-Ctrl과 같은 최근 작업은 FPGA 기반 코디네이터가 비디오 전송 서버용 P2PDMA를 통해 모든 디스크 I/O 연산을 수행할 수 있음을 보여주고 있다. 하지만, 안타깝게도 이러한 시스템의 주요 단점은 컨텐츠 전송이 오늘날의 비디오 스트리밍에서 일반적으로 채택되는 TCP 기반 전송과 달리 UDP와 유사한 프로토콜에서 실행된다는 것이다. 그러나 I/O 오프로드 서버에서 TCP를 지원하기 위해서는 TCP 기능을 어디에 배치해야 하는지에 대한 "기능 배치" 문제가 발생한다. 즉, 모든 디스크 I/O가 프로그래밍 가능한 NIC에서 수행된다면, TCP 스택을 어디에서 실행해야 하는지 의문이 생긴다. 한 가지 접근방식은 CPU 쪽에서 실행하는 것이지만, 디스크 컨텐츠가 NIC에서만 사용 가능하기 때문에 데이터 패킷에 대한 "데이터 누락"이라는 문제가 발생한다. 데이터를 CPU 쪽으로 다시 이동하면 오프로드된 디스크 I/O의 이점이 무효화되는 문제점이 생긴다.
또 다른 접근 방식은 NIC 쪽에서 TCP 스택을 실행하는 것이다. FPGA 보드에 전체 TCP 스택을 구현하는 것이 쉽지는 않지만, SmartNIC에서는 실행이 가능하다. 실제로 최신 SmartNIC 플랫폼은 전체 TCP 스택으로 Linux에서 실행되는 Arm 기반 임베디드 프로세서를 지원한다. 그러나, NIC에서 전체 TCP 스택을 실행하려면 해당 애플리케이션이 제한된 리소스로 동일한 플랫폼에서 공동 실행되어야 한다는 문제점이 있다.
본 발명은 상술한 문제점을 감안하여 안출된 것으로, 본 발명은 컨텐츠 전송 서버의 병목 부분인 파일 I/O와 네트워크 I/O를 CPU에서 오프로딩하여, CPU는 복잡하지만 빠르게 수행해야 하는 컨트롤 플레인(control plane) 연산만 수행하고, 단순하지만 반복적이고 기계적인 데이터 플레인(data plane) 연산은 주변기기(SmartNIC 등)에서 수행하되 TCP protocol과 완벽 호환될 수 있는 네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체를 제공함에 있다.
상기 목적을 달성하기 위한, 본 발명에 따른 파일 입출력 연산 오프로딩 방법은, 파일 기반 컨텐트 전송 서버의 CPU(Central Processing Unit) 및 연산 기능을 갖는 NIC(Network Interface Card)에서의 네트워크 및 파일 입출력 연산 오프로딩 방법으로, 상기 CPU가, 데이터 플레인(data plane) 연산을 상기 NIC에 오프로드(offload)하는 오프로드 단계; 및 상기 NIC가 상기 데이터 플레인 연산을 수행하고, 상기 CPU는 오프로드된 상기 데이터 플레인 연산을 제외한 컨트롤 플레인(control plane) 연산을 수행하는 수행 단계;를 포함하고, 상기 데이터 플레인 연산은 컨텐츠 가져오기, 데이터 버퍼 관리, 데이터 패킷 분할, TCP/IP 체크섬 계산, 데이터 패킷 생성 및 전송 중 적어도 하나의 연산을 포함하며, 상기 컨트롤 플레인 연산은 TCP 프로토콜의 연결 관리, 데이터 전송의 안정성 관리, 데이터 전송의 혼잡 관리, 흐름 제어 및 에러 제어 중 적어도 하나의 연산을 포함한다.
상기 오프로드 단계는, 상기 CPU가 응용 프로그램으로부터 수신한 "offload_open()" 명령을 상기 NIC에 전달하는 단계; 상기 NIC가 NIC 스택에 파일을 열고 결과를 상기 CPU에 회신하는 단계; 및 상기 CPU가 상기 응용 프로그램으로부터 호출된 "offload_write()" 명령을 NIC에 전달하는 단계;를 포함할 수 있다.
상기 CPU의 호스트 스택에서 실제 데이터가 누락된 경우 상기 CPU는 가상으로 상기 데이터 플레인 연산을 수행하는 가상 연산 단계;를 포함할 수 있다.
상기 가상 연산 단계는, 상기 CPU는, 상기 응용 프로그램이 "offload_write()" 명령을 호출한 경우, 메타 데이터만 업데이트하여 전송 버퍼에 가상 기입하는 단계; 및 상기 CPU가 데이터의 정체 및 흐름 제어 매개 변수와 함께 전송해야 하는 바이트 수를 결정한 뒤 "SEND" 명령을 상기 NIC의 NIC 스택에 게시하는 단계;를 포함할 수 있다.
상기 CPU는 TCP 패킷을 활용하여 상기 "SEND" 명령을 전달하고, 상기 TCP 패킷은 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이(length) 정보 중 적어도 하나의 정보를 포함할 수 있다.
상기 "SEND" 명령을 수신한 상기 NIC는, TCP 패킷에 포함된 길이(length) 정보에 기초하여 복수의 TCP 패킷으로 변환하여 전송할 수 있다.
상기 클라이언트는 상기 "SEND" 명령에 대한 데이터 패킷을 전송하려고 할 때 에코 패킷을 상기 CPU로 전송하며, 상기 CPU는 상기 에코 패킷을 수신할 때까지 재전송 타이머의 전송을 소정 시간동안 수행하지 않을 수 있다.
상기 소정 시간은 상기 NIC에서의 패킷처리 지연시간과 상기 에코 패킷의 단방향 처리시간에 의해 결정될 수 있다.
상기 NIC에서의 패킷처리 지연시간은 상기 "SEND" 명령이 상기 NIC에 도착한 뒤 "SEND" 명령에 대한 데이터 패킷이 상기 클라이언트로 출발하는 사이의 지연시간일 수 있다.
상기 CPU는 IO-TCP 응용 프로그램의 파일을 열 때 사용하는 "OPEN" 명령, 파일 내용을 클라이언트로 보낼 때 사용하는 "SEND" 명령, 재전송의 효율적 처리를 위한 "ACKD" 명령 및 IO-TCP 응용 프로그램의 파일을 닫을 때 사용하는 "CLOS" 명령을 정의할 수 있다.
상기 CPU는 "SEND" 명령만을 상기 NIC로 오프로드하고, 클라이언트로부터 수신되는 패킷은 직접 처리할 수 있다.
상기 CPU는 오프로드된 시퀀스 공간 범위에 대한 ACK를 확인하면, 상기 NIC에 주기적으로 상기 "ACKD" 패킷을 전달할 수 있다.
한편, 상기 목적을 달성하기 위한 연산 오프로딩 시스템은, 파일 기반 컨텐트 전송 서버의 CPU(Central Processing Unit) 및 연산 기능을 갖는 NIC(Network Interface Card)을 포함하는 네트워크 및 파일 입출력 연산 오프로딩 시스템으로, 상기 CPU는 데이터 플레인(data plane) 연산을 상기 NIC에 오프로드(offload)하고, 상기 NIC는 상기 데이터 플레인 연산을 수행하고, 상기 CPU는 오프로드된 상기 데이터 플레인 연산을 제외한 컨트롤 플레인(control plane) 연산을 수행하되, 상기 데이터 플레인 연산은 컨텐츠 가져오기, 데이터 버퍼 관리, 데이터 패킷 분할, TCP/IP 체크섬 계산, 데이터 패킷 생성 및 전송 중 적어도 하나의 연산을 포함하며, 상기 컨트롤 플레인 연산은 TCP 프로토콜의 연결 관리, 데이터 전송의 안정성 관리, 데이터 전송의 혼잡 관리, 흐름 제어 및 에러 제어 중 적어도 하나의 연산을 포함한다.
상기 CPU는 응용 프로그램으로부터 수신한 "offload_open()" 명령을 상기 NIC에 전달하면, 상기 NIC가 NIC 스택에 파일을 열고 결과를 상기 CPU에 회신하며, 상기 CPU는 상기 응용 프로그램으로부터 호출된 "offload_write()" 명령을 NIC에 전달할 수 있다.
상기 CPU의 호스트 스택에서 실제 데이터가 누락된 경우 상기 CPU는 가상으로 상기 데이터 플레인 연산을 수행할 수 있다.
상기 CPU는, 상기 응용 프로그램이 "offload_write()" 명령을 호출한 경우, 메타 데이터만 업데이트하여 전송 버퍼에 가상 기입하고, 데이터의 정체 및 흐름 제어 매개 변수와 함께 전송해야 하는 바이트 수를 결정한 뒤 "SEND" 명령을 상기 NIC의 NIC 스택에 게시할 수 있다.
상기 CPU는 TCP 패킷을 활용하여 상기 "SEND" 명령을 전달하고, 상기 TCP 패킷은 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이(length) 정보 중 적어도 하나의 정보를 포함하며, 상기 "SEND" 명령을 수신한 상기 NIC는, TCP 패킷에 포함된 길이(length) 정보에 기초하여 복수의 TCP 패킷으로 변환하여 전송할 수 있다.
상기 클라이언트는 상기 "SEND" 명령에 대한 데이터 패킷을 전송하려고 할 때 에코 패킷을 상기 CPU로 전송하며, 상기 CPU는 상기 에코 패킷을 수신할 때까지 재전송 타이머의 전송을 소정 시간동안 수행하지 않고, 상기 소정 시간은 상기 NIC에서의 패킷처리 지연시간과 상기 에코 패킷의 단방향 처리시간에 의해 결정되며, 상기 NIC에서의 패킷처리 지연시간은 상기 "SEND" 명령이 상기 NIC에 도착한 뒤 "SEND" 명령에 대한 데이터 패킷이 상기 클라이언트로 출발하는 사이의 지연시간일 수 있다.
상기 CPU는 IO-TCP 응용 프로그램의 파일을 열 때 사용하는 "OPEN" 명령, 파일 내용을 클라이언트로 보낼 때 사용하는 "SEND" 명령, 재전송의 효율적 처리를 위한 "ACKD" 명령 및 IO-TCP 응용 프로그램의 파일을 닫을 때 사용하는 "CLOS" 명령을 정의하고, 상기 CPU는 "SEND" 명령만을 상기 NIC로 오프로드하고, 클라이언트로부터 수신되는 패킷은 직접 처리하며, 상기 CPU는 오프로드된 시퀀스 공간 범위에 대한 ACK를 확인하면, 상기 NIC에 주기적으로 상기 "ACKD" 패킷을 전달할 수 있다.
한편, 본 발명에 따른 컴퓨터 판독 가능 기록매체는 상술한 연산 오프로딩 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록할 수 있다.
본 발명에 의하면, P2P DMA를 활용한 디스크 액세스 오프로딩(disk access offloading)을 하고, CPU쪽에서 TCP operation을 컨트롤하면서 완벽히 TCP protocol을 지원하는 네트워크 스택을 설계할 수 있다. 또한, 종래에는 FPGA 기기로 P2P DMA를 구현하여 NVMe disk를 CPU 개입없이 직접 액세스하였으나 TCP protocol을 지원하지 않았다. 따라서, 현대 비디오 스트리밍 서비스가 대부분 TCP기반인 점을 고려할때 종래 기술은 상용화 가능성이 떨어질 수밖에 없었다. 반면 본 발명은 TCP protocol을 지원하여 비디오 서비스에 바로 적용될 수 있다는 장점이 있다.
도 1은 IO-TCP 스택의 아키텍처 개요를 보여준다.
도 2는 널리 사용되는 디스크 벤치 마크 도구인 fio로 측정한 단일 CPU 코어의 NVMe 디스크 사용률을 보여준다
도 3은 웹 서버의 성능 비교에 있어서 단일 CPU 코어의 결과를 보여준다.
도 4는 플랫폼에 사용하는 Mellanox Blue-Field NIC의 아키텍처를 보여준다.
도 5는 HTTP 서버 컨텍스트에서 API 함수를 사용하는 작업의 하위 집합을 보여준다.
도 6은 "SEND" 명령 패킷이 처리되는 방법을 도시준다.
도 7은 호스트와 NIC 스택 사이의 통신을 위한 이더넷(Eithernet)의 라운드 트립 타임(Round-trip time)을 도시한다.
도 8은 대용량 파일 컨텐츠 전달에서 IO-TCP의 효과 평가에 대한 결과를 도시한다.
도 9는 는 호스트 스택이 소비하는 CPU주기의 일부에 대한 처리량(a) 및 Arm 코어수에 따른 단일 SmartNIC의 처리량(b)을 보여준다.
도 10은 실제 데이터 패킷이 전송되는 적시에 재전송 타이머를 시작하는 에코 패킷의 영향(a)과 NIC 스택에서 TCP 타임 스탬프 수정의 영향(b)을 도시한다.
도 11은 동시 통신 연결 개수에 대한 처리량 실험 결과를 도시한다.
도 12는 동시 통신 연결의 다른 개수에 있어서 4KB 파일을 제공하는 처리량을 도시한다.
이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시 예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
이하, 본 발명에 따른 실시예를 첨부된 도면을 참조하여 상세하게 설명하도록 한다.
결론부터 언급하면, 본 발명에서는 I/O 집약적인 애플리케이션을 위한 분할 TCP 스택 설계인 I/O Offloading TCP(IO-TCP)로 위에서 위에서 언급한 문제를 해결했다. IO-TCP의 핵심 아이디어는 P2PDMA를 통해 디스크(예: NVMe 디스크와 같은 PCIe 연결 디스크)에 액세스할 수 있는 SmartNIC에 모든 데이터 플레인 연산(operation)을 위임하면서 CPU에서 컨트롤 플레인(control plane)만 실행하는 것이다. 컨트롤 플레인이란 TCP 프로토콜의 모든 핵심 기능(연결 관리, 데이터 전송 의 안정성 관리, 데이터의 흐름 제어 및 혼잡 관리)을 의미하며 데이터 플레인(data plane)은 NVMe 디스크에서 컨텐츠 가져오기를 포함하여 데이터 패킷 생성 및 전송의 모든 측면을 가리킨다.
본 발명에서는 CPU 측이 여전히 모든 연산을 완전히 제어할 수 있도록 한다. 내부적으로 실제 디스크 및 네트워크 I/O 연산은 SmartNIC로 오프로드된다. 이를 통해 복잡한 제어 연산에서 CPU 주기를 예약하고 단순하지만 반복적인 I/O 연산에서 제외할 수 있다.
IO-TCP는 CPU 주기를 절약할 수 있는 큰 잠재력을 제공하지만 일련의 새로운 과제를 안고 있다. 첫째, 호스트 TCP의 RTT 측정은 디스크로 인한 지연으로 인해 변동된다. IO-TCP에서 NIC의 데이터 패킷 I/O는 디스크에서 패킷 컨텐츠를 가져올 때 디스크 I/O와 결합된다. 그러나, 디스크 I/O는 훨씬 느려질 수 있으며 네트워크 경로에 정체가 없는 경우에도 패킷 전송에 상당한 지연을 추가하는 경우가 많다. IO-TCP는 RTT 측정에서 디스크로 인한 지연을 신중하게 제거하여 이 문제를 해결한다. 호스트 스택이 패킷 출발 시간을 정확하게 추적할 수 있도록 에코 패킷을 사용한다. 둘째, IO-TCP는 패킷 재전송시기에 대한 정보 없이 NIC 스택에서 패킷 재전송을 처리해야 한다. 주의하지 않으면 NIC 스택이 패킷 재전송을 위해 중복 디스크 I/O를 발행할 수 있다. 비효율성을 피하기 위해 IO-TCP는 내부 ACK 프로토콜을 사용하여 데이터 패킷을 버리는 것이 안전한 시기를 알린다. 셋째, IO-TCP는 데이터 전송을 위해 파일 또는 비파일 컨텐츠를 유연하게 구성하기 위해 애플리케이션에 대해 잘 정의된 API를 제공해야 한다. 이를 위해 IO-TCP는 파일을 열고 NIC에서 파일 컨텐츠를 보내는 몇 가지 "오프로드" 기능을 사용하여 버클리 소켓 API를 약간 확장한다.
도 1은 IO-TCP 스택의 아키텍처 개요를 보여준다. P2PDMA로 NVMe 디스크에 직접 액세스할 수 있는 Mellanox BlueField Smart-NIC로 IO-TCP를 구현한다. 호스트 스택의 경우, 기존 사용자 수준 TCP 스택을 확장하여 I/O 오프로딩을 지원하는 동시에 DPDK 라이브러리로 NIC 스택을 구현한다. 호스트 스택의 경우 1,793라인(line)의 코드 수정이 필요하고, NIC 스택의 경우 1,853라인의 C코드가 필요하다. 실제 응용 프로그램의 효과를 평가하기 위해 Lighttpd를 약 10라인의 코드 수정만으로 IO-TCP를 사용하도록 포트한다.
평가 결과, IO-TCP 포트 Lighttpd는 단일 CPU 코어로 44Gbps의 비디오 컨텐츠 전송을 달성한다. 이에 반해, Linux TCP 스택의 원래 Lighttpd가 동일한 성능에 도달하려면 6개의 CPU코어가 필요하다. 현재 병목 현상이 BlueField NIC의 낮은 메모리 대역폭에 있다는 것을 알지만, 향후 버전이 더 나은 성능을 달성할 수 있을 것이다. 발명은 아래와 같은 기술적 의의를 갖는다.
(1) 디스크 I/O에 대한 CPU 병목 현상이 최신 컨텐츠 전송 시스템의 성능에 미치는 영향을 분석
(2)컨텐츠 전달 시스템이 TCP 제어 및 데이터 플레인을 분리하여 SmartNIC의 최근 I/O 발전을 완전히 활용할 수 있도록 하는 새로운 TCP 스택 설계인 IO-TCP의 설계 및 구현을 소개
(3)IO-TCP가 CPU 병목 현상의 한계를 뛰어 넘어 CPU가 정상적으로 수행할 수 있는 것보다 훨씬 더 큰 I/O 대역폭을 달성하는 방법을 제시
I/O 장치 발전과 CPU 용량 사이의 불일치(Mismatch between I/O Device Advances and CPU Capacity)
20년 전에는 가장 빠른 하드 디스크가 초당 약 200 개의 임의 I/O 연산(IOPS)을 달성할 수 있었지만, 최근 NVMe 디스크는 거의 40배 빠른 속도인 1백만 IOPS 이상을 수행할 수 있다. 같은 기간 이더넷 NIC의 대역폭은 200배 이상(1997년 1Gbps에서 2019 년 200Gbps로) 개선되었으며, 800Gbps/1.6Tbps 이더넷은 몇 년 안에 표준화될 것으로 예상하고 있다.
이와는 대조적으로 CPU 용량 향상은 무어의 법칙이 끝나고 Dennard 확장의 붕괴로 인해 크게 방해를 받았다. 최초의 범용 멀티 코어 CPU는 2005년에 등장했지만, CPU당 최대 코어 수는 현재까지 32개로 남아 있다.
도 2는 널리 사용되는 디스크 벤치 마크 도구인 fio로 측정한 단일 CPU 코어의 NVMe 디스크 사용률을 보여준다. CPU에는 Intel Xeon Silver 4210(2.20GHz)을, NVMe 장치에는 Intel Optane 900P를 사용한다. 도 2는 단일 CPU 코어가 단위 블록 크기가 4KB인 NVMe 디스크 2개도 포화시킬 수 없음을 보여준다. 블록 크기가 16KB인 경우에도 단일 코어는 최대 3개의 NVMe 디스크만 병렬로 처리할 수 있다. NVMe 디스크가 일반적으로 4개의 PCIe 레인을 차지하고 최신 서버급 CPU가 40~48개의 PCIe 레인을 지원할 수 있다는 점을 감안할 때, 단일 CPU가 있는 컨텐츠 전송 서버는 고속 NIC외에 최대 8~10개의 NVMe 디스크를 호스팅할 수 있게 된다. CPU와 I/O 장치 간의 성능 차이로 인해 I/O 연산에 대한 현재 OS 추상화를 재검토해야 한다. 기존 OS는 디스크 컨텐츠를 읽고 NIC를 통해 전송하는 등 I/O 연산을 수행하기 위해 CPU 개입이 필요하다. 이는 현재 프로그래밍 모델이 다음 연산을 수행하기 전에 I/O 장치의 내용을 메인 메모리로 이동해야 하므로 메모리 연산이 중단되어 CPU주기가 낭비되기 때문이다.
컨텐츠 전달 시스템 스택의 비효율성(Inefficiencies in Content Delivery System Stacks)
최신 컨텐츠 전송 시스템은 지리적으로 분산된 수 많은 컨텐츠 전송 웹 또는 역방향 프록시 서버로 구성된다. 이러한 시스템은 비디오 스트리밍 및 웹 페이지 액세스와 같은 많은 애플리케이션의 기초가 된다. 이 가운데 비디오 트래픽은 전체 인터넷 트래픽의 약 60%를 차지하며, 최근 폭발적인 수요 증가로 인해 전체 볼륨이 증가했다. 성능을 최적화하기 위해 전통적으로 서버 설계는 하드 디스크 I/O가 훨씬 더 느렸기 때문에 디스크 액세스 및 CPU 사용률 최적화에 초점을 맞춘다. 웹 페이지 컨텐츠와 같은 작은 오브젝트를 가져오기 위해 서버는 인덱싱을 위한 작은 메모리 공간을 유지하면서, 디스크 검색을 최소화하도록 최적화되어 있다. 비디오 다운로드와 같은 대규모 오브젝트 액세스의 경우, 서버는 순차 디스크 읽기를 이용하여 디스크 처리량을 극대화한다. 또한 사용자 프로세스와 커널 간의 빈번한 메모리 복사 및 컨텍스트 전환을 방지하기 위해 일반적으로 sendfile()을 지원한다.
CPU 활용도를 높이기 위해 서버는 일반적으로 이벤트 중심 아키텍처를 채택한다. 기존 디스크 기반 최적화는 검색으로 인한 한계를 없앤 저렴한 대용량 RAM 및 플래시 기반 디스크(예: SSD 및 NVMe 디스크)의 출현으로 인해 대체로 쓸모가 없게 되었다. 주요 디스크 병목 현상이 해결되었으므로 메모리 하위 시스템이 오늘날 서버에서 다음 병목 현상이 된다. 이는 디스크 및 네트워크 I/O뿐만 아니라 암호화 및 암호 해독을 위한 컨텐츠 스캔으로 인한 여러 메모리 복사본으로 인해 악화된다. 최근 작업은 디스크 액세스 계층을 최적화하고 Intel Data Direct I/O(DDIO)를 활용하여 이러한 모든 작업을 CPU 캐시의 데이터로 수행하도록 배열하지만 CPU의 연산 부하를 분산시키지는 않는다. 따라서 워크로드가 CPU 캐시 크기를 초과하면 성능이 메모리 하위 시스템의 성능으로 떨어진다. 웹 기반 컨텐츠 전송의 성능을 이해하기 위해 HTTP 적응형 비디오 스트리밍에 대한 일반적인 설정을 시뮬레이션하는 디스크 바운드 워크로드(disk-bound workload)에 대해 두 개의 인기 웹 서버인 Lighttpd(v1.4.32) 및 nginx(v1.16.1)로 실험을 실행한다. 서버 설정은 5.1 절과 동일하며 100KB, 300KB 및 500KB의 파일 크기를 사용하여 다양한 비디오 품질을 시뮬레이션한다. 1600개의 영구 연결을 사용하고 클라이언트가 병목 현상이 없는지 확인한다.
sendfile() 최적화를 사용하거나 사용하지 않은 웹 서버의 성능을 비교한다. 도 3은 웹 서버의 성능 비교에 있어서 단일 CPU 코어의 결과를 보여준다. 일반적으로 파일 크기가 클수록 성능이 향상되고, sendfile()은 성능이 12%에서 52%까지 향상된다. sendfile()이 없으면 nginx가 더 나은 성능을 보여 주지만 Lighttpd는 sendfile()과 비슷한 성능을 보인다. 단일 NVMe 디스크가 임의 파일 읽기에 대해 약 2.5GB/s(또는 20Gbps)를 달성한다는 점을 감안할 때, 단일 CPU 코어는 300KB 파일이있는 단일 NVMe 디스크 성능의 절반을 약간 넘는다.
[표 1]은 perf로 측정된 함수 호출 수준에서 nginx의 CPU주기 분석을 보여준다.
함수(Function) %CPU
sendfile() 71.59%
open() 14.55%
recv() 1.76%
ngx_http_finalize_request() 3.52%
ngx_http_send_header() 1.17%
others 7.41%
당연히 sendfile() 및 open()은 CPU주기의 대부분을 차지하며, 소비된 주기의 86.1%에 해당한다. 이는 컨텐츠 전달 서버(디스크 및 네트워크I/O)에서 대부분의 CPU주기가 사용되는 위치를 명확하게 보여준다. CPU에서 이러한 연산을 오프로드하면 성능을 향상시킬 수 있는 큰 잠재력이 있다.
SmartNIC를 통한 기회(Opportunities with SmartNIC)
본 발명의 핵심 아이디어는 TCP 기반 컨텐츠 전달을 지원하면서 CPU에서 프로그래밍 가능한 I/O 장치로 데이터 I/O를 오프로드하는 것이다. 이상적으로는 직접 디스크 I/O 및 네트워크 패킷 I/O를 수행할 수 있는 모든 프로그래밍 가능 장치가 그 목적을 달성할 수 있다. 그 구현을 위해 P2PDMA 기능이 있는 최신 SmartNIC 플랫폼을 선택할 수 있고, 본 설계는 FPGA 보드에서도 구현될 수 있을 것이다. Mellanox Blue-Field 및 Broadcom Stingray와 같은 최신 SoC 기반 SmartNIC는 NIC 데이터 처리 장치 위에 Arm 기반 임베디드 시스템을 제공한다. 이러한 시스템은 CPU 또는 메인 메모리의 개입 없이 동일한 도메인의 NVMe 디스크에 대한 직접 액세스를 지원한다. 예를 들어 BlueField NIC는 NVMe-oF(NVMe over Fabrics) 대상 오프로드를 통해 P2PDMA를 지원한다. 모든 NVMe-oF 연산을 하드웨어 가속기로 오프로드하고 Arm 프로세서는 이 시스템에 연결하여 로컬 NVMe 디스크에서 직접 읽을 수 있다. 이러한 디스크는 Arm 프로세서에서 실행되는 Linux 환경에 직접 마운트되며 호스트 OS에 표시되는 것과 동일한 파일 시스템에서 실행된다. 성능 측면에서 BlueField NIC의 fio는 Intel Optane 900P NVMe 디스크당 2.5GB/초를 달성하며 이는 호스트 CPU 측에서 달성한 것과 비슷하다.
도 4는 플랫폼에 사용하는 Mellanox Blue-Field NIC의 아키텍처를 보여준다. 16개의 Armv8 코어와 Linux에서 실행되는 16GB의 DDR4 메모리가 장착되어 있다. Arm 하위 시스템을 사용하면 DPDK 응용 프로그램을 실행하여 원격 시스템이나 로컬 호스트에서 빠른 패킷 I/O를 수행할 수 있다. 또한 애플리케이션은 TCP/IP 체크섬 계산과 TCP 세분화(즉, TSO)를 ConnectX-5 NIC 하드웨어로 오프로드할 수 있다. 그러나 모든 패킷이 임베디드 시스템을 통과하도록 하면 중요한 패킷 포워딩 오버 헤드가 발생할 수 있다. 이를 방지하기 위해 NIC(도 4의 eSwitch)를 구성하여 모든 수신 패킷이 호스트 CPU 측으로 직접 전달되고 NIC 임베디드 시스템은 아웃 바운드 패킷만 처리하도록 할 수 있다. 프로세서와 메모리가 CPU에 비해 강력하지 않다. BlueField NIC의 Arm 하위 시스템의 최대 메모리 대역폭은 19.2GB/s에 불과하므로 전체 성능이 제한되지만, Armv8 기반 SoC는 100GB/s를 초과하는 메모리 대역폭을 지원할 수 있으므로 이는 본질적인 제한에 해당하지는 않을 것이다.
설계(Design)
본 발명에서는 컨텐츠 전달 시스템이 최근 SmartNIC I/O 발전을 활용할 수 있도록 하는 IO-TCP의 설계를 제시한다. IO-TCP의 주요 설계 선택은 개별 I/O 연산이 SmartNIC로 오프로드되는 동안 CPU측이 모든 연산을 완전히 제어하도록 TCP 스택의 제어 플레인과 데이터 플레인을 분리하는 것이다. 이에 대한 핵심 근거는 NIC 스택을 구현하기 쉽도록 유지하면서 I/O 연산에서 대부분의 CPU 주기를 절약하는 것이다. 단순성은 성능 확장성의 핵심이다.
IO-TCP에는 세 가지 설계 목표가 있다. 첫째, IO-TCP는 TCP 프로토콜을 준수해야 하며 다양한 혼잡 제어 구현을 지원할 수 있어야 한다. 예를 들어, NIC 스택에서 디스크 I/O를 처리하는 것은 디스크 액세스 대기 시간(아래에서 설명)으로 인한 부정확한 RTT 측정으로 인해 호스트 스택의 정체 제어 로직을 손상해서는 안된다. 둘째, IO-TCP로 마이그레이션하기 위해 기존 애플리케이션의 수정을 최소화해야 한다. 파일 I/O 오프로딩(아래에서 설명)을 제외하고 동일한 소켓 API를 사용해야 한다. 셋째, IO-TCP 호스트 스택은 I/O 오프 로딩을 위해 NIC 스택과 통신해야 하며 오버 헤드를 줄여야 한다. 또한 호스트 스택에 NIC 스택의 모든 오류를 제때에 알려 제대로 처리해야 한다(아래에서 설명).
TCP 컨트롤 플레인과 데이터 플레인 분리(Separating TCP control and data planes)
호스트 CPU 주기를 절약하려면 SmartNIC 및 CPU의 기능을 기반으로 오프로딩을 통해 가장 많은 이점을 얻을 수 있는 연산을 결정해야 한다. SoC 또는 ASIC 기반 SmartNIC의 임베디드 프로세서는 더 간단한 데이터 플레인 연산에 더 적합하며 고급 기능이 있는 x86 CPU는 복잡한 컨트롤 플레인 연산을 더 빠르게 처리할 수 있다. 따라서 TCP 스택을 컨트롤 플레인과 데이터 플레인 오퍼레이션으로 나눈다.
컨트롤 플레인 기능은 연결 관리, 안정적인 데이터 전송, 혼잡/흐름 제어 및 오류 제어와 같은 주요 TCP 프로토콜 기능을 나타낸다. 동작은 다른 쪽의 응답에 따라 달라지므로 일반적으로 복잡한 상태 관리가 필요하다. 예를 들어, 수신기 측에서 안정적인 데이터 전달을 위해서는 적절한 순차 전달 및 ACK 생성을 위해 분리 된 모든 수신 데이터 범위를 추적해야 한다. 또한 손실 감지 및 패킷 재전송으로 혼잡 제어와 긴밀하게 결합되어 안정적인 전달을 위해 전송창 크기를 다시 조정한다. 마찬가지로 흐름 제어는 창 크기에도 영향을 미치므로 정체 제어와 함께 실행해야 한다. 오류 제어는 오류 동작을 추론하기 위해 자세한 흐름 상태를 추적해야 하므로 단독으로 실행할 수 없다. 이러한 연산은 SmartNIC로 오프로드될 수 있지만 효율성을 위해 함께 오프로드하는 것이 좋다. 위의 각 연산을 SmartNIC로 오프로드할 수 있지만 효율성을 위해 이러한 모든 연산을 함께 오프로드하는 것이 좋다. 그러나, 후술하겠지만 단일 CPU 코어로 수천 개의 연결을 처리하기에 충분하므로 이를 오프로드해도 CPU 주기가 많이 절약되지 않는다. 연결 관리는 AccelTCP에 설명된 대로 독립적으로 오프로드할 수 있는 유일한 기능이다. 그러나 연결 관리에 상대적으로 큰 오버 헤드가 발생하여 컨텐츠 전송 워크로드에 맞지 않을 수 있는 흐름 크기가 작은 경우에만 가장 큰 이점을 제공한다. 따라서, 본 발명에서는 그것들을 모두 CPU 측에 보관한다.
데이터 플레인 연산은 컨트롤 플레인 기능의 구현을 지원하는 데이터 패킷 준비 및 전송과 관련된 모든 작업을 의미한다. 여기에는 데이터 버퍼 관리, 데이터를 패킷으로 분할, TCP/IP 체크섬 계산 등이 포함된다. IO-TCP는 단순하고 반복적이며 상태 비저장이기 때문에 전송 경로에서 데이터 플레인 연산을 오프로드한다. 또한 IO-TCP는 파일/디스크 I/O를 오프로드하고 이를 TCP 데이터 플레인 연산에 결합시킨다. 이 결정의 근거는 이러한 작업이 대용량 파일 컨텐츠 전달에서 TCP주기의 대부분을 차지하므로 상당한 CPU주기를 절약할 수 있게 된다. 또한, SmartNIC에는 하드웨어 기반 암호화 가속기가 있는 경향이 있어 가까운 장래에 TLS 데이터 암호화/복호화를 라인 속도로 활성화할 수 있다.
IO-TCP 오프로드 API 함수(IO-TCP Offload API Functions)
먼저, IO-TCP 애플리케이션을 작성하는 방법을 설명한다. 애플리케이션을 IO-TCP로 포팅하는 것은 핵심 로직의 수정을 거의 필요로 하지 않지만, 애플리케이션이 원하는 것을 유연하게 활성화하는 것이 바람직하다.
예를 들어, IO-TCP 애플리케이션은 파일 컨텐츠인지 여부에 관계없이 전송할 컨텐츠를 구성할 수 있어야 한다. 이 목표를 위해 오프로드된 파일 및 네트워크 I/O에 대해 4개의 기능만 추가하여 기존 소켓 API를 확장한다. 함수는 아래와 같다.
int offload_open(const char *filename, int mode) - opens a file in the NIC and returns a unique file id (fid).
int offload_close(int fid) - closes the file for fid in the NIC.
int offload_fstat(int fid, struct stat* buf) - retrieve the metadata for an opened file, fid.
size_t offload_write(int socket, int fid, off_t offset, size_t length) - sends the data of the given length starting at the offset value read from the file, fid, and returns the number of bytes virtually copied to the send buffer.
IO-TCP는 NIC 스택에서 파일을 열고 닫는 데 offload_open() 및 offload-close()를 제공한다. offload_open()은 NIC 스택에 파일을 열고, 결과(성공 또는 오류)를 보고하도록 요청한다. 이후 작업을 위해 NIC 스택에서 열린 파일을 식별하는 파일 ID(파일 설명자 대신)를 반환한다. offload_open()은 다양한 이유로 파일 열기가 실패할 수 있으므로 epoll()로 결과를 확인해야 하는 비동기 함수이다. 모든 파일 작업이 완료되면 응용 프로그램은 NIC 스택에 offload_close()를 사용하여 파일을 닫도록 요청할 수 있다. 또한 IO-TCP는 열린 파일에 대한 메타 데이터(예 : 파일 크기 및 권한 정보)를 검색하는 offload_fstat()를 추가한다. 열린 파일 ID로 응용 프로그램은 offload_write()를 호출하여 파일 내용을 연결을 위한 TCP 데이터 패킷으로 보낼 수 있다. 기본적으로 offload_write()는 Linux의 sendfile()과 동일한 연산을 수행하지만 NIC 임베디드 시스템에서 열린 파일과 함께 작동한다. 응용 프로그램은 write()와 같은 기존 소켓 API를 사용하여 사용자 지정 데이터(예: HTTP 응답 헤더)를 보내거나 NIC 스택에 의해 열린 여러 파일에서 컨텐츠를 보낼 수 있다. 현재는 일반 텍스트 데이터 전송만 구현하지만, 암호화 연산(예: SSL_offload_write() 사용)을 NIC 스택으로 쉽게 오프로드할 수 있을 것이다. 도 5는 HTTP 서버 컨텍스트에서 API 함수를 사용하는 작업의 하위 집합을 보여준다.
특히, 도 5에 도시된 바와 같이, NIC로의 오프로딩 기능은 패킷데이터를 파일 컨텐트로 채워서 "보내는(SEND)" 기능만 오프로딩하는 것이고, 클라이언트에서 오는 이 데이터 패킷에 대한 ACK 패킷은 NIC를 바이패스(bypass)하여 CPU측 호스트 스택으로 "직접 전송"되어 호스트 스택에서 처리된다. 더욱 상세하게는, IP TCP는 "SEND" 명령만 NIC로 오프로드하고, 리시브(receive)쪽 연산들은 모두 CPU의 호스트 스택에서 구현된다. 다시 말해, 클라이언트로부터 수신되는 ACK나 페이로드가 있는 패킷들은 모두 NIC의 프로세서를 바이패스(bypass)해서 곧바로 호스트스택으로 전달되어 처리된다. ACK처리나 메시지 리시브가 훨씬 복잡한 연산임을 감안한다면 이들을 CPU측에서 처리하게 함으로써 효율을 높일 수 있게 된다.
이러한 설계를 채택한 본 발명에 의하면, TCP의 ACK 처리와 같이 복잡한 부분은 CPU 측에서 처리하고, SmartNIC는 데이터 전송과 같은 단순 반복적인 일만 수행할 수 있기 때문에 전체 효율성이 상당히 향상된다. 다시 말해, 연산성능이 낮은 프로세서를 SmartNIC에서 사용해도 무방하고, 이는 SmartNIC의 제조비용을 줄일 수 있다는 장점을 도모한다.
IO-TCP 호스트 스택(IO-TCP Host Stack)
I/O 오프로드 TCP 스택의 가장 큰 문제는 전송을 위한 실제 데이터가 호스트 스택에서 누락될 수 있다는 것이다. 파일 I/O가 NIC 스택으로 오프로드되기 때문에 파일에서 데이터를 읽어야 하는 경우 호스트 스택은 데이터 패킷을 생성할 수 없다. 마찬가지로 호스트 스택에 데이터 패킷이 없기 때문에 데이터 패킷의 재전송이 불가능해진다.
IO-TCP는 데이터를 사용할 수 없는 경우 호스트 스택에서 데이터 플레인 연산을 가상으로 수행하여 이 문제를 해결한다. IO-TCP 호스트 스택은 시퀀스 번호 공간에서 "누락된" 데이터를 추적하고 실제 I/O 연산을 NIC 스택에 위임하는 동안 부기 작업만 수행한다.
예를 들어 응용 프로그램이 offload_write()를 호출하면 호스트 스택은 메타 데이터만 업데이트하여 전송 버퍼에 가상으로 기입한다. 이 함수는 전송 버퍼에 기록된 "가상" 바이트수와 함께 즉시 반환된다. 그런 다음 호스트 스택은 정체 및 흐름 제어 매개 변수와 함께 전송해야 하는 바이트 수를 결정하고 "SEND" 명령을 NIC 스택에 게시한다(그림 5의 ③및 ④참조).
"SEND" 명령은 NIC 스택으로 향하는 TCP 패킷(NIC의 내부 MAC 주소 포함)에서 수행된다. 명령 패킷의 TCP/IP 헤더는 전체 연결 정보(예: 다음 데이터 패킷에 대한 4개의 연결 튜플, 시퀀스 및 시퀀스 및 ACK 번호 등)를 포함하고 페이로드에는 결국 실제로 대체되는 "SEND" 명령이 포함된다. 컨텐츠가 클라이언트로 전송되기 전에 "SEND" 명령은 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이를 지정한다. 이 정보를 사용하여 NIC 스택은 파일 내용을 읽고 헤더 정보와 함께 실제 데이터 패킷을 생성 및 전송한다. 파일 내용 크기에 따라 하나의 "SEND" 명령이 여러 MTU 크기의 데이터 패킷으로 변환될 수 있다. 즉, "SEND" 명령어의 구현은 CPU측 호스트 스택에서 일반 TCP 패킷을 활용하여 NIC 스택으로 전달하되, 이 패킷의 헤더(header)는 일반 TCP 패킷과 동일한 것을 이용하지만 버추얼 페이로드(virtual payload)를 가지고 있다. 이 버추얼 페이로드 내용에 특정 파일의 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이(length) 정보를 가지고 있고, NIC가 이 파일의 내용을 리드하고, 길이(length)를 고려하여, n개의 리얼 TCP 패킷(real TCP packet)으로 변환하여 전송한다. "SEND" 명령어가 처리되는 방법과 관련하여 아래에서 더욱 상세히 설명한다.
도 6은 "SEND" 명령 패킷이 처리되는 방법을 도시준다. 호스트 스택은 동일한 방식으로 패킷 재전송을 처리한다. 재전송을 위해 파일 내용 정보와 함께 "SEND" 명령을 보낸다. 이 설계의 근거는 NIC 스택을 가능한 단순하게 만드는 것이다. 한 가지 분명한 대안은 NIC 스택이 재전송을 처리하도록 하여 "SEND" 명령에 대한 모든 데이터의 안정적인 전달을 보장하는 것이다. 그런 다음 NIC 스택은 클라이언트의 모든 ACK를 추적하고 정체 제어 로직(congestion control logic)을 실행하여 패킷 재전송시기를 결정해야 한다.
이는 NIC 스택을 상태 저장 및 더 복잡하게 만들 수 있으며 일부 SmartNIC 플랫폼(예: FPGA 기반 플랫폼)에서 효율적으로 구현하는 것이 어려울 수 있다. 다른 모든 작업의 경우 IO-TCP는 일반 TCP 스택과 유사하게 작동한다. 수신 경로의 연결별 상태 및 버퍼 관리, 타이머 관리, 안정적인 데이터 전송, 혼잡/흐름 제어 및 오류 제어와 같은 모든 복잡한 작업이 호스트 스택에서 실행된다. 또한 호스트 스택에서 데이터를 사용할 수 있는 제어 패킷 또는 패킷의 경우 호스트 스택은 이를 생성하여 NIC 스택을 우회하여 클라이언트로 직접 보낸다. 클라이언트에서 들어오는 모든 패킷도 호스트 스택으로 직접 전달된다(그림 5의 ② 및 클라이언트에서 전송한 ACK 참조).
이는 NIC의 내장형 시스템을 통과할 때 도 7과 같이 지연 시간 오버 헤드가 발생할 뿐만 아니라 NIC 스택에 불필요한 부담을 주기 때문이다. 도 7은 호스트와 NIC 스택 사이의 통신을 위한 이더넷(Eithernet)의 라운드 트립 타임(Round-trip time)을 도시한다. 이 패킷 조정은 NIC의 내장형 시스템이 서로 다른 IP 및 MAC 주소를 갖는 Mellanox BlueField NIC의 분리 모드에서 쉽게 시행할 수 있다.
IO-TCP NIC 스택(IO-TCP NIC Stack)
IO-TCP NIC 스택은 호스트 스택에 대한 모든 실제 데이터 플레인 연산을 수행하며 데이터 패킷 전송을 위해 오프로드된 파일 I/O 및 네트워크 I/O를 처리한다. 각 명령이 NIC 스택으로 향하는 특수 패킷에서 전달되는 호스트 스택에서 사용자 지정 명령을 처리하여 작동한다. 현재 "OPEN", "CLOS", "SEND" 및 "ACKD"의 네 가지 명령이 정의되어 있다. "OPEN" 및 "CLOS"는 IO-TCP 응용 프로그램의 파일을 열거나 닫는 데 사용된다. "SEND"는 파일 내용을 클라이언트로 보내기 위한 기본 명령이다. 마지막으로 "ACKD"는 중복 디스크 액세스 없이 재전송을 효율적으로 처리하는 데 사용된다. "SEND" 명령은 I/O 연산을 위한 핵심 드라이버이다. "SEND" 명령이 주어지면 NIC 스택은 대상 파일이 열려 있는지 확인하고 파일 내용을 고정된 크기의 메모리 버퍼로 읽는다. 파일 읽기 오프셋과 길이는 NVMe 디스크 페이지 경계(예: 4KB)에 맞춰 정렬되고 실제 파일 I/O는 메인 스레드의 차단을 방지하기 위해 비동기식으로 실행된다. 메모리 버퍼에서 파일 내용을 사용할 수 있는 경우 NIC 스택은 "SEND" 명령 패킷에 TCP/IP 헤더가 포함된 TSO 패킷을 생성하여 NIC 하드웨어 데이터 플레인으로 보낸다. NIC 하드웨어 데이터 플레인은 TCP 패킷 분할 및 TCP/IP 체크섬 계산을 처리한다.
또한, CPU 측의 호스트 스택이 클라이언트에서 보낸 ACK 패킷을 수신하면, 주기적으로(예: 32KB 단위로) NIC에게 ACK된 일련번호(sequence number)를 통지하게 되고, 이에 따라 NIC는 ACK된 일련번호(sequence number)까지 해당되는 파일 컨텐츠를 메모리에 유지하고 있지 않아도 된다. TCP에서는 데이터 전송시　이 데이터 패킷이 네트워크에서 로스(loss)되면 다시 재전송(retransmission)을 수행하여 신뢰성있게 데이터 전송을 하게 되는데, 이 재전송을 위해 NIC는 한번 보낸 데이터라도 ACK되지 않은 데이터를 메모리에 저장하고 있어야 하는데, ACKD는 이런 데이터를 버릴 수 있게 해 줍니다.　
통합 I/O의 과제(Challenges with Integrated I/O)
파일 I/O를 NIC 스택의 네트워크 I/O에 결합하면 TCP 스택 연산의 정확성에 몇 가지 고유한 문제가 발생한다.
(재전송 타이머 및 RTT 측정)
TCP는 재전송 타이머와 같은 결정을 위해 지연 측정에 의존한다. 그러나 디스크 I/O로 인한 지연은 RTT 측정을 혼동할 수 있다. 빠른 NVMe 디스크를 사용하더라도 몇 KB의 데이터를 읽기 위한 디스크 액세스 지연은 마이크로 초 단위이며 동일한 디스크에 대한 I/O 요청이 백로그되는 경우 최대 밀리 초까지 걸릴 수 있다.
IO-TCP의 초기 구현은 원래 패킷이 클라이언트로 전송되지 않은 경우에도 종종 패킷을 재전송한다. 이 문제를 해결하기 위해 NIC 스택이 해당 "SEND" 명령에 대한 데이터 패킷을 보내려고 할 때 에코 패킷을 호스트 스택으로 다시 보내도록 한다. 호스트 스택은 SEND 명령에 대한 에코 패킷을 수신할 때까지 재전송 타이머를 시작하지 않는다. 높은 정확도를 위해 호스트 스택은 NIC 스택에서 타임 아웃 값에서 에코 패킷의 단방향 지연(플랫폼에서 ∼3.7 마이크로초)을 뺀다. 에코 패킷에 대한 CPU 오버 헤드는 "SEND" 명령당 전송되기 때문에 적으며 일반적인 "SEND" 명령은 덜 혼잡한 네트워크 경로에서 큰 파일을 전송할 때 수십에서 수백 개의 MTU 크기 패킷으로 변환된다.
또한 정확한 RTT 측정을 위해 NIC 스택은 실제 "패킷 처리" 지연을 TCP 타임 스탬프 옵션 값에 반영한다. 즉, "SEND" 명령이 NIC 스택에 도착하고 해당 데이터 패킷이 NIC 스택에서 출발하는 사이의 지연 시간이다. 즉, "SEND" 명령 패킷은 호스트 스택에 의해 채워진 TCP 타임 스탬프 옵션을 전달하고 NIC 스택은 패킷을 보내기 전에 값을 업데이트한다. 타임 스탬프 옵션 값이 밀리 초 단위이고 호스트 스택의 시간 피드가 마이크로 초 단위이므로 호스트 스택은 마이크로 초 단위의 추가 시간 정보를 NIC 스택에 보낸다. 그런 다음 NIC 스택은 필요한 경우 타임 스탬프 값을 반올림할 수 있다.
정리하면, CPU는 상기 에코 패킷을 수신할 때까지 재전송 타이머의 전송을 소정 시간동안 수행하지 않으며, 소정 시간은 상기 NIC에서의 패킷처리 지연시간과 상기 에코 패킷의 단방향 처리시간에 의해 결정되되, 상기 NIC에서의 패킷처리 지연시간은 상기 "SEND" 명령이 상기 NIC에 도착한 뒤 "SEND" 명령에 대한 데이터 패킷이 상기 클라이언트로 출발하는 사이의 지연시간으로 정의될 수 있다. 즉, 에코 패킷은 호스트 스택에서의 플로우(flow)의 RTT 측정을 정확하게 하기 위하여 NIC가 disk IO delay에 대한 정보를 호스트 스택으로 전달해 주는 기능을 갖는다.
(재전송 처리)
위에서 설명한 바와 같이, I/O 오프로드된 패킷의 재전송도 "SEND" 명령으로 구현된다. 그러나, 단순한 구현은 파일 내용을 다시 읽어 디스크 및 메모리 대역폭을 낭비할 수 있다. 비효율성을 방지하기 위해 NIC 스택은 호스트 스택이 클라이언트에 대한 전달을 확인할 때까지 원래 데이터 컨텐츠를 메모리에 보관한다. 호스트 스택이 I/O 오프로드된 시퀀스 공간 범위에 대한 ACK를 확인하면 "ACKD" 명령 패킷으로 전달된 부분을 NIC 스택에 주기적으로 알린다. 그런 다음 NIC 스택은 전달된 데이터를 보유하는 메모리 버퍼를 재활용할 수 있다. 오버 헤드를 최소화하기 위해 호스트 스택은 클라이언트가 마지막으로 확인한 임계 데이터 양(예: 현재 32KB 사용)을 볼 때마다 NIC 스택에 알린다. 이 버퍼 메모리는 기본적으로 일반 TCP 스택에서 소켓 전송 버퍼 역할을 하지만 실제로 필요한 메모리는 대략 대역폭 지연 제품에 해당한다. 연결을 위한 평균 RTT가 30ms 인 100Gbps NIC에는 375MB의 버퍼 메모리가 필요할 수 있다.
오류 처리(Handling Errors)
IO-TCP에서 호스트 스택은 패킷 손실, 잘못된 패킷 또는 갑작스러운 연결 실패 처리와 같은 모든 TCP 수준 오류를 처리한다. NIC 스택은 호스트 스택을 대신해서만 패킷을 보내고 모든 수신 패킷은 NIC 스택을 우회하므로 호스트 스택은 다른 TCP 스택과 마찬가지로 TCP 수준 오류를 추론할 수 있다.
그러나 NIC 스택은 파일 I/O의 오류를 호스트 스택에 보고해야 한다. "OPEN"명령의 경우 NIC 스택은 파일 열기 성공 여부에 관계없이 호스트 스택에 응답한다. 그런 다음 호스트 스택은 해당 파일 ID에 이벤트를 발생시켜 애플리케이션이 결과를 학습하도록 한다. 호스트 스택은 오프로드된 파일의 메타데이터를 캐시에 저장하므로, offload_write()에 잘못된 매개 변수 값이 전달되면 오류를 반환할 수 있다. 파일 읽기 연산 자체에서 오류가 발생하는 경우 파일 ID 및 오류 코드와 함께 "오류" 명령 패킷과 함께 호스트 스택에 보고한다. 그런 다음 offload_write()는 다음에 응용 프로그램이 호출할 때 errno에 오류 코드와 함께 1을 반환한다.
구현(Implementation)
(IO-TCP 호스트 스택)
고성능 사용자 수준 TCP 스택인 mTCP를 수정하여 IO-TCP 호스트 스택을 구현한다. 소켓 API가 Berkeley 소켓 API와 유사하고 epoll을 사용한 이벤트 기반 프로그래밍을 지원하므로 mTCP를 선택한다.
호스트 스택은 모든 mTCP API 기능을 포함하고 4개의 오프로드 기능(표 2 참조)을 애플리케이션에 추가한다. 각 오프로드 기능은 NIC 스택과 특수 명령 패킷을 교환하여 구현된다. NIC 스택은 IP 패킷의 ToS 필드에있는 특수 값을 확인하여 명령 패킷을 감지한다. "SEND" 명령 패킷에는 전체 연결 정보가 포함된 유효한 TCP/IP 헤더가 있으므로 페이로드(체크섬 포함)만 클라이언트로 전송되기 전에 실제 파일 내용과 스왑되어야 한다.
offload_open()의 경우 호스트 스택은 성공적인 작업에 대한 NIC 스택의 응답으로 열린 파일의 메타 데이터(예: fstat()의 출력)를 받는다. 그런 다음 offload_stat()에 대해 캐시하여 함수를 자체적으로 로컬에서 처리할 수 있다. 이렇게 하면 NIC 스택에 대한 라운드 트립이 줄어든다. 파일 작업의 경우 호스트 및 NIC 스택은 모두 동일한 파일 시스템을 공유한다. 호스트 OS는 NVMe 디스크의 파일 시스템을 읽기/쓰기 가능으로 마운트하고, NIC 스택은 읽기 전용으로 마운트한다. 한 가지 문제는 호스트 측 파일 시스템의 업데이트가 별도의 운영 체제에서 실행될 때 NIC 스택에 자동으로 전파되지 않는다는 것이다. 현재 컨텐츠 전달 서비스 중에 파일이 변경되지 않는다고 가정하지만 향후 두 파일 시스템의 동적 동기화에 대한 지원을 추가할 수 있다.
본 발명에서는 오프로드 API를 효율적으로 구현하기 위하여 호스트 스택과 NIC의 통신을 위해 TCP header를 재활용할 수 있다. 구체적으로, "offload_write()" 전송 후 호스트 스택에서 데이터 패킷을 전송하려고 판단한 경우, "SEND" 명령어 전송시 보내야 하는 TCP/IP header의 첫 부분을 함께 피기배킹(piggybacking)해서 NIC로 전송하고, NIC는 이를 그대로 재활용하기 때문에 구현이 매우 편리하고 효율적이다. 피기배킹(Piggybacking)은 정보 프레임의 구조를 적당히 조정해 재정의하면 정보 프레임을 전송하면서 응답 기능까지 함께 수행할 수 있고, 이런 방식으로 프로토콜을 작성함으로써 응답 프레임의 전송 횟수를 줄여 전송 효율을 높이는 방식을 의미한다.
(IO-TCP NIC 스택)
NIC 스택은 DPDK 애플리케이션으로 구현된다. 기본 작업은 호스트 스택에서 보낸 명령 패킷을 읽고, 파일에서 데이터를 읽고, 데이터 패킷을 생성하고, 클라이언트로 보내는 것이다.
여러 메인 스레드는 이러한 작업을 병렬로 수행하는 반면 각 스레드는 서로 독립적으로 작동하는 별개의 Arm 코어에 고정된다. 호스트 스택의 명령 패킷은 NIC 하드웨어의 RSS(수신측 확장)에 의해 이러한 스레드로 분산되어 서로 다른 "SEND" 명령 패킷의 동일한 연결에서 데이터 패킷을 순서대로 전달할 수 있다. 호스트와 NIC 스택 사이의 명령 패킷은 로컬호스트(localhost) 통신이므로 순서를 변경하지 않고도 안정적으로 전달된다. 효율적인 메모리 버퍼 관리를 위해 NIC 스택은 시작시 파일 컨텐츠에 대한 모든 버퍼를 미리 할당한다. 모든 버퍼는 구성 가능한 고정 크기이다. 각 주 스레드는 잠금 경합을 피하기 위해 이러한 버퍼의 1/n을 소유하며 간단한 사용자 수준 메모리 관리자가 저렴한 비용으로 버퍼를 할당하고 해제한다. 스레드당 버퍼가 고갈되면 메모리 관리자가 버퍼를 동적으로 할당한다. 더 빠른 NVMe 디스크로도 파일 읽기는 메모리 연산보다 느리므로 각 기본 스레드는 몇 개의 디스크 읽기 스레드를 사용하여 기본 스레드 차단을 방지한다. 디스크 읽기 스레드는 직접 I/O(즉, O_DIRECT 플래그가 있는 open())를 사용하여 운영 체제의 파일 시스템 캐시의 비효율성을 우회하고 공유 메모리를 통해 메인 스레드와 효율적으로 통신한다. 대안은 Intel SPDK와 같은 사용자 수준 디스크 I/O 라이브러리를 사용하는 것이다. 실제로 SPDK는 직접 I/O보다 최대 2 배 더 작은 Arm 프로세서 사이클로 최대 성능에 도달하지만 여기서는 SPDK의 지원으로 일반 파일 시스템(즉, Linux에서 XFS 사용)을 고수한다.
(Lighttpd를 IO-TCP로 포팅)
실제 애플리케이션에서 IO-TCP의 효과를 평가하기 위해 Lighttpd v1.4.32를 IO-TCP로 포팅하고 Github에서 mTCP 포팅된 Lighttpd 코드를 가져와 오프로드된 I/O 연산을 지원하도록 수정할 수 있다. Lighttpd 코드의 41871 라인 중 약 10라인만 수정해야 했기 때문에 IO-TCP로 이식하는 것은 매우 간단하다.
평가(Evaluation)
본 발명에서의 IO-TCP 평가 기준은 다음과 같다. (1) 새로운 아키텍처가 컨텐츠 전송 시스템의 처리량을 향상시킬 수 있는지 (2) CPU주기가 상당히 절약되는지 (3)설계 및 구현이 그 목적에 잘 부합되는지. 평가를 위한 실험을 실행하기 전, 많은 패킷 손실과 다수의 동시 연결의 경우에 있어서도 IO-TCP 포트 Lighttpd 서버로 IO-TCP 스택의 정확성이 유지되는지를 검증했다.
실험 설정(Experiment Setup)
실험 설정은 1개의 서버와 2개의 클라이언트로 구성된다. 서버 시스템에는 2개의 Intel Xeon Gold 6142 CPU @2.60GHz(16 코어)가 있다. 실험에는 CPU를 1개만 사용한다. 25G Mellanox BlueField SmartNIC 2개와 Intel Optane 900P NVMe 디스크 4개를 사용했다. Smart NIC 1개와 NVMe 디스크 2개를 연결했다. 각 NUMA 도메인과 NVMe-oF 대상 오프로드를 설정하여 NIC가 동일한 도메인에 있는 2개의 NVMe 디스크에 직접 액세스할 수 있다.
호스트 CPU는 Linux 4.14에서 실행되고 Arm 하위 시스템은 Linux 4.20에서 실행된다. 클라이언트 시스템에는 각각 Intel E5-2683v4 CPU @2.10GHz(16 코어) 및 100Gbps Mellanox ConnectX-5 NIC가 장착되어 있다. 클라이언트의 NIC는 LRO(Large 수신 오프로드)를 사용하도록 구성되어 있다. 모든 클라이언트는 Linux 4.14에서 실행되며 클라이언트가 실험의 병목 현상이 아님을 확인한다.
모든 NIC는 100Gbps Dell EMC Networking Z9100-ON 스위치에 연결된다. NVMe 디스크를 최근 작업에 사용된 비디오 청크의 평균 크기인 300KB 파일로 채운다. 작업 세트 크기가 주 메모리 크기를 초과하도록 워크로드가 디스크 바운딩되어 있는지 확인한다. 각 디스크는 2500MB/초의 광고된 읽기 처리량을 가지고 있으며, 4개의 디스크에서 읽을 때 이론적으로 80Gbps의 제한이 있음을 의미한다.
Lighttpd를 사용한 IO-TCP 처리량(IO-TCP Throughput with Lighttpd)
대용량 파일 컨텐츠 전달에서 IO-TCP의 효과를 평가한다. 다양한 CPU 코어 수에 대해 IO-TCP-ported Lighttpd의 처리량과 sendfile()을 사용하는 스톡 버전의 처리량을 비교한다.
300KB의 다른 비디오 청크를 요청하는 영구 연결에 1600개의 동시 요청을 사용한다. 5분 동안 실험을 실행하고 평균 처리량을 보고한다. 도 8은 대용량 파일 컨텐츠 전달에서 IO-TCP의 효과 평가에 대한 결과를 도시한다.
IO-TCP의 Lighttpd의 경우 호스트 측에서 단일 CPU 코어만 사용하고 각 SmartNIC에서 전체 16개의 Arm 코어를 사용한다. 이는 단일 CPU 코어가 모든 1600 클라이언트에 대한 컨트롤 플레인 연산을 처리하기에 충분하고 NIC 대역폭 제한에 가깝게 도달하기 때문에 더 많은 CPU 코어를 사용하더라도 성능이 향상되지 않기 때문이다.
각 NIC는 약 22Gbps를 달성하며, 이는 성능이 NIC 수에 따라 확장된다는 것을 보여준다. 반대로 Linux TCP의 Lighttpd는 단일 CPU 코어로 약 11Gbps를 달성하며 IO-TCP보다 4배 작다. 성능은 CPU 코어에 비해 비선형 적으로 증가하며 6개의 CPU 코어가 있는 IO-TCP 포트 Lighttpd와 유사한 성능에 도달한다. 이는 IO-TCP가 CPU에서 I/O 작업을 효과적으로 오프로드하고 CPU 주기 절약에 상당한 이점을 제공함을 분명히 보여준다.
또한 IO-TCP가 경쟁 연결간에 대역폭 공정성을 제공하는지 평가한다. Jain의 IO-TCP 공정성 지수는 동시 연결 수에 따라 0.91에서 0.97까지이다. 동일한 실험에서 Linux TCP에서 비슷한 범위(0.90∼0.97)를 볼 수 있다. 이는 실험에서 디스크 I/O 경합이 심한 것을 고려하면 상당한 효과가 있음을 입증한다.
CPU 사이클 절약 분석(Analysis on CPU Cycle Saving)
I/O 오프 로딩으로 CPU 주기 절약을 추가로 분석한다. 먼저, 이전 섹션의 실험에서 최고 성능을 달성하기 위해 전체 CPU 코어가 필요한지 조사한다. 구성된 양만큼 CPU 주기를 빼앗는 사용자 지정 프로그램을 작성하고, IO-TCP 호스트 스택이 실행중인 동일한 CPU 코어에 고정한다.
도 9의 (a)는 호스트 스택이 소비하는 CPU주기의 일부에 대한 처리량을 보여준다. 단일 CPU 코어주기의 70 %가 최고 성능의 97.3 %를 달성할 수 있음을 확인했다. 주기의 80%이면 최대 처리량에 충분하다. CPU 코어가 절반이어도 최대 처리량으로 인한 성능 손실의 23%에 불과하다. 이는 1600개의 동시 연결에 대한 컨트롤 플레인 연산을 처리함에 전체 CPU 코어를 이용할 필요가 없음을 보여준다. 데이터 플레인 작업을 SmartNIC로 오프로드하면 CPU 주기가 크게 절약된다.
도 9의 (b)는 사용된 Arm 코어수에 따른 단일 SmartNIC의 처리량을 보여준다. 달성할 수 있는 최대 성능은 22.1Gbps이며, 이는 12개의 Arm 코어로만 실현된다. 6개의 Arm 코어만 사용하더라도 성능 손실은 최대 처리량의 약 10%에 불과하다. 이것은 프로토 타입의 Arm 코어가 병목 현상이 아님을 나타낸다. 실제로 SmartNIC의 병목 현상은 6 절에서 자세히 논의할 메모리 대역폭에 있다.
IO-TCP 설계 선택 평가(Evaluation of IO-TCP Design Choices)
여기서 IO-TCP에 대한 설계 선택의 효과를 평가한다.
(재전송 타이머 수정)
먼저, 실제 데이터 패킷이 전송되는 적시에 재전송 타이머를 시작하는 에코 패킷의 영향을 평가한다. 도 10의 (a)는 타이머 수정이 있을 때와 그렇지 않을 때 Lighttpd의 처리량을 비교한다. 에코 패킷이 없으면 IO-TCP 호스트 스택("RTO 수정 없음")에서 많은 조기 시간 초과가 발생하므로 성능이 37.9Gbps로 유지된다. 타이머 수정을 통해 IO-TCP는 성능을 16.2% 향상시킨다. 실제로 적절한 타이머 수정이 없는 IO-TCP는 타이머 수정을 사용하는 것보다 97.6배 더 많은 타임 아웃을 생성한다. 조기 시간 초과로 인한 성능 저하는 종단 간 RTT가 더 큰 광역 네트워크(WAN)에서 훨씬 더 심각했을 것이다.
(RTT 측정 보정)
또한, NIC 스택에서 TCP 타임 스탬프 수정의 영향을 비교한다. 매초 TCP 스택에 기록된 평균 RTT 값을 측정하여 도 10의 (b)에 표시했다. TCP 타임 스탬프 수정을 비활성화하면 일반 RTT가 1ms 미만인 경우에도 1600 개의 동시 연결이 있는 평균 RTT는 42-44ms에 도달한다. 이는 RTT에 경합으로 인해 10밀리 초에 달할 수 있는 디스크 액세스 지연이 포함되기 때문이다. 타임 스탬프 수정을 활성화하면 평균 RTT가 3-5ms로 감소한다. 훨씬 낮지만 NIC의 과도한 경합으로 인해 RTT는 여전히 1ms 이상이다. 패킷 손실이있을 때 시간 초과를 트리거하려면 보다 정확한 대기 시간 측정이 중요하다.
오버헤드 평가(Overhead Evaluation)
IO-TCP의 분할 아키텍처는 호스트와 NIC 스택 간의 통신 오버 헤드뿐만 아니라 NIC에 있는 Arm 기반 하위 시스템의 낮은 컴퓨팅 용량으로 인해 어려움을 겪을 수 있다. 이러한 이유로, CPU가 오버헤드 없이 연결을 편안하게 처리 할 수 있으므로 Linux TCP의 CPU 전용 접근 방식은 적은 수의 동시 연결에 대해 IO-TCP보다 성능이 좋다.
그러나, 이러한 추세는 연결 수가 증가함에 따라 변경된다. 도 11은 다른 개수의 동시 연결에 대한 처리량 실험 결과를 도시한다. 단일 영구 연결로 Linux TCP는 IO-TCP보다 2배 이상 성능이 뛰어나다. 그러나 최소 4개의 연결로 최대 성능에 도달하고 그 이상의 성능은 동일하게 유지된다. 반대로 IO-TCP의 처리량은 오버 헤드로 인해 천천히 증가하지만 8개 연결에서 Linux TCP의 처리량을 초과하는 반면 128개 연결에서 최대 처리량에 도달한다. 성능 추세는 파일 크기가 더 작아도 계속 유지된다.
도 12는 다른 개수의 연결수에 있어서, 4KB 파일을 제공하는 처리량을 도시한다. 이전 사례와 마찬가지로 Linux TCP 및 IO-TCP는 4개 및 128개 연결에서 최고 성능에 도달하지만 파일 작업의 오버 헤드 증가로 인해 성능이 도 11에 도시된 것보다 훨씬 낮다. 그럼에도 불구하고 IO-TCP는 16개 이상의 동시 연결에서 Linux TCP를 능가한다. 대기 시간 오버 헤드를 평가하기 위해 IO-TCP와 Linux TCP를 사용하여 작은 파일을 다운로드하는 대기 시간을 비교한다. IOTCP는 1KB~16KB의 파일을 다운로드할 때 약 200~500us의 추가 지연을 보여준다. 이 추가 지연 시간은 현재 프로토 타입의 오버 헤드로 인해 불가피하지만, 광역 네트워크에서 컨텐츠를 전달하는 경우 무시할 수 있는 수준이다.
본 발명에서는 향후에도 매우 유망하게 이용될 수 있는 가능성을 지닌다.
(메모리 대역폭 제한)
현재 프로토 타입의 성능 병목 현상은 BlueField NIC의 낮은 메모리 대역폭에 있다. 100Gbps BlueField NIC를 사용하여 그림 8과 동일한 테스트를 실행하여 이를 확인한다. NIC 스택 구현에는 (1)NVMe 디스크에서 메모리 버퍼로 복사하고 (2)메모리 버퍼에서 TSO 패킷 페이로드 버퍼로 복사하는 두 가지 주요 메모리 사본이 있다. 비활성화하면 (1)성능이 36Gbps까지 올라가고 둘 다 비활성화하면 성능이 NIC 당 83Gbps에 도달한다. 현재 BlueField NIC는 Intel Xeon Gold 6142의 메모리 대역폭이 1/6에 불과하다. 그럼에도 불구하고 본 발명에 따른 방법은 향후에도 유망하다. 첫째, Arm 기반 SoC는 훨씬 더 높은 메모리 대역폭으로 설계 할 수 있으며 미래의 SmartNIC는이를 통해 이점을 얻을 수 있다. 예를 들어 Armv8 기반 SoC 서버 인 Cavium ThunderX2의 최대 메모리 대역폭은 166GB/s로 Intel Xeon CPU보다 훨씬 크다. 둘째, Arm SoC가 서버급 x86 CPU보다 저렴하고 여러 NIC를 사용하여 전체 성능을 쉽게 확장할 수 있으므로 SmartNIC의 메모리 대역폭을 개선하는 것이 더 비용 효율적이다.
(암호화 지원)
현재 프로토 타입은 SSL / TLS를 구현하지 않지만 NIC 스택에서 암호화 작업을 수행하여 지원할 수 있다. 이때 CPU 기반 구현의 성능이 더 좋을지 또는 비교할 수 있는지 여부가 중요하다. NIC 플랫폼의 Arm 하위 시스템은 AES-NI를 지원하지만 AES-GCM 성능은 아래 표 3과 같이 Intel CPU(Gold 6142)의 8.1%∼12.7%에 불과하다.
Key Size 64B 256B 1025B 8092B
128 bit(Arm) 212 324 365 377
256 bit(Arm) 192 287 321 333
128 bit(CPU) 1,632 3,063 4,649 5,657
256 bit(CPU 1,507 2,550 3,572 4,103
AES-GCM은 오늘날 TLS에서 대용량 파일 전송 성능을 결정하는 가장 인기 있는 대칭키 암호법이다. 흥미롭게도 IO-TCP에서 TSO 페이로드를 사용하여 256 비트 키 AES-GCM을 실행하면 현재 프로토 타입이 NIC 당 19Gbps(또는 둘 모두에 대해 38Gbps)를 달성하여 일반 텍스트 전송에서 성능의 14%만 손실된다. 동일한 설정에서 Linux TCP 스택의 Lighttpd는 단일 코어로 5.5Gbps만 생성하며 38Gbps에 도달하려면 8개의 코어가 필요하다. 6개의 Arm 코어는 일반 텍스트 전송에서 19Gbps를 달성하기에 충분하고(도 9의 (b) 참조), 나머지 10 개의 코어는 AES-GCM을 수행하여 19Gbps를 달성 할 수 있기 때문에 성능이 매우 합리적이다. BlueField-2에는 AES-GCM용 하드웨어 가속기가 있으므로 NIC 스택에 대한 TLS 지원이 가까운 장래에 더 합리적일 것이다. (QUIC 지원)
본 발명은 QUIC와 같은 다른 전송 계층 프로토콜을 지원하도록 설계를 쉽게 확장할 수 있다. 파일 기반 컨텐츠 전달에서 QUIC를 지원하려면 다른 API 기능을 유지하면서 QUIC에 대한 offload_write() 만 업데이트하면 된다. 내부적으로 각 "SEND" 명령 패킷은 NIC 스택에 헤더가 있는 QUIC 데이터 패킷으로 변환되어야 한다. 또한 QUIC가 TLS에서 작동하므로 암호화 작업을 지원해야 한다.
(다른 애플리케이션 지원)
본 발명에서는 주로 IO-TCP를 사용하는 HTTP 기반 비디오 스트리밍 애플리케이션에 중점을 두지만 대용량 파일을 제공해야 하는 모든 애플리케이션은 스택의 이점을 누릴 수 있다. 여기에는 소프트웨어 다운로드, 웹 브라우징, 파일 수준 동기화 등이 포함된다. 또한 작은 파일 전송의 경우에도 IO-TCP 스택은 위에서 설명한 바와 같이 충분한 동시 연결이 있는 한 여전히 이점을 제공한다.
본 발명과 관련된 작업에 대해 설명한다.
(PCIe P2P 통신)
외부 장치간에 PCIe P2P 통신을 활성화하면 외부 장치간에 데이터를 전송할 때 CPU 오버 헤드를 크게 줄일 수 있다. NVIDIA GPUDirect RDMA, GPUDirect Async 및 AMD DirectGMA 기술은 GPU 메모리를 PCIe 메모리 공간에 직접 노출하여 다른 장치가 GPU의 데이터에 직접 액세스할 수 있는 방법을 제공한다. EXTOLL은 Intel Xeon Phi 코 프로세서(가속기)와 NIC간의 직접 통신을 가능하게 하여 가속기가 CPU의 개입없이 네트워크를 통해 서로 통신할 수 있도록 제안한다. Morpheus는 NVMe 장치와 다른 PCIe 장치 간의 통신을 가능하게 한다. DCS 및 DCS-ctrl은 다양한 유형의 외부 PCIe 장치간에 P2P 통신을 가능하게 하는 하드웨어 기반 프레임 워크를 제안한다. 그러나 이러한 모든 P2P 솔루션은 커널 스택을 고려하지 않고 하드웨어에서의 데이터 통신만 고려한다. 결과적으로 이러한 솔루션은 컨텐츠 전달 응용 프로그램을 실행할 때 여전히 커널 스택 오버 헤드를 겪는다.
(가속화된 네트워킹 스택)
네트워킹 스택의 성능을 향상시키려는 기존 작업이 몇 가지 있다. 일부 작업은 기존 커널 스택의 성능을 향상시키려고 한다. Fastsocket은 테이블 수준 연결 파티션을 달성하고 연결 지역성을 높이며 잠금 경합을 제거하여 TCP 스택 성능을 향상시킨다. StackMap은 애플리케이션 전용 네트워크 인터페이스를 제공하고 애플리케이션을 위한 제로 카피, 낮은 오버 헤드 네트워크 인터페이스를 제공한다. Megapipe는 분할된 경량 소켓을 활용하고 시스템 호출을 일괄 처리하여 성능을 향상킨다. 또 다른 접근 방식은 무거운 커널 스택을 우회하고 사용자 수준에서 전체 스택을 실행하는 것이다. mTCP, IX, Sandstorm 및 F-Stack은 사용자 수준 패킷 I/O 라이브러리를 활용하고 여러 CPU 코어를 활용하여 들어오는 흐름을 동시에 처리하여 처리 처리량을 높이고 커널 호출의 지연 시간을 줄인다. ZygOS, Shinjuku 및 Shenango는 CPU 코어 간의 작업 부하 분산을 개선하여 패킷 처리의 꼬리 지연 시간을 더욱 개선한다. Arrakis는 커널의 보안 기능을 유지하면서 데이터 경로에 대한 커널 개입을 완전히 제거한다. TAS는 데이터 센터에서 RPC 호출의 성능을 향상시키는 것을 목표로 하는 별도의 OS 서비스로 TCP 빠른 경로를 구축한다. Disk | Crypt | Net은 새로운 커널 바이 패스 스토리지 스택과 기존 커널 바이 패스 네트워크 스택을 포함하는 새로운 비디오 스트리밍 스택을 구축하여 비디오 스트리밍 애플리케이션을 위한 낮은 지연 시간과 높은 처리량을 달성한다. 그러나 이러한 모든 솔루션에는 여전히 패킷 처리에 많은 CPU가 필요하므로 외부 장치간에 데이터를 전송할 때 많은 CPU 전력을 낭비한다. AccelTCP라는 최근 작업은 TCP 연결 관리와 연결 릴레이를 SmartNIC로 오프로드하여 호스트 CPU 코어에서 패킷 처리 계산의 일부를 덜어준다. 그러나 단기 연결 및 L7 프록시에 대한 처리량 향상에만 초점을 맞춘다.
(NIC 오프로드)
전통적으로, NIC 오프로드 방식은 TSO(TCP 세분화 오프로드), LRO(Large Receiver Offload), TCP/IP 체크섬 오프로드에서 TCP 엔진 오프로드(TOE), 마이크로소프트 Chimney Offload와 같은 상태 저장 시스템에 이르기까지 다양했다. 상태 비 저장 오프로드 체계는 대규모 메시지 전송을 위해 CPU주기를 효과적으로 줄임으로써 최신 NIC에서 보편화되었다. 반대로 상태 저장 체계는 복잡성으로 인한 다양한 보안 및 유지 관리 문제로 인해 그다지 인기가 없었다. 디스크 I/O에 대한 잠재적인 종속성에도 불구하고 다양한 NIC 플랫폼에서 간편한 구현과 고성능을 수용할 수 있도록 IO-TCP NIC 스택을 상태 비저장으로 설계한다. 최근에는 특정 응용 프로그램의 성능을 향상시키기 위해 다양한 작업을 SmartNIC에 오프로드하는 데 초점을 맞춘 여러 작업이 있다. AccelTCP는 단기 연결 관리 및 L7 프록시를 SmartNIC로 오프로드하여 TCP의 성능을 향상시킨다. KV-Direct는 FPGA 기반 SmartNIC를 활용하여 인 메모리 키-값 저장소의 성능을 향상시킨다. Floem, ClickNP 및 UNO는 SmartNIC를 활용하여 네트워크 애플리케이션의 패킷 처리를 가속화한다. Metron은 패킷 태깅을 NIC로 오프로드하여 네트워크 기능에 대한 패킷 처리 대기 시간을 줄인다. iPipe는 분산 애플리케이션을 SmartNIC로 오프로드하기위한 일반 프레임 워크를 구축한다. IO-TCP는 SmartNIC를 활용하여 컨텐츠 전송 시스템을 위한 디스크 및 패킷 I/O를 가속화하는 최초의 시도임에 분명하다.
본 발명은 확장 가능한 컨텐츠 전달을 위해 CPU에서 I/O 작업을 오프로드하는 분할 TCP 스택 설계인 IO-TCP를 제시한다. IO-TCP는 SmartNIC 프로세서를 활용하여 I/O 작업을 수행하는 새로운 추상화를 제공하여 CPU 및 주 메모리 시스템에 대한 부담을 크게 줄인다. 또한 본 발명은 I/O 장치에서 저전력 프로세서로 쉽게 구현할 수 있도록 NIC 스택 설계의 단순성을 유지한다. 위에서 설명한 평가에 따르면, IO-TCP는 충분한 연결을 제공할 때 작은 파일 전송에도 이점을 제공하면서 CPU주기를 크게 절약한다.
다시 정리하면, 본 발명은 TCP stack 구현을 데이터를 처리하는 부분인 데이터 플레인과, 그 외의 모든 컨트롤 기능을 총괄하는 컨트롤 플레인으로 나누고, 단순하지만 반복적인 기능을 수행하는 data plane을 SmartNIC에서 수행하여 CPU낭비를 막고, 복잡하지만 신속히 수행되어야 하는 control plan기능은 CPU에서 동작하게 하여 단위 CPU용량당 전송 성능을 극대화시키는 기법에 관한 것이다. CPU에서 수행되는 TCP 스택인 호스트 스택과 NIC에서 수행되는 NIC 스택간의 통신 프로토콜을 제안하고, NIC에서의 파일 접근을 지시하는 API를 정의하여 TCP레벨에서 보내야 하는 데이터의 파일내 위치와 사이즈를 NIC stack에게 제공함으로써 host stack에서는 NIC에서 읽어오는 파일 내용을 TCP packet에 담아서 보내는 오퍼레이션을 제어하도록 설계했다. 이외 다른 모든 제어 기능들(연결 관리(connection management), 안정적 데이터 전송(reliable data transfer), 혼잡/흐름 관리(congestion/flow control), 오류 제어(error control))는 모두 호스트 스택에서 동작하도록 설계하여 기존 TCP stack중 아주 일부분만 NIC stack으로 이양하여 구현이 쉽게 하되 이로 인한 CPU 절약의 장점이 최대화될 수 있도록 했다.
이는 다양한 종류의 SmartNIC에서도 구현될 수 있다. 호스트 스택과 NIC 스택 간의 프로토콜을 활용하여 호스트 스택에서의 패킷 RTT측정에 디스크 엑세스 지연이 포함되지 않도록 하여 정확성을 올렸으며, 재전송(retransmission)을 하는 경우에 디스크 액세스를 여러 번 하지 않도록 클라이언트에서 ack한 시퀀스 스페이스(sequence space)를 정기적으로 NIC 스택에 알려주어 적절한 시기에 전송이 완료된 파일 컨텐츠를 해제하도록 설계했다. 프로토타입 시스템을 구현하여 300KB 파일을 무작위로 다운로드하는 성능 평가에서 CPU 코어 1개만으로 50Gbps의 성능을 보였으며 이는 기존 방식을 활용한 서버의 1/6만의 CPU 용량으로 같은 성능을 발휘함을 보여주었다.
컨텐츠 전송 서비스(Content distribution system service) 중 일부분인 온라인 비디오 전송 서비스만 하더라도 이미 전체 인터넷 트래픽의 60%를 넘어섰고, 코로나 바이러스 팬데믹에 따른 비대면 일상이 지속됨에 따라 트래픽의 양이 계속 증가하고 있는 추세에 있다. 또한, 비디오 화질도 HD, UHD를 거치며 점점 좋아지고 있으나 이에 대한 대역폭 수요도 함께 커지는 부담이 생겨 단위 서버당 동시 지원가능한 클라이언트의 수가 상대적으로 줄어들어 비디오 전송 비용이 증가하는 문제가 있다. 본 발명은 SmartNIC을 활용하여 단위 CPU 용량당 전송 성능을 높여 서버당 지원할 수 있는 클라이언트 수를 크게 높일 수 있는 포텐셜을 지니고 있다. 현재 SmartNIC에 대한 기술개발이 활발하여 SmartNIC의 연산성능이 높아지는 추세를 보이고 있어 가까운 미래에 서버 플랫폼에 확산될 것이며, 본 발명은 SmartNIC의 개수에 따라 대역폭 뿐만 아니라 컨텐츠 전송 성능도 선형적으로 확장할 수 있는 장점이 있고, 오프로딩 되는 연산이 간단하여 쉽게 구현될 수 있는 장점을 가진다.
본 발명은 온라인 콘텐츠 전송에 대한 CPU 부담을 획기적으로 줄여주는 분할 TCP 스택 설계인 IO-TCP를 제시하며,IO-TCP는 CPU가 디스크 및 네트워크 I/O를 SmartNIC로 오프로드하는 동안 컨텐츠 제공의 핵심 기능에만 집중할 수 있도록 한다. 이 분업은 데이터 평면 작업만 SmartNIC로 오프로드되는 동안 CPU 측에서 스택 작업의 전체 제어를 가정하는 TCP 스택의 제어 영역과 데이터 영역의 분리를 실현한다. IO-TCP는 디스크 바인딩 워크로드를 위한 단일 CPU 코어로 두 개의 25Gbps NIC를 포화시킬 수 있다.
연산 오프로딩 시스템
본 발명에 따른 연산 오프로딩 시스템은 상술한 연산 오프로딩 방법이 시스템으로 구현된 것으로, 파일 기반 컨텐트 전송 서버의 CPU(Central Processing Unit) 및 연산 기능을 갖는 NIC(Network Interface Card)을 포함한다. 구체적인 동작 방법과 관련해서는 위에서 상세히 설명한 바, 여기서는 주요 동작 내용만 간략히 설명하기로 한다.
CPU는 데이터 플레인(data plane) 연산을 NIC에 오프로드(offload)하며, NIC는 상기 데이터 플레인 연산을 수행하고, CPU는 오프로드된 상기 데이터 플레인 연산을 제외한 컨트롤 플레인(control plane) 연산을 수행하게 된다.
이때, 데이터 플레인 연산은 컨텐츠 가져오기, 데이터 버퍼 관리, 데이터 패킷 분할, TCP/IP 체크섬 계산, 데이터 패킷 생성 및 전송 중 적어도 하나의 연산을 포함한다.
컨트롤 플레인 연산은 TCP 프로토콜의 연결 관리, 데이터 전송의 안정성 관리, 데이터 전송의 혼잡 관리, 흐름 제어 및 에러 제어 중 적어도 하나의 연산을 포함하는 것으로, 각 연산 영역이 구분된다.
CPU는 응용 프로그램으로부터 수신한 "offload_open()" 명령을 상기 NIC에 전달한다. NIC가 NIC 스택에 파일을 열고 결과를 전송 서버의 상기 CPU에 회신하며, 상기 CPU는 상기 응용 프로그램으로부터 호출된 "offload_write()" 명령을 NIC에 전달하게 된다.
이때, CPU의 호스트 스택에서 실제 데이터가 누락된 경우에는 CPU가 가상으로 상기 데이터 플레인 연산을 수행하게 된다.
CPU는, 상기 응용 프로그램이 "offload_write()" 명령을 호출한 경우, 메타 데이터만 업데이트하여 전송 버퍼에 가상 기입하고, 데이터의 정체 및 흐름 제어 매개 변수와 함께 전송해야 하는 바이트 수를 결정한 뒤 "SEND" 명령을 상기 NIC의 NIC 스택에 게시하게 된다.
한편, CPU는 TCP 패킷을 활용하여 상기 “SEND” 명령을 전달하고, 상기 TCP 패킷은 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이(length) 정보 중 적어도 하나의 정보를 포함하며, 상기 “SEND” 명령을 수신한 상기 NIC는, TCP 패킷에 포함된 길이(length) 정보에 기초하여 복수의 TCP 패킷으로 변환하여 전송할 수 있다.
또한, 상기 클라이언트는 상기 “SEND” 명령에 대한 데이터 패킷을 전송하려고 할 때 에코 패킷을 상기 CPU로 전송하며, 상기 CPU는 상기 에코 패킷을 수신할 때까지 재전송 타이머의 전송을 소정 시간동안 수행하지 않고, 상기 소정 시간은 상기 NIC에서의 패킷처리 지연시간과 상기 에코 패킷의 단방향 처리시간에 의해 결정되며, 상기 NIC에서의 패킷처리 지연시간은 상기 “SEND” 명령이 상기 NIC에 도착한 뒤 “SEND” 명령에 대한 데이터 패킷이 상기 클라이언트로 출발하는 사이의 지연시간이다.
CPU는 IO-TCP 응용 프로그램의 파일을 열 때 사용하는 “OPEN” 명령, 파일 내용을 클라이언트로 보낼 때 사용하는 "SEND" 명령, 재전송의 효율적 처리를 위한 “ACKD” 명령 및 IO-TCP 응용 프로그램의 파일을 닫을 때 사용하는 “CLOS” 명령을 정의하고, 상기 CPU는 “SEND” 명령만을 상기 NIC로 오프로드하고, 클라이언트로부터 수신되는 패킷은 직접 처리하며, 상기 CPU는 오프로드된 시퀀스 공간 범위에 대한 ACK를 확인하면, 상기 NIC에 주기적으로 상기 "ACKD" 패킷을 전달할 수 있다. ACKD에 의하여 재전송(retransmission)의 효율적 처리가 가능해진다.
IO-TCP는 “SEND”만 오프로드(offload)하고 리시브(receive)쪽 연산들은 모두 CPU의 호스트 스택에서 구현된다. 즉 클라이언트 쪽에서 오는 ACK이나 페이로드(payload)가 있는 패킷(packet)들은 모두 NIC의 프로세서(processor)를 바이패스(_bypass_)하여 곧바로 호스트 스택에 전달되어 처리된다. 이는 ACK처리나 메시지 리시브가 훨씬 복잡한 연산이어서 CPU에서 처리하는 게 효율적이기 때문이다.
본 발명에 따른 연산 오프로딩 시스템은 비디오 서버 시스템과 같은 네트워크 웹 서버가 TCP로 디스크에 있는 파일을 전송할 때, 전송해야 할 파일을 CPU대신 NIC이 읽어서 보내게 하는 오프로딩을 구현하며, 이 경우 TCP 구현이 어떻게 재설계되어야 하는 지에 대한 기술적 특징을 갖는다. CPU에서는 TCP수행에 필요한 모든 기능을 수행하되 데이터 입출력에 관한 내용만 NIC으로 오프로딩하여 단순 반복적이고 시간을 많이 차지하는 작업은 NIC에서 수행하게 한다. 그리고, 이를 가능하게 하기 위한 TCP 재설계가 본 발명의 주요 특징이며, 이는 종래 기술에 비해 온라인 콘텐츠 전송에 대한 CPU 부담을 획기적으로 줄여주게 된다.
위에서 설명한 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 기록 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상에서 실시예들에 설명된 특징, 구조, 효과 등은 본 발명의 하나 의 실시예에 포함되며, 반드시 하나의 실시예에만 한정되는 것은 아니다. 나아가, 각 실시예에서 예시된 특징, 구조, 효과 등은 실시예들이 속하는 분야의 통상의 지식을 가지는 자에 의해 다른 실시예들에 대해서도 조합 또는 변형되어 실시 가능하다. 따라서 이러한 조합과 변형에 관계된 내용들은 본 발명의 범위에 포함되는 것으로 해석되어야 할 것이다.
Host Stack: 호스트 스택
NIC Stack: NIC(Network Interface Card) 스택

Claims (20)

  1. 파일 기반 컨텐트 전송 서버의 CPU(Central Processing Unit) 및 연산 기능을 갖는 NIC(Network Interface Card)에서의 네트워크 및 파일 입출력 연산 오프로딩 방법으로,
    상기 CPU가, 데이터 플레인(data plane) 연산을 상기 NIC에 오프로드(offload)하는 오프로드 단계; 및
    상기 NIC가 상기 데이터 플레인 연산을 수행하고, 상기 CPU는 오프로드된 상기 데이터 플레인 연산을 제외한 컨트롤 플레인(control plane) 연산을 수행하는 수행 단계;를 포함하고,
    상기 데이터 플레인 연산은 컨텐츠 가져오기, 데이터 버퍼 관리, 데이터 패킷 분할, TCP/IP 체크섬 계산, 데이터 패킷 생성 및 전송 중 적어도 하나의 연산을 포함하며, 상기 컨트롤 플레인 연산은 TCP 프로토콜의 연결 관리, 데이터 전송의 안정성 관리, 데이터 전송의 혼잡 관리, 흐름 제어 및 에러 제어 중 적어도 하나의 연산을 포함하는 연산 오프로딩 방법.
  2. 제1항에 있어서,
    상기 오프로드 단계는,
    상기 CPU가 응용 프로그램으로부터 수신한 "offload_open()" 명령을 상기 NIC에 전달하는 단계;
    상기 NIC가 NIC 스택에 파일을 열고 결과를 상기 CPU에 회신하는 단계; 및
    상기 CPU가 상기 응용 프로그램으로부터 호출된 "offload_write()" 명령을 NIC에 전달하는 단계;를 포함하는 연산 오프로딩 방법.
  3. 제2항에 있어서,
    상기 CPU의 호스트 스택에서 실제 데이터가 누락된 경우 상기 CPU는 가상으로 상기 데이터 플레인 연산을 수행하는 가상 연산 단계;를 포함하는 연산 오프로딩 방법.
  4. 제3항에 있어서,
    상기 가상 연산 단계는,
    상기 CPU는, 상기 응용 프로그램이 "offload_write()" 명령을 호출한 경우, 메타 데이터만 업데이트하여 전송 버퍼에 가상 기입하는 단계; 및
    상기 CPU가 데이터의 정체 및 흐름 제어 매개 변수와 함께 전송해야 하는 바이트 수를 결정한 뒤 "SEND" 명령을 상기 NIC의 NIC 스택에 게시하는 단계;를 포함하는 연산 오프로딩 방법.
  5. 제4항에 있어서,
    상기 CPU는 TCP 패킷을 활용하여 상기 "SEND" 명령을 전달하고, 상기 TCP 패킷은 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이(length) 정보 중 적어도 하나의 정보를 포함하는, 연산 오프로딩 방법.
  6. 제5항에 있어서,
    상기 "SEND" 명령을 수신한 상기 NIC는, TCP 패킷에 포함된 길이(length) 정보에 기초하여 복수의 TCP 패킷으로 변환하여 전송하는 연산 오프로딩 방법.
  7. 제6항에 있어서,
    클라이언트는 상기 "SEND" 명령에 대한 데이터 패킷을 전송하려고 할 때 에코 패킷을 상기 CPU로 전송하며,
    상기 CPU는 상기 에코 패킷을 수신할 때까지 재전송 타이머의 전송을 소정 시간동안 수행하지 않는 연산 오프로딩 방법.
  8. 제7항에 있어서,
    상기 소정 시간은 상기 NIC에서의 패킷처리 지연시간과 상기 에코 패킷의 단방향 처리시간에 의해 결정되는 연산 오프로딩 방법.
  9. 제8항에 있어서,
    상기 NIC에서의 패킷처리 지연시간은 상기 "SEND" 명령이 상기 NIC에 도착한 뒤 "SEND" 명령에 대한 데이터 패킷이 상기 클라이언트로 출발하는 사이의 지연시간인 연산 오프로딩 방법.
  10. 제1항에 있어서,
    상기 CPU는 IO-TCP 응용 프로그램의 파일을 열 때 사용하는 "OPEN" 명령, 파일 내용을 클라이언트로 보낼 때 사용하는 "SEND" 명령, 재전송의 효율적 처리를 위한 "ACKD" 명령 및 IO-TCP 응용 프로그램의 파일을 닫을 때 사용하는 "CLOS" 명령을 정의하는 연산 오프로딩 방법.
  11. 제10항에 있어서,
    상기 CPU는 "SEND" 명령만을 상기 NIC로 오프로드하고, 클라이언트로부터 수신되는 패킷은 직접 처리하는 연산 오프로딩 방법.
  12. 제10항에 있어서,
    상기 CPU는 오프로드된 시퀀스 공간 범위에 대한 ACK를 확인하면, 상기 NIC에 주기적으로 상기 "ACKD" 패킷을 전달하는 연산 오프로딩 방법.
  13. 파일 기반 컨텐트 전송 서버의 CPU(Central Processing Unit) 및 연산 기능을 갖는 NIC(Network Interface Card)를 포함하는 네트워크 및 파일 입출력 연산 오프로딩 시스템으로,
    상기 CPU는 데이터 플레인(data plane) 연산을 상기 NIC에 오프로드(offload)하고,
    상기 NIC는 상기 데이터 플레인 연산을 수행하고, 상기 CPU는 오프로드된 상기 데이터 플레인 연산을 제외한 컨트롤 플레인(control plane) 연산을 수행하되,
    상기 데이터 플레인 연산은 컨텐츠 가져오기, 데이터 버퍼 관리, 데이터 패킷 분할, TCP/IP 체크섬 계산, 데이터 패킷 생성 및 전송 중 적어도 하나의 연산을 포함하며,
    상기 컨트롤 플레인 연산은 TCP 프로토콜의 연결 관리, 데이터 전송의 안정성 관리, 데이터 전송의 혼잡 관리, 흐름 제어 및 에러 제어 중 적어도 하나의 연산을 포함하는 연산 오프로딩 시스템.
  14. 제13항에 있어서,
    상기 CPU는 응용 프로그램으로부터 수신한 "offload_open()" 명령을 상기 NIC에 전달하면, 상기 NIC가 NIC 스택에 파일을 열고 결과를 상기 CPU에 회신하며, 상기 CPU는 상기 응용 프로그램으로부터 호출된 "offload_write()" 명령을 NIC에 전달하는 연산 오프로딩 시스템.
  15. 제14항에 있어서,
    상기 CPU의 호스트 스택에서 실제 데이터가 누락된 경우 상기 CPU는 가상으로 상기 데이터 플레인 연산을 수행하는 연산 오프로딩 시스템.
  16. 제15항에 있어서,
    상기 CPU는, 상기 응용 프로그램이 "offload_write()" 명령을 호출한 경우, 메타 데이터만 업데이트하여 전송 버퍼에 가상 기입하고, 데이터의 정체 및 흐름 제어 매개 변수와 함께 전송해야 하는 바이트 수를 결정한 뒤 "SEND" 명령을 상기 NIC의 NIC 스택에 게시하는 연산 오프로딩 시스템.
  17. 제16항에 있어서,
    상기 CPU는 TCP 패킷을 활용하여 상기 "SEND" 명령을 전달하고, 상기 TCP 패킷은 파일 ID, 읽기 스타터 오프셋(starter offset to read) 및 데이터 길이(length) 정보 중 적어도 하나의 정보를 포함하며,
    상기 "SEND" 명령을 수신한 상기 NIC는, TCP 패킷에 포함된 길이(length) 정보에 기초하여 복수의 TCP 패킷으로 변환하여 전송하는 연산 오프로딩 시스템.
  18. 제17항에 있어서,
    클라이언트는 상기 "SEND" 명령에 대한 데이터 패킷을 전송하려고 할 때 에코 패킷을 상기 CPU로 전송하며,
    상기 CPU는 상기 에코 패킷을 수신할 때까지 재전송 타이머의 전송을 소정 시간동안 수행하지 않고,
    상기 소정 시간은 상기 NIC에서의 패킷처리 지연시간과 상기 에코 패킷의 단방향 처리시간에 의해 결정되며,
    상기 NIC에서의 패킷처리 지연시간은 상기 "SEND" 명령이 상기 NIC에 도착한 뒤 "SEND" 명령에 대한 데이터 패킷이 상기 클라이언트로 출발하는 사이의 지연시간인 연산 오프로딩 시스템.
  19. 제13항에 있어서,
    상기 CPU는 IO-TCP 응용 프로그램의 파일을 열 때 사용하는 "OPEN" 명령, 파일 내용을 클라이언트로 보낼 때 사용하는 "SEND" 명령, 재전송의 효율적 처리를 위한 "ACKD" 명령 및 IO-TCP 응용 프로그램의 파일을 닫을 때 사용하는 "CLOS" 명령을 정의하고,
    상기 CPU는 "SEND" 명령만을 상기 NIC로 오프로드하고, 클라이언트로부터 수신되는 패킷은 직접 처리하며,
    상기 CPU는 오프로드된 시퀀스 공간 범위에 대한 ACK를 확인하면, 상기 NIC에 주기적으로 상기 "ACKD" 패킷을 전달하는 연산 오프로딩 시스템.
  20. 제1항 내지 제12항 중 어느 한 항에 기재된 연산 오프로딩 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터 판독 가능 기록매체.
KR1020210058761A 2020-11-24 2021-05-06 네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체 KR102479757B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020200158580 2020-11-24
KR20200158580 2020-11-24

Publications (2)

Publication Number Publication Date
KR20220071858A true KR20220071858A (ko) 2022-05-31
KR102479757B1 KR102479757B1 (ko) 2022-12-22

Family

ID=81786657

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020210058761A KR102479757B1 (ko) 2020-11-24 2021-05-06 네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체

Country Status (1)

Country Link
KR (1) KR102479757B1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080101787A (ko) * 2007-05-18 2008-11-21 엔비디아 코포레이션 부하 조절형 네트워크 환경에서의 지능형 장애극복
WO2012135442A1 (en) * 2011-03-30 2012-10-04 Amazon Technologies, Inc. Frameworks and interfaces for offload device-based packet processing
KR20140143155A (ko) * 2012-03-21 2014-12-15 마이크로소프트 코포레이션 네트워킹 장치 가상화를 위한 패킷 처리 오프로딩 기법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080101787A (ko) * 2007-05-18 2008-11-21 엔비디아 코포레이션 부하 조절형 네트워크 환경에서의 지능형 장애극복
WO2012135442A1 (en) * 2011-03-30 2012-10-04 Amazon Technologies, Inc. Frameworks and interfaces for offload device-based packet processing
KR20140143155A (ko) * 2012-03-21 2014-12-15 마이크로소프트 코포레이션 네트워킹 장치 가상화를 위한 패킷 처리 오프로딩 기법

Also Published As

Publication number Publication date
KR102479757B1 (ko) 2022-12-22

Similar Documents

Publication Publication Date Title
Moon et al. {AccelTCP}: Accelerating network applications with stateful {TCP} offloading
EP3238401B1 (en) Network extended tcp splicing
Kaufmann et al. High performance packet processing with flexnic
Kim et al. Generic external memory for switch data planes
US10798206B1 (en) Network cache accelerator
US8713180B2 (en) Zero-copy network and file offload for web and application servers
US7941613B2 (en) Shared memory architecture
US20070011358A1 (en) Mechanisms to implement memory management to enable protocol-aware asynchronous, zero-copy transmits
US8788726B2 (en) Data transmission system, storage medium and data transmission program
Kim et al. TCP offload through connection handoff
Marinos et al. Disk| Crypt| Net: rethinking the stack for high-performance video streaming
Ren et al. Design and performance evaluation of NUMA-aware RDMA-based end-to-end data transfer systems
Kim et al. Rearchitecting the {TCP} Stack for {I/O-Offloaded} Content Delivery
Hu et al. Adaptive fast path architecture
US11503140B2 (en) Packet processing by programmable network interface
Lai et al. Designing efficient FTP mechanisms for high performance data-transfer over InfiniBand
US20230328008A1 (en) Network interface and buffer control method thereof
Mansley Engineering a user-level TCP for the CLAN network
KR102479757B1 (ko) 네트워크 및 파일 입출력 연산 오프로딩 방법, 연산 오프로딩 시스템 및 컴퓨터 판독 가능 기록매체
Grant et al. Scalable connectionless RDMA over unreliable datagrams
CN114138707B (zh) 一种基于fpga的数据传输系统
US20090271521A1 (en) Method and system for providing end-to-end content-based load balancing
Kim et al. Network interface data caching
Xue et al. Network interface architecture for remote indirect memory access (rima) in datacenters
Ekane et al. Networking in next generation disaggregated datacenters

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right