KR100850254B1 - 순서가 어긋난 ＲＤＭＡ Ｓｅｎｄ 메시지들의 전달에관련한 기입 연산들 수의 감소 - Google Patents

Abstract

특정 접속의 모든 세그먼트들이 정렬되어 있는 메모리로의 직접적인 데이터 배치를 수행하거나 특정 접속의 모든 세그먼트들이 비-정렬되어 있는 재조립 버퍼들(34)을 통해 데이터를 이동시키는 RNIC(16) 구현. 재조립 버퍼들(34)에 액세스하지 않으면서 관통하는 접속 유형을, 그것은 정렬될 가능성이 높기 때문에, "고속" 접속이라고 하는 한편, 다른 유형은 "저속" 접속이라고 한다. 소비자가 접속을 확립할 때, 소비자는 접속 유형을 특정한다. 접속 유형은 고속에서 저속으로 그리고 저속에서 고속으로 변할 수 있다. 본 발명은 메모리 대역폭, 지연, TCP 재전송을 사용하는 오류 복구를 감소시키고, 공백 수신 큐로부터의 "우아한 복구"를 제공한다. 본 구현은, 세그먼트 수신을 확인하는 TCP Ack(acknowledgement)를 송신하기 전에, 고속 접속의 대다수 내향 DDP 세그먼트들에 대한 CRC 평가를 수행할 수도 있다.

Description

순서가 어긋난 ＲＤＭＡ Ｓｅｎｄ 메시지들의 전달에 관련한 기입 연산들 수의 감소{REDUCING NUMBER OF WRITE OPERATIONS RELATIVE TO DELIVERY OF OUT-OF-ORDER RDMA SEND MESSAGES}

본 발명은 일반적으로 데이터 전송에 관한 것으로서, 보다 구체적으로는, 정렬된 DDP 세그먼트들을 위한 관통 구현(cut-through implementation)의 RNIC(RDMA enabled network interface controller)에 관한 것이다.

1. 개요

도 1A를 참조하면, 기존 데이터 전송 환경(1)의 블록도가 도시되어 있다. 데이터 전송 환경(1)은 하나 이상의 RNIC(RDMA(remote memory data access) enabled network interface controller(s);4)를 통해 데이터 전송(3B)을 수신하는 데이터 싱크(5;즉, 피어)로 데이터 전송(3A)을 송신하는 데이터 소스(2;즉, 피어)를 포함한다. RNIC(4)는 무엇보다도 (다음에서 부연되는) 재조립 버퍼들(6)을 포함한다. 네트워킹 통신 속도는 최근 10 Mbps(mega bits per second) 내지 100 Mbps에서 1 Gbps(giga bits per second)로 크게 증가하였으며, 이제는 10 Gbps 범위의 속도에 근접하고 있다. 그러나, 통신 대역폭은 이제서야, CPU들(central processing units)이 데이터를 효율적으로 프로세싱할 수 있는 속도를 앞서기 시작 함으로써, 서버 프로세서들, 예를 들어, RNIC(4)에서 병목 현상을 초래하고 있다. 예를 들어, 통상적인 1 Gbps 네트워크 접속이, 완전하게 이용된다면, 2 GHz CPU에게는 큰 부담일 수 있다. 특히, 이와 같은 CPU는 네트워크 카드에서 유래하는 데이터로부터의 저레벨 TCP(transmission control protocol) 프로세싱만을 핸들링하여 스스로의 프로세싱 능력을 약 1/2만큼 확장할 수 있다.

이 문제를 해결하기 위한 일 접근 방법은 TCP/IP(transmission control and Internet protocol) 스택을 CPU에 의해 프로세싱될 소프트웨어가 아니라 하드웨어 FSM(finite state machines)으로 구현하는 것이었다. 이러한 접근 방법은, 배면 결합의 짧은 패킷들(back-to-back short packets)에 대한 유선 속도 프로세싱을 초래하는 초고속 패킷 프로세싱을 허용한다. 또한, 이러한 접근 방법은 저비용으로 아주 컴팩트하며 강력한 솔루션을 제시한다. 불행하게도, TCP/IP 스택은 소프트웨어 구현을 위해 정의되고 개발되었으므로, 하드웨어로 TCP/IP 스택을 발생시키는 것은 광범위하게 새로운 문제점들을 초래해 왔다. 예를 들어, 발생하는 문제점들로는, 소프트웨어-기반의 프로토콜을 하드웨어 FSM들로 구현하고 향상된 성능을 실현하는 방법, ULP(upper layer protocol)의 좀더 빠른 구현을 제공하도록, ULP들(예를 들어, 애플리케이션 프로토콜들)에 대한 바람직하고 효율적인 인터페이스를 설계하는 방법, 및 확대된 구현에서 새로운 병목 현상들을 방지하는 방법을 들 수 있다.

이러한 새로운 문제점들을 해결하기 위해, 기존 ULP와 TCP/IP 스택 사이에 놓기 위한 새로운 통신 계층들이 개발되었다. 불행히도, TCP/IP 스택위에 배치된 프로토콜들은 통상적으로, ULP가 간접적인 데이터 배치를 위한 버퍼들을 공급해야 하기 때문에, 다수의 카피 연산들을 요하는데, 이것이 지연을 가중하며 상당한 CPU 및 메모리 리소스들을 소비한다. 카피 연산들의 양을 감소시키기 위해, iWARP라고 하는 새로운 프로토콜들의 슈트(a suite of new protocols)가 개발되었다.

2. 프로토콜들

도 1B를 참조하여, 이하에서는, iWARP 프로토콜들을 포함하는, 다양한 프로토콜들 및 데이터 전송 포맷 구조의 간략한 개요가 설명될 것이다. 도시된 바와 같이, 각각의 데이터 전송은 다수의 상이한 프로토콜들에 관련된 정보를 포함할 수 있는데, 각각의 프로토콜은 데이터 전송에 관한 상이한 기능을 제공하기 위한 것이다. 예를 들어, 도 1B에 도시된 바와 같이, 이더넷 프로토콜(100)은 IEEE 표준 802.3에 의해 정의되는 LAN(local area network) 액세스를 제공하고; IP(Internet protocol;102)는 필요한 네트워크 라우팅 정보를 추가하며; TCP(transfer control protocol;104)는 외향 TCP 세그먼트들(106;outbound TCP segments)을 스케줄링하고 전달 보증들을 충족시키며; MPA(marker with protocol data unit (PDU) alignment) 프로토콜(108)은 (하나만 표시되어 있지만, 스트림일 수 있는) DDP 세그먼트들(112)에 걸쳐 고정된 구간에서(즉, 매 512 바이트들마다) 역방향 MPA 마커(들)(110)을 포함하는 MPA 프레임(109)을 제공하며, 각각의 MPA 프레임(109)에 길이 필드(114) 및 CRC(cyclic redundancy checking) 필드(116)도 추가한다. 또한, DDP(direct data placement) 프로토콜(120)은 외향 메시지들을 하나 이상의 DDP 세그먼트들(112)로 분할하며, 하나 이상의 DDP 세그먼트들을 DDP 메시지(113)로 재조립하고; RDMA(remote data memory access) 프로토콜(122)은 RDMA Write, Read, Send들을 DDP 메시지들로/로부터 변환한다. 명료화를 위해 하나의 DDP 세그먼트(112)만이 도시되었지만, 다수의 DDP 세그먼트들(112)이 각각의 TCP 세그먼트(106)에 제공될 수 있다는 것을 알 수 있어야 한다.

특별히 RDMA 프로토콜(122)을 살펴보면, RDMA 컨소시엄에 의해 개발된 이 프로토콜은, 메모리 보호 시맨틱스를 보존하면서, 하나의 컴퓨터가 메모리 버스 대역폭 및 CPU(central processing unit) 프로세싱 오버헤드에 대한 요구들을 최소화한 상태에서 다른 컴퓨터의 메모리에 직접적으로 정보를 배치할 수 있게 하는 것에 의해, 데이터 카피 연산들의 제거 및 지연들의 감소를 가능하게 한다. TCP/IP에 비해 RDMA는, 프로세서들 및 메모리에 대한 오버헤드 부담을 감소시키는 것에 의해 데이터 센터내에서의 좀더 효율적이고 측정 가능한 컴퓨팅 및 데이터 전송을 약속하는데, 이로 인해, 프로세서 리소스들은, 사용자 애플리케이션들과 같은, 다른 작업을 위해 이용될 수 있으며 인프라스트럭처 활용을 향상시킨다. 이 경우, 네트워크들이 좀더 효율화됨에 따라, 애플리케이션들은, 작업을 좀더 크고 값비싼 시스템들에 집중시키는 것이 아니라, 네트워크에 걸쳐 태스크들을 공유하는 것에 의해 좀더 양호하게 크기 조정(scale)할 수 있다. RDMA 기능에 의해, 전송자는, 이더넷 바이트 스트림들이 순서가 어긋난 모드로 수신자에서 좀더 용이하게 디코딩되고 실행될 수 있도록, 프레이밍(framing)을 사용해 이더넷 바이트 스트림들에 헤더들을 배치할 수 있는데, 이것은 성능 - 특히 iSCSI(Internet Small Computer System Interface) 및 다른 저장 트래픽 유형들에 대한 성능을 향상시킬 것이다. RDMA에 의해 제시되는 다른 이점은 데이터 센터의 펑크션들을 직접 접속들(interconnects)의 더 적은 유형들에 걸쳐 수렴시킬 수 있는 능력이다. 펑크션들을 더 적은 직접 접속들에 걸쳐 수렴시키는 것에 의해, 얻어지는 인프라스트럭처는 덜 복잡하고, 관리가 좀더 용이하며, 아키텍처 리던던시를 위한 기회를 제공하는데, 이것이 시스템 복원력을 향상시킨다.

특별히 DDP 프로토콜을 살펴보면, 이 프로토콜은, 데이터가 중간 버퍼들 없이 ULP(upper layer protocol)의 수신 버퍼에 직접적으로 배치될 수 있게 하는 메커니즘을 도입한다. DDP는 내향 TCP 세그먼트들을 프로세싱할 때 RNIC(RDMA enabled network interface controller)에 의해 수행되는 (재조립 버퍼들로의 그리고 재조립 버퍼들로부터의) 추가적인 카피를 감소시키고, 일부 경우들에서는, 제거한다.

3. 어려움들

하드웨어 셋팅의 RDMA 및 DDP에 의한 TCP/IP의 효율적 구현에서 직면하게 되는 한가지 어려움은, 표준 TOE(TCP/IP off-load engine) 구현들은 수신 로직에 순서가 어긋나게 수신된 TCP 스트림들을 정렬하기 위한 재조립 버퍼들을 포함하는데, 이것이 카피 연산들을 증가시킨다는 것이다. 또한, 수신자의 데이터 버퍼들에 대한 직접적인 데이터 배치가 완료되기 위해서는, RNIC가, 도달 중인 각각의 TCP 세그먼트 페이로드(127)를 위한 목적지 버퍼를 위치 지정할 수 있어야 한다. 따라서, 모든 TCP 세그먼트들은, 그들이 순서에 따르고 있으며 목적지 버퍼들이 위치 지정될 수 있다는 것을 보장하기 위해, 재조립 버퍼들에 저장된다. 이 문제를 해 결하기 위해, iWARP 설계 명세서들은 전송 중인 RNIC에, 생성된 DDP 세그먼트들이 TCP 세그먼트들로 "정렬되는" 방식으로 RDMA 메시지들의 분할을 수행할 것을 강하게 권고한다. 그럼에도 불구하고, 정렬되지 않은 DDP 세그먼트들이 가끔은 불가피한데, 특히 데이터 전송이 다수 인터체인지들을 통과할 경우에 그러하다.

도 1B를 참조하면, "정렬"은, TCP 헤더(126) 직후에 DDP 세그먼트(112)가 수반되고(즉, MPA 헤더가 TCP 헤더를 수반한 다음, DDP 헤더를 수반하고), DDP 세그먼트(112)는 하나의 TCP 세그먼트(106)에 완전히 포함된다는 것을 의미한다. 좀더 구체적으로, 각각의 TCP 세그먼트(106)는 TCP 헤더(126) 및 TCP 페이로드/TCP 데이터(127)를 포함한다. "TCP 홀"(130)은 TCP 데이터 스트림에서의 손실 TCP 세그먼트(들)이다. MPA 마커들(110)은, 순서가 어긋난 TCP 세그먼트(106)가 수신될 경우를 위한 데이터를 제공하고, 수신자는, TCP 세그먼트(106) 내부의 MPA 프레임(109)이 TCP 세그먼트(106)와 정렬되어 있는지의 여부를 알고 싶어한다. 각각의 마커(110)는, 특정 접속의 ISN(Initial Sequence Number)으로 시작해, TCP 스트림에 등간격(512 바이트)으로 배치되고, 그것이 통과하는 MPA 프레임(109)의 DDP/RDMA 헤더(124)를 포인팅한다. 제 1의 순차적 식별 번호가 제 1의 TCP 세그먼트(106)에 할당되고, 후속 TCP 세그먼트들(106)의 ISN 각각은 증분된 시퀀스 번호를 포함한다.

도 1B에서, 실선들은, TCP 헤더(126) 직후에 MPA 길이 필드(114) 및 DDP/RDMA 헤더(124)가 수반되며 DDP 세그먼트(112)가 TCP 세그먼트(106)에 완전히 포함되어 있는 정렬된 데이터 전송을 예시한다. DDP 프로토콜(120) 계층의 점선 은, TCP 헤더(126) 직후에 MPA 길이 필드(114) 및 DDP/RDMA 헤더(124)가 수반되지 않는 비-정렬 DDP 세그먼트(112NA)를 지시한다. 비-정렬 DDP 세그먼트는, 예를 들어, RNIC들을 송신하고 수신하는 도중에 존재할 수 있는 중간-박스에 의한 재-분할 또는 진행 중인 MSS(maximum segment size)의 감소로부터 유래할 수 있다. 전송자 RNIC는 DDP 분할(TCP 스트림에서의 DDP 헤더들의 위치)을 변경할 수 없으므로, 재전송 연산은, 더 큰 MSS에 의한 원래의 DDP 세그먼트들의 생성에도 불구하고, 감소된 새로운 MSS를 요할 수 있다. 어떤 경우이든, 카피 연산들의 증가는 속도 및 효율성을 감소시킨다. 따라서, 비-정렬 DDP 세그먼트 배치 및 전달과는 상이한 방식으로 정렬 DDP 세그먼트 배치 및 전달을 핸들링하기 위한 방법에 대한 업계의 수요가 존재한다.

핸들링 중인 비-정렬 DDP 세그먼트(112NA)에 관한 다른 어려움은, 비-정렬을 발생시키는 것이 무엇인지를 대개는 판정하기 어렵다는 사실에 의해 발생된다. 예를 들어, 하나의 비-정렬 DDP 세그먼트(112NA)는 2 이상의 TCP 세그먼트들(106) 사이에서 분리될 수 있고, 그들 중 하나는 도달하고 다른 것은 도달하지 않을 수 있다. 다른 경우로서, 일부의 DDP 세그먼트들(112NA)은 MPA 마커들(110) 사이에 떨어질 수 있고, 헤더가 손실되거나 세그먼트 테일이 손실될 수 있는 등이다(후자의 경우, 세그먼트를 부분적으로 배치할 수 있고, 나머지 부분이 도달할 때, 그것을 어디에 배치할 것인지를 추측하기 위해서는 일부 정보를 유지해야 한다). 이러한 후자의 경우와 관련하여, 도 1C는, 하나 이상의 비-정렬 DDP 세그먼트들(112NA)을 위한 MPA 마커 참조들에 관한 가능한 상황들의 블록도를 나타낸다. 경우 A는, 새 롭게 수신된 DDP 세그먼트(126)의 DDP 세그먼트 헤더(160)가 앞서 프로세싱된 DDP 세그먼트(166)의 MPA 길이 필드(164)에 의해 참조되는 상황을 예시한다. 경우 B는, 새롭게 수신된 DDP 세그먼트(162) 헤더(160)가 새롭게 수신된 DDP 세그먼트(162) 내부에 배치된 마커(168)에 의해 참조되는 상황을 예시한다. 다시 말해, 마커(168)는 새롭게 수신된 DDP 세그먼트(162)의 시작을 참조하고 있다. 경우 C는, 마커(168)가 새롭게 수신된 DDP 세그먼트(162)에 배치되어 있지만, 세그먼트 외부를 포인팅하는 상황을 예시한다. 경우 D는, 마커(168)가 새롭게 수신된 DDP 세그먼트(162)에 배치되어 있으며 세그먼트 내부를 포인팅하는 상황을 예시한다. 경우 E는, 마커가 새롭게 수신된 DDP 세그먼트(162)에 배치되어 있지 않은 상황을 예시한다. 어떤 경우에서든, DDP 세그먼트 비-정렬의 원인이 판정될 수 없다면, 적절히 해결해야 할 너무 많은 경우들 및 중간 스토리지에 보유해야 할 너무 많은 정보/불완전한 세그먼트들이 존재하기 때문에, RNIC는 직접적인 데이터 배치를 수행할 수 없다. 따라서, 정렬 및 비-정렬 DDP 세그먼트들의 상이한 핸들링을 제공하는 어떤 솔루션도 비-정렬을 발생시킬 수 있는 다양한 상황들을 해결해야 한다.

4. DDP/RDMA 연산 흐름

