TCP 오프로드 엔진

TCP offload engine

TCP 오프로드 엔진(TOE)은 전체 TCP/IP 스택의 처리를 네트워크 컨트롤러로 오프로드하기 위해 일부 NIC(네트워크 인터페이스 카드)에서 사용되는 기술이다.주로 기가비트 이더넷과 10기가비트 이더넷과 같은 고속 네트워크 인터페이스와 함께 사용되며, 네트워크 스택의 처리 오버헤드가 상당해진다.TOE는 iSCSI 및 NFS(Network File System)와 같은 IP(Internet Protocol) 스토리지 프로토콜과 관련된 오버헤드를 줄이는 방법으로 자주 사용된다[1].

목적

원래 TCP는 신뢰할 수 없는 저속 네트워크(예: 초기 전화 접속 모뎀)를 위해 설계되었지만 백본 전송 속도(광학 캐리어, 기가비트 이더넷 및 10기가비트 이더넷 링크 사용)와 더 빠르고 신뢰할 수 있는 액세스 메커니즘(DSL 및 케이블 모뎀 등) 측면에서 인터넷이 증가함에 따라 데이터에 자주 사용된다.초당 1기가비트 이상의 속도로 센터 및 데스크톱 PC 환경.이러한 속도에서 호스트 시스템의 TCP 소프트웨어 구현은 상당한 컴퓨팅 파워를 필요로 한다.2000년대 초반, 전이중 기가비트 TCP 통신은 2.4GHz 펜티엄 4 프로세서의 80% 이상을 소비할 수 있어,[2] 시스템에서 애플리케이션을 실행할 수 있는 처리 자원이 작거나 남아 있지 않을 수 있었다.

TCP는 복잡성과 처리 오버헤드를 추가하는 연결 지향 프로토콜이다.이러한 측면에는 다음이 포함된다.

  • "3방향 핸드셰이크"(동기화, 동기화-ACKnowledge, ACKnowledge)를 사용한 연결 설정.
  • 패킷이 맨 끝에 수신될 때 패킷을 수신하여 엔드포인트 사이의 메시지 흐름과 그에 따라 프로토콜 로드가 추가됨.
  • 체크섬 및 시퀀스 번호 계산 - 다시 일반 목적 CPU가 수행해야 하는 부담.
  • 패킷 승인 및 정체 제어를 위한 슬라이딩 윈도우 계산.
  • 연결 종료.

이러한 기능의 전부 또는 일부를 전용 하드웨어인 TCP 오프로드 엔진으로 이동하면 시스템의 주 CPU를 다른 작업에 사용할 수 없게 된다.2012년 현재 TOE를 지원하는 소비자 네트워크 인터페이스 카드는 거의 없다.

사용 가능한 CPU 주기

일반적으로 인정되는 경험 법칙은 1 Hertz의 CPU 처리가 TCP/IP의 1비트/s를 송신하거나 수신하는 데 필요하다는 것이다.[2]예를 들어, 5Gbit/s(625MB/s)의 네트워크 트래픽에는 5GHz의 CPU 처리가 필요하다.이는 TCP/IP 트래픽의 5Gbit/s와 관련된 TCP/IP 처리를 처리하기 위해 2.5GHz 멀티 코어 프로세서의 전체 코어 2개가 필요함을 의미한다.이더넷(이 예의 10GE)은 양방향이기 때문에 10Gbit/s(20Gbit/s의 총 처리량)의 송수신이 가능하다.1Hz/(비트/초) 규칙을 사용하면 이는 8개의 2.5GHz 코어와 동일하다.

TCP/IP 처리에 사용되는 많은 CPU 사이클은 TCP/IP 오프로드에 의해 해제되며 CPU(일반적으로 서버 CPU)가 파일 시스템 처리(파일 서버 내) 또는 인덱싱(백업 미디어 서버 내)과 같은 다른 작업을 수행하는 데 사용할 수 있다.즉, TCP/IP 오프로드 NIC가 없는 서버보다 TCP/IP 오프로드 서버가 더 많은 서버 작업을 할 수 있다.

