KR20240041500A - 네트워크 종단 단말에서의 트래픽 송수신 제어 장치 및 방법 - Google Patents

Abstract

본 발명의 일 실시 예에 따른 네트워크 종단 단말에서의 트래픽 송수신 제어 방법은, CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 측정하는 단계; 상기 측정된 CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 기반으로 응용이 요구하는 네트워크 성능을 예약하는 단계; 및 상기 응용의 네트워킹 쓰레드(thread)에게 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 할당함으로써, 트래픽의 송수신을 제어하는 단계를 포함한다.

Description

네트워크 종단 단말에서의 트래픽 송수신 제어 장치 및 방법 {APPARATUS AND METHOD FOR CONTROLLING TRAFFIC TRANSMISSION/RECEPTION IN A NETWORK END TERMINAL}

본 개시는 네트워크 종단 단말에서의 트래픽 송수신 제어 기술에 관한 것이며, 보다 구체적으로 네트워크 종단 단말 내에서 응용이 원하는 트래픽 송수신 성능을 보장하기 위한 트래픽 송수신 제어 장치 및 방법에 대한 것이다.

화상회의, 원격제어, 가상현실, 메타버스 및 홀로그램 등 새로운 서비스들이 등장하면서 응용들은 계속해서 네트워크 트래픽에 대해서 더 많은 네트워크 대역폭과 더 적은 지연시간을 요구하고 있다. 또한 이들 대역폭과 지연시간 요구사항은 서비스를 수행하는 동안 그 성능이 보장되기를 요구하고 있다.

현재 종단과 종단(end-to-end)에 걸친 네트워크 구간에서 이들 응용의 요구사항을 만족시키기 위한 많은 노력이 이루어지고 있다. 하지만 이들 노력은 주로 네트워크 프로토콜 입장에서의 방법론을 취하고 있다. 네트워크 프로토콜들은 주로 한 쪽 종단과 다른 쪽 종단에서 동작하면서 패킷 손실 방지, 전달 순서 보장, 대역폭 보장, 지연시간 보장 등의 목적을 달성하려고 노력한다. 네트워크 프로토콜들이 네트워크 구간에서의 성능 보장을 위해서 동작하는 반면에, 이들 네트워크 프로토콜들은 종단 단말 내에서의 트래픽 성능 보장은 고려하지 않고 있다.

하지만 종단 단말 내에서도 여러 서비스들의 트래픽이 혼재할 수 있고, 단말 내에서 트래픽을 처리하기 위한 CPU, 네트워크 디바이스 등의 자원들이 한정되어 있다. 이렇게 한정된 자원을 가진 단말에서 여러 서비스들에 대한 트래픽이 혼재할 때 각 서비스들이 요구하는 네트워크 성능을 보장할 수 있어야만 그 서비스들이 느끼는 전체적인 체감 성능을 완벽하게 보장할 수 있다.

본 개시의 기술적 과제는, 네트워크 종단 단말 내에서 응용이 원하는 트래픽 송수신 성능을 보장하기 위한 트래픽 송수신 제어 장치 및 방법을 제공하는데 그 목적이 있다.

본 개시에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명의 일 실시예에 따른 네트워크 종단 단말에서의 트래픽 송수신 제어 방법은, CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 측정하는 단계; 상기 측정된 CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 기반으로 응용이 요구하는 네트워크 성능을 예약하는 단계; 및 상기 응용의 네트워킹 쓰레드(thread)에게 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 할당함으로써, 트래픽의 송수신을 제어하는 단계를 포함한다.

이때, 상기 제1 네트워크 스택은, AF_INET(Address Family INTERNET) 네트워크 스택을 포함하고, 상기 제2 네트워크 스택은, AF_XDP(Address Family eXpress Data Path) 네트워크 스택을 포함할 수 있다.

이때, 상기 제어하는 단계는, 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 SCHED_DEADLINE 스케줄링 정책으로 할당함으로써, 상기 트래픽의 송수신을 제어할 수 있다.

이때, 상기 측정하는 단계는, 측정을 위한 쓰레드를 생성하고, SCHED_DEADLINE 스케줄링 정책으로 상기 생성된 쓰레드에서 해당 CPU 코어를 100% 사용하도록 제어한 후 상기 제1 네트워크 스택의 송수신 처리 성능 값과 상기 제2 네트워크 스택의 송수신 처리 성능 값을 측정할 수 있다.

이때, 상기 예약하는 단계는, 상기 제1 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고, 상기 제어하는 단계는, 상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당할 수 있다.

이때, 상기 제어하는 단계는, 상기 응용의 트래픽이 다른 트래픽과 혼재되는 경우 상기 응용의 트래픽에 대한 송신 대역폭을 보장하기 위하여, 리눅스 TC(traffic control)의 Queuing을 제어할 수 있다.

이때, 상기 예약하는 단계는, 상기 제2 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고, 상기 제어하는 단계는, 상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당할 수 있다.

이때, 상기 제2 네트워크 스택은, 미리 정의된 속도 이상의 초고속 대역폭을 제공하는 경우 L2, L3 및 UDP 중 적어도 하나의 처리 기능을 제공할 수 있다.

이때, 상기 제어하는 단계는, 수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어에서 처리할 수 있도록, 상기 수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어의 수신큐에 전달함으로써, 상기 수신 트래픽의 스티어링(steering) 제어를 수행할 수 있다.

본 개시의 다른 실시예에 따른 네트워크 종단 단말에서의 트래픽 송수신 제어 장치는, CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 측정하는 측정부; 상기 측정된 CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 기반으로 응용이 요구하는 네트워크 성능을 예약하는 예약부; 및 상기 응용의 네트워킹 쓰레드(thread)에게 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 할당함으로써, 트래픽의 송수신을 제어하는 제어부를 포함한다.

본 개시에 대하여 위에서 간략하게 요약된 특징들은 후술하는 본 개시의 상세한 설명의 예시적인 양상일 뿐이며, 본 개시의 범위를 제한하는 것은 아니다.

본 개시에 따르면, 네트워크 종단 단말 내에서 응용이 원하는 트래픽 송수신 성능을 보장하기 위한 트래픽 송수신 제어 장치 및 방법을 제공할 수 있다.