도 1D 내지 도 1H를 참조하여, 이하에서는, DDP/RDMA 연산 흐름의 간략한 개요가 이후의 상세한 설명을 위해 설명될 것이다. DDP 프로토콜(120)을 특별히 살펴보면(도 1B), DDP는 태그형 및 비태그형 메시지들이라고 하는 메시지들의 2가지 유형들을 제공한다. 도 ID를 참조하면, "태그형 메시지"에서, 각각의 DDP 세그먼트(112)(도 1B)는 데이터가 직접적으로 배치될 수 있는 수신자상의 목적지 버퍼에 서의 메모리 영역/윈도(예를 들어, 도 1G의 메모리 영역(232))를 식별하는 DDP/RDMA 헤더(124)의 STag( steering tag), 이 영역/윈도에서의 TO(target offset), 및 (나타내지 않은) 세그먼트 페이로드를 전달한다. 이 경우, 목적지 버퍼의 가용성은 STag를 통해 "광고된다". 도 1E를 참조하면, "비태그형 메시지"는, 원격 전송자가 수신자에서의 버퍼들을 알 수 없는 메시지이고, 수신자에 의해 적당한 버퍼들을 판정하는데 사용될 수 있는 QN(message with aqueue ID), MSN(message sequence number) 및 MO(message offset)를 송신한다.

도 1F 내지 도 1H를 참조하면, RDMA 프로토콜은 메시지들의 4가지 유형들: Send(200), Write(202), Read(204), 및 Read Response(206)를 정의한다. 도 1A로 돌아가면, 동사 인터페이스(7)는 소비자에게 RNIC(4)를 제시하고, RNIC(4) 리소스들을 할당하고 할당 해제하기 위한 그리고 WR(work requests;208)을 RNIC(4)에 포스팅하기 위한 방법들을 포함한다. 동사 인터페이스(7)는 대부분 2개 부분들: 소비자들에게 사용자 공간을 제공하는 사용자 공간 라이브러리(9A) 및 소비자들에게 커널 공간을 제공하는 커널 모듈(9B)을 가진 동사 라이브러리(8)에 의해 구현된다. 동사 인터페이스(7)는, RNIC(4) 하드웨어 및 펌웨어와 함께 동작하는 RNIC-특정 소프트웨어이다. 동사 인터페이스(7)(동사 라이브러리(8)), 하드웨어 및 펌웨어로 무엇이 구현되어야 하는지에 대한 엄격한 정의는 존재하지 않는다. 동사 인터페이스(7)는 소비자에게 RNIC(4) 서비스들을 제공함으로써, 사용자가 주로 연산들의 2가지 유형들: RNIC(4) 리소스들의 관리(할당 및 할당 해제) 및 RNIC(4)로의 WR(work request(s)) 포스팅을 수행할 수 있는 단일 패키지로서 보여질 수 있다. RNIC(4) 리소스 관리의 예들로는 큐 쌍 할당 및 할당 해제, (이하 "CQ"라고 하는) 완결 큐 할당 및 할당 해제, 또는 메모리 영역 할당 및 할당 해제를 들 수 있다. 이러한 관리 태스크들은 다음에서 부연될 것이다.

도 1F 내지 도 1H에 도시된 바와 같이, 소비자는 작업 요청들(208)이 포스팅되는 큐 쌍을 할당한다. (이하 "QP"라고 하는) "큐 쌍"은 TCP 접속과 연관되고 한 쌍의 작업 큐들(예를 들어, 송신 및 수신;210, 212) 뿐만 아니라 각각의 큐를 위한 (나타내지 않은) 포스팅 메커니즘도 포함한다. 각각의 작업 큐(210, 212)는 WQE들(Work Queue Elements;216)의 리스트인데, 여기에서, 각각의 WQE는 하나의 작업 요청(WR;208)을 설명하는 약간의 제어 정보를 보유하고 소비자 버퍼들을 참조한다(또는 포인팅한다). 소비자는, 동사 인터페이스(7;도 1A) 및 RNIC(4;도 1A)가 포스팅된 작업 요청들(WR;208)을 실행하게 하기 위해, 작업 요청(WR;208)을 작업 큐들(210, 212)로 포스팅한다. 또한, 소비자가 직접적으로 상호 작용하지 않는 QP를 구성할 수 있는, 판독 큐(214;도 1H) 및 WQE들(work queue elements;216)과 같은, 리소스들도 존재한다.

WQE(216)에 의해 보유될 수 있는 통상적인 정보는 (즉, RDMA Send, RDMA Write, RDMA Read 등일 수 있는 Send WR(208S)을 위한, RDMA Receive만일 수 있는 Receive WR(208R)을 위한) 소비자 WR(work request) 유형, 및 수신 데이터를 위한 위치를 전송하거나 표현하기 위한 데이터를 전달하는 소비자 버퍼들의 기술(description of consumer buffers)이다. WQE(216)는 항상 단일 RDMA 메시지로 기술/대응된다. 예를 들어, 소비자가 RDMA Write 유형의 Send WR(208S)을 포스팅 할 때, 동사 라이브러리(도 1A)는, RDMA Write 메시지를 사용해, 데이터가 취해져야 하고 응답자에게 송신되어야 하는 소비자 버퍼들을 설명하는 WQE(216S)를 구축한다. 다른 예에서는, Receive WR(208R;도 1F)이 존재한다. 이 경우, 동사 라이브러리(8;도 1A)는 수신된 Send 메시지(200)의 페이로드를 배치하는데 사용될 소비자 버퍼를 보유하는 RQ(receive queue;212)에 WQE(216R)를 추가한다.

동사 라이브러리(8;도 1A)가 새로운 WQE(216)를 SQ(send queue;210) 또는 RQ(receive queue;212)에 추가할 때, 동사 라이브러리(8)는 새로운 WQE(216)가, 각각, SQ(send queue)/RQ(receive queue)에 추가되었다는 것을 RNIC(4;도 1A)에 통지한다(이것을 여기에서는 "도어벨 울리기"라고 한다). 이러한 "도어벨 울리기(doorbell ring)" 연산은 대부분, RNIC 하드웨어에 의해 검출되고 디코딩되는 RNIC 메모리 공간으로의 기입이다. 따라서, 도어벨 울리기는, 각각, 특정된 SQ/RQ를 위해 수행될 필요가 있는 새로운 작업이 존재한다는 것을 RNIC에 통지한다.

RNIC(4;도 1A)는 계류 중인(포스팅된) WQE들(216)을 가진 SQ들(send queues;210)의 리스트를 보유한다. 또한, RNIC는 그러한 SQ들(210) 사이에서 중재하고, 그것들을 하나씩 차례로 서빙한다. RNIC(4)가 서빙을 위해 SQ(210)를 선택할 때, 그것은 서빙을 위한 후속의 WQE(216)를 판독하고(WQE들은 그들이 소비자에 의해 포스팅된 순서로 RNIC에 의해 프로세싱되고), 요청된 RDMA 메시지에 속하는 하나 이상의 DDP 세그먼트들(220)을 발생시킨다.

이하에서는, 도 1F 내지 도 1H를 참조하여 RDMA 메시지들의 특정 유형들에 대한 핸들링이 설명될 것이다. 도 1F에 도시된 바와 같이, RNIC(요청자)는 특정 SQ(send queue;210S)를 서빙할 것을 선택한다. RNIC는 SQ(210S)로부터 WQE(216S)를 판독한다. 이 WQE(216S)가 RDMA Send 요청에 대응되면, RNIC는 Send 메시지를 발생시키고, 이 메시지를 피어 RNIC(응답자)로 송신한다. 발생된 메시지는, 예를 들어, 3개의 DDP 세그먼트들(220)을 포함할 수 있다. RNIC(응답자)가 Send 메시지를 수신할 때, RNIC는 RQ(receive queue;212)로부터 WQE(216R)를 판독하고, 수신된 PDP 세그먼트들(220)의 페이로드를 그러한 WQE(216R)에 의해 참조되는 소비자 버퍼들(즉, 응답자 Rx 버퍼)에 배치한다. Send 메시지(200)가 순서대로 수신되면, RNIC는 RQ(212)로부터 제 1의 미사용 WQE(216R)를 선택한다. WQE들(216R)은, 그들이 소비자에 의해 포스팅된 순서로 RQ(212)에 연쇄된다. 미태그형 DDP 메시지의 관점에서, Send 메시지(200)는, 1로 초기화되고 동일한 DDP 큐에 속하는 송신된 각각의 DDP 메시지(220)로써 전송자에 의해 단조롭게 증가되는 MSN(Message Sequence Number;도 IE)을 전달한다. (태그형 메시지들은 RDMA Write 메시지(202)와 관련하여 후술될 것이다). DDP 큐는 DDP 헤더의 QN(Queue Number;도 1E)에 의해 식별된다. RDMA 프로토콜은 3개의 DDP 큐들: 내향의 RDMA Send들을 위한 QN #0, 내향의 RDMA Read 요청들을 위한 QN #1, 및 내향의 Terminate들을 위한 QN #2를 정의한다. 따라서, Send 메시지(200)가 순서가 어긋나게 도달하면, RNIC(4)는 그 메시지의 MSN을 사용해 그러한 Send 메시지(200)에 대응되는 WQE(216R)를 찾아낼 수 있다. 수신된 하나의 Send 메시지(200)는 RQ(212)로부터 하나의 WQE(216R)를 소비한다. 포스팅된 WQE의 부족 또는 WQE 버퍼들의 길이를 초과하는 메시지 데이터 길이는 결정적인 오류로 간주되고 접속 종료를 초래한다.

도 1G 및 도 1H를 참조하여, 이하에서는, 태그형 연산들을 사용해, RDMA Write 메시지(202) 및 RDMA Read 메시지(204)의 일부가 설명될 것이다. 태그형 연산들을 사용하기 위해, 소비자는 메모리 영역(232)을 등록해야 한다. 메모리 영역(232)은 수신자, 즉, 도 1G의 응답자상에서의 사실상 연속적인 한 덩어리의 핀형 메모리이다. 메모리 영역(232)은 그것의 시작하는 VA(virtual address), 길이, 액세스 권한들, 및 그 메모리 영역(232)과 연관된 물리적 페이지들의 리스트에 의해 기술된다. 메모리 영역(232) 등록의 결과로서, 소비자는, 등록된 그 메모리 영역(232)에 액세스하는데 사용될 수 있는 STag(steering tag)를 역수신한다. 원격 소비자(예를 들어, 도 1G의 요청자)에 의한 메모리 영역(232)의 액세스는 로컬 소비자(예를 들어, 도 1G의 응답자)와의 상호 작용이 전혀 없는 상태에서 RNIC(4)에 의해 수행된다. 소비자가 원격 메모리(232)에 액세스하기를 원할 때, 그것은, 각각, RDMA Write 또는 RDMA Read 유형의 Send WR(208W 또는 208R;도 1H)을 포스팅한다. 동사 라이브러리(8;도 1A)는 대응되는 WQE들(216W(도 1G) 또는 216R(도 1H))을, 각각, SQ(210W 또는 210R)에 추가하고, RNIC(4)에 통지한다. 접속이 통신 규약을 획득하면, RNIC(16)는 WQE들(216W 또는 216R)을 판독하고, 각각, RDMA Write 메시지(202) 또는 RDMA Read 메시지(204)를 발생시킨다.

RDMA Write 메시지(202)를 특별히 고려하면, 도 1G에 도시된 바와 같이, RDMA Write 메시지(202)가 RNIC(4)에 의해 수신될 때, RNIC는 STag와 TO(도 1D) 및 (그 메시지에 속하는) DDP 세그먼트들의 헤더에서의 길이를 사용해 등록된 메모리 영역(232)을 찾아내고, RDMA Write 메시지(202)의 페이로드를 메모리(232)에 배치 한다. 수신자 소프트웨어 또는 CPU(즉, 도시되어 있는 응답자)는 데이터 배치 연산에 관여하지 않으며, 이 연산이 발생했다는 것을 알지 못한다.

RDMA Read 메시지(204)를 특별히 고려하면, 도 1H에 도시되어 있는 바와 같이, 메시지가 RNIC(4)(도 1A)에 의해 수신될 때, RNIC는 RDMA Read Response 메시지(206)를 발생시키고, 그것을 원격 호스트, 즉, 도시되어 있는 요청자로 역 송신한다. 이 경우, 수신 큐는 판독 큐(214)로서 참조된다. RDMA Read Response(206)의 발생 또한, 이 연산이 발생했다는 것을 알지 못하는 로컬 소비자(즉, 응답자)의 관여없이 수행된다. RDMA Read Response(206)이 수신될 때, RNIC(4)(도 1A)는 이 메시지를 RDMA Write 메시지(204)를 핸들링하는 것과 유사하게 핸들링한다. 다시 말해, 그것은 요청자측의 메모리 영역(232)에 기입한다.

소비자 작업 요청들을 핸들링하는 이외에, RNIC(4)(도 1A)는, 도 1F 내지 도 1H에 도시된 바와 같이, 소비자에게 그러한 요청들의 완결에 관해서도 통지한다. 완결 통지는 (동사 라이브러리(8)에 의해 제공되는 전용 펑크션을 통해) 소비자에 의해 할당되는 또 하나의 RNIC 리소스인 완결 큐들(240)을 사용하는 것에 의해 이루어진다. 완결 큐(240)는 CQE들(completion queue elements;242)을 포함한다. CQE들(242)은, RNIC(4)(도 1A)가 소비자 WR(208S, 208W, 208RR)의 완결을 보고할 때, RNIC(4)(도 1A)에 의해 완결 큐(CQ;240)에 배치된다. 각각의 작업 큐(즉, SQ(210), RQ(212))는 연관된 완결 큐(CQ;240)를 가진다. (주: 판독 큐(214)는 하드웨어에 의해 유지되는 내장형 큐이고, 소프트웨어에 비가시적이다. 따라서, CQ(240)는 이 큐와 관련이 없으며, 소비자는 이 큐를 할당하지도 그것의 존재에 관 해 알지도 못한다). 그러나, 동일한 완결 큐(CQ;240)가 하나 이상의 SQ(210) 및 RQ(212)와 연관될 수 있다는 것에 주의해야 한다. 연관은 QP(queue pair) 할당시에 수행된다. 연산에서, 소비자가 WR(208)을 SQ(210)로 포스팅할 때, 소비자는, 이 요청이 완결될 때 통지 받기를 원하는지의 여부를 특정할 수 있다. 소비자가 완결 통지를 요청했다면, RNIC(4)는 WR의 완결시에 CQE(242)를 SQ(210)와 연관되어 있는 연관 CQ(240)에 배치한다. RDMA 프로토콜은 SQ(210)로 포스팅된 WR(208)을 위한 초간편 완결 발주를 정의한다. 특히, RDMA Send WR(208S) 및 RDMA Write WR(208W)은, 이들이 안전하게 전송되었을 때 완결된다. RDMA Read WR(208R)은, 대응되는 RDMA Read Response 메시지(206)가 수신되어 메모리 영역(232)에 배치되었을 때, 완결된다. 소비자 WR은, 그들이 SQ(210)로 포스팅된 순서로 완결된다. 도 1F를 참조하면, RQ(210)로 포스팅된 WR 각각도 완결 통지를 요한다. 따라서, RNIC(4)(도 1A)가 수신된 Send 메시지(200)의 배치를 마쳤을 때, RNIC(4)(도 1A)는 그러한 RQ(212)와 연관된 CQ(240)에 CQE(242)를 배치한다.

상기 관점에서, 업계에는 정렬 DDP 세그먼트 배치 및 전달을 비-정렬 DDP 세그먼트 배치 및 전달과 상이하게 핸들링하는 방법에 대한 수요가 존재한다.

본 발명은, 특정 접속의 수신된 DDP 세그먼트들 모두가 정렬되어 있는 메모리에 대해 직접적인 데이터 배치를 수행하거나, 특정 접속의 일부 DDP 세그먼트들이 비-정렬되어 있는 재조립 버퍼들을 통해 데이터를 이동시키는 RNIC 구현을 포함한다. 재조립 버퍼들에 액세스하지 않으면서 관통하는 접속 유형을 "고속" 접속이라고 하는 반면, 다른 유형을 "저속" 접속이라고 한다. 소비자가 접속을 확립할 때, 소비자는 접속 유형을 특정한다. 예를 들어, 인터넷을 통해 다른 대륙으로 통과할 접속은 세그먼트들이 정렬된 상태로 수신지에 도달할 확률이 낮으므로, 소비자에 의해 "저속" 접속 유형으로 특정되어야 한다. 반면, SAN(storage area network)의 2개 서버들을 접속하는 접속은 모든 DDP 세그먼트들이 정렬될 확률이 아주 높으므로, 소비자에 의해 "고속" 접속 유형으로서 특정될 것이다. 접속 유형은 고속에서 저속으로 그리고 저속에서 고속으로 바뀔 수 있다. 본 발명은 메모리 대역폭, 지연, TCP 재전송을 사용하는 오류 복구를 감소시키고, 공백 수신 큐, 즉, 수신 큐가 내향의 미태그형 DDP 세그먼트를 위해 포스팅된 WQE를 갖지 않을 경우로부터의 "우아한 복구(graceful recovery)"를 제공한다. 기존의 구현은 접속 종결로써 종료할 것이다. 이에 반해, 본 발명에 따른 고속 접속은 이러한 세그먼트를 드롭(drop)시킬 것이고, 이 상황으로부터 복구되며 접속 종결을 방지하기 위해 TCP 재전송 프로세스를 사용할 것이다. 또한, 본 구현은, 세그먼트 수신을 확인하는 TCP Ack(acknowledgement)를 송신하기 전에, 고속 접속의 대다수 내향 DDP 세그먼트들에 대해 CRC(cyclical redundancy checking) 평가를 수행할 수도 있다. 이것은, CRC 점검에 의해 검출되는 데이터 붕괴로부터의 신뢰 가능한 TCP 서비스들을 사용하는 효율적 복구를 허용한다.