PCI 트래픽 감소

TOE가 다룰 수 있는 프로토콜 오버헤드 외에도, 많은 비율의 호스트 기반(서버 및 PC) 엔드포인트에 영향을 미치는 일부 아키텍처 문제를 해결할 수 있다.많은 구형 엔드포인트 호스트는 PCI 버스 기반이며, 이것은 서버 및 PC에 대한 네트워크 인터페이스와 같은 특정 주변 장치의 추가를 위한 표준 인터페이스를 제공한다.PCI는 PCI 버스를 통해 메인 메모리에서 네트워크 인터페이스 IC로 작은 버스트를 전송하는 데는 비효율적이지만, 데이터 버스트 크기가 커질수록 효율성이 향상된다.TCP 프로토콜 내에서 다수의 작은 패킷(예: 승인)이 생성되며, 이러한 패킷은 일반적으로 호스트 CPU에서 생성되고 PCI 버스를 통해 네트워크 물리적 인터페이스를 통해 전송되기 때문에 이는 호스트 컴퓨터 IO 처리량에 영향을 미친다.

네트워크 인터페이스에 위치한 TOE 솔루션은 CPU 호스트에서 PCI 버스의 반대편에 위치하므로, 이 I/O 효율성 문제를 해결할 수 있다. TCP 연결을 통해 전송될 데이터는 PCI 버스를 통해 CPU에서 TOE로 전송될 수 있고, 그 중 작은 TCP 패킷은 이동하지 않아도 된다.PCI 버스.

역사

UDP 오프로드에 대한 이 기술의 첫 번째 특허 중 하나는 1990년 초에 아우스펙스 시스템에 발급되었다.[3]Auspex 설립자 Larry Boucher와 많은 Auspex 엔지니어들은 네트워크 스택 오프로드 개념을 TCP로 확장하고 그것을 사용자 정의 실리콘으로 구현하는 아이디어로 1997년에 Alacritech를 찾았다.그들은 1999년 초에 최초의 병렬 스택 풀 오프로드 네트워크 카드를 도입했다. 이 회사의 SLIC(Session Layer Interface Card)는 현재 TOE 서비스의 전신이었다.알라크리텍은 TCP/IP 오프로드 분야에서 다수의 특허를 보유하고 있다.[4]

2002년까지 iSCSI와 같은 TCP 기반 스토리지의 등장으로 관심이 높아지면서 "대부분 닷컴 버블의 종말을 향해 설립된 최소한 12명의 신규업체들이 6개의 견고한 공급업체와 사내 ASIC desig와 경쟁하면서 스토리지 프로토콜과 애플리케이션용 가맹점 반도체 가속기의 기회를 노리고 있다"고 말했다.ns."[5]

2005년에 마이크로소프트는 Alacritech의 특허 기반을 허가했고 Alacritech와 함께 TCP Chimney 오프로드라고 알려진 부분 TCP 오프로드 아키텍처를 만들었다.TCP Chimney 오프로드는 Alacritech "Communication Block Passing 특허"를 중심으로 한다.동시에 브로드컴은 TCP Chimney 오프로드 칩 제작 면허도 취득했다.

TCP/IP 오프로드 유형

TCP 스택을 완전히 TOE로 대체하는 대신, 운영 체제의 TCP 스택과의 공동 작업에서 일부 작업을 오프로드하는 대체 기법이 있다.오늘날 대부분의 이더넷 NIC에서 TCP 체크섬 오프로드 및 대규모 세그먼트 오프로드가 지원된다.대형 수신 오프로드 및 TCP 수신확인 오프로드와 같은 새로운 기술은 이미 일부 고급 이더넷 하드웨어에서 구현되어 있지만, 순전히 소프트웨어에서 구현되어도 효과적이다.[6][7]

병렬 스택 전체 오프로드