본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1은 네트워킹 운영체제 모듈 구조에 대한 예시도를 나타낸 것이다.
도 2는 Linux CPU 스케줄링 정책 구성도를 나타낸 것이다.
도 3은 Linux Traffic Control 구조도를 나타낸 것이다.
도 4는 AF_XDP ZeroCopy 패킷 송수신 구조도를 나타낸 것이다.
도 5는 수신 트래픽 steering 기법들에 대한 예를 나타낸 것이다.
도 6은 AF_INET 네트워크 스택의 트래픽 송수신 처리 성능을 측정하는 절차를 나타낸 것이다.
도 7은 AF_INET 네트워크 성능의 예약 절차를 나타낸 것이다.
도 8은 AF_XDP 네트워크 스택 처리 성능의 측정 절차도를 나타낸 것이다.
도 9는 AF_XDP 네트워크 성능의 예약 절차도를 나타낸 것이다.
도 10은 AF_XDP L2/L3/UDP 처리 절차도를 나타낸 것이다.
도 11은 수신 트래픽 steering 절차도를 나타낸 것이다.
도 12는 본 개시의 또 다른 실시 예에 따른 트래픽 송수신 제어 장치가 적용되는 디바이스의 구성도를 나타낸 것이다.

이하에서는 첨부한 도면을 참고로 하여 본 개시의 실시 예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나, 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.

본 개시의 실시 예를 설명함에 있어서 공지 구성 또는 기능에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우에는 그에 대한 상세한 설명은 생략한다. 그리고, 도면에서 본 개시에 대한 설명과 관계없는 부분은 생략하였으며, 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

본 개시에 있어서, 어떤 구성요소가 다른 구성요소와 "연결", "결합" 또는 "접속"되어 있다고 할 때, 이는 직접적인 연결 관계 뿐만 아니라, 그 중간에 또 다른 구성요소가 존재하는 간접적인 연결관계도 포함할 수 있다. 또한 어떤 구성요소가 다른 구성요소를 "포함한다" 또는 "가진다"고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 배제하는 것이 아니라 또 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

본 개시에 있어서, 제1, 제2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용되며, 특별히 언급되지 않는 한 구성요소들 간의 순서 또는 중요도 등을 한정하지 않는다. 따라서, 본 개시의 범위 내에서 일 실시 예에서의 제1 구성요소는 다른 실시 예에서 제2 구성요소라고 칭할 수도 있고, 마찬가지로 일 실시 예에서의 제2 구성요소를 다른 실시 예에서 제1 구성요소라고 칭할 수도 있다.

본 개시에 있어서, 서로 구별되는 구성요소들은 각각의 특징을 명확하게 설명하기 위함이며, 구성요소들이 반드시 분리되는 것을 의미하지는 않는다. 즉, 복수의 구성요소가 통합되어 하나의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있고, 하나의 구성요소가 분산되어 복수의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있다. 따라서, 별도로 언급하지 않더라도 이와 같이 통합된 또는 분산된 실시 예도 본 개시의 범위에 포함된다.

본 개시에 있어서, 다양한 실시 예에서 설명하는 구성요소들이 반드시 필수적인 구성요소들은 의미하는 것은 아니며, 일부는 선택적인 구성요소일 수 있다. 따라서, 일 실시 예에서 설명하는 구성요소들의 부분집합으로 구성되는 실시 예도 본 개시의 범위에 포함된다. 또한, 다양한 실시예에서 설명하는 구성요소들에 추가적으로 다른 구성요소를 포함하는 실시 예도 본 개시의 범위에 포함된다.

본 개시에 있어서, 본 명세서에 사용되는 위치 관계의 표현, 예컨대 상부, 하부, 좌측, 우측 등은 설명의 편의를 위해 기재된 것이고, 본 명세서에 도시된 도면을 역으로 보는 경우에는, 명세서에 기재된 위치 관계는 반대로 해석될 수도 있다.

본 개시에 있어서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나", "A, B 또는 C", "A, B 및 C 중 적어도 하나", 및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다.

본 개시의 실시예들은, 종단 단말 내에서 각 서비스들이 요구하는 네트워크 성능인 대역폭과 지연시간을 보장할 수 있는 트래픽 송수신을 제어함으로써, 초고속, 대용량 및 저지연을 필요로 하는 서비스들에게 네트워크 종단 단말 내에서 흔들림 없는 네트워크 성능을 보장하고자 하는 것을 그 요지로 한다.

도 1은 네트워킹 운영체제 모듈 구조에 대한 예시도를 나타낸 것이다.

일반적으로 응용 프로그램은(100) 네트워크를 통해서 다른 대상과 통신하기 위해서 운영체제(120)를 사용한다. 본 개시의 실시예에서는, 응용에게 종단 단말 내에서의 네트워크 성능을 보장하기 위해서 네트워킹 운영체제 모듈(110)를 제공한다. 네트워킹 운영체제 모듈은 API를(111) 통해서 응용들이 네트워킹 운영체제 모듈이 제공하는 서비스를 이용할 수 있도록 한다. 또한 네트워킹 운영체제 모듈은 네트워크 성능 보장을 위한 CPU core 예약 기능(112), 네트워크 성능에 대한 지터(jitter)를 보장하기 위한 네트워크 장치 큐 관리 기능(113), 초고속 패킷 송수신을 위한 ZeroCopy 기능(114) 및 타 트래픽과의 경쟁 상황에서도 네트워크 성능 보장을 위한 Traffic Shaping 기능들을 제공한다(115). CPU Core 예약 기능은 Linux에서 제공하는 스케줄링 기능을(121) 활용하고, 네트워크 장치 큐 관리 기능은 NIC(Network Interface Card, 125)의 큐 제어를 통해서 제공하고, ZeroCopy 기능은 Linux 운영체제의 AF_XDP(Address Family eXpress Data Path, 122) 네트워크 스택을 활용해서 제공하며, 그리고 Traffic Shaping 기능은 Linux의 Traffic Control Framework에서 제공하는 Queuing 기능(124)을 통해서 제공한다. 이들 각각의 기능 및 동작 방식에 대해서 상세히 설명하면 다음과 같다.