본 발명의 제 1 태양은 순서가 어긋난 RDMA Send 메시지들의 전달에 관련한 기입 연산들의 수를 감소시키는 방법에 관한 것으로서, 본 방법은 CQE(completion queue element)에 기준 카운터를 제공하는 단계; 기준 카운터를 선택된 TCP 홀을 위해 완결된 RDMA Send 메시지들의 수로 설정하는 단계; RDMA 동사 인터페이스에 의해 수행되는 완결을 위한 폴 각각에 대해 기준 카운터를 1만큼 감소시키는 단계; 및 카운터가 0이 되는 경우 개개의 CQ로부터 CQE를 제거하는 단계를 구비한다.

본 발명의 제 2 태양은 순서가 어긋난 RDMA Send 메시지들의 전달에 관련한 기입 연산들의 수를 감소시키기 위한 시스템에 관한 것으로서, 본 시스템은 CQE의 기준 카운터를 선택된 TCP 홀을 위해 완결된 RDMA Send 메시지들의 수로 설정하기 위한 수단; RDMA 동사 인터페이스에 의해 수행되는 완결을 위한 폴 각각에 대해 기준 카운터를 1만큼 감소시키기 위한 수단; 및 카운터가 0이 되었을 경우, 개개의 CQ로부터 CQE를 제거하기 위한 수단을 구비한다.

본 발명의 제 3 태양은, 순서가 어긋난 RDMA Send 메시지들의 전달에 관련한 기입 연산들의 수를 감소시키기 위한 컴퓨터 판독 가능 프로그램 코드가 구현되어 있는 컴퓨터 사용 가능 매체를 구비하는 컴퓨터 프로그램 제품에 관한 것으로서, 본 프로그램 제품은 CQE와 연관된 기준 카운터를 선택된 TCP 홀을 위해 완결된 RDMA Send 메시지의 수로 설정하도록 구성되어 있는 프로그램 코드; RDMA 동사 인터페이스에 의해 수행되는 완결을 위한 폴 각각에 대해 기준 카운터를 1만큼 감소시키도록 구성되어 있는 프로그램 코드; 및 카운터가 0이 되었을 경우, 개개의 CQ로부터 CQE를 제거하도록 구성되어 있는 프로그램 코드를 구비한다.

본 발명의 실시예들에 대한 다음의 좀더 구체적인 설명으로부터 본 발명의 상기 및 다른 사양들을 분명히 알 수 있을 것이다.

본 발명의 실시예들은, 유사한 참조 부호들이 유사한 요소들을 지시하는 다음의 도면들을 참조하여, 상세하게 설명될 것이다.

도 1A는 기존의 데이터 전송 환경 및 RNIC의 블록도를 나타낸다.

도 1B는 TCP/IP 데이터 전송 구조에 대한 기존의 MPA/RDMA/DDP의 블록도를 나타낸다.

도 1C는 하나 이상의 DDP 세그먼트들을 위한 가능한 MPA 마커 기준들의 블록도를 나타낸다.

도 1D는 기존의 태그형 DDP 헤더의 블록도를 나타낸다.

도 1E는 기존의 비태그형 DDP 헤더의 블록도를 나타낸다.

도 1F 내지 도 1H는 기존의 다양한 RDMA 메시지 데이터 전송들의 블록도들을 나타낸다.

도 2A는 본 발명에 따른 데이터 전송 환경 및 RNIC의 블록도를 나타낸다.

도 2B는 도 2A의 RNIC의 접속 문맥의 블록도를 나타낸다.

도 2C는 도 2A의 RNIC에 대한 평가 유닛의 블록도를 나타낸다.

도 3은 RNIC 입력 로직(즉, InLogic) 펑크션들의 흐름도를 나타낸다.

도 4A 및 도 4B는 도 3의 InLogic에 대한 제한된 재전송 시도 모드 실시예를 위한 흐름도들을 나타낸다.

도 5는, 다른 실시예에 따른, 접속 열화 이후의 TCP 세그먼터들의 핸들링을 예시하는 블록도를 나타낸다.

도 6은 도 3의 InLogic에 대한 접속 업그레이드 실시예를 위한 흐름도를 나 타낸다.

도 7은 CRC(cyclical redundancy checking) 계산 및 평가를 위한 초기 시퀀스 번호 협상 구현에 사용하기 위한 MPA 요청/응답 프레임을 나타낸다.

도 8은 CRC 계산 및 평가를 위한 대안의 변경된 MPA 길이 구현을 위한 흐름도를 나타낸다.

도 9는 CRC 계산 및 평가를 위해 무-마커들의 관통 구현(no-markers cut-through implementation)을 사용하는 InLogic의 제 1 대안 실시예를 위한 흐름도를 나타낸다.

도 10은 CRC 계산 및 평가를 위해 무-마커들의 관통 구현을 사용하는 InLogic의 제 2 대안 실시예를 위한 흐름도를 나타낸다.

도 11은, 본 발명에 따른, Read Queue를 포함하는 RDMA Read 및 Read Response 메시지 데이터 전송들의 블록도를 나타낸다.

도 12는 RNIC 출력 로직(즉, OutLogic)에 의해 프로세싱되는 메시지들을 위한 WQE들(work queue elements) 및 TCP 홀들의 블록도를 나타낸다.

도 13은, 본 발명에 따른, CQE(completion queue element)를 포함하는 RDMA Send 메시지 데이터 전송들의 블록도를 나타낸다.

도 14는 도 13의 CQE에 대한 블록도를 나타낸다.

다음의 개요는 I. 개요, II. InLogic, Ⅲ. OutLogic, 및 IV. 결론에 대한 편성 목적만을 위해 제공된다.

I. 개요

A. 환경

첨부 도면들을 참조하면, 도 2A는 본 발명의 일 실시예에 따른 데이터 전송 환경(10)의 블록도이다. 데이터 전송 환경(10)은 하나 이상의 RNIC(remote memory data access (RDMA) enabled network interface controller(s))를 통해 데이터 전송(14B)을 수신하는 데이터 싱크(18;즉, 피어)로 데이터 전송(14A)을 전송하는 데이터 소스(12;즉, 피어)를 포함한다. 설명을 위해, 데이터 전송을 개시하는 엔티티를 여기에서는 "요청자"라고 할 것이고 데이터 전송에 응답하는 엔티티를 여기에서는 "응답자"라고 할 것이다. 마찬가지로, 데이터를 전송하는 엔티티를 여기에서는 "전송자"라고 할 것이고, 데이터 전송을 수신하는 엔티티를 여기에서는 "수신자"라고 할 것이다. 데이터 소스(12) 및 싱크(18) 각각은, 상이한 시점들에서, 데이터의 전송자 또는 수신자이거나 요청자 또는 응답자일 수 있으며, "소스" 및 "싱크"의 레이블들은 전송될 데이터를 보유하는 엔티티를 처음에 지시할 목적을 위해서만 제공된다는 것을 알 수 있어야 한다. 다음 설명은 상기 엔티티들 중 하나를 (RNIC(16) 리소스들을 소비하기 위한) "소비자"로서도 언급할 수 있는데, 이 경우, 좀더 구체적인 레이블은 불필요하다. "목적지 버퍼들"은 수신자에서 데이터를 궁극적으로 수신하는 데이터 스토리지, 즉, 데이터 소스(12) 또는 데이터 싱크(18)의 데이터 버퍼들(50)을 참조할 것이다. 데이터 소스(12) 및 데이터 싱크(18)는 각각 데이터 저장을 위한 데이터 버퍼들(50)을 포함한다.

하드웨어의 관점들에서, RNIC(16)는 iWARP 및 동사들의 기능을 가진 네트워 크 I/O 어댑터 또는 매입형 컨트롤러와 같은 임의의 네트워크 인터페이스 컨트롤러이다. 또한, RNIC(16)는 동사 인터페이스(20), 액세스 제어(30), (이하, "InLogic"이라고 하는) RNIC 입력 로직(32), 재조립 버퍼들(34), 내장형 데이터 버퍼(38), (이하, "OutLogic"이라고 하는) RNIC 출력 로직(40), 접속 문맥(42), 평가 유닛(44), 및 다른 컴포넌트들(46)도 포함한다. 동사 인터페이스(20)는, 연산들을 수행하기 위한 RNIC(16) 하드웨어 및 (나타내지 않은) RNIC 드라이버의 조합을 통해 구현되는 바와 같이, 소비자에 대한 RNIC(16)의 프레젠테이션이다. 동사 인터페이스(20)는 2가지 부분들: 사용자 공간 라이브러리(24) 및 커널 모듈(26)을 가진 동사 라이브러리(22)를 포함한다. 액세스 제어(30)는 InLogic(32)으로의 액세스를 제어하기 위해 현재 공지되어 있거나 나중에 개발될 임의 로직을 포함할 수 있다. 재조립 버퍼들(34)은 데이터 전송(14A, 14B)에 관련한 데이터의 임시 저장을 위한 임의 메커니즘을 포함할 수도 있다. 특히, 재조립 버퍼들(34)은 흔히, 다음에서 부연되는 바와 같이, 순서가 어긋난 TCP 스트림들의 임시 저장을 위해 사용된다. 다른 컴포넌트들(46)은, RNIC(16)의 연산을 위해 필요하지만 여기에서 설명되지는 않는 임의의 다른 로직, 하드웨어, 소프트웨어 등을 포함할 수도 있다.

도 2B를 참조하면, 접속 문맥(42)은 접속-특정 데이터를 저장하기 위한 다수 필드들을 포함한다. 다른 문맥 데이터(60)는, 여기에서 설명되지는 않지만 당업자라면 알 수 있는 접속-특정 데이터를 제공한다. 본 발명에 따르면, 2개의 접속 유형들: (이하 "FAST"라고 하는) 고속 접속 및 (이하 "SLOW"라고 하는) 저속 접속을 정의한다. "고속" 및 "저속"이라는 용어들은 정렬된 DDP 세그먼트들을 전달하는 접속 가능성을 언급한다. 접속 유형은 ConnectionType(62)이라고 하는 접속 문맥 필드에서 식별된다. SLOW 접속은, 다음에서 부연되는 바와 같이, SLOW 접속들로서 생성되었거나 내향 데이터의 프로세싱 동안 RNIC(16)에 의해 열화된 RDMA 접속을 위해 사용될 수 있다. 도 2B에 도시된 다른 필드들은, 본 명세서의 어디에서든 그들과 연관된 프로세싱에 관련하여설명될 것이다. 도 2C를 참조하면, 평가 유닛(44)은, 평가 프로세싱을 위해 필요할 수 있는, CRC(cyclic redundancy checking) 로직(64), TCP 체크섬 로직(66), 및 저장-및-전달 버퍼들(68)을 포함한다.

B. RNIC의 일반적 연산

도 2A로 돌아가면, 연산시에, RNIC(16)는 InLogic(32)으로의 액세스를 제어하는 액세스 제어(30)를 통해 데이터 전송(14A)을 수신한다. 접속을 유지하기 위한 정보는, 기존의 경우와 같이, 접속 문맥(42)의 다른 문맥 데이터(60)(도 2B)에 유지된다. InLogic(32)은 데이터 전송(14A)의 내향 TCP 세그먼트들을 프로세싱하고, TCP 체크섬 로직(66)(도 2C)을 통해 수신된 TCP 세그먼트들의 평가를 수행하며, CRC 로직(64)(도 2C)을 통해 MPA CRC를 계산하고, SLOW 접속 데이터 스트림들로부터 FAST 접속 데이터 스트림들을 분리한다. 후자의 펑크션을 참조하면, InLogic(32)은, 다음에서 부연되는 바와 같이, SLOW 접속을 통해 RNIC(16)에 의해 수신된 모든 데이터를 재조립 버퍼들(34)로 향하게 하고, FAST 접속을 다수의 상이한 방법들로 핸들링한다. FAST 접속들과 관련하여, InLogic(32)이 정렬 파괴를 검출하면(즉, TCP 헤더 직후에 DDP 헤더가 수반되지 않으며, DDP 세그먼트가 하나의 TCP 세그먼트에 완전히 포함되어 있지 않으면), 접속은 SLOW 접속으로 열화되고 데이터는 재조립 버퍼들(34)로 유도된다. 대조적으로, 정렬 파괴가 존재하지 않으면, InLogic(32)은 정렬된 내향 DDP 스트림을 내장형 데이터 버퍼(38)로 유도한 다음 수신지 데이터 버퍼(50)로의 직접적인 배치를 위해 OutLogic(40)으로 유도한다. 다른 방법으로는, TCP 세그먼트(106)가 드롭될 수 있고, Ack가 송신되지 않음으로써, 세그먼트의 재-전송을 필요로 한다.

OutLogic(40)은 FAST와 SLOW 접속들 사이에서 중재하며, 양자의 접속 유형 스트림들의 데이터 싱크(18) 데이터 버퍼들(50)로의 데이터 배치를 수행한다. FAST 접속상의 정렬된 DDP 세그먼트들이 목적지 버퍼로의 직접적인 배치를 위해 내장형 데이터 버퍼(38)로 유도되는 상황을 "관통 모드(cut-through mode)"라고 하는데, 정렬된 DDP 세그먼들을 가진 FAST 접속들은, 재조립 버퍼(34)를 우회하여, OutLogic(40)에 의해 직접적으로 배치되기 때문이다. 그러나, 양자의 접속 유형들을 위해, 순서에 따라 수신된 데이터 스트림만이 OutLogic(40)을 통해 데이터 싱크(18)로 전달된다.

Ⅱ. InLogic

도 3을 참조하여, 본 발명에 따른 InLogic(32)(도 2A) 및 데이터 전송(14A)에 대한 그것의 프로세싱의 흐름도가 부연될 것이다. 상기한 바와 같이, InLogic(32)은 내향 TCP 세그먼트들을 프로세싱하고, 수신된 세그먼트들의 TCP 평가를 수행하며, MPA CRC를 계산하고, SLOW 접속 데이터 스트림들로부터 FAST 접속 데이터 스트림들을 분리한다. 다른 언급이 없다면, "S"가 수반되지 않는 참조 부 호들은 도 2A 내지 도 2C에 도시된 구조를 언급한다.

제 1 단계 S1에서, InLogic(32)은 RNIC(16) 접속들에 속하는 데이터 전송(14A)의 TCP 세그먼트들(106)을 필터링하고, 수신된 세그먼트들을 위해 (평가 유닛(44)을 통해) 계산된 CRC 평가 결과들을 갖춘 패킷들을 획득한다. (CRC 평가는, InLogic(32)의 판정 프로세싱 이전에 수행되어야 한다는 것에 주의한다. CRC 평가는, TCP 세그먼트(106)가 FAST 접속에 속하는 것으로 식별되기 전에-단계 S2, TCP 체크섬 계산과 동시에 수행될 수도 있다.)

단계 S2에서, InLogic(32)은, TCP 세그먼트(106)가 SLOW 접속에 속하는지의 여부를 판정한다. 이 경우, InLogic(32)은, 전송자가 접속을 어떻게 레이블링했는지를 판정한다. 예라면, 단계 S3에서, TCP 세그먼트(106)는 재조립 버퍼들(34)로 유도되고, TCP 로직은 이 세그먼트를 성공적으로 수신된 것으로 간주한다.

아니오라면, InLogic(32)은, 단계 S4에서, TCP 세그먼트(106) 길이가 기술된 MPA 세그먼트 길이보다 긴지의 여부를 판정하도록 진행한다. 다시 말해, TCP 헤더(126)에서 기술된 TCP 세그먼트(106) 길이가 MPA 길이 필드(114)에서 기술된 MPA 길이보다 긴지의 여부를 판정한다. 예라면, 이것은, TCP 세그먼트(106)가 다수의 DDP 세그먼트들(112)을 포함한다는 것을 지시하는데, 이것의 프로세싱은 다음에서 설명될 것이다. 아니오라면, 이것은, TCP 세그먼트(106)가 하나의 DDP 세그먼트(112 또는 112NA)를 포함한다는 것을 지시한다.

이러한 후자의 경우, 단계 S5에서, InLogic(32)은, MPA 길이가 TCP 세그먼트(106) 길이보다 긴지의 여부를 판정한다. 예라면, 이것은, 3가지 상황들: 1) 단 일 DDP 세그먼트(112NA)가 TCP 세그먼트(106)로 정렬되지 않으며, MPA 길이 필드인 것으로 가정된 필드가 길이 필드가 아닌 상황; 2) 단일 DDP 세그먼트(112)의 시작이 TCP 세그먼트(106)로 정렬되지 않지만, 단일 DDP 세그먼트의 길이가 TCP 세그먼트(106)의 페이로드 사이즈를 초과하는 상황; 또는 3) 수신된 단일 DDP 세그먼트(112)가 TCP 세그먼트(106)로 정렬되지만, 손상된 MPA 길이 필드(114)를 갖는 상황 중 하나를 지시한다. 처음의 2가지 경우들(1 및 2)은, 정렬되지 않은 단일 DDP 세그먼트(112NA)가 FAST 접속을 통해 수신되었으므로, 단계 S3에서, 접속이 SLOW 접속으로 열화되어야 한다는 것을 지시한다. 세번째 경우(3)는, 접속 열화를 요하지 않는다. 그러나, MPA 프레임(109) 길이가 TCP 세그먼트(106) 길이를 초과하는 이유가 식별될 수 없고 확인될 수 없으므로, 이러한 TCP 세그먼트(106)의 드롭(즉, 상쇄 및 비-전달)은 바람직하지 않은데, 이것은 교착 상태(deadlock;상기, 경우 2)를 초래할 수 있기 때문이다. 다시 말해, 이러한 TCP 세그먼트가 정말로 비-정렬 DDP 세그먼트를 전달했다면, 전송자는 동일한 비-정렬 DDP 세그먼트를 재전송할 것이고, 이것은, 동일한 흐름을 따라, 교착 상태를 초래하며 수신자에 의해 반복적으로 드롭될 것이다. 따라서, InLogic(32)은, 단계 S3에서, TCP 세그먼트(106)의 데이터 전송을 재조립 버퍼들(34)로 유도하고, TCP 세그먼트(106)가 성공적으로 수신되었다는 것을 확인하도록 Ack를 스케줄링하며, 접속을 SLOW 접속으로 열화시킨다(즉, 도 2B의 ConnectionType 필드(62)는 Fast에서 Slow으로 전환된다). 후술되는 바와 같이, MPA 길이 필드(114)가 손상되면(상기 경우 3), 이것은 OutLogic(40)에 의해 검출되고, 접속은 평가 유닛(44)에 의해 검출되는 CRC 오류로 인해 폐쇄될 것 이다. 따라서, 단계 S3에서의 접속 열화가, FAST 접속을 정렬된 DDP 세그먼트(112)에서의 데이터 손상으로 인해 영구적으로 SLOW 접속화하지는 않을 것이다.