병렬 스택 풀 오프로드는 두 개의 병렬 TCP/IP 스택의 개념에서 이름을 얻는다.첫 번째는 호스트 OS에 포함된 메인 호스트 스택이다.두 번째 또는 "병렬 스택"은 "뱀파이어 탭"을 사용하여 애플리케이션 계층과 전송 계층(TCP) 사이에 연결된다.흡혈귀 탭은 애플리케이션별 TCP 연결 요청을 가로채 TCP 데이터 전송뿐만 아니라 TCP 연결 관리도 담당한다.다음 절의 많은 비판은 이러한 유형의 TCP 오프로드와 관련이 있다.

HBA 전체 오프로드

(TCP/IP를 통해) iSCSI 스토리지 디바이스에 연결하는 동안 호스트 시스템에 디스크 컨트롤러로 표시되는 iSCSI 호스트 어댑터에서 HBA(호스트 버스 어댑터) 전체 오프로드가 발견됨이러한 유형의 TCP 오프로드는 TCP/IP 처리를 오프로드할 뿐만 아니라 iSCSI 이니시에이터 기능도 오프로드한다.HBA는 호스트에 디스크 컨트롤러로 나타나기 때문에 iSCSI 디바이스에서만 사용할 수 있으며 일반적인 TCP/IP 오프로드에는 적합하지 않다.

TCP Chimney 부분 오프로드

TCP Chimney Offload는 병렬 스택 풀 오프로드에 대한 주요 보안 비판을 해결한다.부분 오프로드에서는 메인 시스템 스택이 호스트에 대한 모든 연결을 제어한다.로컬 호스트(일반적으로 서버)와 외부 호스트(일반적으로 클라이언트) 사이에 연결이 설정된 후 연결과 상태는 TCP 오프로드 엔진으로 전달된다.데이터 송수신의 무거운 리프팅은 오프로드 장치에 의해 처리된다.거의 모든 TCP 오프로드 엔진은 호스트 CPU 개입 없이 데이터 전송을 수행하기 위해 TCP/IP 하드웨어 구현의 어떤 유형을 사용한다.연결이 닫히면 오프로드 엔진에서 메인 시스템 스택으로 연결 상태가 반환된다.TCP 연결의 제어를 유지하면 메인 시스템 스택이 연결 보안을 구현하고 제어할 수 있다.

대용량 수신 오프로드

LRO(Large Receiver Offload)는 중앙처리장치(CPU) 오버헤드를 줄여 고대역폭 네트워크 연결의 인바운드 처리량을 높이는 기법이다.하나의 스트림에서 여러 개의 수신 패킷이 네트워킹 스택 위로 더 높게 전달되기 전에 더 큰 버퍼로 통합하여 처리해야 하는 패킷 수를 줄이는 방식으로 작동한다.Linux 구현에서는 일반적으로 NAPI(New API)와 함께 LRO를 사용하여 인터럽트 수도 줄인다.

벤치마크에 따르면, 이 기법을 전적으로 소프트웨어에 구현해도 네트워크 성능을 크게 높일 수 있다고 한다.[6][7][8]2007년 4월 현재 리눅스 커널은 소프트웨어에서만 TCP용 LRO를 지원한다.FreeBSD 8은 이를 지원하는 어댑터의 하드웨어에서 LRO를 지원한다.[9][10][11][12]

LRO는 엔드투엔드 원칙을 깨고 성능에 상당한 영향을 미칠 수 있으므로 라우터 역할을 하는 기계에서 작동해서는 안 된다.[13][14]

일반 수신 오프로드

GRO(Generic Receive Offload)는 TCP/IPv4로 제한되지 않거나 LRO에 의해 생성된 문제가 없는 소프트웨어에서 일반화된 LRO를 구현한다.[15][16]

대용량 전송 오프로드