도 2는 Linux CPU 스케줄링 정책 구성도를 나타낸 것이다.

도 2에 도시된 바와 같이, 운영체제 위에서 동작하는 응용프로그램들은 실제로는 커널의 thread로 동작한다. 이들 각 thread들이 얼마만큼의 CPU 자원을 사용할 수 있을 지는 커널의 CPU 스케줄링 정책에 의해서 결정된다. 응용이 패킷을 송수신할 때도 송수신 로직을 처리하기 위한 CPU 자원을 필요로 한다. 즉, 응용의 패킷 송수신 처리를 담당하는 thread에게 얼마만큼의 CPU 자원을 할당해 주는 가에 따라서 패킷 처리 성능이 달라진다. 다시 말하면, 응용이 요구하는 네트워크 대역폭과 지연시간을 보장하기 위해서는 제한 시간 내에 그 요구되는 대역폭을 처리할 수 있을 만큼의 CPU 자원을 네트워킹 thread에게 할당해 주어야 한다.

Linux는 비실시간(213), 실시간(212) 및 Deadline 스케줄링(211) 정책을 제공한다(210). 비실시간 정책은 처리 시간에 민감하지 않은 응용들이 사용하는 정책으로 SCHED_OTHER(204), SCHED_IDLE(205)와 SCHED_BATCH(206) 등이 있다. 실시간 정책은 처리 시간에 민감한 응용들에게 할당되는 정책으로 SCHED_RR(Round Robin, 202)과 SCHED_FIFO(First In First Out, 202)가 있다. 비실시간 정책보다는 실시간 정책으로 동작하는 thread들이 우선순위 높아서 CPU 자원을 먼저 사용할 수 있다. 그 중에서도 최고의 우선순위를 갖는 정책으로 SCHED_DEADLINE(201)이 있다. 이 정책으로 동작하는 thread들은 정해진 period 동안 정해진 runtime을 보장받도록 동작한다. 본 개시의 실시예에서는 응용이 요구하는 네트워크 송수신 대역폭을 만족할 만큼 CPU 자원을 네트워킹 thread에게 할당하기 위해서 SCHED_DEADLINE 정책을 활용할 수 있다.

도 3은 Linux Traffic Control 구조도를 나타낸 것이다.

도 3에 도시된 바와 같이, Linux의 네트워크 스택에서는 스택으로 유입되는 트래픽의 양을 조절하거나 특정 트래픽을 drop하기 위해서, 또한 네트워크로 송신되는 트래픽들의 양을 조절하거나, 특정 트래픽들에 대해서 특별한 처리를 하기 위한 프레임워크로 TC(Traffic Control, 308) 프레임워크를 제공할 수 있다. 입력 네트워크 인터페이스를(302)를 통해서 네트워크 스택으로 유입되는 트래픽들은 Ingress Policing(303)에서 어느 정도의 양으로 트래픽이 스택으로 유입될 지 등을 결정해서 네트워크 스택으로 유입된다. 네트워크 스택으로 유입된 트래픽들은 De-multiplexing 처리(304)를 통해서 해당 종단이 최종 수신지일 경우에는 상위 계층인 TCP, UDP(301) 계층으로 전달되고, 그렇지 않은 경우에는 Forwarding(305) 단계를 통해서 다른 네트워크로 전송된다. 상위 계층에서 송신된 트래픽 또한 Forwarding(305) 단계를 통해서 네트워크로 전송된다. Forwarding 단계(305)에서 어떤 출력 네트워크 인터페이스(307)로 보낼 지가 결정된 패킷들은 해당 출력 네트워크 인터페이스로 전송되기 전에 항상 TC의 Queuing 단계(306)를 거치게 된다. 만약 이 Queuing 단계에서 패킷을 출력 네트워크 인터페이스로 보내 주지 않으면 그 패킷은 영원히 바깥 세상으로 전송될 수 없다.

처리 시간에 민감한 트래픽과 민감하지 않은 트래픽이 동일한 출력 네트워크 인터페이스를 통해서 전송될 때 TC의 Queuing 단계를 제어해 주지 않으면, 일반적으로 두 트래픽은 공평하게 네트워크 인터페이스를 사용하게 된다. 예를 들어, 출력 네트워크 인터페이스가 1Gbps의 전송률을 지원하고, 처리 시간에 민감한 트래픽이 500Mbps의 속도록 패킷을 전송하고, 처리 시간에 민감하지 않은 트래픽이 1Gbps의 속도록 패킷을 전송한다면 실제로 민감 트래픽은 1/3Gbps(333Mbps)의 속도로, 비민감 트래픽은 2/3Gbps(666Mbps)의 속도로 송신된다. 이렇게 되면 시간 민감 트래픽에 대한 처리 성능을 보장할 수 없다.

이에 본 개시의 실시예에서는 응용의 네트워킹 대역폭 요구사항에 맞게 TC의 Queuing을 제어해서, 비민감 트래픽들과 동일한 출력 네트워크 인터페이스를 사용하는 경우에도 민감 트래픽에 대한 네트워크 대역폭 요구사항을 보장할 수 있다.

도 4는 AF_XDP ZeroCopy 패킷 송수신 구조도를 나타낸 것이다.

Linux는 여러 종류의 네트워크 스택을 가지고 있는데, 그 중에서 현재 가장 많이 사용되는 TCP/IP 스택을 구현한 네트워크 스택이 AF_INET(Address Family INTERNET)이다. AF_INET은 많은 다양한 기능들을 가진 성숙된 네트워크 스택이지만, 가장 치명적인 단점을 가지고 있다. 그것은 바로 패킷 복사 오버헤드이다. AF_INET 스택을 거치는 모든 패킷들은 Kernel과 User 영역 간에 패킷 복사 과정을 수행해야만 한다. 낮은 대역폭을 요구하는 응용들에게는 이들 복사 오버헤드가 문제가 되지 않지만, 초고속 대역폭을 요구하는 응용들에게는 이 복사 오버헤드로 인해서 그들이 원하는 대역폭을 제공할 수 없게 된다. 이와 같이 초고속 대역폭 처리를 필요로 하는 응용들을 위해서 Linux에 추가된 네트워크 스택이 AF_XDP(Address Family eXpress Data Path)이다.