단계 S5로 돌아가서, MPA 길이가 TCP 길이보다 길지 않다면, 즉, 아니오라면, 이것은, MPA 프레임(109) 길이가 TCP 세그먼트(106) 길이와 부합한다(동일하다)는 것을 지시한다. InLogic(32)은, 단계 S6에서, CRC 평가 결과들이 이러한 TCP 세그먼트(106)를 위해 유효한지의 여부를 판정하도록 진행한다. 다시 말해, CRC 로직(64)이 "유효한" 지시를 리턴했는지의 여부를 판정하도록 진행한다. 예라면, 이것은, 단일 DDP 세그먼트(112)가 TCP 세그먼트(106) 경계들에 정확하게 들어맞으며(즉, 길이들이 서로 동일하며), 이 세그먼트에 대해 데이터 손상이 검출되지 않았다는 것을 지시한다. 따라서, 단계 S7에서, 단일 DDP 세그먼트(112)는, 수신된 TCP 세그먼트(106)를 수신자의, 예를 들어, 데이터 싱크(18)의 수신지 데이터 버퍼들(50)에 직접적으로 배치하는 OutLogic(40)에 의한 프로세싱을 위해, 수신된 TCP 세그먼트(106)를 RNIC(16)의 내장형 데이터 버퍼(38)에 배치하는 것에 의해 "고속 경로 모드"에서 프로세싱된다. 또한, Ack는 이러한 TCP 세그먼트(106)의 성공적인 수신을 확인하도록 스케줄링된다.

CRC 로직(64)이, 단계 S6에서, "무효한" 지시, 즉, 아니오를 리턴한다면, 이것은, 본 발명에 따라 판정될 수 있는 5가지의 가능한 경우들 중 하나가 존재한다는 것을 지시한다. 도 1C는 가능한 5가지 경우들을 예시하고, 단계들 S8 내지 S10은, InLogic(32)이 각 경우를 핸들링하는 방법을 예시한다. 어떤 경우이든, 프로세싱의 목적은 1) 전송자에 의해 FAST 접속인 것으로 선언된 경우라 하더라도, 비- 정렬 접속들의 종결을 방지하는 것; 2)FAST 접속에 속하는 정렬된 DDP 세그먼트들에서의 데이터 손상으로 인한 접속 종결의 확률을 감소시키는 것; 및 3) 개별적으로 취급될 경우들의 수를 최소값으로 감소시키면서, InLogic(32)을 가능한 단순하게 유지하는 것이다.

단계 S8에서, InLogic(32)은, 도 1C의 경우 A에서 도시된 바와 같이, 새롭게 수신된 DDP 세그먼트(162)의 DDP 세그먼트 헤더(160)가 앞서 프로세싱된 DDP 세그먼트(166)의 MPA 길이 필드(164)에 의해 참조되는지의 여부를 판정한다. 이 경우, 앞서 프로세싱된 DDP 세그먼트(166)의 MPA 길이는 새롭게 수신된 DDP 세그먼트(162)의 MPA CRC 평가 동안 점검되었고, 따라서, 후속 세그먼트의 DDP 헤더(160)에 대한 정확한 위치를 참조한다. 경우 A에 대한 CRC 무효는, 단계 S6에서, 단일 DDP 세그먼트(162) 데이터 또는 헤더(160)가 손상되었다는 것을 의미한다. 새롭게 수신된 세그먼트(162)의 TCP 재전송이 이 문제를 해결한다. 따라서, 단계 S9에서, TCP 세그먼트(106)는 드롭되고, 세그먼트 수신은 확인되지 않은 것으로 간주된다.

새롭게 수신된 DDP 세그먼트(162) 헤더(160)가 앞서 프로세싱된 DDP 세그먼트(166)의 MPA 길이 필드(164)에 의해 참조되지 않으면(즉, 단계 S8에서 아니오라면), InLogic(32)은, 단계 S10에서, 도 1C의 경우 B로서 도시된 바와 같이, 새롭게 수신된 DDP 세그먼트(162) 헤더(160)가 새롭게 수신된 DDP 세그먼트(162) 내부에 위치하는 마커(168)에 의해 참조되는지의 여부를 판정하도록 진행한다. 다시 말해, 마커(168)는 새롭게 수신된 DDP 세그먼트(162)의 시작을 참조하고 있다. 이 경우, CRC 무효는, 단계 S6에서, 1) 마커(168)가 정확한 값을 전달하며, 새롭게 수 신된 DDP 세그먼트(162)는 손상된 DDP 헤더(160) 또는 데이터를 갖거나, 2) 새롭게 수신된 DDP 세그먼트(162) 내부의 마커(168)가 손상되었다는 것을 지시한다. 어떤 경우이든, 새롭게 수신된 DDP 세그먼트(162)의 재전송이 문제를 해결한다. 따라서, 단계 S9에서, TCP 세그먼트는 드롭되고, 세그먼트 수신은 확인되지 않는다.

새롭게 수신된 DDP 세그먼트(162) 헤더(160)가 새롭게 수신된 DDP 세그먼트(162) 내부에 위치하는 마커(168)에 의해 참조되지 않으면, 즉, 단계 S10에서 아니오라면, 3가지 경우들 중 하나가 존재한다. 첫번째, 도 1C의 경우 C로서 도시된 바와 같이, 마커(168)는 새롭게 수신된 DDP 세그먼트(162)에 위치하지만, 세그먼트 외부를 포인팅한다. 두번째, 도 1C의 경우 D로서 도시된 바와 같이, 마커(168)는 새롭게 수신된 DDP 세그먼트(162)에 위치하지만, 세그먼트 내부를 포인팅한다. 세번째, 도 1C의 경우 E로서 도시된 바와 같이, 마커가 새롭게 수신된 DDP 세그먼트(162)에 위치하지 않는다.

경우들 C, D 및 E에서, CRC 로직(64)이 무효 지시를 리턴하는 원인은 불확실하며 데이터 손상 및/또는 비-정렬 DDP 세그먼트(112NA)(도 1B) 수신의 결과일 수 있다. 이러한 세그먼트의 무제한적인 재전송은 비-정렬 DDP 세그먼트(112NA)의 경우에서 교착 상태를 초래할 수 있다. 잠재적 교착 상태를 방지하기 위해, InLogic(32)은, 단계 S3에 도시된 바와 같이, 새롭게 수신된 DDP 세그먼트(162)를 재조립 버퍼들(34)로 유도하고, Ack를 세그먼트의 성공적인 수신을 확인하도록 스케줄링하며, 접속을 SLOW 접속으로 열화시키는 것에 의해, 경우들 C, D 및 E를 핸들링한다. CRC 로직(64)이 무효 지시를 리턴하는 것이 정렬된 DDP 세그먼트(112) 에서의 데이터 손상으로 인한 것이라면, 이 오류는, 후술되는 바와 같이, SLOW 접속의 데이터를 프로세싱하고 접속이 종결될 때, OutLogic(40)에 의해 검출될 것이다. 그렇지 않으면, 접속은 SLOW 접속 상태를 영원히 유지할 것이다. 그러나, LRAM(Limited Retransmission Attempt Mode)은, 후술되는 바와 같이, 이 문제를 방지할 수 있다.

도 3의 단계 S4로 돌아가, InLogic(32)이, TCP 세그먼트(106) 길이가 MPA 프레임(109) 길이보다 길다고 판정하면, 이것은, TCP 세그먼트(106)가 다수의 DDP 세그먼트들(112)을 포함한다는 것을 지시한다. 이 경우, 단계 S11에서는, CRC 로직(64) 평가 결과들의 순차적 점검이 첫번째에서 마지막 DDP 세그먼트(112)까지 수행된다. 모든 DDP 세그먼트들(112)이 유효한 CRC를 가진다면, 즉, 예라면, 모든 DDP 세그먼트들(112)은 TCP 세그먼트(106)에 완전히 포함되고, 모두는 적절하게 정렬된, 유효한 DDP 세그먼트들(112)이다. 이 경우, InLogic(32)은, 단계 S7에서, 수신된 TCP 세그먼트(106)를 OutLogic(40)에 의한 프로세싱을 위해 RNIC(16)의 내장형 데이터 버퍼(38)에 배치하는 것에 의해 고속 경로 모드에서 DDP 세그먼트들(112)을 프로세싱하는데, 이는, 수신된 TCP 세그먼트(106)를 수신지 데이터 버퍼들, 예를 들어, 데이터 싱크(18)의 데이터 버퍼들(50)에 배치한다. 또한, Ack는 이러한 TCP 세그먼트(106)의 성공적인 수신을 확인하도록 스케줄링된다. InLogic(32)은, 제 1 실패가 검출되었을 때 CRC 평가 결과들의 점검을 중단하는데, 이것의 관리는 단계들 S12-S13에 관련하여 설명된다.

단계 S12에서, InLogic(32)은, 제 1 DDP 세그먼트(112)가 CRC 로직(64)에 의 해 판정되는 바에 따라 무효 CRC를 갖는지의 여부를 판정한다. 예라면, InLogic(32)은 제 1 DDP 세그먼트(112)를 단일 DDP 세그먼트를 위한 무효 CRC 경우와 유사하게 프로세싱한다(단계 S8). 다시 말해, InLogic(32)은 무효 CRC를 가진 제 1 DDP 세그먼트(112)를 단일 DDP 세그먼트(112)로서 취급하고 무엇이 CRC 무효의 원인인지를, 즉, 경우들(A-E) 중 어떤 것이 적용되는지를 그리고 그 경우를 적절하게 핸들링하는 방법을 판정하도록 진행한다.

단계 S12의 결과가 아니오라면, 즉, 제 1 DDP 세그먼트(112)가 유효 CRC를 가진다면, InLogic(32)은, 단계 S13에서 중간 또는 마지막 DDP 세그먼트(112)를 점검할 때 CRC 무효가 검출되었는지의 여부를 판정하도록 진행한다. 예라면, 이 오류는, CRC 무효를 발생시킨 DDP 세그먼트(112)의 데이터 또는 헤더(즉, 유효 CRC를 가진 선행 DDP 세그먼트의 길이)가 손상되었다는 것을 지시하므로, InLogic(32)(도 1)은 단계 S9로 진행한다. 다시 말해, CRC 오류는 동일한 TCP 세그먼트(106)의 중간 또는 마지막 DDP 세그먼트(112)에서 검출되었고, 이것은, 선행 DDP 세그먼트가 유효한 CRC를 가지며, 따라서, 선행 DDP 세그먼트의 길이가 무효한 CRC를 가진 세그먼트의 헤더를 포인팅한다는 것을 의미한다. 이것은 경우 A(도 1C)의 기술과 부합한다. 따라서, 경우 A에서 설명된 바와 같이, 헤더의 위치가 공지되고, 따라서, CRC 오류는 데이터 또는 헤더 손상에 의해 발생된 것으로 공지된다. 따라서, 전체 TCP 세그먼트의 재전송이, 교착 상태 상황의 리스크가 전혀 없는 상태에서, 이 문제를 해결할 것이다. 단계 S9에서, TCP 세그먼트는 드롭되고, 세그먼트 수신은 확인되지 않는다.

단계 S13의 결과가 아니오라면, 즉, 중간 또는 마지막 DDP 세그먼트(112)가 CRC 무효를 발생시키지 않았다면, 이것은, 마지막 DDP 세그먼트(112)의 MPA 길이 필드가 TCP 세그먼트(106)의 경계들을 초과한다는 것, 즉, 마지막 DDP 세그먼트가 TCP 세그먼트(106)의 경계들 밖에 있거나 너무 길다는 것을 지시한다. 이 경우, InLogic(32)은 너무 긴 단일 DDP 세그먼트(112)와 동일한 상황을 취급한다. 특히, InLogic(32)은, 단계 S3에서, TCP 세그먼트(106)의 데이터 전송(14A)을 재조립 버퍼들(34)로 유도하고, TCP 세그먼트(106)가 성공적으로 수신되었다는 것을 확인하도록 Ack를 스케줄링하며, 접속을 SLOW 접속으로 열화시킨다. 이런 식으로, 교착 상태가 방지된다. RNIC(16)가 TCP 세그먼트(106)에 포함되어 있는 다수의 DDP 세그먼트들(112) 중 하나를 드롭시키기로 판정하면, 전체 TCP 세그먼트(106)가 드롭되는데, 이는, 구현을 단순화하며 핸들링되어야 하는 경우들의 수를 감소시킨다.

앞서 명시적으로 논의되지는 않았지만, 다른 데이터 전송 프로세싱도 InLogic(32)의 상술된 연산과 함께 수행될 수 있다는 것을 알 수 있어야 한다. 예를 들어, TCP 체크섬 로직(66)(도 2C)에 의한 체크섬 평가를 포함하여, RNIC(16) 접속들에 속하는 TCP 세그먼트들의 필터링 및 수신된 세그먼트들의 TCP/IP 평가들도 수행될 수 있다. 내향 TCP 세그먼트(106)의 프로세싱도 MPA CRC의 계산 및 CRC 로직(64)(도 2C)에 의한 이러한 CRC의 평가를 포함할 수 있다. CRC 계산 및 평가의 특정한 일 실시예가 다음에서 부연될 것이다.

A. 제한된 재전송 시도 모드

검출된 오류의 원인에 대한 불확실성과 관련한 다른 실시예로서(예를 들어, 도 3의 단계 S10에서의 아니오는 이러한 상황을 초래할 수 있는 예시적 일 판정임), 교착 상태를 방지하고 불필요하게 SLOW 접속들로 감소되는 FAST 접속들의 수를 감소시키기 위해, "제한된 재전송 시도 모드"가 재전송 시도들의 수를 제한하도록 구현될 수 있다. 특히, 상기된 바와 같이, 경우들 C, D 및 E는, 검출된 오류의 원인에 대한 불확실성으로 인해, 오류가 DDP 세그먼트(112) 정렬의 손실이 아니라 데이터 손상에 의해 발생되었을 경우, 접속이 (OutLogic(40)에 의한) 잠재적 접속 종료의 SLOW 접속으로 열화될 수 있는 몇가지 경우들을 표현한다.

재전송 시도들의 수를 제한하기 위해, 본 발명은, 접속을 열화시키기 전에 소정 횟수의 재전송들을 허용하도록, 접속 문맥(42)(도 2B)에 추가 필드들을 제공한다. 특히, 도 2B에 도시된 바와 같이, 접속 문맥(42)은 다수의 복구 시도 필드(RecoveryAttemptsNum;292), 마지막 복구 시퀀스 번호 필드(LastRecoverySN;294) 및 최대 복구 시도들의 횟수 필드(MaxRecoveryAttemptsNum;296)를 포함하여 한 세트의 필드들(290)을 포함한다. RecoveryAttemptsNum 필드(292)는, 마지막 업데이트 이후로 접속을 위해 수행된 복구 시도들의 수를 보유하고; LastRecoverySN 필드(294)는 마지막으로 개시된 복구 연산의 시퀀스 번호(SN)를 보유하며; MaxRecoveryAttemptsNum 필드(296)는 접속을 열화시키기 전에 InLogic(32)에 의해 수행되어야 하는 복구 시도들의 최대 횟수를 정의한다.

도 4A를 참조하면, 연산시에, InLogic(32)이 (도 4A의 단계 S101로서 일반적으로 도시된 바와 같이) 순서에 따른 새로운 수신 데이터 전송이 오류를 포함한다는 것을 검출하면, (도 3의 단계 S3에서) 접속을 즉각적으로 SLOW 접속으로 열화시 키는 것이 아니라, InLogic(32)은 그러한 오류-포함 데이터 전송을 위해 수행될 소정 횟수의 재전송들을 제공한다. 단계 S101은 비-정렬 DDP 세그먼트(112NA)나 데이터 손상에 의해 발생되는 다수 오류 판정들에 대해 일반적이라는 것(단계 S101은, 예를 들어, 도 3의 단계 S5에서의 예에 대해서 또는 도 3의 단계 S10에서의 아니오에 대해서도 적용될 수 있다는 것)을 알 수 있어야 한다. 단계 S102에서, InLogic은, RecoveryAttemptsNum을 1만큼 증가시키는 것에 의해, 이러한 오류-포함 데이터 전송을 위한 전송 시도를 기록하도록 진행한다. 또한, InLogic은 LastRecoverySN을 앞서 저장된 시퀀스 번호와 새롭게 수신된(그러나 드롭된) 데이터 전송의 시퀀스 번호 중에서 최대 시퀀스 번호를 저장하도록 업데이트한다. 다시 말해, InLogic은 LastRecoverySN을 하나 이상의 앞서 수신된 오류-포함 데이터 전송과 새롭게 수신된 (그러나 드롭된) 오류-포함 데이터 전송 중에서 최대 시퀀스 번호를 저장하도록 업데이트한다. 새롭게 수신된 오류-포함 데이터 전송은, 새롭게 수신된 오류-포함 데이터 전송의 시퀀스 번호를 저장된 최대 시퀀스 번호와 비교하는 것에 의해, 최대 시퀀스 번호보다 큰 시퀀스 번호를 갖는 것으로 판정된다. LastRecoverySN 기록의 중요성은 다음에서 분명해질 것이다.