컴퓨터 네트워킹에서 LSO(Large Send Offload)는 CPU 오버헤드를 줄임으로써 고대역폭 네트워크 연결의 송신 처리량을 증가시키는 기술이다.멀티패킷 버퍼를 네트워크 인터페이스 카드(NIC)에 전달해 작동한다.그런 다음 NIC는 이 버퍼를 별도의 패킷으로 분할한다.이 기법은 TCP에 적용할 때 TSO(TCP 세분화 오프로드) 또는 일반 세분화 오프로드(GSO)라고도 한다. LSO와 LRO는 독립적이며 한 기법은 다른 기법을 사용할 필요가 없다.

시스템이 컴퓨터 네트워크를 통해 많은 양의 데이터를 전송할 필요가 있을 때, 그 청크는 우선 라우터나 소스 컴퓨터와 대상 컴퓨터 사이의 스위치와 같은 모든 네트워크 요소들을 통과할 수 있는 더 작은 세그먼트로 분해할 필요가 있다.이 과정을 세분화라고 한다.종종 호스트 컴퓨터의 TCP 프로토콜은 이 분할을 수행한다.이 작업을 NIC로 오프로드하는 것을 TSO(TCP 세분화 오프로드)라고 한다.

예를 들어, 64KiB(65,536바이트)의 데이터 단위는 대개 NIC를 통해 네트워크로 전송되기 전에 각각 1460바이트의 45개 세그먼트로 분할된다.NIC의 일부 인텔리전스를 통해 호스트 CPU는 단일 전송 요청으로 NIC에 64KB의 데이터를 전달할 수 있으며 NIC는 해당 데이터를 1460바이트의 작은 세그먼트로 세분화하고, 호스트의 TCP/IP 스택에서 제공하는 템플릿에 따라 TCP, IP 및 데이터 링크 계층 프로토콜 헤더를 각 세그먼트에 추가하고, 결과물을 전송할 수 있다.네트워크상의 틀이는 CPU가 수행하는 작업을 크게 줄인다. 2014년 현재 시장에 출시된 많은 새로운 NIC가 TSO를 지원한다.

일부 네트워크 카드는 일반적으로 TSO를 충분히 구현하여 다른 전송 계층 프로토콜의 단편화를 오프로드하거나 UDP와 같이 스스로 단편화를 지원하지 않는 프로토콜의 IP 단편화를 수행할 수 있다.

Linux에서 지원

리눅스 커널은 FreeBSD와 같은 다른 운영 체제와 달리 TOE에 대한 지원을 포함하지 않는다(다른 유형의 네트워크 오프로드와 혼동되지 않도록 함).[17]첼시오나 Qlogic과 같은 하드웨어 제조업체의 패치가 TOE 지원을 추가하는 반면 리눅스 커널 개발자들은 다음과 같은 몇 가지 이유로 이 기술에 반대하고 있다.[18]

  • 보안 – TOE는 하드웨어에 구현되기 때문에 특정 TOE 구현에서 발견된 보안 취약점을 해결하기 위해 단순한 소프트웨어 대신 TOE 펌웨어에 패치를 적용해야 한다.이는 TOE를 사용하지 않는 운영 체제에서 발견된 것과 같이 잘 테스트된 TCP/IP 스택과 비교했을 때 이 하드웨어의 새롭고 벤더별 특성으로 인해 더욱 복잡해진다.
  • 하드웨어의 한계 – 연결이 TOE 칩에서 버퍼링되고 처리되기 때문에 운영 체제에서 사용할 수 있는 넉넉한 CPU와 메모리에 비해 리소스 부족이 더 쉽게 발생할 수 있다.
  • 복잡성 – 커널이 항상 모든 리소스에 액세스할 수 있다고 가정하는 TOE – 개방형 연결에 사용되는 메모리와 같은 세부 사항은 TOE와 함께 사용할 수 없다. TOE는 또한 제대로 지원되기 위해 네트워킹 스택을 매우 크게 변경해야 하며, 이 작업이 완료된 경우에도 서비스 품질 및 패킷과 같은 기능을 변경해야 한다. 필터링이 작동하지 않을 수 있음.
  • 독점 – TOE는 각 하드웨어 공급업체에 의해 다르게 구현된다.이는 앞서 언급한 복잡성과 가능한 보안을 희생하여 다양한 TOE 구현을 처리하기 위해 더 많은 코드를 다시 작성해야 함을 의미한다.더욱이 TOE 펌웨어는 폐쇄 소스가므로 쉽게 수정할 수 없다.
  • 노후화 – 각 TOE NIC는 시스템 하드웨어가 TOE 성능 수준을 빠르게 따라잡고 결국 TOE 성능 수준을 초과하기 때문에 사용 수명이 제한적이다.