AF_XDP는 User 영역과 Kernel 영역 간에 패킷 송수신 시에 패킷 복사 과정이 발생하지 않는다. 이는 UMEM(User Memory, 421) 메모리 버퍼를 응용과 커널이 공유해서 사용함으로써 가능해 진다. 도 4의 401은 응용이 AF_XDP 스택을 사용하고자 할 때 수행하는 절차를 보여 주는 것으로, 먼저 socket() API로 AF_XDP socket(410)을 열고, UMEM으로 사용할 메모리 버퍼를 할당한다. 그리고 그 할당한 메모리 버퍼를 AF_XDP 스택에 등록하고, 패킷 송수신을 위해서 사용할 송수신 Descriptor 큐들을 AF_XDP에 등록한다. 또 하나 특이한 점은 해당 socket을 netdev의 특정 큐와 binding을 한다는 점이다. 이는 특정 (netdev, queue_id)를 해당 socket에 연결(422)시킴으로써 송수신 처리 성능을 보장하기 위한 것이다. 응용이 패킷을 송신할 때는 UMEM의 메모리 버퍼에 송신 데이터의 내용을 채워 넣고, 그 메모리를 가리키는 송신 Descriptor를 TXQ(412)에 넣는다. 그러면 AF_XDP 스택에서는 TXQ에 있는 송신 Descriptor가 가리키는 데이터를 NIC을 통해서 송신하고, 송신이 완료되면 그 Descriptor 정보를 Completion Q(414)에 넣는다(415). 이렇게 Completion Q(414)에 유입된 Descriptor는 송신을 위해서 다시 사용될 수 있다(416). 패킷 수신을 위해서는 수신된 패킷을 저장할 메모리 버퍼에 대한 정보를 포함하고 있는 수신 Descriptor를 Filling Q(413)에 넣는다. 그리고 나서 실제로 AF_XDP에서 패킷을 수신하면 수신한 데이터를 Filling Q(412)의 수신 Descriptor가 가리키고 있는 메모리에 넣어주고, 해당 수신 Descriptor에 대한 정보를 RXQ(411)에 넣는다(417). 그러면 응용은 RXQ(411)를 보고 도착한 패킷이 있다는 것을 확인하고 처리한다. 그리고 나서 처리가 완료된 수신 Descriptor는 다시 Filling Q로 들어 가서 또 다른 패킷의 수신을 기다리는 과정을 반복하게 된다(418).

위와 같이 AF_XDP는 패킷 복사 과정을 제거해서 초고속 처리 성능을 낼 수 있는 반면에, TCP/IP와 같은 프로토콜 처리 기능이 없다. 그러므로 본 개시의 실시예에서는 AF_INET이 제공할 수 없는 초고속 대역폭을 필요로 하는 응용들이 AF_XDP 스택을 활용해서 그 대역폭 요구사항을 만족시키도록 하고, 패킷 송수신 처리 과정에서 필요한 L2/L3/UDP 처리 기능을 제공할 수 있다.

현대의 NIC(Network Interface Card)들은 다중 송수신큐를 지원한다. 이들 NIC들은 NIC이 장착된 단말이 가지고 있는 CPU core 개수와 동일한 개수의 송수신큐를 생성해서 각각의 송수신큐에서 발생하는 인터럽트를 그 큐와 연결된 CPU core에서 처리하도록 설정되는 것이 일반적이다.

도 5는 수신 트래픽 steering 기법들에 대한 예를 나타낸 것으로, NIC에서 트래픽이 수신될 때 그 트래픽을 어떤 수신큐로 보내서 패킷 수신 로직을 처리할 지를 제어하는 방법들(501, 502)을 나타낸 것이다.

RPS(503)와 RFS(504)는 소프트웨어 방식으로, RPS는 패킷이 가지고 있는 n-tuple 정보를 기반으로 패킷을 해슁한 후에 그 해쉬 값을 기준으로 수신큐를 선택하는 방식이다. 이때, n-tuple은 IP source address, UDP/TCP source port, IP destination address와 UDP/TCP destination port 값들이 될 수 있다. RFS는 AF_INET 네트워크 스택과의 협력을 통해서 수신된 패킷을 최종적으로 소비할 응용이 동작하고 있는 CPU core와 연결된 수신큐에서 처리하도록하는 기법이다. RSS(505)는 NIC에서 하드웨어적으로 n-tuple hash를 처리하는 기법이고, aRFS(506)는 하드웨어에서 수신 패킷을 소비할 최종 응용이 동작하는 CPU core와 연결된 수신큐를 선택할 수 있도록 확장된 기법이다. 가장 진보된 방식이 aRFS라고 할 수 있다. 이 밖에도 어떤 NIC들은 관리자가 수동으로 특정 flow를 특정 수신큐에서 처리할 수 있게 해주는데, 이것이 manual steering 기법(507)이다.

수신 트래픽 steering 기법들은 트래픽을 소비할 응용이 동작하고 있는 CPU core에서 트래픽 수신 처리를 해서 CPU 캐쉬 hit율을 높임으로써 트래픽 수신 성능에 대한 jitter에 도움을 줄 수 있다.

AF_INET 스택은 응용이 동작하고 있는 CPU Core 정보를 NIC과 연동하는 기능이 구현되어 있지만, AF_XDP는 그런 기능이 없다. 그러므로 AF_XDP를 사용하는 경우에는 manual steering으로 수신 트래픽을 원하는 CPU core에서 처리하도록 할 수 있다. 본 개시의 실시예에서는 수신 트래픽에 대한 성능 jitter를 보장하기 위해서 NIC이 지원하는 수신 트래픽 steering 기법들을 최대한 활용한다.

본 개시의 실시예에서는 성능 보장을 위한 CPU Core 자원 할당을 위해서는 Linux의 SCHED_DEADLINE 스케줄링 정책을 활용하고, 네트워킹 성능 jitter 보장을 위해서는 NIC의 수신 트래픽 steering 기법을 활용하며, 초고속 성능을 위해서는 AF_XDP 프로토콜 스택을 활용하고, 타 트래픽과의 혼재 시에 송신 성능 보장을 위해서는 Linux TC(Traffic Control)의 Queuing 기법을 활용할 수 있다.