다음으로, 단계 S103에서, InLogic(32)은, RecoveryAttemptsNum(필드 292)이 MaxRecoveryAttemptsNum(필드 296)을 초과하는지의 여부를 판정한다. 아니오라면, 단계 S104에서, InLogic(32)은 TCP 세그먼트(106)를 드롭시키고 성공적인 수신을 확인하지 않는데, 이는, TCP 세그먼트의 재전송을 발생시킨다. 그 다음, 프로세싱은 단계 S1(도 3)으로 복귀한다. TCP 세그먼트(106)가 손상되었다면, 재전송은, 데이터 전송(14A)이 (도 3의 단계 S7에서) FAST 접속으로서 메모리에 직접적으로 배치되도록, 손상을 교정해야 한다. 다른 방법으로, 프로세싱이 (예를 들어, 도 3의 단계 S10에서) 다른 오류 검출들을 계속해서 리턴한다면, RecoveryAttemptsNum(필드 292)은 궁극적으로 MaxRecoveryAttemptsNum(필드 296)을 초과할 것이고 단계 S106에서 예를 초래할 것이다. 이 경우, InLogic(32)은, 로직(32)이 접속을 SLOW 접속으로 열화시키고, 오류-포함 데이터 전송(14A)을 재조립 버퍼(34)에 배치하며, Ack를 이러한 TCP 세그먼트의 성공적인 수신을 확인하도록 스케줄링하는 단계 S105로 진행한다. 상기 프로세스는 오류-포함 데이터 전송 각각에 대해 발생한다.

도 4B는, 데이터 손상이 대개는 연속적인 다수 TCP 세그먼트들에서는 발생하지 않지만, 비-정렬 세그먼트들은 몇개의 후속 TCP 세그먼트들에 영향을 미칠 수 있다는 사실을 다루는 제한된 재전송 시도 모드의 다른 컴포넌트를 표현한다. 예를 들어, FAST 접속은 오랜 시간 동안, 예를 들어, 5시간 동안 유지될 수도 있고, 때때로, 예를 들어, 1시간에 한번, CRC 평가가 실패할 데이터 손상을 가질 수도 있다. 이런 일이 발생함에 따라, RecoveryAttemptsNum(필드 292)은, 오류-포함 데이터 전송(즉, 손상된 세그먼트)이 드롭될 때마다 증가될 수 있다. 이 프로세스는, 상이한 세그먼트들이 상이한 시간들에서의 데이터 손상으로 인해 드롭되고, 몇번의(어쩌면 한번의) 재전송 연산 이후에, 이들 세그먼트들이 성공적으로 수신되어 메모리에 배치되는 상황을 다룬다. 따라서, 이러한 세그먼트들의 복구 연산은 성공적으로 완결되었고, 다시 말해, 새로운 오류 세그먼트의 수신으로 인해 새로운 복구 모드로 진입할 때, 복구되는 데이터 손상 경우들은 카운팅되지 않는다.

제한된 재전송 시도 모드로부터 벗어나기 위해, 순서에 따라 새롭게 수신된 데이터 전송의 TCP 세그먼트 시퀀스 번호(즉, InOrderTCPSegmentSN)가 LastRecoverySN(도 2B의 필드 294)보다 큰지의 여부에 대한 판정이 단계 S105에서 이루어진다. 다시 말해, FAST 접속에 속하는 새롭게 순서에 따라 수신된 TCP 세그먼트 각각의 시퀀스 번호가 하나 이상의 앞서 수신된 오류-포함 데이터 전송들로부터 선택되는 저장된 최대 시퀀스 번호와 비교된다. (더 큰 SN을 가진 순서가 어긋난 세그먼트의 수신이, 오류 복구가 완료되었다는 것을 의미하는 것은 아니라는 것에 주의한다.) 그러나, 복구 모드로의 진입을 발생시켰던 세그먼트(들) 이후에 전송된 TCP 세그먼트가 수신된다는 것은 복구가 완결되었다는 일 표시기이다. 이 상황은, InOrderTCPSegmentSN을 LastRecoverySN과 비교하는 것에 의해 판정될 수 있다. 이 판정은 실제로 이 접속을 위해 수신된 TCP 세그먼트를 프로세싱하는 임의 단계에서 이루어질 수 있다. 예를 들면, 도 3의 단계 S9 이후 또는 도 4A의 단계 S102 이전이다. 순서에 따른 세그먼트 SN이 LastRecoverySN보다 크고, 즉, 새로운 TCP 세그먼트가 수신되고, 단계 S105에서 예라고 판정되면, 단계 S106에서는, RecoveryAttemptsNum(도 2B의 필드 292)은 리셋, 즉, 0으로 설정된다. 상기 예와 관련하여, 단계 S105는, 긴 시간, 예를 들어, 5시간 이후의 FAST 접속의 SLOW 접속으로의 열화를 방지하는데(즉, RecoveryAttemptsNum이 MaxRecoveryAttemptsNum을 초과하기 때문에), 이 경우, 드롭된 세그먼트들은 데이터 손상으로 인해 드롭된 다음, 전송자가 세그먼트를 재전송한 후, 성공적으로 수신되어 정렬된 세그먼트로서 프로세싱되었다. 단계 S105에서 아니오라면 또는 단계 S106 이후에, 세그먼트 프로세싱은 평소처럼, 예를 들어, 도 3의 단계 S1으로 진행한다.

상기 프로세싱을 사용하면, 허용되는 재전송들의 수는, MaxRecoveryAttemptsNum 필드(296)를 설정하는 것에 의해 사용자 정의될 수 있다. 제한된 재전송 시도 모드가 도 4A-4B와 관련하여 설명되고 도 3의 단계 S10에 관련한 오류 검출이 설명되었지만, 제한된 재전송 시도 모드는, 다음에서 부연되는 바와 같이, 단계 S10의 오류 검출 이외에도 적용될 수 있다는 것을 알 수 있어야 한다. 제한된 재전송 시도 모드는 또한, 세그먼트가 ULP 고려들로 인해 드롭되었을 때 즉각적인 중복 Ack를 송신하는, 후술되는 파트 D의 TCP 재전송 프로세스의 가속화(Speeding Up TCP Retransmit Process)에도 도움이 된다는 것에 주의한다.

B. 접속 다운로딩

도 5를 참조해, 이하에서는, 하나 이상의 순서가 어긋나게 수신된 DDP 세그먼트들(112)이 고속 경로 모드로 수신지 데이터 버퍼들(50)에 배치된 후, 접속이 열화되는 고유한 상황을 핸들링하는 것(도 3의 단계 S3)에 대한 논의가 설명될 것이다. 도 5에 도시된 바와 같이, 패킷(Pkt) 레이블링된 4개의 TCP 세그먼트들이 순서가 어긋나게, 즉, 3, 4, 1 및 2의 순서로 수신된다. 접속이 SLOW 접속으로 열화될 때, 열화되는 순간에 수신된 모든 데이터는 재조립 버퍼들(34)에 배치되고 순서대로, 즉, Pkt들 1, 2, 3 및 4로서 재조립된다. 이 경우, TCP 프로토콜에 따르면, InLogic(32)은 그러한 세그먼트들이 수신된 레코드들을 보유한다.

드물기는 하지만, 세그먼트(들), 예를 들어, (음영진) Pkt#3가 수신지 데이 터 버퍼들(50)에 직접적으로 배치되는 상황이 발생할 수도 있다. 이 상황은, 통상적으로 패킷 3(Pkt#3)가 '쓰레기' 데이터, 즉, 갭들 또는 홀들로 채워지게 할 재조립 버퍼들(34)의 위치를 초래하지만, InLogic(32)은 모든 데이터가 수신된 것으로 가정한다. 프로세싱이 계속해서 정정되지 않아도 된다면, OutLogic(40)이 재조립 버퍼들(34)을 수신지 데이터 버퍼들(50)로 전송할 때, 고속 경로 모드를 통해 앞서 전송된 패킷 3(Pkt#3)는 '쓰레기' 데이터로 겹쳐쓰기될 것이고, 이것은 데이터를 손상시킬 것이다.