공급자

현재 TOE 기술에 관한 대부분의 작업은 브로드컴, 첼시오 통신, 에뮬렉스, 멜라노스 테크놀로지, QLogic과 같은 10기가비트 이더넷 인터페이스 카드 제조업체에 의해 이루어지고 있다.

참고 항목

참조

  1. ^ Jeffrey C. Mogul (2003-05-18). TCP Offload Is a Dumb Idea Whose Time Has Come. HotOS. Usenix.
  2. ^ a b Annie P. Foong; Thomas R. Huff; Herbert H. Hum; Jaidev P. Patwardhan; Greg J. Regnier (2003-04-02). TCP performance re-visited (PDF). Proceedings of the International Symposium on Performance Analysis of Systems and Software (ISPASS). Austin, Texas.
  3. ^ 미국 특허: 5355453 "병렬 I/O 네트워크 파일 서버 아키텍처 범주"
  4. ^ 미국 특허: 6247060 "호스트에서 로컬 장치로 통신 블록 전달하여 장치에서 메시지 처리"
  5. ^ "뉴커머 스핀 스토리지 네트워크 실리콘 ", Rick Meritt, 2002년 10월 21일, EE Times
  6. ^ a b Jonathan Corbet (2007-08-01). "Large receive offload". LWN.net. Retrieved 2007-08-22.
  7. ^ a b Aravind Menon; Willy Zwaenepoel (2008-04-28). Optimizing TCP Receive Performance. USENIX Annual Technical Conference. USENIX.
  8. ^ Andrew Gallatin (2007-07-25). "lro: Generic Large Receive Offload for TCP traffic". linux-kernel (Mailing list). Retrieved 2007-08-22.
  9. ^ "Cxgb". Freebsd.org. Retrieved 12 July 2018.
  10. ^ "Mxge". Freebsd.org. Retrieved 12 July 2018.
  11. ^ "Nxge". Freebsd.org. Retrieved 12 July 2018.
  12. ^ "Poor TCP performance can occur in Linux virtual machines with LRO enabled". VMware. 2011-07-04. Retrieved 2011-08-17.
  13. ^ "Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of Adapters". Intel Corporation. 2013-02-12. Retrieved 2013-04-24.
  14. ^ "Disable LRO for all NICs that have LRO enabled". Red Hat, Inc. 2013-01-10. Retrieved 2013-04-24.
  15. ^ "JLS2009: Generic receive offload". lwn.net.
  16. ^ Huang, Shu; Baldine, Ilia (March 2012). Schmitt, Jens B. (ed.). Performance Evaluation of 10GE NICs with SR-IOV Support: I/O Virtualization and network Stack Optimizations. Measurement, Modeling, and Evaluation of Computing Systems and Dependability and Fault Tolerance: 16th International GI/ITG Conference, MMB & DFT 2012. Lecture Notes in Computer Science. Vol. 7201. Kaiserslautern, Germany: Springer (published 2012). p. 198. ISBN 9783642285400. Retrieved 2016-10-11. Large-Receive-Offload (LRO) reduces the per-packet processing overhead by aggregating smaller packets into larger ones and passing them up to the network stack. Generic-Receive-Offload (GRO) provides a generalized software version of LRO [...].
  17. ^ "리눅스 및 TCP 오프로드 엔진", 2005년 8월 22일, LWN.net
  18. ^ Net:TOE, Linux Foundation.

외부 링크