이하, 응용이 요구하는 네트워크 성능을 제공하기 위해서 네트워킹 운영체제 모듈에서 응용의 요구사항들을 처리하는 절차에 대해서 설명한다.

도 6은 AF_INET 네트워크 스택의 트래픽 송수신 처리 성능을 측정하는 절차를 나타낸 것으로, hpn-nos(602)는 도 1의 네트워킹 운영체제 모듈(110)을 의미할 수 있다.

hpn-nos는 라이브러리 형태로 제작될 수 있으며, 그 라이브러리는 응용들(601)에게 API를 제공할 수 있다.

응용이 hpn-nos 라이브러리를 사용하기 위해서는 제일 처음에 초기화를 요청하는 hpnNosInit() API(605)를 호출한다. 종단 단말이 AF_INET 네트워크 스택을 처리하는 성능은 그 단말의 사양에 따라서 다르다. 그러므로 hpn-nos는 초기화 시에 해당 단말이 AF_INET 네트워크 스택을 처리하는 성능을 측정해서 그 측정된 값을 관리해야 한다. honNosInit()에서는 단말이 가지고 있는 모든 CPU core에 대해서 AF_INET 네트워크 스택 처리 성능을 측정한다(610, 611). 성능 측정을 위해서는 thread를 생성(612)해서, SCHED_DEADLINE 정책으로 그 thread가 해당 Core를 100% 사용할 수 있도록 제어한다(614). 그리고 나서 그 성능 측정용 thread(613)에서 AF_INET(618)의 lo(loopback) 네트워크 인터페이스(619)로 트래픽을 송신한 후에 수신을 해서 AF_INET의 트래픽 송수신 처리 성능을 측정한다(615, 617). 그리고 나서 측정된 성능을 내부 자료구조에 기록한다(616). 측정을 완료한 후에 응용에게 결과를 반환한다(620). 이렇게 측정된 CPU core별 AF_INET 네트워크 스택 송수신 처리 성능은, 추후에 응용들이 요구하는 성능을 예약하기 위해서 사용된다.

도 7은 AF_INET 네트워크 성능의 예약 절차를 나타낸 것으로, 도 6에서 측정된 CPU core별 AF_INET 네트워크 스택 송수신 처리 성능 값을 기반으로 응용이(701) 요구하는 네트워크 성능을 네트워킹 운영체제 모듈에서(702) Linux Kernel(703)에 예약하는 절차를 나타낸 것이다.

응용은 hpn-nos가 제공하는 hpnNosReserveBandwidth() API를 이용할 수 있다(704, 705). 이 API 처리 로직에서는 먼저, 응용이 요구하는 네트워크 대역폭을 제공하기 위해서 CPU core를 얼마만큼 할당해야 하는 가를 계산해서, SCHED_DEADLINE으로 예약할 CPU core의 양을 추출한다(706). 이렇게 추출된 CPU core 양을 SCHED_DEADLINE 정책으로 응용이 사용할 네트워킹 thread에 할당한다(707). 이후에 이 네트워킹 thread는 CPU core 스케줄링(710)을 통해서 AF_INET 네트워크 스택(711)을 사용할 때 자신이 원하는 만큼의 대역폭을 보장 받을 수 있다.

또한 그 응용이 송신하는 트래픽이 타 트래픽들과 혼재될 때, 송신 대역폭을 보장하기 위해서 Linux TC의 Queuing(713)을 제어한다. 먼저 응용이 사용할 flow 정보들을 활용해서 그 flow를 네트워크로 내보내는 netdev(714)를 탐색한다. 이때, flow 정보는 source IP address, source TCP/UDP port, destination IP address, destination TCP/UDP port 및 IP protocol 등이 활용될 수 있고, 해당 응용이 보내는 트래픽이 송신될 netdev 정보는 AF_INET 스택(712)의 FIB(Forwarding Information Base) lookup으로 알 수 있다. 이렇게 탐색된 netdev의 Queuing에 응용이 원하는 만큼의 대역폭이 처리될 수 있도록 제어한다(708). 그리고 나서 응용에게 결과를 반환한다(709).

도 8은 AF_XDP 네트워크 스택 처리 성능의 측정 절차도를 나타낸 것으로, hpn-nos(802)는 도 1의 네트워킹 운영체제 모듈을 의미할 수 있다.

응용(801)은 hpnNosInit() API를 호출(804, 805)해서 hpn-nos에게 초기화를 요청한다. 이때, hpn-nos는 단말이 가지고 있는 모든 CPU core들에 대해서 AF_XDP 네트워크 스택 처리 성능을 측정한다(810, 811).

먼저 성능 측정을 위한 thread를 생성(812, 813)하고, 그 thread에게 각 CPU core를 100% 사용할 수 있도록 한다(814). 그리고 나서 AF_XDP 스택(817)과 연동되어 있는 XDP Forwarder(819)로 트래픽을 송신해서 수신(816)한 후에 AF_XDP 스택의 트래픽 송수신 처리 성능을 측정한다(815). 이때, XDP Forwarder는 별도로 디바이스 드라이버에 프로그램될 수도 있고, 아니면 기본값을 활용할 수도 있다.

이렇게 측정된 성능 결과를 내부 자료구조에 저장(820)하고, 결과를 반환한다(806). 측정된 CPU core별 AF_XDP 네트워크 스택 송수신 처리 성능은, 추후에 응용들이 요구하는 성능을 예약하기 위해서 사용된다.

도 9는 AF_XDP 네트워크 성능의 예약 절차도를 나타낸 것으로, 도 8에서 측정된 CPU core별 AF_XDP 네트워크 스택 송수신 처리 성능 값을 기반으로 응용(901)이 요구하는 네트워크 성능을 네트워킹 운영체제 모듈(902)에서 Linux Kernel(903)에 예약하는 절차를 나타낸 것이다.