하드웨어 복잡도를 증가시키지 않으면서 이 문제를 해결하기 위해, 다른 실시예에서, InLogic(32)은, 접속이 FAST 접속이었을 때에 순서가 어긋나게 수신된 세그먼트들(즉, 도 5의 Pkt#3)에 관해 망각할 것을 TCP 로직에 지시한다. 특히, InLogic(32)은, 접속을 단계 S3(도 3)에서 SLOW 접속으로 열화시킬 때 순서가 어긋나게 배치된 데이터 전송을 위해 TCP 홀을 소거하도록 구성되고, 이들 패킷들이 수신되었다고 전송자에 수신 보고하는 것을 중단한다(SACK 옵션). 따라서, 전송자는, 수신지 데이터 버퍼들(50)에 순서가 어긋나게 직접적으로 배치된 세그먼트(들), 즉, Pkt#3를 포함하여, 긍정 확인되지 않은 모든 데이터를 재전송한다. 재전송된 데이터가 수신되면, 그것은 재조립 버퍼들(34)에 기재되고, 순서가 어긋나게 직접적으로 배치된 임의 세그먼트들은, OutLogic(40)이 데이터를 재조립 버퍼들(34)로부터 전송할 때, 수신지 데이터 버퍼들(50)에 겹쳐쓰기된다. 이 기능은 사실상, RNIC(16)가 이 접속에서 수신지 데이터 버퍼들(50)에 순서가 어긋나게 배치된 세그먼트들을 '드롭'시킨다는 것을 의미한다. 이러한 접근 방법은 재조립 버퍼들(34) 의 순서에 따른 스트림들에 틈이 생기는 경우를 제거하고, 이러한 거동을 초래할 드문 조건들로 인한 가시적 성능 열화를 발생시키지 않는다.

C. 접속 업그레이드

또 다른 실시예로서, 본 발명은 도 6에 도시된 바와 같은 접속 업그레이드 절차를 포함할 수도 있다. 상술된 고속 경로 모드 접근 방법의 목적은, 정렬된 DDP 세그먼트들(112)을 전달 중인 접속을 위해 재조립 버퍼들(34)의 우회를 허용하는 것이다. 그러나, FAST 접속들에서도, 데이터 소스(12) 또는 중간 네트워크 장치는 간헐적인 비-정렬 DDP 세그먼트들(112NA)을 발생시킬 수 있고, 이것은 상술된 기술들에 따라 FAST 접속들이 SLOW 접속들로 열화되게 한다. 간헐적 거동은, 예를 들어, TCP 재전송 동안의 MSS(maximum segment size) 변화들 또는 다른 우발적 상황들에 의해 발생될 수 있다.

도 6에 도시된 바와 같이, 이러한 상황으로부터 회복하기 위해, 본 발명은, 예를 들어, 단계 S3(도 3)에서의 선행 열화 이후에 SLOW 접속으로부터 FAST 접속으로의 접속 업그레이드도 제공할 수 있다. 업그레이드를 수용하기 위해서는, 다수의 상황들이 존재해야 한다. 다른 실시예의 제 1 단계 S31에서, InLogic(32)은, 재조립 버퍼들(34)이 공백인지의 여부를 판정한다. 아니오라면, 업그레이드는 발생하지 않는다 - 단계 S32. 단계 S31에서 예라고 판정되면, 단계 S33에서, InLogic(32)은, 정렬된 DDP 세그먼트들(112)이 수신되고 있는지의 여부를 판정한다. 아니오라면, 업그레이드는 발생하지 않는다 - 단계 S32. 단계 S33에서 예라고 판정되면, 단계 S34에서, InLogic(32)은, 접속이 전송자, 예를 들어, 데이터 소스(12)에 의해 FAST 접속으로서 시작되었는지의 여부를 판정한다. 단계 S34에서 아니오라고 판정되면, 업그레이드는 발생하지 않는다 - 단계 S32. 단계 S34에서 예라고 판정되면, 접속은 단계 S35에서 FAST 접속으로 업그레이드된다.

D. TCP 재전송 프로세스의 가속화

또 다른 실시예는, TCP 세그먼트(106)가 수신되지만, RDMA 또는 ULP 고려들, 예를 들어, DDP 세그먼트들의 손상, 무효 CRC 등으로 인해 드롭되는 상황을 다룬다. 상술된 절차들에 따르면, TCP 세그먼트(106)가 수신되고 TCP 체크섬을 통과했지만, 세그먼트를 커버하는 TCP Ack를 송신하지 않으면서 InLogic(32)에 의해 드롭되는(즉, 도 3의 단계 S9) 다수 시점들이 존재한다. 기존의 절차들은 그 다음에 그러한 패킷들의 재전송 시도를 발생시킬 것이다. 특히, (소위 "Reno 프로토콜"이라는 기본적인 방식에서), TCP 전송자는, 그것이 3개의 중복되는 Ack들(즉, 순서에 따라 수신된 데이터의 시퀀스 번호를 선행하지 않는 Ack들)을 취했을 때, '고속 재전송' 모드를 시작한다. 예를 들어, 세그먼트 B가 TCP 순서로 세그먼트 A를 뒤따르는 2개의 TCP 세그먼트들(A 및 B)을 가정한다. 세그먼트 A가 드롭되면, 수신자는, 그것이 세그먼트 B를 수신한 경우에만, 중복 Ack를 송신할 것이다. 이러한 중복 Ack는, "나는 세그먼트 A를 대기하고 있지만, 다른 세그먼트, 즉, 세그먼트 B가 수신되었다"는 것을 지시할 것이다. Reno 프로토콜에 따른 '고속 재전송' 모드에서, 전송자는 하나의 세그먼트를 송신한 다음, 다른 패킷을 재전송하기 위해 3개의 다른 중복 Ack들을 대기한다. (소위 "New-Reno 프로토콜" 같은) 좀더 향상된 방식들은, '고속 복구' 모드에서 수신된 각각의 중복에 대해 세그먼트의 재전송을 허용 한다. 이 프로세스에 따른 로직은, 하나의 세그먼트가 네트워크를 떠난다면, 전송자가 네트워크에 다른 패킷을 배치할 수 있는 그런 것이다.

재전송을 용이하게 하기 위해, 본 발명의 다른 실시예에 따르면, InLogic(32)은 TCP에 의해 유효한 것으로 판정되고 (예를 들어, 도 3의 단계 S9에서) ULP(upper layer protocol) 판정에 기초해 TCP에 의해 드롭된 수신 TCP 세그먼트를 커버하는 제 1의 중복 TCP Ack를 발생시키고; 중복 TCP Ack를 전송한다. ULP는, 상기한 바와 같이, MPA 프로토콜, DDP 프로토콜, 및 RDMA 프로토콜 중 하나 이상을 포함할 수 있다. 제 1의 중복 TCP Ack는, TCP 세그먼트가 순서에 따르는지 아니면 순서가 어긋나는지에 무관하게 심지어 순서에 따른 후속의 TCP 세그먼트가 수신되지 않은 경우에도 TCP 세그먼트를 위해 발생된다. 또한, InLogic(32)은 후속의 순서에 어긋나게 수신된 TCP 세그먼트를 커버하는 제 2의 중복 TCP Ack를 발생시키고, 제 2의 중복 TCP Ack를 전송할 수도 있다.

이러한 상기 프로세싱은 사실상, 후속의 순서에 따른 세그먼트(예를 들어, 상기 일례에서의 세그먼트 B)가 아직 수신되지 않았다 하더라도 (예를 들어, 상기 일례에서의 세그먼트 A를 위한) 중복 Ack의 발생이 가능함으로써, 전송자가 상술된 재전송 규칙들에 따라 고속 경로 모드로 재진입하는 프로세스를 가속할 것이라는 것을 의미한다. 좀더 구체적으로, 세그먼트 B가 수신되지 않은 경우라 하더라도, 전송자는 세그먼트 A, 유효한 TCP 세그먼트가 수신되었고 ULP 고려들로 인해 드롭되었다는 것을 알 수 있을 것이다. 따라서, 추가적인 중복 Ack는, 재전송이 시작되기 전에 다수의 중복 Ack들이 수신되어야 하는 경우에, 전송자가 좀더 빨리 재전 송 절차를 시작할 수 있게 한다. TCP 세그먼트(106)는 성공적으로 ULP로 전달되었고 ULP 고려들(무효 CRC)로 인해 드롭되었으므로, 이러한 접근 방법이 TCP 원리들을 위반하지는 않는다. 따라서, 패킷은 IP 프로토콜에 의해 드롭되거나 순서 조정되지 않았다. 이러한 접근 방법은, RNIC(16)가 도 4A와 관련하여 약술된 바와 같이 제한된 재전송 시도 모드를 구현할 경우, 즉, Ack가 단계 S103에서 송신되는 경우에 특히 유용하다.

E. CRC 계산 및 평가

입력 중인 이더넷 프레임들의 기존 프로세싱은 필터링 프로세스로 시작한다. 필터링의 목적은 무효한 이더넷 프레임들로부터 유효한 이더넷 프레임들을 분리하는 것이다. "무효한 프레임들"은 손상된 프레임들은 아니지만, 예를 들어, MAC 어드레스들에 기초한 MAC 필터링-프레임 선택, VLAD 태그들에 기초한 VLAN(virtual local area network) 필터링-프레임 선택 등에 의해 RNIC(16)에 의해 수신되지 않아야 할 프레임들이다. RNIC(16)로의 진입이 허용된 유효한 프레임들도 상이한 유형들로 분리된다. 이러한 유형들 중 하나가 TCP 세그먼트이다. 필터링 프로세스는, 전체 이더넷 프레임의 저장-및-전달 프로세싱을 수행할 필요가 전혀 없는 상태에서, 동작 중에 수행된다.

TCP 세그먼트 프로세싱의 후속 단계는 TCP 체크섬 계산 및 평가이다. 체크섬 계산은, 통상적으로 데이터 블록의 2진 값들을 사용해 전송시의 값을 계산하고, 동일한 방식으로 수신시에 계산되는 값과의 비교를 위해 소정 알고리즘을 사용해 데이터에 따른 결과들을 저장하는 것에 의해, 데이터가 오류없이 전송되었는지의 여부를 판정한다. 체크섬 계산 및 평가는 전체 TCP 세그먼트 페이로드를 커버하기 때문에, 체크섬 계산 및 평가는 전체 TCP 세그먼트의 저장-및-전달 프로세싱을 요한다. 관습적으로, 통상적인 TCP 체크섬 평가에는, 다시 말해, 접속이 RDMA 접속인 것으로 인식된 후 그리고 DDP 세그먼트의 경계들이 선행 DDP 세그먼트나 MPA 마커들의 길이를 사용 중인 것으로 검출된 후에는, CRC의 계산 및 평가가 수반된다. CRC 계산 및 평가는, 메시지들을, 피제수들로서 사용되어 고정된 제수만큼 나누어지는 소정 길이들로 분할하는 것에 의해, 데이터가 정확하게 전송되었는지의 여부를 판정한다. 계산의 나머지는 수신자에 의해 수행되는 동일한 계산과의 비교를 위해 메시지에 첨부된다. CRC 계산 및 평가 또한 전체 DDP 세그먼트의 저장-및-전달을 요하는데, 이는 지연을 증가시키고 저장을 위해 대용량 데이터 버퍼들을 요한다. CRC 계산의 일 요구 사항은, 선행 DDP 세그먼트를 사용하거나 MPA 마커들(110)(도 1B)을 사용해 판정되는 DDP 세그먼트의 경계들을 아는 것이다. 마커-기반 판정은 많은 예외들 및 난처한 경우들로 인해 아주 복잡하다. 부분적으로 수신된 DDP 세그먼트의 CRC 계산 또한 복잡한 프로세스이다.

상기 문제들을 다루기 위해, 도 2C에 도시된 바와 같이, 본 발명은 동일한 저장-및 전달 버퍼(68)를 사용해 TCP 체크섬 로직(66)을 통한 TCP 체크섬 계산 및 평가와 병렬로 CRC 로직(64)을 통한 CRC 계산 및 평가를 수행한다. 또한, 본 발명은 DDP 세그먼트 경계들을 배치한 다음 즉각적으로, DDP 세그먼트 CRC를 계산하고 평가하지 않는다. 오히려, 본 발명은 CRC를 계산한 후에 DDP 경계들을 판정하는 것에 의해 연산들의 순서를 전환한다. 이러한 전환을 수행하기 위해, CRC 로 직(64)은, (세그먼트가 RDMA 접속에 속한다고 알려지기 전에) 각각의 TCP 세그먼트가 정렬된 DDP 세그먼트로 시작한다고 가정한다. 또한, 본 발명은, TCP 페이로드(127)(도 1B)의 처음의 2개 바이트가 MPA 프레임의 MPA 길이 필드(114)(도 1B)라고 가정한다. 그 다음, 이 길이는 DDP 세그먼트 경계들을 식별하고 그 세그먼트를 위한 CRC를 계산하는데 사용된다. 평가 유닛(114)이 TCP 세그먼트(106)에서 가능한 제 1 DDP 세그먼트(112)의 경계를 식별한 후, 평가 유닛(114)은 TCP 세그먼트 페이로드(127)의 그 부분에 대한 체크섬 계산과 동시에 그러한 DDP 세그먼트에 대한 CRC를 계산하고 평가한 다음, (존재한다면) 동일한 TCP 세그먼트(106)에 포함되어 있는 후속의 잠재적 DDP 세그먼트(112)로 진행한다. TCP 세그먼트(106)에서 발견된 "잠재적" DDP 세그먼트 각각에 대해, CRC 평가 결과들은 유효, 무효, 또는 너무 길 수도 있다. CRC 평가의 결과들은 도 3에 관련하여 상술된 바와 같은 사용을 위해 저장된다.

CRC를 상술된 바와 같이 실제로 계산하기 위해, TCP 세그먼트(106)의 페이로드가 프로세싱될 때, InLogic(32)은, MPA 마커들(110)이 TCP 세그먼트(106)의 어디에 위치하고 있는지를 알아야 한다. 도 1B와 관련하여 상술된 바와 같이, MPA 마커들(110)은 TCP 세그먼트(106)에서 매 512 바이트들만큼 떨어져 배치되고, 제 1 MPA 마커는 접속 문맥(42)의 StartNum 필드(248)(도 2B)로서 저장되어 있는 TCP 헤더(126)(도 1B)의 ISN(Initial Sequence Number)으로부터 512 바이트에 위치한다. 불행스럽게도, 각 MPA 마커(110)의 평가가 StartNum(248)(도 2B)과 관련한 그것의 위치를 드러내지는 않는다. 또한, MPA 마커들(110)은 CRC 데이터(116)에 의해 커 버되지만, MPA 프레임의 페이로드만을 포함하는 MPA 길이 필드(114)에는 포함되지 않는다. 따라서, MPA 마커들(110)을 식별하기 위해, RNIC(16)는 접속 문맥(42)으로부터 인출되어야만 하는 StartNum(248)(도 2B)을 알아야 한다. 불행스럽게도, 접속 문맥(42)의 판독은 프로세싱의 아주 초기에 발생하고 패킷 프로세싱을 중단하거나 방해하므로, 접속 문맥(42)의 판독을 TCP 프로세싱 동안에 수행하기는 아주 불편하다.

접속 문맥(42) 인출을 감소시키거나 제거하기 위해, 본 발명은 DDP 세그먼트(112)의 MPA CRC를 계산하고 평가하는데 필요한 DDP 세그먼트(112) 길이의 정확한 계산을 허용하는 4가지 대안들을 제시한다. 다음 섹션들에서는 이 옵션들이 논의된다.

1. 접속 문맥 선행 인출 방법

DDP 세그먼트(112) 길이를 정확하게 계산하기 위한 제 1의 다른 실시예는 StartNum 필드(248)(도 2B)로서 저장되어 있는 ISN(Initial Sequence Number)의 접속 문맥(42) 선행 인출을 구현하는 단계를 포함한다. 여기에서, MPA 설계 명세서에 대한 변경은 제안되지 않는다. 현재의 MPA 설계 명세서는 TCP 세그먼트(106)에서 MPA 마커(110)의 위치를 식별하기 위해 ISN(StartNum)에 관한 지식을 요한다. ISN은, 접속에 따라 달라지고 접속 확립시에 협상되는 TCP 접속 속성이다. 따라서, StartNum(248)(도 2B)은 매 접속 기반으로 보유된다. MPA 마커(110)의 위치를 식별하기 위해, CRC 로직(64)(도 2C)은, 특정 세그먼트의 시퀀스 번호(SeqNum) 및 StartNum의 나머지(SeqNum-StartNum) mod 512가 0인지를 점검한다. 다시 말해, 각각의 TCP 세그먼트(106) 헤더는 자신의 페이로드에 대한 제 1 바이트의 시퀀스 번호를 전달하기 때문에, CRC 로직(64)은, 특정 세그먼트의 시퀀스 번호와 StartNum(248)의 차이를 취하는 것에 의해 어디에서 마커를 찾아야 하는지를 판정할 수 있고, 그 다음, 이 위치로부터 시작해, 매 512 바이트들마다 마커를 찾아낸다. MPA 설계 명세서는 상술된 마커 검출 방법을 정의한다. 이런 식으로, (TCP 투플에 기초한) Hash 룩업 및 접속 문맥(42) 선행 인출은, TCP 체크섬 평가가 수행되기 전에 수행될 수 있다. 이것은 보통의 접속 문맥(42) 인출 흐름이다. RNIC(16)가 접속 문맥(42)을 취하고자 한다면, RNIC(16)는 먼저, 이 문맥이 어디에 위치하는지를 알고 있거나 접속 ID를 취해야 한다. TCP 세그먼트(106) 헤더는 TCP 투플(IP 어드레스들(소스 및 수신지)과 TCP 포트들(소스 및 목적지))을 전달한다. 투플은 Hash 펑크션으로의 입력이다. Hash 펑크션의 출력은 접속 ID이다. 물론, 상이한 투플들에 대해 동일한 접속 ID가 얻어질 수도 있는데, 이는 "충돌"이라고 한다. 충돌을 핸들링하기 위해, RNIC(16)는 접속 문맥(42)을 판독하고, 패킷의 투플로써 접속 문맥(42)의 투플을 점검하며, 부합하지 않으면, RNIC(16)는 후속 접속 문맥(42)으로의 포인터를 취한다. RNIC(16)는, 부합을 발견하거나 세그먼트가 어떤 공지 접속에도 속하지 않는 세그먼트로 인식될 때까지, 계속해서 투플들을 점검한다. 이 프로세스로 인해, TCP 스트림에서 MPA 마커들(110)을 찾아낼 수 있다. 따라서, CRC 계산 및 평가는 TCP 체크섬 평가와 동시에 수행될 수 있다.

2. 초기의 시퀀스 번호 협상 방법

제 2의 다른 실시예에서는, MPA 설계 명세서를 다수 변경하는 것에 의해, 접 속 문맥을 인출하지 않으면서 DDP 세그먼트 길이를 정확하게 계산하는 것이 가능하다. 첫번째, MPA 설계 명세서의 MPA 마커(110) 배치에 대한 정의가 변경된다. 상술된 접속 문맥 사전 인출 방법의 일 단점은 TCP 세그먼트(106)에서 MPA 프레임(109)의 경계들을 식별하기 위해서는 Hash 룩업 및 접속 문맥(42) 사전 인출을 수행해야 한다는 것이다. 이를 방지하기 위해, 본 발명은 MPA 마커들(110)을, (상술된 SN-StartNum mod 512 프로세싱을 충족시키는) (StartNum(248)으로서 저장되어 있는) ISN으로 시작해 매 512 바이트마다가 아니라, 매 512 바이트마다 배치한다. 이런 식으로, MPA 마커들(110)의 위치는 MPA 마커들(110)을 찾아내기 위한 시퀀스 번호 mod 512 프로세스에 의해 판정될 수 있고, 접속 문맥(42) 인출은 불필요하다.

이 실시예에 따른 MPA 설계 명세서에 대한 두번째 변화는, 하나의 마커가 2개의 DDP 세그먼트들(112) 사이에서 나누어지는, 즉, ISN이 워드-정렬되어 있지 않은 상황을 방지하도록 동작한다. 따라서, 표준 TCP 구현은, ISN이 무작위로 발생된 바이트-정렬 값을 갖게 하기 때문에, 시퀀스 번호 mod 512 프로세스가 모든 환경들에서 작용하지 않을 수도 있다. 다시 말해, ISN이 워드-정렬형인지의 여부는 RNIC(16)에 의해 제어될 수 없다. 따라서, 소정 접속을 위한 TCP 스트림이 반드시 MPA 마커(110)로 시작할 필요는 없다. 따라서, CRC 로직(64)이 단지 시퀀스 번호 mod 512 프로세스를 사용하는 것에 의해 마커(110)의 위치를 찾아낸다면, 마커들은 바이트 정렬형 위치에 배치된 마커들을 취할 수 있는데, 이는 수용 불가능하다. 이런 상황을 방지하기 위해, 본 발명은 MPA 협상 단계 동안에 교환되는 MPA 프레임들, 즉, 소위 "MPA 요청/응답 프레임"에 패딩을 추가하여, RDMA 모드로 이동할 때 RDMA 접속의 ISN이 워드-정렬되게 한다. 다시 말해, 도 7에 도시된 바와 같이, ISN을 워드-정렬되게 하는데 필요한 다수 바이트들을 포함하는 정정 팩터(150)가 TCP 세그먼트(106)의 MPA 요청/응답 프레임(152)에 삽입된다. 정정 팩터(150)의 정확한 위치는 도시된 바와 같지 않을 수도 있다는 것을 알 수 있어야 한다. 이런 식으로, CRC 로직(64)은 접속 문맥 인출없이 TCP 스트림에서 MPA 마커들(110)의 정확한 위치를 획득하기 위한 시퀀스 번호 mod 512 프로세스를 구현할 수 있다. MPA 설계 명세서의 상술된 변경들을 사용해, 본 발명은 접속 문맥(42)의 인출없이 MPA 마커들(110)을 찾아낼 수 있고 MPA 세그먼트 길이를 적절히 계산할 수 있다.

3. MPA 길이 필드 변경 방법

접속 문맥의 인출없이 DDP 세그먼트(112) 길이를 정확하게 계산하기 위한 제 3의 다른 실시예에서, MPA 설계 명세서의 MPA 길이 필드(114) 정의는 변경된다. 전통적으로, MPA 길이 필드(114)는, 마커들(110), 패딩(121)(도 1B) 및 MPA 계층에 의해 추가된 CRC 데이터(116)를 제외한, 개개 MPA 프레임(109)의 ULP 페이로드의 길이를 전달하도록 정의된다. 불행스럽게도, 이 정보가 TCP 세그먼트(106)에 의해 제공되는 정보를 사용해 MPA 프레임 경계들을 찾아낼 수 있게 하지는 않는다. 이 문제를 해결하기 위해, 본 실시예에 따르면, MPA 설계 명세서의 MPA 길이 정의는 MPA 길이 필드(114)의 14개 MSB들(most significant bits), ULP 페이로드(118) 길이, MPA 마커들(110), CRC 데이터(116), MPA 길이 필드(114)의 2개의 LSB들(least significant bits), 및 패딩(121)의 유효 비트들을 포함하는 전체 MPA 프레임(109)의 길이를 특정하도록 변경된다.

이처럼 수정된 정의로 인해, MPA 프레임에 매입되어 있는 모든 MPA 마커들(100)을 찾아내지 않으면서, MPA 길이 필드(114)를 사용해 MPA 프레임(109) 경계들을 검출할 수 있다. MPA 계층 프로토콜은 마커들(110), CRC 데이터(116) 및 패딩(121)을 제거하여 ULP(DDP 계층)에 ULP 페이로드 길이를 제공하는 것을 책임진다.

도 8을 참조하면, MPA 길이의 이 정의를 사용해, CRC 로직(64)은 다음 프로세스에 의해 MPA 프레임(109)의 경계들을 찾아낸다. 단계 S100에서, CRC 로직(64)은, MPA 프레임(109)의 제 1 워드가 0인지의 여부를 판정한다. 예라면, 로직(32)(도 2A)은 단계 S102에서 후속 워드로부터 MPA 길이 필드(114)를 판독한다. 이것은, 마커(110)가 2개의 MPA 프레임들(109) 사이에 위치하는 경우이다. 이 상황에서, MPA 길이 필드(114)는 단계 S104에서 지시되는 바와 같이 후속 워드에 배치된다. 단계 S100에서의 판정이 아니오라면, 이 워드는 MPA 길이 필드(114)를 보유한다. 단계 S106에서, MPA 길이는 이러한 MPA 프레임(109)을 커버하는 CRC 데이터(116)의 위치를 찾아내는데 사용된다. 그 다음, 상기 프로세스는 TCP 세그먼트(106)에 매입되어 있는 다른 MPA 프레임들(109)을 찾아내기 위해 반복한다. 이 실시예는, 접속 문맥(42)으로부터의 어떠한 추가 정보도 없이 MPA 프레임(109) 경계들을 찾아낼 수 있게 한다.

4. 무-마커들의 관통 구현

제 4의 다른 실시예에서는, 후술되는 바와 같이, 무-마커 관통 구현이 CRC 계산 및 평가와 관련하여 사용된다. DDP 세그먼트 길이를 정확하게 계산하기 위한 상술된 3가지 다른 실시예들의 단점은, 각각 MPA 설계 명세서의 변경 또는 접속 문맥(42) 사전 인출을 요한다는 것이다. 이 실시예는, 도달 중인 MPA 프레임들의 CRC를 계산하기 위해 접속 문맥(42)을 사전 인출하지 않고 MPA 설계 명세서를 추가적으로 변경하지 않으면서, 내향 세그먼트들의 관통 프로세싱을 구현한다. 또한, 이 실시예는, MPA 마커들을 사용하지 않으면서, 순서가 어긋난 데이터의 직접적인 배치를 허용한다. 이 실시예는, MPA 설계 명세서의 최근 업데이트 버전에 따른, 수신자가 소정 접속을 위해 '무-마커들'의 옵션과 협상할 수 있는 능력에 부분적으로 기초한다. 특히, 업데이트된 MPA 설계 명세서는, MPA 수신자가 소정 접속을 위해 마커들을 사용할 것인지의 여부를 판정할 수 있게 하며, 송신기는 수신자의 판정을 존중해야 한다. 이 실시예는 평가 유닛(44) 로직을, TCP 체크섬 계산과 동시에 그리고 접속 문맥(42)을 사전 인출하지 않으면서 동작 중에 CRC 계산을 수행할 수 있도록 변경한다.

CRC 계산은 마커들의 경우에 대해 설명된 바와 같이 정확하게 수행된다. 다시 말해, 본 발명은, TCP 세그먼트가 정렬된 DDP 세그먼트로 시작한다고 가정하고, MPA 길이 필드를 사용해 CRC의 위치를 찾아낸 다음, CRC를 계산하고 평가한다. 그러나, 이 실시예의 차이점은, MPA 헤더의 MPA 길이 필드가 주어지면, DDP 세그먼트 길이를 계산할 때 마커들을 고려할 필요가 없다는 것이다.

도 9를 참조하면, 이 실시예의 제 1 대안에 관한 InLogic(32) 기능을 예시하는 흐름도가 도시되어 있다. InLogic(32) 기능의 대부분이 도 3과 관련하여 상술된 기능과 실질적으로 유사하다는 것을 알 수 있어야 한다. 명료화를 위해, InLogic(32) 기능이 도 3과 관련하여 상술된 기능과 실질적으로 유사할 경우, 단계들은 점선 박스로써 반복되고 서술되었다.

업데이트된 MPA 설계 명세서에 따라, 수신자는 접속 초기화시에 특정 접속을 위해 '무-마커' 옵션을 협상한다. 도 9에 도시된 바와 같이, 이 실시예에서는, 단계 S201에서, InLogic(32)이, 내향 TCP 세그먼트(106)가 마커들(110)을 포함하는지의 여부를 판정한다. 예라면, InLogic(32)은 도 3에서와 같은 프로세싱으로 진행하고, 상술된 바와 같이, 소정의 다른 CRC 계산 및 평가 방법이 사용될 것이다. 아니오라면, 단계 S202에서, 내향 MPA 프레임(109)은 TCP 체크섬 로직(66)과 동일한 저장-및-전달 버퍼들(68)을 사용하지만 접속 문맥(42)의 인출없이 그들의 CRC를 동작 중에 계산하고 평가한다. 접속이 SLOW 접속인지의 여부에 대한 판정(도 3의 단계들(S2 및 S3))도 완결될 수 있다. CRC 평가의 결과들은 다음: 1) MPA 프레임(109)의 길이가 TCP 세그먼트(106)의 길이와 부합하고, MPA 프레임(109)이 유효한 MPA CRC를 가짐; 2) MPA 프레임(109)의 길이가 TCP 세그먼트(106)의 길이와 부합하지만, MPA 프레임(109)은 무효한 CRC를 가짐; 3) MPA 프레임(109)의 길이가 TCP 세그먼트의 길이를 초과함; 그리고 4) MPA 프레임(109)의 길이가 TCP 세그먼트(106)의 길이보다 작음 중 하나일 수 있다.

경우 1)에서, InLogic(32)은 도 3의 단계들(S4-S7)과 실질적으로 유사하게 동작한다. 다시 말해, MPA 프레임(109)이 TCP 세그먼트(106)와 동일한 길이를 가지며(도 3의 단계들 S4 및 S5), 유효한 MPA CRC를 전달할 경우(단계 S6), 프레임은 유효한 MPA 프레임으로 간주되어 내장형 데이터 버퍼들(38)을 통해 추가적 프로세 싱을 위해 OutLogic(40)으로 그리고 고속 경로 모드에서 수신지 데이터 버퍼들(50)로 전달된다.

경우 2)에서, MPA 프레임(109)이 TCP 세그먼트(106)와 동일한 길이를 갖지만(도 3의 단계들 S4 및 S5), 무효한 CRC를 가질 경우(도 3의 단계 S6), InLogic(32)은 도 3과 관련하여 설명된 것과는 상이하게 동작한다. 특히, 수신된 MPA 프레임(109)이 MPA 마커들(110)을 포함하지 않으므로, 마커 관련 정보는 (도 3의 단계 S10에서와 같이) 복구를 위해 사용될 수 없다. 이것은, 해결되어야 할 2가지 경우들: 경우 A: MPA 프레임(109)이 (도 3의 단계 S8에서 판정되는 바와 같이) 앞서 수신된 (그리고 평가된) MPA 프레임(109)의 세그먼트 길이에 의해 참조될 경우; 및 경우 B: 다른 모든 경우들만을 남긴다. 경우 A에서, MPA 프레임(109)은 손상되고, 경우 B에서, MPA 프레임(109)은 손상되거나 정렬되지 않을 수 있다. 양자의 경우들에서, 수신된 TCP 세그먼트(106)는 드롭되고(도 3의 단계 S9), 수신은 확인되지 않는다. 이 경우, 그러한 TCP 세그먼트(106)의 드롭으로부터 복구하기 위해, 도 4와 관련하여 설명된 제한된 재전송 시도 모드가 구현될 수도 있는데, 이로 인해 송신기는 드롭된 TCP 세그먼트(106)를 재전송할 수 있고 임의의 잠재적 데이터 손상을 해결할 수 있다. MPA 프레임(109)이 TCP 세그먼트(106)로 정렬되지 않았다면, 제한된 재전송 시도 모드는, 상술된 바와 같이, 접속을 SLOW 접속으로 열화시키는 것으로 종료할 것이다.

경우 3)에서, MPA 프레임(109)의 길이가 TCP 세그먼트(106)의 길이를 초과할 경우(도 3의 단계 S5), MPA 프레임(109)은 TCP 세그먼트(106)로 정렬되지 않거나 길이가 손상된다. 이 경우, 수신된 TCP 세그먼트(106)는 드롭되고(도 3의 단계 S9), TCP는 수신을 확인하지 않는다. 이 경우에도 역시, 그러한 TCP 세그먼트(106)의 드롭으로부터 복구하기 위해, 도 4와 관련하여 설명된 제한된 재전송 시도 모드가 구현될 수 있는데, 이로 인해 송신기는 드롭된 TCP 세그먼트를 재전송할 수 있고 임의의 잠재적 데이터 손상을 해결할 수 있다. 이번에도, MPA 프레임(109)이 TCP 세그먼트(106)로 정렬되지 않으면, 제한된 재전송 시도 모드는, 상술된 바와 같이, 접속을 SLOW 접속으로 열화시키는 것으로 종료할 것이다.

경우 4)에서, MPA 프레임(109)의 길이가 TCP 세그먼트(106)의 길이보다 작거나(도 3의 단계 S4), TCP 세그먼트(106)가 잠재적으로 다수의 MPA 프레임들(109)을 전달할 경우(송신기가 패킹 옵션(packing option)을 실시하는 경우), InLogic(32)은 수신된 TCP 세그먼트(106)에 매입되어 있는 모든 DDP 세그먼트들(112)의 CRC들을 순차적으로 점검한다(도 3의 단계들 S11-S13). 모든 DDP 세그먼트들(112)이 유효한 CRC를 가지면, InLogic(32)은 그러한 TCP 세그먼트(106)의 수신을 승인하고, 모든 MPA 프레임들은 고속 경로 모드에서의 추가적인 프로세싱을 위해 전달된다(도 3의 단계 S7). DDP 세그먼트들(112) 중 하나가 무효한 CRC를 갖거나 마지막 세그먼트가 TCP 세그먼트에 완전히 포함되어 있지 않으면(도 3의 단계들 S12-S13), 전체 TCP 세그먼트가 드롭되고(도 3의 단계 S9), InLogic(32)은 그러한 TCP 세그먼트의 수신을 확인하지 않는다. 상기한 바와 같이, 그러한 TCP 세그먼트(106)의 드롭으로부터 복구하기 위해, 도 4와 관련하여 설명된 제한된 재전송 시도 모드가 구현될 수도 있는데, 이로 인해 송신기는 드롭된 TCP 세그먼트를 재전송할 수 있고 임 의의 잠재적 데이터 손상을 해결할 수 있다. MPA 프레임(109)이 TCP 세그먼트(106)로 정렬되지 않았다면, 제한된 재전송 시도 모드는, 상술된 바와 같이, 접속을 SLOW 접속으로 열화시키는 것으로 종료할 것이다.

도 10을 참조하면, 이 실시예에 관한 InLogic(32) 기능을 예시하며 제한된 재전송 시도 모드 및 TCP 재전송 가속화의 태양들을 포함하는 또 하나의 대안 흐름도가 도시되어 있다. 도 9와 대조적으로, InLogic(32) 기능은 도 3에 비해 크게 단순화되어 있다. 명료화를 위해, InLogic(32) 기능이 도 3과 관련하여 상술된 기능과 실질적으로 유사할 경우, 단계들은 점선 박스로써 반복되고 서술되었다.

도 10에서, 단계들 S151-S153은 실질적으로 도 3의 단계들 S1-S3과 동일하다. 단계 S154에서, InLogic(32)은, CRC 평가를 통과했는지의 여부를 판정한다. 이 평가는, 매 DDP 세그먼트마다 지시를 제공하는 대신에, CRC 로직(54)이 수신된 TCP 세그먼트의 모든 DDP 세그먼트들의 CRC 평가에 대한 성공 또는 실패를 지시하는 CRCValidationPassed 비트를 제공한다는 점에서, 도 3의 단계 S4와는 상이하다. 이 비트는, 수신된 TCP 세그먼트에 포함된 모든 DDP 세그먼트들에 대해 CRC 평가가 통과되면 설정되고, CRC 평가가 세그먼트들 중 하나에 대해 실패했거나 (유일하게) 마지막 세그먼트가 지나치게 길다면 소거된다. 아니오라면, InLogic(32)은, RecoveryAttemptsNum(도 2B의 필드 292)이 MaxRecoveryAttemptsNum(도 2B의 필드 296)보다 큰지의 여부에 대한 판정이 수행되는 단계 S155로 진행한다. 예라면, InLogic은, DDP 세그먼트가 재조립 버퍼들(34)에 배치되고, Ack가 송신되며, (접속이 FAST 접속이었다면) 접속이 SLOW 접속으로 열화되는 단계 S153으로 진행한다. 단계 S155에서 아니오라면, 다음으로 단계 S156에서, TCP 세그먼트(106)는 드롭되고 확인은 스케줄링되지 않는다. 또한, RecoveryAttemptNum(도 2B의 필드 292)은 1만큼 증가되고, LastRecoverySN(도 2B의 필드 294)은 업데이트된다.

단계 S154로 돌아가서, 판정 결과가 예라면, InLogic(32)은, 단계 S157에서, 새롭게 순서에 따라 수신된 데이터 전송의 시퀀스 번호(In-order SN)가 LastRecoverySN (도 1B의 필드 294)보다 큰지의 여부를 판정하도록 진행한다. 예라면, 단계 S158에서, InLogic(32)은 RecoveryAttemptsNum(도 1B의 필드 292)을 소거, 즉, 그것을 0으로 설정한다. 단계 S157 또는 후속의 단계 S158에서 아니오라면, 단계 S159에서, 세그먼트를 수신지 데이터 버퍼들(50)에 배치하는 것에 의해, 세그먼트는 "고속 경로 모드"에서 프로세싱된다. 단계 S159는, TCP 재전송 가속 옵션과 관련하여 상술된 바와 같이, 중복 Ack의 구현을 포함할 수도 있다.

상술된 도 10의 실시예는, MPA 마커들을 사용하지 않으면서, 본 발명의 관통 모드 + 제한된 재전송 시도 모드 및 TCP 재전송 가속 옵션을 구현한다.

III. OutLogic

OutLogic(40)(도 2A)은 매 RDMA 메시지마다 정보를 유지하지 않으면서 RDMA 메시지들의 순서에 따른 전달을 수행한다. 1) Send 메시지를 제외한 모든 RDMA 메시지들, 및 2) RDMA Send 메시지의 2가지 상황들이 다루어진다.

도 1F 내지 도 1H로 돌아가, 이하에서는, OutLogic40(도 2A)의 연산이 설명될 것이다. OutLogic은, 상술된 바와 같이, 고속 경로 모드에서 거기에 배치된 내장형 데이터 버퍼들(38)(도 2A)로부터의 정렬된 DDP 세그먼트들(220)을 프로세싱하 고, 정렬된 DDP 세그먼트들의 수신자 데이터 버퍼들로의 데이터 배치 및 전달을 수행한다. 여기에서 사용되는 바와 같이, "배치"는 실제로 데이터를 버퍼에 넣는 프로세스를 의미하고, "전달"은 데이터 전송의 완결을 확인하는 프로세스를 의미한다. "배치"는 세그먼트들과 메시지들 모두에 적용될 수 있는 한편, "전달"은 메시지들에만 적용된다. RDMA 프로토콜에 따르면, 정렬된 DDP 세그먼트들은 순서가 어긋난 방식으로 배치될 수 있지만, 전달은 정렬된 DDP 세그먼트들 모두가 순서에 따라 배치될 때까지 발생하지 않는다. 예를 들어, 3개의 정렬된 DDP 세그먼트들(1, 2 및 3)에 대해, 세그먼트들(2 및 3)이 세그먼트 1없이 먼저 배치될 경우, 세그먼트 1이 배치될 때까지 전달은 발생하지 않는다.

A. 배치

배치와 관련하여, OutLogic(40)은, 후술되는 바와 같이, RDMA Read 메시지들에 관한 것을 제외한 RDMA 메시지들의 통상적인 배치를 제공한다.

태그형 DDP 세그먼트들과 관련하여, 예를 들어, 도 1D를 참조하면, RDMA 프로토콜에 따라, 태그형 DDP 세그먼트의 헤더(124)는 수신자의 앞서 등록된 메모리 영역(예를 들어, 도 1G의 메모리 영역(232))에 대한 어드레스를 전달한다. 앞서 지시된 바와 같이, 이 어드레스는 메모리 영역/윈도(예를 들어, RDMA Write 메시지를 위한 도 1G의 메모리 영역(232))에 놓인 목적지 버퍼를 지시하는 시작 태그(STag), 이 영역/윈도에서의 TO(target offset), 및 트랜잭션 길이(세그먼트 페이로드)를 포함한다. 이 경우, 데이터 배치는, 접속 문맥(42)(도 2A)으로부터 임의의 추가 정보를 검색하지 않으면서, OutLogic(40)에 의해 종래의 방식으로 수행 된다. STag 및 TO가 수신지 데이터 버퍼를 설명하는 메모리 영역의 물리 버퍼들의 리스트로 해석되는 통상적인 ATP(Address Translation and Protection) 프로세스들이 OutLogic(40)에 의한 데이터 배치에 선행된다.

RDMA Read 메시지와 같은 미태그형 DDP 세그먼트들에 관련하여, 도 1H를 참조하면, RDMA 프로토콜은, 협상시에 교환되는 계류 중인 내향 Read Request들(222)의 최대 수를 정의한다. 각각의 RDMA Read 메시지(204)가 하나의 DDP 세그먼트(222)를 소비한다. RNIC(16)가 RDMA Read 메시지(204)를 수신할 때, RNIC(16)는 RDMA Read Response WQE(216RR)를 Read Queue(214)로 포스팅한다. 다른 예에서, 도 1F를 참조하면, 각각의 Send 메시지(200)가 응답자, 예를 들어, 데이터 싱크(18)(도 2A)의 수신 큐(RQ;212)에 배치된다. 상기한 바와 같이, 각각의 RQ(212)는 제어 명령어들이 배치되는 버퍼이고, 페이로드가 배치되는 WQE(216R)를 포함한다. RQ(212)는 WQE들(216R)을 포함한다. 각각의 WQE(216R)는 소비자에 의해 포스팅된 수신 WR(208R)을 설명하는 제어 정보를 보유한다. 또한, 각각의 WQE(216R)는 그 WR(208R)에서 포스팅된 소비자 버퍼(들)도 포인팅한다. 그러한 버퍼들은 페이로드를 배치하는데 사용된다. 따라서, 각각의 메시지(200)는 WQE(216R)를 소비한다.

도 11을 참조하면, 도 1H와 유사한 RDMA Read 메시지(204) 및 RDMA Read Response(206)의 표현이 도시되어 있다. 그러나, 본 발명에 따르면, Read Queue(414)는 순환 버퍼로서 구현된 특수한 WQ(work queue)로서 제공되고, 이러한 순환 버퍼의 각 엔트리는 전송 로직에 의해 발생되어야 하는 RDMA Read Response를 설명하는 WQE(216RR)이다. 각각의 내향 RDMA Read Request에 대해, 주지의 위치가 Read Queue(414), 즉, WQE(216RR)에 존재하므로, 이로 인해, 순서가 어긋난 RDMA Read Request들(222)의 용이하고 효율적인 배치가 가능해진다. 예를 들어, RDMA Read 메시지 #3가 수신되고 RDMA Read 메시지 #2가 상실되었을 경우, RDMA Read 메시지 #3가 배치된다. 이 배치는 RDMA Read Request 메시지(222), 즉, 요청자의 Read WR(208R) 포스팅으로 인해 송신된 메시지의 수신시에 수행된다. Read Queue(414)에서의 WQE(216RR) 위치는 RDMA Read 메시지 헤더(124)(도 1D)의 MSN에 의해 식별된다.

B. 전달