응용은 hpn-nos가 제공하는 hpnNosReserveBandwidth() API를 이용할 수 있다(904, 905). 이 API 처리 로직에서는 먼저, 응용이 요구하는 네트워크 대역폭을 제공하기 위해서 CPU core를 얼마만큼 할당해야 하는 가를 계산해서, SCHED_DEADLINE으로 예약할 CPU core의 양을 추출한다(906). 이렇게 추출된 CPU core 양을 SCHED_DEADLINE 정책으로 응용이 사용할 네트워킹 thread에 할당한다(907). 이제부터 이 네트워킹 thread는 CPU core 스케줄링을(908) 통해서 AF_XDP 네트워크 스택(909)을 사용할 때 자신이 원하는 만큼의 대역폭을 보장 받을 수 있다. 그리고 나서 결과를 반환한다(910).

AF_XDP 스택은 TCP/IP 프로토콜을 알지 못한다. 즉, AF_XDP 네트워크 스택으로는 L2 프레임만을 송수신할 수 있다. 그러므로 AF_XDP를 이용해서 초고속 대역폭을 제공하려고 할 때 네트워킹 운영체제 모듈인 hpn-nos(1002)에서는 L2, L3 및 UDP 등의 처리 기능을 제공해야만 한다.

도 10은 AF_XDP L2/L3/UDP 처리 절차도를 나타낸 것으로, 상기 절차를 보여주고 있다. 먼저 AF_XDP를 이용한 메시지 송신 절차(1010, 1011)를 설명하면, 응용(1001)은 hpn-nos가 제공하는 API인 hpnNosSendmsg()를 통해서 자신이 원하는 메시지를 hpn-nos로 전달한다(1012, 1013). 그러면 hpn-nos는 UDP, L3 및 L2 헤더를 추가해서(1014) AF_XDP 스택으로 운영체제의 송신 API인 sendmsg() 등을 이용해서 L2 프레임을 송신한다(1015, 1016). 그리고 나서 결과를 반환한다(1017).

AF_XDP를 이용한 메시지 수신 절차(1020, 1021)를 설명하면, 수신에서도 응용은 hpnNosRecvmsg() 등의 API(1023)로 네트워크로부터 메시지가 도착하기를 기다린다. hpn-nos에서는 AF_XDP 스택으로부터 L2 프레임을 수신하게 된다(1024, 1025).

이때, 불필요한 정보는 L2, L3 및 UDP 헤더를 제거(1026)한 후에, 나머지 메시지 내용들만을 응용에게 전달할 수 있다(1027).

도 11은 수신 트래픽 steering 절차도를 나타낸 것으로, 수신 트래픽을 응용의 네트워킹 thread가 동작하고 있는 CPU core와 연결되어 있는 수신큐로 보내는 절차를 나타낸 것이다.

도 11에 도시된 바와 같이, 이렇게 수신 트래픽을 최종적으로 소비할 thread가 동작하고 있는 CPU core에서 처리하도록 함으로써, CPU cache hit율을 높여서 수신 성능에 대한 jitter를 어느 정도 보장할 수 있다. 응용(1101)은 hpn-nos가(1102) 제공하는 hpnNosReserveBandwidth() API를 호출(1104, 1105)하는데, 이때 수신 트래픽 steering 제어를 할 수 있다(1106, 1107). 예를 들어, 수신 트래픽 steering은 ethtool 명령어를 이용해서 제어(1108)될 수 있는데, 1108은 ens2f0 네트워크 인터페이스에서 트래픽을 수신했을 때, TCP의 목적지 port가 5201인 경우에 수신큐 2번으로 보내도록 설정하는 경우이다. 이는 manual steering을 제공하는 NIC에서 사용 가능한 방법이다. 이렇게 제어를 하게 되면 NIC(1120)의 hardware filter(1124)에서 프레임을 수신했을 때 해당되는 트래픽을 rxq2(1122)로 보내게 되고, 그 트래픽은 rxq2와 연결되어 있는 CPU core C2(1114)에서 패킷 수신 처리 로직을 수행해서 최종 목적지인 네트워킹 thread(1110)에게 도달한다. 이와 같은 과정은 AF_INET과 AF_XDP 모두 동일하게 수행된다.

이와 같이, 본 개시의 실시예에 따른 네트워크 종단 단말에서의 트래픽 송수신 제어 장치와 방법은, 다음과 같은 장점이 있다.

첫째, 응용에서 네트워킹 송수신 역할을 수행하는 네트워킹 thread에게, 그 응용이 요구하는 네트워크 성능을 낼 수 있을 만큼의 CPU core를 할당함으로써, 응용이 요구하는 대역폭과 지연시간이 종단 단말 내에서 시간이 지남에 따라 흔들리지 않도록 보장할 수 있다.

둘째, AF_INET이 지원할 수 없는 초고속 대역폭 성능을 AF_XDP를 이용해서 지원할 수 있다.

셋째, AF_INET을 이용하는 트래픽들이 혼재되어 있는 상황에서도, TC의 Queuing을 제어함으로써 처리 시간 민감 트래픽에게 그들이 원하는 네트워크 성능을 제공할 수 있다.

넷째, 네트워크 디바이스에서 수신한 트래픽을 그 트래픽을 최종적으로 소비할 응용이 동작하고 있는 CPU core에서 처리하도록 함으로써, 수신 처리 성능을 향상시킬 수 있다.

실시예에 따라서, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치는, 측정부, 예약부와 제어부의 기능적인 구성 수단으로 구성될 수도 있다. 실시예에 따라, 측정부는, CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 측정하는 구성 수단일 수 있다. 실시예에 따라, 예약부는, 상기 측정된 CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 기반으로 응용이 요구하는 네트워크 성능을 예약하는 구성 수단일 수 있다. 실시예에 따라, 제어부는, 상기 응용의 네트워킹 쓰레드(thread)에게 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 할당함으로써, 트래픽의 송수신을 제어하는 구성수단일 수 있다.

여기서, 상기 제1 네트워크 스택은, AF_INET(Address Family INTERNET) 네트워크 스택을 포함하고, 상기 제2 네트워크 스택은, AF_XDP(Address Family eXpress Data Path) 네트워크 스택을 포함할 수 있다.

실시예에 따라, 상기 제어부는, 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 SCHED_DEADLINE 스케줄링 정책으로 할당함으로써, 상기 트래픽의 송수신을 제어할 수 있다.