RDMA 프로토콜은 순서가 어긋난 데이터 배치를 허용하지만 순서에 따른 전달을 요한다. 따라서, 기존의 구현들은 메모리에 (완전하게 또는 부분적으로) 배치되었지만, 아직 전달되지 않은 메시지 각각에 관한 정보를 유지할 것을 요한다. 그러나, 단일 TCP 세그먼트의 손실은, 목적지 버퍼들에 배치되지만 드롭 세그먼트가 재전송되어 성공적으로 메모리에 배치될 때까지는 완결되지 않을, 순서가 어긋난 다수 RDMA 메시지들의 수신을 초래할 수 있다. 종래 환경들하에서는, 순서가 어긋난 스트림이 수신된 후 소정 갯수의 후속 메시지들만이 저장될 수 있도록, 제한된 리소스들이 순서가 어긋난 스트림의 저장에 이용될 수 있다.

그러나, 본 발명에 따르면, 전달되지 않은 RDMA 메시지 각각에 대한 일부 정보를 보유하고 그에 따라 지원되는 순서가 어긋난 수신 메시지들의 수를 제한하는 대신에, 매 TCP 홀 기반으로 정보를 저장하는 것에 의해, 전달되지 않은 RDMA 메시 지들이 무제한으로 지원된다. "TCP 홀"은, 순서가 어긋난 TCP 세그먼트의 수신 결과로서 TCP 스트림에 발생되는 공백을 설명하는 용어이다.

도 12를 참조하면, 화이트 블록들은 TCP 홀들(130A-130C)을 형성하는 드롭 TCP 세그먼트들(400)을 지시하고, 음영/그레이 블록들(402)은 연속적으로 수신된 TCP 스트림을 지시한다. 매 TCP 홀(130A-130C)마다의 정보가 접속 문맥(42)(도 2B)에 저장된다. 지원되는 TCP 홀들(130A-130C)의 제한된 수는 TCP 프로토콜 구현의 본래적인 특징이다. 특히, TCP 프로토콜은 일반적으로 지원되는 TCP 홀들(130A-130C)의 수를, 예를 들어, 1, 2 또는 3개 홀들로 제한한다. 통상적으로, 제한된 수의 TCP 홀들(130A-130C)을 지원한다는 것은 사실상, 새로운 TCP 홀을 개방하며 순서가 어긋난 TCP 세그먼트가 도달할 때, 이 세그먼트는 TCP 로직에 의해 드롭된다는 것을 의미한다. 도 12는 3-TCP 홀 구현을 예시한다. 이 경우, 하부 TCP 홀(130C) 이후에, 즉, 2개의 하부 드롭 세그먼트들(400) 이후에, 새로운 세그먼트가 도달하면, 이 세그먼트는 지원되지 않는 4번째 홀을 "개방"할 것이다. 따라서, 그 세그먼트는 드롭될 것이다.

이 상황을 해결하기 위해, 본 발명은 순서가 어긋난 메시지들/세그먼트들을 추적하는 것이 아니라 접속 문맥(42)(도 2A 및 도 2B)을 통한 TCP 홀들(130)(도 12)의 추적을 구현한다. 특히, 도 2B에 도시된 바와 같이, 본 발명은 완결된 RDMA Read Request들을 카운팅하기 위한 PendingReadResponseNum 필드(300), 완결된 Send 메시지들을 카운팅하기 위한 CompletedSendsNum 필드(302), 및 완결된 RDMA Read Response들을 카운팅하기 위한 CompletedReadResponseNum 필드(306)를 저장한 다. 당업자들이라면, 각각의 홀을 위해 다른 필드들이 필요할 수도 있다는 것을 알 수 있을 것이므로, 그에 대한 설명은 간략화를 위해 생략할 것이다. 이러한 접근 방법은 완결 및 순서에 따른 전달을 대기 중인 순서가 어긋나게 수신된 RDMA 메시지들을 무제한으로 허용한다. 이러한 접근 방법은 수신(212) 및 송신(210) 큐들 모두에 의해 전혀 제한없이 완결 큐(240)(도 1F-1H)를 공유할 수 있는 능력을 제한하지 않는다. 이하에서는, 메시지들의 특정 유형들에 대한 핸들링의 세부 사항들이 설명될 것이다.

첫번째, RDMA Write 메시지들(202)(도 1G)의 전달은, 연산의 특징으로 인해, 응답자에 대한 어떤 보고 또는 다른 하드웨어 로직으로의 어떤 통지도 초래하지 않는다는 것에 주목해야 한다. 따라서, 이 유형의 RDMA 메시지와 관련한 전달 용무는 존재하지 않는다.

두번째, RDMA Read Response 메시지(206)에 관련하여, 도 11로 돌아가면, 이 연산은 계류 중인 RDMA Read 메시지(204)의 완결을 표현한다. 이 경우, 매 TCP 홀(130)마다의 완결된 다수 RDMA Read Response 메시지들(206)을 포함하는 CompletedReadResponseNum 필드(306)(도 2B)를 접속 문맥(42)에 저장하는 것은 요청자의 완결 핸들링 로직에 계류 중인 RDMA Read WR들(208R)을 완결하기에 충분한 정보를 제공하기에 충분하다. TCP 홀을 폐쇄할 때, 이 홀과 연관되어 있는 완결된 RDMA Read Response들의 수는 계류 중인 RDMA Read WR들(208R)의 완결을 지시하기 위해 요청자의 완결 핸들링 로직으로 보고된다.

RDMA Read Request들과 관련하여, WQE(216RR) 포스트 연산은 2가지 단계들: WQE (216RR)의 Read Queue(414)로의 배치 및 통지, 즉, RNIC(16)에 이 WQE가 프로세싱될 수 있다고 통지하기 위한 도어벨 링을 포함한다. WQE(216RR)의 배치는 순서가 어긋나게 수행될 수 있다. 그러나, 상기한 바와 같이, WQE 프로세싱의 시작(및 그에 따른 도어벨 링)은 RDMA 순서화 규칙들에 따라야 한다. 다시 말해, RDMA 프로토콜은, 임의 종류의 앞서 전송된 모든 RDMA 메시지들이 완결될 때까지, 내향 RDMA Read 메시지들(204)의 프로세싱에 대한 지연을 요청한다. 따라서, 도어벨 링, 즉, 통지는, 순서에 따른 모든 선행 RDMA Read 메시지들(204)이 완결될 때까지 지연되어야 한다. 단일 도어벨 링, 즉, 통지가 수 개 WQE들(216RR)의 포스팅을 지시할 수 있다.

상기 문제를 해결하기 위해, 본 발명에 따른 RNIC(16)는 접속 문맥(42)(PendingReadResponseNum 필드(300)(도 2B))에, 각각의 TCP 홀(130)(도 1B)에 대한 도어벨 링(통지)을 대기 중인 포스팅된 RDMA 판독 응답 WQE들(216RR)의 수를 저장한다. TCP 홀(130)이 폐쇄될 때, RNIC(16)는 PendingReadResponseNum WQE들(216RR)의 Read Queue(214)로의 포스팅을 확인하기 위해 도어벨을 울린다(통지한다). 이것은, 모든 선행 판독 메시지들(204)이 완결되었으며, RNIC(16)가 포스팅된 판독 응답 WQE들(216RR)의 프로세싱을 시작할 수 있다는 것을 지시한다.

도 13을 참조하면, RDMA Send 메시지(500)는 고유한 상황을 표현한다. 특히, 완결된 Send 메시지의 전달은 CQE(542)를 CQ(540)에 배치하는 단계를 포함한다. CQE(542)는 완결된 메시지를 설명하는 정보(예를 들어, 길이, Invalidate STag 등)를 전달한다. 이 정보는 메시지 특정 정보이므로, 계류 중인 각각의 Send 메시지(500)에 대해 유지되어야 한다. RNIC(16)는 (수신된 Read WR들(508R)에서의 RDMA Read Response WQE(508RR) 배치와 유사하게) Send 메시지(500)가 완결되기 전에는 CQE(542)를 배치할 수 없는데, CQ(540)는, 상기한 바와 같이, 수 개의 송신(510) 및 수신(512) 큐들에 의해 공유될 수 있기 때문이다.

추가적인 RNIC 리소스들을 소비하지 않으면서 그리고 판매 가능한 구현을 제공하면서 이 쟁점을 해결하기 위해, 본 발명에 따른 OutLogic(40)은 CQE(542)에 포함되어야 하는 모든 정보를 그러한 Send 메시지(500)에 의해 소비되는 WQE(516R)에 배치한다. 그 다음, 이 정보는 완결 요청을 위한 폴링시에 동사 인터페이스(20)(도 2A)에 의해 WQE(516R)로부터 검색된다. RNIC(16)는 매 TCP 홀(130)마다의 (CompletedSendsNum 필드(302)의) 완결된 송신 메시지들(500)의 수를 접속 문맥(42)에 유지해야 하는데, 이것은, 대응되는 TCP 홀이 폐쇄될 때, CQE들(542)을 CQ(540)로 포스팅하는데 사용된다. TCP 홀(130)이 폐쇄될 때, RNIC(16)는 CQE들(542)을 CQ(540)로 포스팅한다. 배치될 CQE들(542)의 수는 이 홀에 대해 카운팅된 완결된 Send 메시지들(500)의 수와 같다. 이러한 접근 방법은 2N번의 기입 연산들을 수반하는데, 여기에서 N은 완결된 Send 메시지들(500)의 수이다.

RDMA Send 메시지(500)의 전달과 관련하여 앞서 제시된 접근 방법의 일 단점은, 그것이 RNIC(16)에 의해 수행되는 기입 연산들의 수를 2배가 되게 한다는 점이다. 다시 말해, 완결된 각각의 Send 메시지(500)에 대해, WQE(516R)로의 일 기입 및 CQE(542)의 일 기입이 존재한다. 이 문제를 해결하기 위해, 도 14에 도시된 바와 같이, 본 발명의 다른 실시예에 따르면, CQE(542)의 내용은, 특정 CQE(542)가 완결한 WQE들(516R)의 기준 카운터(544)를 전달하도록 변경된다. 기준 카운터(544)는 RNIC(16)에 의해 소정 TCP 홀(130)을 위해 완결된 Send 메시지들(500)의 수로 초기화된다. 동사 인터페이스(20)는, 완결을 위한 폴링 연산 각각에 대해, 기준 카운터(544)를 감소시키고, 카운터가 0이 될 경우에만 CQ(540)로부터 CQE(542)를 제거한다. 또한, RNIC(16)는, 그것이 완결을 대기 중인 Send 메시지들(500)을 나타내는 임계 수(M)보다 큰 값을 보유하고 있을 때만, WQE(516S)를 업데이트한다. M은, 계류 중인 내향(inbound) Send 메시지들(500)을 위한 정보를 보존하기 위해 할당된 내장형(internal) 리소스들의 양을 나타내는 구성 가능한 파라미터이다. M이 0이면, 순서가 어긋나게 수신된 임의의 Send 메시지(500)는 WQE(516R)의 업데이트를 수반한다(순서에 따라 수신된 Send 메시지들(500)에 대해서는 업데이트가 불필요하다).

또한, 이 실시예는 2 종류의 CQE들(542)을 정의하는 단계 및 CQE가 모든 완결 데이터를 CQE의 바디(body)에 전달 중인 CQE인지 아니면 완결 데이터의 일부를 하나 이상의 RDMA Send 메시지들과 연관된 WQE(516R)에 저장된 완결 정보의 나머지에 의해 전달하는 CQE인지의 여부를 지시하는 표시기(546)를 CQE(542)에 제공하는 단계도 포함한다. 이러한 다른 실시예는 기입 연산들의 수를 N+1로 감소시키는데, 여기에서, N은 TCP 홀(130)이 폐쇄되기 전에 계류 중이었던 완결된 Send 메시지들(500)의 수이다.

IV. 결론

선행 논의에서, 방법 단계들은 본 발명의 펑크션 태스크들 중 하나 이상을 수행하기 위한 특수 하드웨어를 포함하고 있는 특정 용도의 컴퓨터, 즉, 유한 상태 기계에 의해 수행되는 것이 바람직하다는 것을 이해할 수 있을 것이다. 그러나, 방법 단계들은 메모리에 저장된 프로그램 제품의 명령어들을 실행하는, CPU와 같은, 프로세서에 의해서도 수행될 수 있다. 여기에서 설명되는 다양한 장치들, 모듈들, 메커니즘들 및 시스템들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합으로 실현될 수도 있으며, 도시된 것과 다르게 구분될 수도 있다는 것을 이해할 수 있을 것이다. 이들은 여기에서 설명되는 방법들을 수행하도록 적응된 임의 유형의 컴퓨터 시스템 또는 다른 장치에 의해 구현될 수도 있다. 하드웨어와 소프트웨어의 통상적인 조합은, 로딩되고 실행될 경우, 컴퓨터 시스템이 여기에서 설명되는 방법들을 수행하도록, 컴퓨터 시스템을 제어하는 컴퓨터 프로그램을 갖춘 범용 컴퓨터 시스템일 수 있다. 또한, 본 발명은, 여기에서 설명되는 방법들 및 펑크션들의 구현을 가능하게 하는 모든 사양들을 구비하며, 컴퓨터 시스템으로 로딩될 때, 이들 방법들 및 펑크션들을 수행할 수 있는 컴퓨터 프로그램 제품에 매입될 수도 있다. 본 문맥의 컴퓨터 프로그램, 소프트웨어 프로그램, 프로그램, 프로그램 제품, 또는 소프트웨어는 직접적으로 또는 (a) 다른 언어, 코드, 또는 표기 방법으로의 변환; 및/또는 (b) 상이한 재료 형태의 재생 이후에 시스템이 특정 펑크션을 수행하는 정보 프로세싱 능력을 갖게 하기 위한 한 세트의 명령어들의 임의 표현, 임의 언어의 코드 또는 표기 방법을 의미한다.

본 발명이 앞서 약술된 특정 실시예들과 관련하여 설명되었지만, 당업자들에게는 분명히 다수 대안들, 변경들, 및 변형들이 명백할 것이다. 따라서, 앞서 기 술된 본 발명의 실시예들은 한정이 아닌 예시를 위한 것이다. 다음의 청구항들에서 정의되는 본 발명의 정신 및 범위를 벗어나지 않으면서, 다양한 변경들이 이루어질 수 있다. 특히, 본 발명의 범위를 벗어나지 않으면서, 소정 환경들에서 단계들의 설명된 순서는 변경될 수 있거나 단계들의 상이한 세트에 의해 펑크션들이 제공될 수 있다.

본 발명은 컴퓨터 프로그래밍 및 정보 기술의 분야에 유용하다.

Claims (20)

1. 순서가 어긋난 RDMA Send 메시지들(500;out-of-order RDMA Send messages)의 전달에 관련한 다수의 기입 연산들을 감소시키는 방법으로서,

   기준 카운터에 CQE(completion queue element;542)를 제공하는 단계;

   상기 기준 카운터를 선택된 TCP 홀(130)을 위해 완결된 다수의 RDMA Send 메시지들(500)로 설정하는 단계;

   RDMA 동사 인터페이스(20)에 의해 수행되는 완결을 위한 폴(Poll-for-Completion) 각각에 대해 상기 기준 카운터를 1만큼 감소시키는 단계; 및

   상기 기준 카운터가 0이 되는 경우, 개개 CQ(completion queue;540)로부터 상기 CQE(542)를 제거하는 단계를 포함하는 다수의 기입 연산들을 감소시키는 방법.
2. 제 1 항에 있어서, 송신 큐의 WQE(work queue element;516)가 계류 중인 RDMA Send 메시지들(500)의 임계 수보다 큰 값을 가질 경우에만, 상기 송신 큐의 WQE를 업데이트하는 단계를 더 포함하는 다수의 기입 연산들을 감소시키는 방법.
3. 제 2 항에 있어서, 상기 임계 수는 계류 중인 RDMA Send 메시지들(500)을 위한 정보를 저장하기 위해 할당된 리소스들의 양을 나타내는 것인 다수의 기입 연산들을 감소시키는 방법.
4. 제 1 항에 있어서, 상기 CQE(542)가 완결 데이터의 적어도 일부를 포함하게 하는 단계를 더 포함하는 다수의 기입 연산들을 감소시키는 방법.
5. 제 4 항에 있어서, 상기 완결 데이터의 나머지는 하나 이상의 RDMA Send 메시지들(500)과 연관된 WQE(work queue element;516)에 포함되는 것인 다수의 기입 연산들을 감소시키는 방법.
6. 제 4 항에 있어서, 1) 상기 CQE(542)가 모든 완결 데이터를 포함함, 및 2) CQE 완결 데이터는 하나 이상의 RDMA Send 메시지들(500)과 연관된 WQE(516)에 적어도 부분적으로 포함되어 있음 중 하나를 나타내는 단계를 더 포함하는 다수의 기입 연산들을 감소시키는 방법.
7. 제 1 항에 있어서, 다수의 기입 연산들은 N+1이고, 여기에서, N은 상기 선택된 TCP 홀(130)을 폐쇄하기 전에 계류 중이었던 다수의 완결된 RDMA Send 메시지들(500)인 것인 다수의 기입 연산들을 감소시키는 방법.
8. 제 1 항 내지 제 7 항 중 어느 한 항에 기재된 각각의 단계들을 수행할 수 있는 각각의 수단을 포함하는, 순서가 어긋난 RDMA Send 메시지들(500)의 전달에 관련한 다수의 기입 연산들을 감소시키기 위한 시스템.
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 제 1 항 내지 제 7 항 중 어느 한 항에 기재된 각각의 단계들을 수행하기 위한 컴퓨터 프로그램 명령들을 포함하는, 순서가 어긋난 RDMA Send 메시지들(500)의 전달에 관련한 다수의 기입 연산들을 감소시키기 위한 컴퓨터 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체.
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images