실시예에 따라, 상기 측정부는, 측정을 위한 쓰레드를 생성하고, SCHED_DEADLINE 스케줄링 정책으로 상기 생성된 쓰레드에서 해당 CPU 코어를 100% 사용하도록 제어한 후 상기 제1 네트워크 스택의 송수신 처리 성능 값과 상기 제2 네트워크 스택의 송수신 처리 성능 값을 측정할 수 있다.

실시예에 따라, 상기 예약부는, 상기 제1 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고, 상기 제어부는, 상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당할 수 있다.

실시예에 따라, 상기 제어부는, 상기 응용의 트래픽이 다른 트래픽과 혼재되는 경우 상기 응용의 트래픽에 대한 송신 대역폭을 보장하기 위하여, 리눅스 TC(traffic control)의 Queuing을 제어할 수 있다.

실시예에 따라, 상기 예약부는, 상기 제2 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고, 상기 제어부는, 상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당할 수 있다.

실시예에 따라, 상기 제2 네트워크 스택은, 미리 정의된 속도 이상의 초고속 대역폭을 제공하는 경우 L2, L3 및 UDP 중 적어도 하나의 처리 기능을 제공할 수 있다.

실시예에 따라, 상기 제어부는, 수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어에서 처리할 수 있도록, 상기 수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어의 수신큐에 전달함으로써, 상기 수신 트래픽의 스티어링(steering) 제어를 수행할 수 있다.

물론, 이 뿐만 아니라, 도 1 내지 도 11에서 설명한 모든 기능적인 내용을 각 구성 수단에서 수행할 수 있다.

도 12는 본 개시의 또 다른 실시 예에 따른 트래픽 송수신 제어 장치가 적용되는 디바이스의 구성도를 나타낸 것이다.

예를 들어, 본 개시의 다른 실시 예에 따른 트래픽 송수신 제어 장치는 도 12의 디바이스(1600)가 될 수 있다. 도 12를 참조하면, 디바이스(1600)는 메모리(1602), 프로세서(1603), 송수신부(1604) 및 주변 장치(1601)를 포함할 수 있다. 또한, 일 예로, 디바이스(1600)는 다른 구성을 더 포함할 수 있으며, 상술한 실시 예로 한정되지 않는다. 이때, 상기 디바이스(1600)는 예를 들어 이동 가능한 사용자 단말기(예를 들어, 스마트 폰, 노트북, 웨어러블 기기 등) 이거나 고정된 관리 장치(예를 들어, 서버, PC 등) 일 수 있다.

보다 상세하게는, 도 12의 디바이스(1600)는 트래픽 제어 장치, 네트워크 단말 등과 같은 예시적인 하드웨어/소프트웨어 아키텍처일 수 있다. 이때, 일 예로, 메모리(1602)는 비이동식 메모리 또는 이동식 메모리일 수 있다. 또한, 일 예로, 주변 장치(1601)는 디스플레이, GPS 또는 다른 주변기기들을 포함할 수 있으며, 상술한 실시 예로 한정되지 않는다.

또한, 일 예로, 상술한 디바이스(1600)는 상기 송수신부(1604)와 같이 통신 회로를 포함할 수 있으며, 이에 기초하여 외부 디바이스와 통신을 수행할 수 있다.

또한, 일 예로, 프로세서(1603)는 범용 프로세서, DSP(digital signal processor), DSP 코어, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit) 및 상태 머신과 관련되는 하나 이상의 마이크로프로세서 중 적어도 하나 이상일 수 있다. 즉, 상술한 디바이스(1600)를 제어하기 위한 제어 역할을 수행하는 하드웨어적/소프트웨어적 구성일 수 있다. 또한 상기 프로세서(1603)는 전술한 측정부, 예약부와 제어부의 기능을 모듈화하여 수행할 수 있다.

이때, 프로세서(1603)는 트래픽 송수신 제어 장치의 다양한 필수 기능들을 수행하기 위해 메모리(1602)에 저장된 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 일 예로, 프로세서(1603)는 신호 코딩, 데이터 처리, 전력 제어, 입출력 처리 및 통신 동작 중 적어도 어느 하나를 제어할 수 있다. 또한, 프로세서(1603)는 물리 계층, MAC 계층, 어플리케이션 계층들을 제어할 수 있다. 또한, 일 예로, 프로세서(1603)는 액세스 계층 및/또는 어플리케이션 계층 등에서 인증 및 보안 절차를 수행할 수 있으며, 상술한 실시 예로 한정되지 않는다.

일 예로, 프로세서(1603)는 송수신부(1604)를 통해 다른 장치들과 통신을 수행할 수 있다. 일 예로, 프로세서(1603)는 컴퓨터 실행가능한 명령어들의 실행을 통해 트래픽 송수신 제어 장치가 네트워크를 통해 다른 장치들과 통신을 수행하게 제어할 수 있다. 즉, 본 개시에서 수행되는 통신이 제어될 수 있다. 일 예로, 송수신부(1604)는 안테나를 통해 RF 신호를 전송할 수 있으며, 다양한 통신망에 기초하여 신호를 전송할 수 있다.

또한, 일 예로, 안테나 기술로서 MIMO 기술, 빔포밍 등이 적용될 수 있으며, 상술한 실시 예로 한정되지 않는다. 또한, 송수신부(1604)를 통해 송수신한 신호는 변조 및 복조되어 프로세서(1603)에 의해 제어될 수 있으며, 상술한 실시 예로 한정되지 않는다.

본 개시의 예시적인 방법들은 설명의 명확성을 위해서 동작의 시리즈로 표현되어 있지만, 이는 단계가 수행되는 순서를 제한하기 위한 것은 아니며, 필요한 경우에는 각각의 단계가 동시에 또는 상이한 순서로 수행될 수도 있다. 본 개시에 따른 방법을 구현하기 위해서, 예시하는 단계에 추가적으로 다른 단계를 포함하거나, 일부의 단계를 제외하고 나머지 단계를 포함하거나, 또는 일부의 단계를 제외하고 추가적인 다른 단계를 포함할 수도 있다.

본 개시의 다양한 실시 예는 모든 가능한 조합을 나열한 것이 아니고 본 개시의 대표적인 양상을 설명하기 위한 것이며, 다양한 실시 예에서 설명하는 사항들은 독립적으로 적용되거나 또는 둘 이상의 조합으로 적용될 수도 있다.

또한, 본 개시의 다양한 실시 예는 하드웨어, 펌웨어(firmware), 소프트웨어, 또는 그들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 범용 프로세서(general processor), 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

본 개시의 범위는 다양한 실시 예의 방법에 따른 동작이 장치 또는 컴퓨터 상에서 실행되도록 하는 소프트웨어 또는 머신-실행가능한 명령들(예를 들어, 운영체제, 애플리케이션, 펌웨어(firmware), 프로그램 등), 및 이러한 소프트웨어 또는 명령 등이 저장되어 장치 또는 컴퓨터 상에서 실행 가능한 비-일시적 컴퓨터-판독가능 매체(non-transitory computer-readable medium)를 포함한다.

Claims (18)

1. CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 측정하는 단계;
   상기 측정된 CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 기반으로 응용이 요구하는 네트워크 성능을 예약하는 단계; 및
   상기 응용의 네트워킹 쓰레드(thread)에게 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 할당함으로써, 트래픽의 송수신을 제어하는 단계
   를 포함하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
2. 제1항에 있어서,
   상기 제1 네트워크 스택은,
   AF_INET(Address Family INTERNET) 네트워크 스택을 포함하고,
   상기 제2 네트워크 스택은,
   AF_XDP(Address Family eXpress Data Path) 네트워크 스택을 포함하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
3. 제1항에 있어서,
   상기 제어하는 단계는,
   상기 예약된 네트워크 성능에 해당하는 CPU 코어를 SCHED_DEADLINE 스케줄링 정책으로 할당함으로써, 상기 트래픽의 송수신을 제어하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
4. 제1항에 있어서,
   상기 측정하는 단계는,
   측정을 위한 쓰레드를 생성하고, SCHED_DEADLINE 스케줄링 정책으로 상기 생성된 쓰레드에서 해당 CPU 코어를 100% 사용하도록 제어한 후 상기 제1 네트워크 스택의 송수신 처리 성능 값과 상기 제2 네트워크 스택의 송수신 처리 성능 값을 측정하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
5. 제1항에 있어서,
   상기 예약하는 단계는,
   상기 제1 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고,
   상기 제어하는 단계는,
   상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
6. 제5항에 있어서,
   상기 제어하는 단계는,
   상기 응용의 트래픽이 다른 트래픽과 혼재되는 경우 상기 응용의 트래픽에 대한 송신 대역폭을 보장하기 위하여, 리눅스 TC(traffic control)의 Queuing을 제어하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
7. 제1항에 있어서,
   상기 예약하는 단계는,
   상기 제2 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고,
   상기 제어하는 단계는,
   상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
8. 제2항에 있어서,
   상기 제2 네트워크 스택은,
   미리 정의된 속도 이상의 초고속 대역폭을 제공하는 경우 L2, L3 및 UDP 중 적어도 하나의 처리 기능을 제공하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
9. 제1항에 있어서,
   상기 제어하는 단계는,
   수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어에서 처리할 수 있도록, 상기 수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어의 수신큐에 전달함으로써, 상기 수신 트래픽의 스티어링(steering) 제어를 수행하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 방법.
   
10. CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 측정하는 측정부;
    상기 측정된 CPU 코어 별 제1 네트워크 스택의 송수신 처리 성능 값과 제2 네트워크 스택의 트래픽 송수신 처리 성능 값을 기반으로 응용이 요구하는 네트워크 성능을 예약하는 예약부; 및
    상기 응용의 네트워킹 쓰레드(thread)에게 상기 예약된 네트워크 성능에 해당하는 CPU 코어를 할당함으로써, 트래픽의 송수신을 제어하는 제어부
    를 포함하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
11. 제10항에 있어서,
    상기 제1 네트워크 스택은,
    AF_INET(Address Family INTERNET) 네트워크 스택을 포함하고,
    상기 제2 네트워크 스택은,
    AF_XDP(Address Family eXpress Data Path) 네트워크 스택을 포함하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
12. 제10항에 있어서,
    상기 제어부는,
    상기 예약된 네트워크 성능에 해당하는 CPU 코어를 SCHED_DEADLINE 스케줄링 정책으로 할당함으로써, 상기 트래픽의 송수신을 제어하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
13. 제10항에 있어서,
    상기 측정부는,
    측정을 위한 쓰레드를 생성하고, SCHED_DEADLINE 스케줄링 정책으로 상기 생성된 쓰레드에서 해당 CPU 코어를 100% 사용하도록 제어한 후 상기 제1 네트워크 스택의 송수신 처리 성능 값과 상기 제2 네트워크 스택의 송수신 처리 성능 값을 측정하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
14. 제10항에 있어서,
    상기 예약부는,
    상기 제1 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고,
    상기 제어부는,
    상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
15. 제14항에 있어서,
    상기 제어부는,
    상기 응용의 트래픽이 다른 트래픽과 혼재되는 경우 상기 응용의 트래픽에 대한 송신 대역폭을 보장하기 위하여, 리눅스 TC(traffic control)의 Queuing을 제어하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
16. 제10항에 있어서,
    상기 예약부는,
    상기 제2 네트워크 스택의 송수신 처리 성능 값에 해당하는 대역폭을 제공하기 위한 CPU 코어의 양을 계산해서, SCHED_DEADLINE으로 예약할 CPU 코어의 양을 추출하고,
    상기 제어부는,
    상기 추출된 CPU 코어의 양을 SCHED_DEADLINE 스케줄링 정책으로 상기 응용의 네트워킹 쓰레드에 할당하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
17. 제11항에 있어서,
    상기 제2 네트워크 스택은,
    미리 정의된 속도 이상의 초고속 대역폭을 제공하는 경우 L2, L3 및 UDP 중 적어도 하나의 처리 기능을 제공하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    
18. 제10항에 있어서,
    상기 제어부는,
    수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어에서 처리할 수 있도록, 상기 수신 트래픽을 상기 응용의 네트워킹 쓰레드가 동작하는 CPU 코어의 수신큐에 전달함으로써, 상기 수신 트래픽의 스티어링(steering) 제어를 수행하는, 네트워크 종단 단말에서의 트래픽 송수신 제어 장치.
    

Images