KR20090094256A - 멀티코어 통신 처리를 위한 시스템 및 방법 - Google Patents

Abstract

데이터 처리 장치들 사이의 통신의 멀티코어 처리를 위한 시스템 및 방법이 제공된다. 예시적인 실시예의 메커니즘과 함께, 전송 및 수신측 처리를 다수의 프로세싱 코어들로 분산시킴으로써 매체 속도를 유지할 수 있도록 하는 일련의 기술들이 제공된다. 추가로, 이러한 기술들은 또한 입력/출력(I/O) 버스 상의 데이터 패킷 전달과 관련된 직접 메모리 액세스(DMA) 동작들의 지연을 효율적으로 숨기는 멀티스레드 네트워크 인터페이스 제어기(NIC) 하드웨어의 설계를 가능하게 한다. 네트워크 어댑터의 분리된 하드웨어 구현 송신큐 관리자는 데이터 패킷들의 전송을 위한 처리를 하며, 다수의 프로세싱 코어가 데이터 패킷들을 전송을 위해 처리하기 위하여 통신 프로토콜 스택 및 장치 드라이버들의 분리된 인스턴스들을 사용하여 동시에 동작할 수 있다. 네트워크 어댑터의 다수의 하드웨어 수신 패킷 프로세서가 흐름 분류기 엔진과 함께 수신된 데이터를 처리를 위해 적합한 수신큐 및 프로세싱 코어들로 라우팅하기 위해 사용될 수 있다.

Description

멀티코어 통신 처리를 위한 시스템 및 방법{SYSTEM AND METHOD FOR MULTICORE COMMUNICATION PROCESSING}

본 출원은 일반적으로 향상된 데이터 처리 시스템 및 방법에 관한 것이다. 보다 구체적으로, 본 출원은 멀티코어 통신 처리를 위한 시스템 및 방법에 관한 것이다.

고속 네트워킹이 필수적으로 되어가는 현대 컴퓨팅 시스템에서, 하나의 시스템 내에 일반적으로 다수의 프로세싱 코어(즉, 프로세서)가 존재한다. 다수의 프로세싱 코어가 제공될 수 있지만, 그와 같은 고속 네트워킹에서 데이터 패킷들의 처리는 일반적으로 수신측 및 송신측 동작을 핸들링하는 하나의 프로세싱 코어로 제한된다.

고속 네트워킹 메커니즘의 수신측 처리에서, 일반적으로 하나의 프로세서 또는 코어가 수신 인터럽트 핸들링을 수행한다. 송신측의 처리와 관련하여, 종래의 시스템은 일반적으로 하나의 프로세서 또는 코어에서, 송신측 처리의 전송 부분을 네트워크 장치 드라이버에 직렬화한다. 복수의 프로세서가 복수의 연결 상에서 데이터를 송신하려고 할 수 있지만, 이러한 동작들은 장치 드라이버에서 한번 직렬화될 것이다.

통신 처리를 핸들링하기 위해 단일 코어를 사용하는 것은 통신 병목현상을 야기한다. 통신의 속도가 증가함에 따라(예를 들어, 10 Gbps), 통신 스택(예를 들어, TCP/IP 스택)의 처리 오버헤드는 통신 처리를 핸들링하기 위해 단일 프로세싱 코어를 사용하는 것을 불가능하게 한다. 즉, 단일 프로세싱 코어는 매체 속도 대역폭을 유지할 (즉, 통신 링크 용량을 최대로 이용할) 수 없다.

Microsoft® Corporation에 의해 제안된 하나의 해결책은 수신측 확장(Receive-Side Scaling: RSS)이라고 불리고, 예를 들어 2004.04.14, WinHEC 2004 Version의 "Scalable Networking: Eliminating the Receive Processing Bottleneck-Introducing RSS"에 설명된다(Microsoft는 미국이나 기타 국가들에서 Microsoft Corporation의 상표이다). RSS 해결책은 처리를 위해 데이터 패킷들을 복수의 프로세서에 분산시키기 위하여 해시 함수 및 간접 테이블(indirection table)을 사용하는 것을 포함한다. 해시는 수신된 데이터 패킷에 기초하여 생성되고, 결과 해시 값의 최하위비트들(least significant bits)은 간접 테이블로의 인덱스로 사용될 수 있다. 간접 테이블은 복수의 프로세서 중 하나로 데이터 패킷을 보내기 위한 엔트리들을 저장한다. 데이터 패킷은 이어서 선택된 프로세서에 의해 처리된다.

RSS 해결책은 통신 패킷들의 수신측 처리를 분산시키는 것을 돕는다. 그러나, RSS는 통신 패킷들의 송신측 처리를 향상시키기 위한 어떠한 메커니즘도 제공하지 않는다. 반대로, RSS는 송신측 처리 속도가 증가하도록 하기 위해 수신측 처리량을 증가시키는 것의 수동적 효과에 전적으로 의존한다.

본 발명의 바람직한 실시예가 다음의 도면을 참고하여 예시적인 방법으로 설명될 것이다.

도 1은 예시적인 실시예의 예시적인 태양이 구현될 수 있는 분산 데이터 처리 시스템의 예시적인 블록도.

도 2는 예시적인 실시예의 전형적인 태양이 구현될 수 있는 멀티코어 데이터 처리 장치의 예시적인 도면.

도 3은 예시적인 일실시예에 따른 MCS 구현의 예시적인 하드웨어 및 소프트웨어 요소들을 도시하는 예시적인 블록도.

도 4는 예시적인 일실시예에 따른 데이터 패킷들의 수신측 처리를 도시하는 예시적인 블록도.

도 5는 예시적인 일실시예에 따른 데이터 패킷들의 전송 또는 송신측 처리를 도시하는 예시적인 블록도.

도 6A 및 6B는 예시적인 일실시예에 따라 데이터 패킷들을 수신하기 위한 예시적인 동작의 개요를 나타내는 순서도.

도 7은 예시적인 일실시예에 따라 데이터 패킷들을 전송 또는 송신하기 위한 예시적인 동작의 개요를 나타내는 순서도.

제1 태양에 따라, 데이터 처리 시스템에서 데이터 패킷을 전송하기 위한 방법으로서, 프로세싱 코어에서, 외부 장치로의 전송을 위한 데이터 패킷을 생성하는 단계; 상기 데이터 패킷의 헤더로부터 추출된 연결 정보에 기초하여 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하는 단계; 상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하는 단계; 및 네트워크 어댑터의 관련 하드웨어 구현 송신큐 관리자에 의해 상기 선택된 송신큐의 엔트리를 처리하여, 상기 데이터 패킷을 외부 장치로 전송하는 단계를 포함하고, 상기 관련 하드웨어 구현 송신큐 관리자는 상기 네트워크 어댑터에 제공되는 복수의 하드웨어 구현 송신큐 관리자 중의 하나이며, 상기 복수의 하드웨어 구현 송신큐 관리자의 각각의 하드웨어 구현 송신큐 관리자는 서로 다른 송신큐에 관련되는 방법이 제공된다.

예시적인 실시예는 여기서 멀티코어 스케일링(multicore scaling: MCS)이라고 불리는, 데이터 처리 장치들 간의 통신의 멀티코어 처리를 위한 시스템 및 방법을 제공한다. 예시적인 실시예의 메커니즘과 함께, MCS는 전송 및 수신측 처리를 다수의 프로세싱 코어들로 분산시킴으로써 메체 속도를 유지할 수 있도록 하는 일련의 기술들로 제공된다. 이러한 기술들은 또한 입력/출력(I/O) 버스 상의 데이터 패킷 전달과 관련된 직접 메모리 액세스(direct memory access: DMA) 동작들의 지연(latency)을 효율적으로 숨기는 멀티스레드 네트워크 인터페이스 제어기(network interface controller: NIC) 하드웨어의 설계를 가능하게 한다.

예시적인 실시예의 메커니즘에 따라, MCS는 병렬 패킷 처리를 두 개의 중요한 레벨(소프트웨어 레벨(예를 들어, TCP/IP 스택 레벨) 및 하드웨어 레벨(예를 들어, NIC 레벨))에서 가능하게 함으로써 매체 속도 통신 프로토콜을 전달한다(예를 들어, TCP/IP 처리). 기본 개념은 통신 링크가 대부분 서로 독립적인 흐름(즉, 연결)을 갖는다는 사실에 기초한다. 따라서, 이러한 흐름들(하나의 물리적 또는 가상적 포트로부터 나오거나 들어가는)은, 다수의 프로세싱 코어 상에서 병렬적으로 처리될 수 있다. NIC 레벨에서, 멀티스레딩은 서로 다른 흐름들에 속한 패킷들이 서로 다른 하드웨어 스레드들에 의해 동시에 처리될 수 있도록 한다.

수신측에서, 흐름 식별이 NIC에서 통신 프로토콜 스택의 MAC 계층 바로 위의 레벨에서 수행될 수 있다. 각각의 흐름은 이어서 NIC 내부의 서로 다른 하드웨어 스레드들에 의해 동시에 처리될 수 있으며, 각각의 흐름 전용 인터럽트들 및 큐들을 사용하여 서로 다른 프로세싱 코어들로 보내질 수 있다. 전송측에서, 흐름 식별은 소프트웨어(예를 들어, 통신 프로토콜 스택 및/또는 장치 드라이버)에 의해 수행될 수 있다. 각각의 흐름은 바람직하게는 전용 송신큐에 관련되고 각각의 송신큐는 NIC 내부의 서로 다른 하드웨어 스레드에 의해 처리될 수 있다.

예시적인 실시예들의 메커니즘과 함께, NIC는 복수의 송신큐 관리자(send queue manager: SQMs)와 함께 제공되는데, 이들은 NIC에 의한 전송을 위해 관련 송신큐로 제출된 패킷들을 처리하는 하드웨어 요소들이다. 호스트 시스템의 프로세싱 코어들은 SQM들이 직접 메모리 액세스(DMA) 동작들을 이용하여 데이터 패킷을 처리하고 관련된 물리적 또는 가상적 포트를 통하여 데이터 패킷을 전송할 관련 송신큐로 패킷들을 위치시킨다.

예시적인 실시예에 따라, NIC는 나아가 하드웨어로 제공되는, 관련된 물리적 또는 가상적 포트를 통하여 수신된 패킷들을 처리하기 위한 복수의 수신 패킷 프로세서(receive packet processor: RPPs)와 함께 제공된다. RPP들은 동일한 물리적 또는 가상적 포트를 통하여 도착하는 데이터 흐름들을 분리하도록 동작하는 하드웨어 구현 흐름 분류기 엔진과 협력하여 동작한다. 흐름 분류기 엔진에 의해 수행되는 분류에 기초하여, 수신큐가 선택된다. 임의의 일정한 시간에, 스케줄러 엔진은 RPP가 일정한 수신큐와 함께 사용되도록 선택할 수 있고, 스케줄러 엔진은 이어서 동일한 시간에 동일한 수신큐 상에서 동작하는 두 RPP가 존재하지 않도록 확실히 할 것이다. 데이터 패킷은 선택된 수신큐에 대한 패킷들을 처리하는 RPP들 중의 하나로 제공된다. 수신큐와 관련된 프로세서에 새로운 데이터 패킷이 처리를 위해 도착하였다는 것을 알리기 위해 인터럽트 또는 폴링 기술이 사용될 수 있다.

예시적인 실시예에 따라, 프로세싱 코어들은 데이터 패킷들의 전송 및 수신을 위한 전송 및 수신큐 이용을 핸들링하기 위한 소프트웨어를 실행한다. 이 소프트웨어는 통신 프로토콜 스택 레벨에서 동작하고, 통신 프로토콜 스택의 일부로 구현되거나 예를 들어 분리된 장치 드라이버로 구현될 수 있다. 예시적인 일실시예에서, 소프트웨어는 TCP/IP 스택의 어떠한 변화도 요구하지 않고 동작하는 NIC 장치 드라이버로 구현된다.

수신측 처리에서, 소프트웨어는 데이터 패킷 수신을 나타내는 인터럽트 생성에 대응하여 동작할 수 있고, 처리를 위해 수신된 데이터 패킷을 통신 프로토콜 스택(예를 들어, TCP/IP 스택)으로 전달하는 역할을 할 수 있다. 송신측 처리에서, 소프트웨어는 데이터 패킷들을 송신할 송신큐를 선택하도록 동작할 수 있고, 선택된 송신큐에 데이터 패킷들을 큐잉할 수 있다. 소프트웨어는 이어서 송신큐와 관련된 도어벨(doorbell)을 설정하여, NIC에게 데이터 패킷이 송신될 준비가 되었다는 것을 알릴 수 있다.

소프트웨어 메커니즘에 의해 수행되는 송신 및 수신 양측의 처리는 서로 병렬적으로, 그리고 다른 프로세싱 코어 상에서 실행되는 다른 소프트웨어 인스턴스에 의해 수행되는 다른 송신 및 수신측 처리와 병렬적으로 수행될 수 있다. 다수의 TCP/IP 인스턴스들이 동일한 데이터 흐름의 부분인 연결들 상에서 동작할 수 있기 때문에 TCP/IP 스택이 송신큐에 액세스할 필요가 있는 경우(즉, 다수의 TCP/IP 스택이 동일한 송신큐에 액세스해야 할 수 있고, 따라서 잠금(lock)이 필요할 수 있음)를 제외하고는 그러한 처리에 잠금이 요구되지 않는다.

따라서, 예시적인 실시예의 MCS 메커니즘은 통신 흐름의 전송 및 수신 양측의 동시적인 처리를 가능하게 함으로써 고성능을 제공한다. 게다가, MCS 메커니즘은 바람직하게는 NIC 및 프로세싱 코어들에서의 동시적인 처리를 가능하게 함으로써 고성능을 가능하게 한다. 더 나아가, MCS 메커니즘은 바람직하게는 흐름들과 프로세서 캐시들 사이에 선택적인 친화성(affinity)을 만듦으로써 고성능을 가능하게 한다. 이러한 이점들 모두는 통신 링크 용량의 전부가 이용될 수 있도록 하여 예시적인 실시예의 MCS 메커니즘이 10 Gbps 이상의 고속 매체 대역폭을 포함하는 고속 매체 응용에 적합하도록 만든다.

상기 프로세싱 코어는 복수의 프로세싱 코어 중의 하나일 수 있다. 상기 방법은 상기 복수의 프로세싱 코어 각각에 대해 실질적으로 병렬 방식(parallel manner)으로 구현될 수 있다.

상기 데이터 패킷의 전송을 위해 사용하는 송신큐를 선택하는 단계는, 시스템 메모리로부터 송신 버퍼 기술자(descriptor) 정보를 검색하는 단계 및 상기 연결 정보 및 상기 송신 버퍼 기술자 정보에 기초하여 송신큐가 상기 데이터 패킷에 관련된 연결을 위해 이전에 할당되었는지를 결정하는 단계를 포함할 수 있다. 송신큐를 선택하는 단계는, 송신큐가 상기 연결을 위해 이전에 할당되었다면 상기 이전에 할당된 송신큐를 선택하는 단계를 더 포함할 수 있다. 송신큐가 상기 연결을 위해 이전에 할당되지 않았다면, 상기 방법은 해시 값을 생성하기 위해 상기 연결 정보에 해시 동작을 수행하는 단계, 상기 생성된 해시 값에 기초하여 라우팅 테이블 데이터 구조로 인덱싱하는 단계, 및 상기 해시 값과 관련된 상기 라우팅 테이블 데이터 구조에 저장된 엔트리의 값에 기초하여 송신큐를 선택하는 단계를 포함할 수 있다.

상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하는 단계 및 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하는 단계는, 상기 프로세싱 코어에서 실행되는 소프트웨어에 의해 수행될 수 있다. 상기 소프트웨어는 통신 프로토콜 스텍으로부터 분리되는 네트워크 인터페이스 장치 드라이버일 수 있다. 선택적으로, 상기 소프트웨어는 통신 프로토콜 스택의 일부분일 수 있다.

방법은 상기 데이터 처리 시스템의 네트워크 인터페이스에서 인입(incoming) 데이터 패킷을 수신하는 단계 및 상기 인입 데이터 패킷을 위치시키기 위한 수신큐를 선택하기 위해 하드웨어 구현 데이터 흐름 분류기 엔진을 사용하여 상기 인입 데이터 패킷을 처리하는 단계를 더 포함할 수 있다. 게다가, 방법은 하드웨어 구현 수신 패킷 프로세서에 의해, 상기 데이터 흐름 분류기 엔진에 의해 수행된 상기 선택에 기초하여 상기 인입 데이터 패킷을 선택된 수신큐에 위치시키는 단계를 더 포함할 수 있다.

상기 데이터 흐름 분류기 엔진은 상기 인입 데이터 패킷이 수신된 연결을 위한 수신큐가 이전에 할당되었는지 결정하고 수신큐가 상기 연결을 위해 이전에 할당되었다면 상기 이전에 할당된 수신큐를 선택함으로써 수신큐를 선택할 수 있다. 상기 연결을 위한 수신큐가 이전에 할당되지 않았다면, 상기 데이터 흐름 분류기 엔진은 상기 인입 데이터 패킷으로부터 연결 정보를 추출하고, 해시 값을 생성하기 위해 상기 추출된 연결 정보에 해시 동작을 수행하며, 상기 생성된 해시 값에 기초하여 상기 인입 데이터 패킷이 라우팅될 수신큐를 선택하기 위해 라우팅 테이블로 인덱싱할 수 있다.

상기 수신 패킷 프로세서는 복수의 수신 패킷 프로세서 중의 하나일 수 있다. 상기 수신 패킷 프로세서는 상기 복수의 수신 패킷 프로세서의 수신 패킷 프로세서들의 이용가능성에 기초하여 스케줄러 엔진에 의해 상기 복수의 수신 패킷 프로세서로부터 선택될 수 있다.

방법은 상기 선택된 수신큐와 관련된 프로세싱 코어로 인터럽트를 송신하는 단계 및 상기 선택된 수신큐와 관련된 수신 완료 큐에 완료 이벤트 엔트리를 포스팅하는 단계를 더 포함할 수 있다. 게다가, 방법은 통신 프로토콜 스택에 의해, 상기 선택된 수신큐에 위치된 상기 인입 데이터 패킷을 처리하는 단계를 포함할 수 있다.

다른 일실시예에 따라, 적어도 하나의 프로세싱 코어; 및 상기 적어도 하나의 프로세싱 코어에 결합되는 네트워크 어댑터를 포함하는 장치로서, 상기 적어도 하나의 프로세싱 코어는, 외부 장치로의 전송을 위한 데이터 패킷을 생성하고, 상기 데이터 패킷의 헤더로부터 추출된 연결 정보에 기초하여 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하며, 상기 데이터 패킷을 위해 선택된 송신큐에 엔트리를 생성하고, 상기 선택된 송신큐의 상기 엔트리는 네트워크 어댑터의 관련 하드웨어 구현 송신큐 관리자에 의해 처리되어 상기 데이터 패킷을 외부 장치로 전송하고, 상기 관련 하드웨어 구현 송신큐 관리자는 네트워크 어댑터에 제공되는 복수의 하드웨어 구현 송신큐 관리자 중 하나이며, 상기 복수의 하드웨어 구현 송신큐 관리자의 각각의 하드웨어 구현 송신큐 관리자는 서로 다른 송신큐에 관련되는 장치가 제공된다.

상기 적어도 하나의 프로세싱 코어는 복수의 프로세싱 코어 중 하나일 수 있다. 상기 복수의 프로세싱 코어 각각은 상기 생성 및 선택 동작 중 하나 이상을 실질적으로 병렬 방식으로 수행할 수 있다.

상기 적어도 하나의 프로세싱 코어는, 시스템 메모리로부터 송신 버퍼 기술자 정보를 검색하고, 상기 연결 정보 및 상기 송신 버퍼 기술자 정보에 기초하여 송신큐가 그 데이터 패킷에 관련된 연결에 이전에 할당되었는지를 결정하며, 송신큐가 상기 연결을 위해 이전에 할당되었다면 상기 이전에 할당된 송신큐를 선택함으로써 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택할 수 있다. 만약 송신큐가 상기 연결을 위해 이전에 할당되지 않았다면, 상기 적어도 하나의 프로세싱 코어는, 해시 값을 생성하기 위해 상기 연결 정보에 해시 동작을 수행하고, 상기 생성된 해시 값에 기초하여 라우팅 테이블 데이터 구조로 인덱싱하며, 상기 해시 값과 관련된 라우팅 테이블 데이터 구조에 저장된 엔트리의 값에 기초하여 송신큐를 선택함으로써 송신큐를 선택할 수 있다.

상기 적어도 하나의 프로세싱 코어는, 상기 적어도 하나의 프로세싱 코어에서 소프트웨어를 실행함으로써 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택할 수 있고, 상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성할 수 있다. 소프트웨어는 통신 프로토콜 스택으로부터 분리되는 네트워크 인터페이스 장치 드라이버일 수 있다. 선택적으로, 소프트웨어는 통신 프로토콜 스택의 일부분일 수 있다.

상기 네트워크 어댑터는, 상기 데이터 처리 시스템의 네트워크 인터페이스에서 인입 데이터 패킷을 수신하고, 상기 인입 데이터 패킷을 위치시키기 위한 수신큐를 선택하기 위해 하드웨어 구현 데이터 흐름 분류기 엔진을 사용하여 상기 인입 데이터 패킷을 처리할 수 있다. 네트워크 어댑터는 추가로, 하드웨어 구현 수신 패킷 프로세서에 의해, 상기 데이터 흐름 분류기 엔진에 의해 수행된 상기 선택에 기초하여 상기 인입 데이터 패킷을 선택된 수신큐에 위치시킬 수 있다.

상기 데이터 흐름 분류기 엔진은 상기 인입 데이터 패킷이 수신된 연결을 위한 수신큐가 이전에 할당되었는지 결정하고, 수신큐가 상기 연결을 위해 이전에 할당되었다면 상기 이전에 할당된 수신큐를 선택함으로써 수신큐를 선택할 수 있다. 상기 연결을 위한 수신큐가 이전에 할당되지 않았다면, 상기 데이터 흐름 분류기 엔진은 상기 인입 데이터 패킷으로부터 연결 정보를 추출하고, 해시 값을 생성하기 위해 상기 추출된 연결 정보에 해시 동작을 수행하며, 상기 생성된 해시 값에 기초하여 상기 인입 데이터 패킷이 라우팅될 수신큐를 선택하기 위해 라우팅 테이블로 인덱싱할 수 있다.

상기 수신 패킷 프로세서는 복수의 수신 패킷 프로세서 중의 하나일 수 있다. 수신 패킷 프로세서는 복수의 수신 패킷 프로세서의 수신 패킷 프로세서들의 이용가능성에 기초하여 스케줄러 엔진에 의해 상기 복수의 수신 패킷 프로세서로부터 선택될 수 있다.

상기 수신 패킷 프로세서는 상기 선택된 수신큐와 관련된 프로세싱 코어로 인터럽트를 송신할 수 있다. 상기 수신 패킷 프로세서는 추가로 상기 선택된 수신큐와 관련된 수신 완료 큐에 완료 이벤트 엔트리를 포스팅할 수 있다. 상기 적어도 하나의 프로세싱 코어의 통신 프로토콜 스택은 상기 선택된 수신큐에 위치된 상기 인입 데이터 패킷을 처리할 수 있다.

다른 일실시예에 따라, 복수의 프로세싱 코어(상기 복수의 프로세싱 코어의 각각의 프로세싱 코어는 통신 프로토콜 스택 인스턴스 및 네트워크 인터페이스 장치 드라이버 인스턴스를 실행함); 상기 복수의 프로세싱 코어에 결합되는 네트워크 어댑터를 포함하는 시스템으로서, 상기 네트워크 어댑터는 복수의 하드웨어 구현 송신큐 관리자; 및 복수의 하드웨어 구현 수신 패킷 프로세서를 포함하고, 상기 복수의 하드웨어 구현 송신큐 관리자는 상기 복수의 프로세싱 코어에 의해 송신큐에 위치된 데이터 패킷들을 처리하고, 상기 복수의 하드웨어 구현 수신 패킷 프로세서는 상기 네트워크 어댑터의 포트를 통하여 상기 네트워크 어댑터에 의해 수신된 데이터 패킷들을 처리하는 시스템이 제공된다.

상기 복수의 프로세싱 코어의 각각의 프로세싱 코어는, 각각의 프로세싱 코어가 외부 장치로 전송하는 대응되는 데이터 패킷들에 대해, 외부 장치로의 전송을 위한 데이터 패킷을 생성하는 동작; 상기 데이터 패킷의 헤더로부터 추출된 연결 정보에 기초하여 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하는 동작; 및 상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하는 동작을 실질적으로 병렬 방식으로 수행할 수 있다.

상기 네트워크 어댑터는 관련 하드웨어 구현 송신큐 관리자에 의해 선택된 송신큐의 엔트리를 처리하여, 상기 데이터 패킷을 상기 외부 장치로 전송할 수 있다. 상기 관련 하드웨어 구현 송신큐 관리자는 상기 복수의 하드웨어 구현 송신큐 관리자 중 하나일 수 있다. 상기 복수의 하드웨어 구현 송신큐 관리자의 각각의 하드웨어 구현 송신큐 관리자는 서로 다른 송신큐에 관련될 수 있다.

각각의 프로세싱 코어는, 시스템 메모리로부터 송신 버퍼 기술자 정보를 검색하고, 상기 연결 정보 및 상기 송신 버퍼 기술자 정보에 기초하여 송신큐가 상기 데이터 패킷에 관련된 연결을 위해 이전에 할당되었는지 결정하며, 송신큐가 상기 연결을 위해 이전에 할당되었다면 상기 이전에 할당된 송신큐를 선택함으로써 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택할 수 있다. 만약 송신큐가 상기 연결을 위해 이전에 할당되지 않았다면, 각각의 프로세싱 코어는 해시 값을 생성하기 위해 상기 연결 정보에 해시 동작을 수행하고, 상기 생성된 해시 값에 기초하여 라우팅 테이블 데이터 구조로 인덱싱하며, 상기 해시 값과 관련된 상기 라우팅 테이블 데이터 구조에 저장된 엔트리의 값에 기초하여 송신큐를 선택함으로써 송신큐를 선택할 수 있다.

상기 네트워크 어댑터는, 상기 데이터 처리 시스템의 네트워크 인터페이스에서 인입 데이터 패킷을 수신하고, 상기 인입 데이터 패킷을 위치시키기 위한 수신큐를 선택하기 위해 하드웨어 구현 데이터 흐름 분류기 엔진을 사용하여 상기 인입 데이터 패킷을 처리할 수 있으며, 상기 복수의 수신 패킷 프로세서의 하드웨어 구현 수신 패킷 프로세서에 의해, 상기 데이터 흐름 분류기 엔진에 의해 수행된 상기 선택에 기초하여 상기 인입 데이터 패킷을 선택된 수신큐에 위치시킬 수 있다.

상기 데이터 흐름 분류기 엔진은 상기 인입 데이터 패킷이 수신된 연결을 위한 수신큐가 이전에 할당되었는지 결정하고, 수신큐가 상기 연결을 위해 이전에 할당되었다면 상기 이전에 할당된 수신큐를 선택함으로써 수신큐를 선택할 수 있다. 상기 연결을 위한 수신큐가 이전에 할당되지 않았다면, 상기 데이터 흐름 분류기 엔진은, 상기 인입 데이터 패킷으로부터 연결 정보를 추출하고, 해시 값을 생성하기 위해 상기 추출된 연결 정보에 해시 동작을 수행하며, 상기 생성된 해시 값에 기초하여 상기 인입 데이터 패킷이 라우팅될 수신큐를 선택하기 위해 라우팅 테이블로 인덱싱할 수 있다. 상기 수신 패킷 프로세서는 상기 복수의 수신 패킷 프로세서의 수신 패킷 프로세서들의 이용가능성에 기초하여 상기 네트워크 어댑터의 스케줄러 엔진에 의해 상기 복수의 수신 패킷 프로세서들 중에서 선택될 수 있다.

상기 수신 패킷 프로세서는, 상기 선택된 수신큐와 관련된 프로세싱 코어로 인터럽트를 송신할 수 있고, 상기 선택된 수신큐와 관련된 수신 완료 큐에 완료 이벤트 엔트리를 포스팅할 수 있다. 대응되는 프로세싱 코어의 통신 프로토콜 스택 인스턴스는 상기 선택된 수신큐에 위치된 상기 인입 데이터 패킷을 처리할 수 있다.

다른 일실시예에 따라, 컴퓨터 판독가능 프로그램이 있는 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 판독가능 프로그램은 컴퓨팅 장치에서 실행되었을 때 상기 컴퓨팅 장치로 하여금, 프로세싱 코어에서 외부 장치로의 전송을 위한 데이터 패킷을 생성하고, 상기 데이터 패킷의 헤더로부터 추출된 연결 정보에 기초하여 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하며, 상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하고, 네트워크 어댑터의 관련 하드웨어 구현 송신큐 관리자에 의해 상기 선택된 송신큐의 엔트리를 처리하여 상기 데이터 패킷을 외부 장치로 전송하도록 하고, 상기 관련 하드웨어 구현 송신큐 관리자는 상기 네트워크 어댑터에 제공되는 복수의 하드웨어 구현 송신큐 관리자 중의 하나이며, 상기 복수의 하드웨어 구현 송신큐 관리자의 각각의 하드웨어 구현 송신큐 관리자는 서로 다른 송신큐와 관련되는 컴퓨터 프로그램 제품이 제공된다.

예시적인 실시예는 멀티코어 통신 처리를 위한 시스템 및 방법을 제공한다. 이러한 이유로, 예시적인 실시예의 메커니즘은 바람직하게는 분산 데이터 처리 시스템 내의 하나 이상의 데이터 네트워크를 통하여 서로 통신하는 멀티코어 또는 멀티프로세서 데이터 처리 장치에 구현될 수 있다. 따라서, 예시적인 실시예의 메커니즘이 구현될 수 있는 예시적인 환경을 이해하도록, 도 1-2가 이하에 분산 데이터 처리 시스템 및 멀티코어 또는 멀티프로세서 데이터 처리 장치의 예로서 제공된다. 그 후의 도면들은 이 예시적인 환경에 구현될 수 있는 예시적인 실시예의 특정 메커니즘들을 나타낸다. 도 1-2는 예시적인 실시예가 구현될 수 있는 데이터 처리 환경의 종류 또는 구성에 어떠한 제한도 제시하거나 암시하도록 의도되지 않았고, 예시적인 것으로만 의도되었다는 것을 이해해야 한다. 도시된 환경에 많은 변경이 본 발명의 사상과 범위를 벗어나지 않고 이루어질 수 있다.

이제 도면을 참고하면, 도 1은 예시적인 실시예의 태양들이 구현될 수 있는 예시적인 분산 데이터 처리 시스템의 회화적 표현을 도시한다. 분산 데이터 처리 시스템(100)은 예시적인 실시예가 구현될 수 있는 컴퓨터들의 네트워크를 포함할 수 있다. 분산 데이터 처리 시스템(100)은 적어도 하나의 네트워크(102)를 포함하는데, 이는 분산 데이터 처리 시스템(100) 내에 같이 연결되는 다양한 장치들 및 컴퓨터들 사이에 통신 링크를 제공하는데 사용되는 매체이다. 네트워크(102)는 유선, 무선 통신 링크, 또는 광섬유 케이블과 같은 연결들을 포함할 수 있다.

도시된 예에서, 서버(104) 및 서버(106)는 저장 유닛(108)과 함께 네트워크(102)에 연결된다. 추가로, 클라이언트들(110, 112 및 114)도 네트워크(102)에 연결된다. 이 클라이언트들(110, 112 및 114)은, 예를 들어 개인용 컴퓨터 또는 네트워크 컴퓨터 등일 수 있다. 도시된 예에서, 서버(104)는, 예를 들어 부트 파일, 운영체제 이미지 및 애플리케이션들과 같은 데이터를 클라이언트들(110, 112 및 114)로 제공할 수 있다. 클라이언트들(110, 112 및 114)은 도시된 예에서 서버(104)에 대한 클라이언트들이다. 분산 데이터 처리 시스템(100)은 추가적인 서버, 클라이언트 및 기타 도시되지 않은 장치들을 포함할 수 있다.

도시된 예에서, 분산 데이터 처리 시스템(100)은 인터넷이고, 네트워크(102)는 서로 통신하기 위한 프로토콜의 TCP/IP 모음을 사용하는 네트워크 및 게이트웨이의 월드와이드 집합을 나타낸다. 인터넷의 중심에는 주요 노드들 또는 호스트 컴퓨터들 사이의 고속 데이터 통신선의 백본이 존재하는데, 이는 데이터 및 메시지를 라우팅하는 수천의 상업적, 관영, 교육용 및 기타 컴퓨터 시스템들로 구성된다. 물론, 분산 데이터 처리 시스템(100)은, 예를 들어 인트라넷, LAN 또는 WAN 등과 같은 다수의 서로 다른 종류의 네트워크를 포함하도록 구현될 수도 있다. 위에 기술한 바와 같이, 도 1은 하나의 예로 의도되었고, 본 발명의 다양한 실시예들에 대한 구조적인 제한으로 의도되지 않았으므로, 도 1에 도시된 구체적 요소들은 본 발명의 예시적인 실시예가 구현될 수 있는 환경에 관한 제한으로 여겨져서는 안 된다.

도 2는 본 발명의 실시예가 구현될 수 있는 데이터 처리 장치의 예시적인 블록도이다. 도 2에 도시된 예시적인 데이터 처리 장치는 멀티코어 또는 멀티프로세서 데이터 처리 장치의 한 종류의 예이지만, 당업자가 이하의 설명을 읽을 때 자명한 것처럼 본 발명은 이에 한정되지 않는다. 오히려, 예시적인 실시예의 메커니즘은 임의의 멀티코어 또는 멀티프로세서 데이터 처리 장치에 적용가능하다. 다른 멀티코어 또는 멀티프로세서 데이터 처리 장치는 도 2에 도시된 것과 매우 상이한 구조를 가질 수 있지만, 어떤 한 멀티코어 또는 멀티프로세서 구조에 한정되지 않는 본 발명의 사상 및 범위 내인 것으로 여겨져야 한다.

도 2는 예시적인 실시예에 따라 도 1에 도시된 서버 또는 클라이언트 컴퓨팅 장치로 구현될 수 있는 대칭형 멀티프로세서(symmetric multiprocessor: SMP) 데이터 처리 장치의 보다 상세한 블록도이다. SMP 데이터 처리 장치가 여기에 설명되어 있지만, 예시적인 실시예의 메커니즘은 본 발명의 사상 및 범위를 벗어나지 않고 서로 다른 프로세싱 코어들이 서로 다른 명령어들의 세트들을 실행하는 이종(heterogeneous) 멀티코어 또는 멀티프로세서 데이터 처리 장치에 이용될 수 있다고 이해해야 한다. 예를 들어, 예시적인 실시예의 메커니즘은 Armonk, New York의 International Business Machines Corporation로부터 입수할 수 있는 CBE(Cell Broadband Engine)와 같은 이종 멀티프로세서 시스템 온 칩에 구현될 수 있다.

도 2를 참고하면, 데이터 처리 장치(200)는 시스템 버스(206)에 연결되는 복수의 프로세서(202 및 204)를 포함한다. 로컬 메모리(209)로의 인터페이스를 제공하는 메모리 제어기/캐시(208) 또한 시스템 버스(206)에 연결된다. I/O 버스 브리지(210)는 시스템 버스(206)에 연결되고 I/O 버스(212)로의 인터페이스를 제공한다. 메모리 제어기/캐시(208)와 I/O 버스 브리지(210)는 도시된 것처럼 통합될 수 있다.

I/O 버스(212)에 연결되는 PCI(Peripheral component interconnect) 버스 브리지(214)는 PCI 로컬 버스(216)로의 인터페이스를 제공한다. 다수의 모뎀이 PCI 버스(216)로 연결될 수 있다. 일반적인 PCI 버스 구현은 네 개의 PCI 확장 슬롯 또는 애드 인(add-in) 커넥터들을 지원할 것이다. 도 1의 네트워크 컴퓨터들(108-112)로의 통신 링크들은 애드 인 보드를 통하여 PCI 로컬 버스(216)에 연결되는 모뎀(218) 및 네트워크 어댑터(220)를 통하여 제공될 수 있다.

추가적인 PCI 버스 브리지들(222 및 224)은 추가적인 모뎀 또는 네트워크 어댑터가 지원될 수 있는 추가적인 PCI 버스들(226 및 228)을 위한 인터페이스를 제공한다. 이러한 방법으로, 데이터 처리 장치(200)는 다수의 네트워크 컴퓨터로의 연결을 가능하게 한다. 메모리 매핑 그래픽 어댑터(230) 및 하드디스크(232)도 또한 도시된 것처럼 직접적으로 또는 간접적으로 I/O 버스(212)에 연결될 수 있다.

당업자는 도 2에 도시된 하드웨어가 변경될 수 있다고 이해할 것이다. 예를 들어, 광디스크 드라이브 등과 같은 다른 주변 장치들도 도시된 하드웨어에 추가로 또는 이를 대신하여 사용될 수 있다. 도시된 예는 본 발명에 대해 구조적인 제한을 암시하도록 의도되지 않았다.

도 2에 도시된 데이터 처리 장치는, 예를 들어 Armonk, New York의 International Business Machines Corporation의 제품으로서 Advanced Interactive Executive(AIX®) 운영체제를 실행하는 IBM® RISC/System 6000® 시스템일 수 있다. 물론, 여기에 설명되고 독립적인 특허청구범위에 설명되는 예시적인 실시예의 하나 이상의 메커니즘들을 구현하는 한, 다른 운영체제를 실행하는 다른 데이터 처리 장치가 도 2에 도시된 것 대신 이용될 수 있다(IBM 및 RISC/System 6000은 미국이나 기타 국가들에서 International Business Machines Corporation의 상표이다).

예시적인 실시예는 여기서 멀티코어 스케일링(MCS)이라고 불리는, 데이터 처리 장치들간의 통신들의 멀티코어 처리를 위한 시스템 및 방법을 제공한다. 예시적인 실시예의 메커니즘과 함께, MCS는 전송 및 수신측 처리를 다수의 프로세싱 코어들로 분산시킴으로써 메체 속도를 유지할 수 있도록 하는 일련의 기술들을 제공한다. 추가로, 이러한 기술들은 또한 입력/출력(I/O) 버스 상의 데이터 패킷 전달과 관련된 직접 메모리 액세스 동작들의 지연을 효율적으로 숨기는 멀티스레드 네트워크 인터페이스 제어기(NIC) 하드웨어의 설계를 가능하게 한다.

예시적인 실시예의 메커니즘에 따라, MCS는 병렬 패킷 처리를 두 개의 중요한 레벨(소프트웨어 레벨(예를 들어, TCP/IP 스택 레벨) 및 하드웨어 레벨(예를 들어, NIC 레벨))에서 가능하게 함으로써 매체 속도 통신 프로토콜(예를 들어, TCP/IP 처리)을 전달한다. 기본 개념은 통신 링크가 대부분 서로 독립적인 흐름(즉, 연결)을 갖는다는 사실에 기초한다. 따라서, 이러한 흐름들(하나의 물리적 또는 가상적 포트로부터 나오거나 들어가는)은, 다수의 프로세싱 코어 상에서 병렬적으로 처리될 수 있다. NIC 레벨에서, 멀티스레딩은 서로 다른 흐름들에 속한 패킷들이 서로 다른 하드웨어 스레드들에 의해 동시에 처리될 수 있도록 한다.

도 3은 예시적인 일실시예에 따른 MCS 구현의 예시적인 하드웨어 및 소프트웨어 요소들을 도시하는 예시적인 블록도이다. 도 3에 도시된 바와 같이, 복수의 프로세싱 코어(310-314 및 340-344)가 멀티코어 데이터 처리 장치에 제공되는데, 각각의 프로세싱 코어(310-314 및 340-344)는 도시된 예에서 TCP/IP 스택인 통신 프로토콜 스택의 분리된 인스턴스(320, 350)를 실행한다. 추가로, 각각의 프로세싱 코어(310-314 및 340-344)는 예시적인 실시예의 태양이 구현될 수 있는 네트워크 인터페이스 카드(NIC) 장치 드라이버(325, 355)의 분리된 인스턴스(실행의 스레드)를 실행한다. 도 3에 도시된 예시적인 실시예는 분리된 NIC 장치 드라이버(325, 355)에 구현되는 예시적인 실시예의 소프트웨어 태양을 도시하지만, 다른 예시적인 실시예에서, 예시적인 실시예의 소프트웨어 태양은 통신 프로토콜 스택(320, 350)의 일부분으로서 구현될 수 있다.

NIC 장치 드라이버(325, 355)는 데이터 패킷이 NIC(370)으로부터 송신 또는 수신되는 송신큐(SQ)(330-336) 및 수신큐(RQ)(360-366)와 인터페이스 연결을 하도록 동작한다. SQ(330-336) 및 RQ(360-366)는 프로세싱 코어들(310-314, 340-344) 및 NIC(370)에 의해 액세스될 수 있는 메모리 또는 기타 저장소(예를 들어, 시스템 메모리) 내에 유지되는 데이터 구조일 수 있다. SQ(330-336) 및 RQ(360-366)는 일반적으로 하나의 송신큐와 하나의 수신큐를 포함하는 큐쌍(Queue pair: QP)으로서 하나 이상의 프로세싱 코어(310-314 및 340-344)에 할당된다. 예를 들어, QP는 당업계에 일반적으로 알려져 있고 www.infinibandta.org/specs/ 에서 InfiniBand Trade Association으로부터 입수할 수 있는 InfiniBand 상세사항에 따라 할당되고 유지될 수 있다. 게다가, QP의 사용은, 예를 들어 공통으로 양도된 2004.04.13에 보이드(Boyd) 등에게 발행된 미국특허 제6,721,806호 및 2006.03.07에 아른트(Arndt) 등에게 발행된 미국특허 제7,010,633에 추가로 설명되어 있다.

NIC(370)는 하나 이상의 데이터 네트워크와의 통신이 이용가능하게 될 수 있는 네트워크 인터페이스 또는 어댑터의 임의의 종류일 수 있다. NIC(370)는 분리된 "카드"일 필요가 없고, 호스트 시스템으로부터 분리되거나 이에 통합되는 임의의 장치일 수 있는데, 데이터 패킷들은 이 장치를 통하여 송신 및/또는 수신될 수 있다. NIC(370)는 하나 이상의 송신큐 관리자(SQM) 엔진(372), 큐쌍(QP) 콘텍스트 저장소(376), 디스패처 엔진(dispatcher engine)(378), 하나 이상의 수신 패킷 프로세서(RPP) 엔진(380), 스케줄러 엔진(390), 흐름 분류기 엔진(392), 및 하나 이상의 포트(399)를 포함한다.

SQM(372)은 포트(399)를 통한 NIC(370)에 의한 전송을 위해 관련 송신큐(330-336)에 제출된 패킷들을 처리하는 하드웨어 요소들이다. 호스트 시스템의 프로세싱 코어들은 직접 메모리 액세스(DMA) 동작을 사용하여 패킷들을 SQM(372)이 데이터 패킷들을 처리할 수 있는 관련 송신큐(330-336)에 위치시키고, 데이터 패킷들을 관련 물리적 또는 가상적 포트(399)를 통하여 전송한다. 디스패처 엔진(378)은 특정한 시간에, 특정 송신큐(330-336)로부터의 데이터 흐름을 핸들링하도록 SQM(372)을 선택한다. 디스패처 엔진(378)은 추가로, 동일한 시간에 동일한 송신큐(330-336)로부터의 데이터 흐름들에 대해 두 SQM(372)들이 서비스를 제공하지 못하도록, 한 시점에 특정 송신큐(330-336)로부터의 데이터 흐름을 하나의 SQM만이 핸들링하도록 보장한다.

RPP(380)는 관련 물리적 또는 가상적 포트(399)를 통하여 수신된 데이터 패킷들을 처리하기 위해 서로 병렬적으로 동작하는 하드웨어 구현 엔진들이다. RPP(380)는 동일한 물리적 또는 가상적 포트(399)를 통하여 도달하는 데이터 흐름들을 분리해내도록 동작하는 하드웨어 구현 흐름 분류기 엔진(392)과 협력하여 동작한다. 흐름 분류기 엔진(392)에 의해 수행되는 분류에 기초하여, 수신큐(360-366)가 선택된다. 임의의 일정한 시간에, 스케줄러 엔진(390)은 RPP(380)가 일정한 수신큐(360-366)와 함께 사용되도록 선택할 수 있고, 스케줄러 엔진(390)은 이어서 동일한 시간에 동일한 수신큐(360-366) 상에서 동작하는 두 RPP(380)가 존재하지 않도록 확실히 할 것이다. 데이터 패킷들은 선택된 수신큐(360-366)를 위해 패킷들을 처리할 선택된 RPP(380)로 제공된다. 수신큐(360-366)와 관련된 프로세싱 코어(340-344)에 새로운 데이터 패킷이 처리를 위해 도착하였다는 것을 알리기 위해 인터럽트 또는 폴링 기술이 사용될 수 있다.

선택적으로, 스케줄러 엔진(390)은 어떤 RPP(380)가 수신된 데이터 패킷을 처리할지 선택하기 위해 제공될 수 있다. 그러한 구현에서, 흐름 분류기 엔진(392)이 어떤 수신큐(360-366)가 그 데이터 패킷을 수신할지 결정할 수 있다. 이 수신큐(360-366)의 선택은 스케줄러 엔진(390)으로 제공될 수 있고, 스케줄러 엔진(390)은 이어서 RPP(380)의 이용가능성에 기초하여(즉, 현재 RPP(380)의 작업 부하) 수신된 데이터 패킷을 처리하기 위한 RPP(380)를 선택할 수 있다. 따라서, 다수의 RPP(380)가 동일한 수신큐(360-366)로 향하는 데이터 패킷들을 처리할 수 있지만, 같은 시간에는 그러하지 않다. 한 시점에 특정 수신큐(360-366)의 데이터 패킷들을 단 하나의 RPP(380)만이 처리하도록 보장하는 것이 스케줄러 엔진(390)의 역할이다.

QP 콘텍스트 저장소(376)는 데이터 패킷들의 송신큐(330-336)로부터의 라우팅 및 수신큐(360-366)로의 라우팅을 결정하기 위해 SQM(372), 디스패처 엔진(378), 흐름 분류기 엔진(392), 스케줄러 엔진(390) 및 RPP(380)에 의해 이용될 수 있는 큐쌍 콘텍스트 정보를 저장한다. QP 콘텍스트 정보는, 예를 들어 QP 자신들에 관한 구조적 정보(예를 들어, 포인터, 링크, 구성 파라미터 등), 수신된 데이터 패킷들이 위치될 수신 메모리를 관리하는데 사용되는 정보, 에러 감지 레지스터 정보 및 소프트웨어 인터페이스 레지스터 정보(예를 들어, 도어벨 레지스터 등)를 포함할 수 있다. InfiniBand 상세사항에서, QP 콘텍스트는 약 40개 영역의 정보를 포함하는데, 이는 여기에서 상세히 설명되지 않을 것이다.

도 3은 데이터 패킷이 송/수신될 수 있는 단일 포트(399)를 도시하지만, 예시적인 실시예는 그에 한정되지 않는다. 오히려, SQM(372), 디스패처 엔진(378), 흐름 분류기 엔진(392), 스케줄러 엔진(390) 및 RPP(380)는 본 발명의 사상과 범위를 벗어나지 않고 다수의 포트를 통하여 송/수신되는 데이터 패킷들에 동작할 수 있다. 게다가, 위에 언급된 바와 같이, 이 포트들(399)은 물리적 및/또는 가상적 포트로 구현될 수 있다.

도 3은 데이터 패킷들의 전송 또는 송신측 처리를 핸들링하기 위한 분리된 프로세싱 코어들(310-314) 및 데이터 패킷들의 수신측 처리를 핸들링하기 위한 분리된 프로세싱 코어들(340-344)을 도시하지만, 예시적인 실시예는 그에 한정되지 않는다. 오히려, 동일한 프로세싱 코어들이 본 발명의 사상 및 범위를 벗어나지 않고 데이터 패킷들의 전송 또는 송신측 처리와 수신측 처리를 모두 수행할 수 있다. 분리된 프로세싱 코어들(310-314 및 340-344)은 예시적인 실시예에 따른 전송 또는 송신측 처리와 수신측 처리를 위한 데이터의 흐름의 도시를 용이하게 하기 위한 목적으로만 도 3에 제공되었다.

예시적인 일실시예에서, NIC 장치 드라이버(325) 및 TCP/IP 스택(320)은 프로세싱 코어들(310-314 및 340-344) 상에서 실행되는 소프트웨어 프로세스들인데, 이들의 목적은 데이터 패킷들을 전송 및 수신하기 위한 송신큐(330-336) 및 수신큐(360-366)의 이용을 핸들링하는 것이다. 이 소프트웨어는 통신 프로토콜 스택 레벨(즉, TCP/IP 스택(320) 레벨)에서 동작하고, 통신 프로토콜 스택의 일부로 또는 도시된 것처럼 분리된 장치 드라이버로 구현될 수 있다. 이러한 프로세스들을 소프트웨어에 구현하기보다, 이 소프트웨어 프로세스들(320 및 325)에 기인하는 것으로 이하에서 설명되는 동작과 동일한 동작을 수행하기 위한 전용 하드웨어 장치들이 각각의 프로세싱 코어(310-314 및 340-344)와 관련되어 제공될 수 있다. 게다가, 하드웨어와 소프트웨어 요소들의 조합이 소프트웨어 프로세스들(320 및 325)의 이러한 동작들을 수행하는데 이용될 수 있다.

예시적인 일실시예에 따라, 전송 또는 송신측 처리에서, TCP/IP 스택(320)은 당업계에 일반적으로 알려진 방법과 거의 변경 없는 방법으로 동작한다. 그러나, NIC 장치 드라이버(325)는 데이터 패킷들이 송신될 송신큐(330-336)를 선택하고 선택된 송신큐(330-336)에 데이터 패킷들을 큐잉하도록 동작한다. NIC 장치 드라이버(325)는 이어서 QP 콘텍스트 저장소(376)에서와 같이 송신큐에 관련된 도어벨을 설정하여, 데이터 패킷이 선택된 송신큐(330-336)로부터 송신될 준비가 되었다는 것을 NIC(370)에게 알릴 수 있다. SQM(372)는 두 SQM들(372)이 일정한 시점에 동일한 송신큐에서 동작하지 않도록 보장하는 디스패처 엔진(378)에 의해 선택될 수 있다. 선택된 SQM(372)은 이어서 DMA 동작을 사용하여 선택된 송신큐(330-336) 내의 데이터 패킷을 처리하고, 데이터 패킷을 포트(399)를 통하여 전송한다.

수신측 처리에서, NIC 장치 드라이버(355)는 수신큐(360-366)에서 데이터 패킷이 수신된 것을 나타내는, 예를 들어 RPP(380)에 의한 인터럽트의 생성에 대한 응답으로 동작할 수 있고, 수신된 데이터 패킷을 처리를 위해 통신 프로토콜 스택(예를 들어, TCP/IP 스택(350))으로 전달하는 역할을 할 수 있다. NIC 장치 드라이버(355)는 수신측 처리 과정에서 바람직한 특정 구현에 따라 인터럽트 또는 폴링 기술에 기초하여 동작할 수 있다.

소프트웨어 메커니즘에 의해 수행되는 송신 및 수신측 처리 양측은, 다른 프로세싱 코어들(310-314 및 340-344) 상에서 실행되는 소프트웨어의 다른 인스턴스들에 의해 수행되는 다른 송신 및 수신측 처리와 병렬적으로 수행될 수 있다. 즉, 프로세싱 코어(310) 내의 NIC 장치 드라이버(325) 및 TCP/IP 스택(320)은 데이터 패킷들을 거의 동시에 송신 및 수신하도록 동작하여, 데이터 통신에 관한 프로세싱 코어(310)의 처리량 및 처리 능력을 증가시킬 수 있다. 게다가, 프로세싱 코어(310)의 NIC 장치 드라이버(325) 및 TCP/IP 스택(320)은 데이터 패킷들을 프로세싱 코어(340)의 TCP/IP 스택 및 NIC 장치 드라이버 인스턴스들(350 및 355)과 거의 동시에 송신 및 수신할 수 있다.

다수의 TCP/IP 인스턴스들(320, 350)이 동일한 데이터 흐름의 부분인 연결들 상에서 동작할 수 있기 때문에 TCP/IP 스택이 송신큐(330-336)에 액세스할 필요가 있는 경우를 제외하고는 그러한 처리에 잠금(lock)이 요구되지 않는다. 즉, 잠금은 두 TCP/IP 스택들이 동일한 SQ(330-336)에 대한 액세스를 갖는 경우에만 필요하다.

예시적인 실시예에 따른 데이터 패킷들의 전송 또는 송신측 처리 및 데이터 패킷들의 수신측 처리가 도 4-7을 참고하여 더 상세히 설명될 것이다. 데이터 패킷들의 전송 또는 송신측 처리 및 수신측 처리에 대한 설명은 TCP/IP 스택 처리에 대하여 설명될 것이지만, 그에 한정되지 않는다. 오히려, 예시적인 실시예의 메커니즘은 본 발명의 사상 및 범위를 벗어나지 않는 임의의 데이터 통신 프로토콜에 이용될 수 있다.

도 4는 예시적인 일실시예에 따른 데이터 패킷들의 수신측 처리를 도시하는 예시적인 블록도이다. 도 4에 도시된 바와 같이, 데이터 패킷이 포트(399)를 통해 도착할 때, 데이터 패킷은 하드웨어 구현 흐름 분류기 엔진(392)으로 제공된다. 흐름 분류기 엔진(392)은 수신된 데이터 패킷 내의 헤더 정보를 파싱하고(parse), 데이터 패킷에 의해 사용될 통신 프로토콜(예를 들어, TCP, UDP, IPv4, IPv6 등)을 결정하기 위해 확인한다. 이 정보는 헤더 정보의 포맷을 흐름 분류기 엔진(392)에 알려서, 데이터 패킷의 적절한 수신큐(360-366)로의 라우팅을 결정하기 위해 필요한 정보가 추출될 수 있도록 한다. 통신 프로토콜의 결정은, 데이터 패킷과 관련된 통신 프로토콜을 식별하는 데이터 패킷의 헤더 정보의 미리 정의된 영역에 기초하여 이루어질 수 있다.

사용되는 통신 프로토콜을 결정한 후, 흐름 분류기 엔진(392)은 데이터 패킷으로부터, 예를 들어 IP 목적지 주소, IP 소스 주소, 목적 포트, 소스 포트, 프로토콜 포트, 가상 포트 등을 포함하는 헤더 정보(예를 들어, 6 튜플(tuples))를 추출한다. 이 정보에 기초하여, 흐름 분류기 엔진(392)이 QP 콘텍스트 저장소(376)에 액세스하거나, 또는 선택적으로, 시스템 메모리(440) 내의 연결 정보 데이터 구조(460)를 액세스하는 것을 요구할 수 있는 연결 룩업(lookup) 동작이 수행되고, 수신큐(360-366)가 연결 설정 시간에 이 데이터 흐름과 특히 관련되었는지를 결정한다. 연결 정보 데이터 구조(460)는, 예를 들어 나무 구조와 같은 구조로 할당된 모든 연결들을 설명하는 엔트리들을 포함하는데, 이는 (만약 존재한다면) 어떤 연결 검색 데이터에 대한 QP 식별자를 룩업하는데 사용될 수 있다. 선택적으로, 정보는 어떤 수신큐(360-366)가 특정 연결에 관련되는지 식별하는 QP 콘텍스트 저장소(376)에 저장될 수 있다.

본질적으로, QP 콘텍스트 또는 연결 룩업 동작은 데이터 패킷 헤더로부터 추출된 특정 연결 정보의 해쉬 상에 수행되고, 그 해시 값에 대응되는 연결에 대해 존재한다면 QP 식별자를 반환하여, 연결을 위한 수신큐(360-366)를 식별한다. 특정 수신큐(360-366)가 연결 설정 시간에 이 데이터 흐름과 특히 관련되었다면, 이 수신큐(예를 들어, RQ(362))는 데이터 패킷이 라우팅될 흐름 분류기 엔진(392)에 의해 선택된다.

수신큐(360-366)가 이 데이터 흐름에 특히 관련되지 않았다면, 흐름 분류기 엔진(392)은 추출된 헤더 정보(예를 들어, 6 튜플)에 해시 동작을 수행하고, 결과 해시 값은 데이터 패킷을 라우팅하기 위하여 수신큐(360-366)를 선택하는데 사용된다. 예를 들어, 해시 값은 데이터 패킷이 라우팅될 수신큐(360-366)에 대응되는 저장 위치의 주소를 식별하는 라우팅 테이블 데이터 구조(410)로의 인덱스로 사용될 수 있다.

흐름 분류기 엔진(392)에 의한 수신큐(360-366)의 식별은 선택적인 스케줄러 엔진(390)으로 제공되는 수신큐 식별자를 가져온다. 만약 선택적인 스케줄러 엔진(390)이 이용되지 않는다면, 흐름 분류기 엔진(392)은 데이터 패킷을 특정 수신 패킷 프로세서(RPP)(380)로 제공할 수 있다. 선택적인 스케줄러 엔진(390)은, 예를 들어 일정 시점에 특정 수신큐에 대해 하나의 RPP만이 동작하도록 보장하기 위해, 다수의 RPP(380)가 동일한 수신큐에 대한 서비스를 제공할 수 있는 구현에 이용될 수 있다. 선택적인 스케줄러 엔진(390)은 RPP(380)의 현재의 로딩에 기초하여 식별된 수신큐(360-366)에 서비스를 제공할 수 있는 다수의 RPP들(380) 사이에서 선택할 수 있고, 이어서 선택된 RPP(380)를 선택된 수신큐로의 데이터 흐름들에 관련시킬 수 있다. 선택적인 스케줄러 엔진(390)은 데이터 패킷들의 처리 속도를 더 증가시키기 위해서만 제공되고, 예시적인 실시예의 동작에 필수적인 것은 아니다.

데이터 패킷은, 특정 수신큐(360-366)를 선택하기 위하여 흐름 분류기 엔진(392)에 의해 수행되는 흐름 분류 및 구현에 따라 선택적인 스케줄러 엔진(390)이나 흐름 분류기 엔진(392) 중 어느 하나에 의한 RPP(380)의 선택을 통하여, 선택된 RPP(380)에 의해 선택되는 수신큐(360-366)로 포스팅된다. 데이터 패킷의 포스팅은 선택된 수신큐(360-366)에서 발견되는 수신 버퍼 기술자 내에 존재하는 정보를 사용하여 수행될 수 있다. 예를 들어, 이 수신 버퍼 기술자는 시스템 메모리(440)에서 데이터 패킷을 직접 메모리 액세스할 주소를 포함할 수 있다. 선택된 RPP(380)는 이어서 선택된 수신큐(360-366)와 관련된 수신 완료 큐(RCQ)(420-426)에 완료 이벤트 엔트리를 포스팅할 수 있다. 예를 들어, 이 완료 이벤트 엔트리는 수신된 데이터 패킷의 길이를 포함할 수 있다.

예시적인 일실시예에서, 각각의 수신큐(360-366)는 일대일 기반으로 수신 완료 큐(420-426)에 관련된다. 완료 이벤트 엔트리는 새로운 데이터 패킷이 처리를 위해 이용가능한 선택된 수신큐(360-366)뿐 아니라 선택된 수신큐(360-366)의 처리될 데이터 패킷들의 수를 식별한다. 인터럽트는 하나 이상의 수신 완료 큐(420-426)에 관련된다. 하나의 인터럽트는 유일한 프로세싱 코어(340-344) 또는 프로세싱 코어들(340-344)의 한 세트와 관련된다. 동일한 인터럽트에 관련된 모든 수신 완료 큐(420-426)는 동일한 프로세싱 코어(340-344) 또는 프로세싱 코어들(340-344)의 동일한 세트에 의해 처리된다. 캐시 친화성을 최대화하기 위해, 동일한 데이터 흐름은 항상 동일한 프로세서 코어(340-344) 또는 프로세싱 코어들(340-344)의 세트에 의해 처리될 수 있다.

완료 이벤트 엔트리를 수신 완료 큐(420-426)에 포스팅하는 것에 더해, RPP(380)는 수신 완료 큐(420-426)에 관련된 프로세싱 코어(340-344)로 인터럽트를 트리거할 수 있다. 인터럽트는 새로운 수신 완료 큐 완료 이벤트 엔트리가 처리를 위해 이용가능하다는 것을 프로세싱 코어(340-344)에 알린다. 인터럽트는 수신된 데이터 패킷의 데이터 패킷 정보(예를 들어, 메모리의 주소, 길이 등)를 관련된 TCP/IP 스택(350)으로 전달하는 NIC 장치 드라이버(355)를 트리거한다. 서로 다른 프로세싱 코어들(340-344)을 타겟으로 하는 다수의 인터럽트가 RPP(380)에 의해 동시에 일어날 수 있다. 따라서, 이러한 인터럽트들은 각각의 프로세싱 코어(340-344)의 NIC 장치 드라이버(355)의 동시적인 실행을 트리거한다. NIC 장치 드라이버(355)의 각각의 인스턴스는 서로 다른 수신 완료 큐들(420-426)의 완료 이벤트 엔트리를 처리할 수 있다. 각각의 NIC 장치 드라이버 인스턴스(355)는 이어서 서로 다른 TCP/IP 스택 인스턴스(350)들을 디스패치할 수 있다. 따라서, 각각의 TCP/IP 스택 인스턴스는 흐름 분류기 엔진(392)에 의해 식별되는 서로 다른 TCP 연결들의 세트 상에서 동작할 수 있다.

선택적으로, 폴링 동작이 인터럽트 동작 대신에 이용될 수 있다. 그와 같은 예시적인 실시예에서, 다수의 TCP/IP 사용자 공간 스레드가 서로 다른 프로세싱 코어들(340-344) 상에 동시에 실행될 수 있다. 각각의 스레드는 스레드가 실행되는 특정 프로세싱 코어(340-344)와 관련된 수신 완료 큐(420-426)의 세트를 폴링할 수 있다. 만약 스레드가 처리를 위한 새로운 완료 이벤트 엔트리를 식별한다면, 그 프로세싱 코어(340-344)와 관련된 NIC 장치 드라이버 인스턴스(355)로 새로운 완료 이벤트 엔트리가 알려지고, 이어서 적절히 처리된다.

NIC 장치 드라이버(355)는 TCP/IP 스택(350)의 매체 액세스 제어(MAC) 계층 바로 위(즉, TCP/IP 스택(350)의 데이터 링크 계층과 네트워크 계층 사이)에서 동작할 수 있고, 따라서 검색된 수신 완료 큐 완료 이벤트 엔트리를 처리를 위해 TCP/IP 스택(350)의 네트워크 계층으로 제공할 수 있다. 완료 이벤트 엔트리에 기초하여, TCP/IP 스택(350)은 관련된 수신큐(360-366)로부터의 관련된 데이터 패킷을 검색하고 처리할 수 있다.

위에서, 선택된 구현방법과 무관하게(즉, 인터럽트 구현 또는 폴링 구현) NIC 장치 드라이버(355) 또는 TCP/IP 스택(350) 내의 수신큐, 수신 완료 큐, 또는 기타 수신측 처리 과정에서 이용되는 자원들을 잠그기 위한 잠금 요구사항이 없다는 것을 이해해야 한다. 잠금 요구사항이 없기 때문에, 자원들은 데이터 패킷의 처리가 완료될 때까지 잠겨지지 않고, 따라서 TCP/IP 스택(350) 인스턴스들 및 NIC 장치 드라이버(355)의 다수의 인스턴스에 의한 데이터 패킷들의 동시적인 처리가 가능해진다.

도 5는 예시적인 일실시예에 따른 데이터 패킷들의 전송 또는 송신측 처리를 도시하는 예시적인 블록도이다. 도 5에 도시된 바와 같이, 데이터 패킷이 프로세싱 코어(310-314)로부터 하나 이상의 데이터 네트워크 상으로 NIC(370)을 통하여 송신되어야할 경우에, TCP/IP 스택(320), 또는 NIC 장치 드라이버(325)의 동작이 TCP/IP 스택(320)으로 통합되는지 여부에 따라 NIC 장치 드라이버(325)는 전송을 위하여 데이터 패킷을 포스팅하기 위한 송신큐(330-336)를 선택한다. 예시적인 실시예의 목적으로, NIC 장치 드라이버(325)의 동작은 TCP/IP 스택(320)으로 통합되지 않았고, 따라서 TCP/IP 스택(320)은 본질적으로 종래의 시스템의 것과 동일하다고 가정될 것이다.

송신큐(330-336)의 선택은, 데이터 패킷이 일부분을 이루는 데이터 흐름을 위해 미리 할당된 송신큐(330-336)에 기초하여 또는 데이터 패킷의 헤더에 제공되는 연결 정보의 해시에 기초하여 수행될 수 있다. 예를 들어, NIC 장치 드라이버(325)는 통신 스택으로부터 이 데이터 흐름은 (예를 들어, 송신큐 인덱스의 형태로) 이미 할당된 송신큐를 가지고 있다는 정보를 수신했을 수 있다. 송신큐가 데이터 흐름을 위해 할당되어 있다면, NIC 장치 드라이버(325)는 그 송신큐를 데이터 패킷이 라우팅될 큐로 선택한다.

만약 송신큐가 데이터 흐름을 위해 할당되어 있지 않다면, NIC 장치 드라이버(325)는 데이터 패킷 헤더의 연결 정보(예를 들어, IP 목적지 주소, IP 소스 주소, 목적 포트, 소스 포트 및 프로토콜 포트)에 해시 동작을 수행한다. 이 해시 동작은 이전에 설명된 수신측 처리에서 수행되는 해시 동작과 동일할 필요는 없다. 즉, 전송 또는 송신측 처리와 수신측 처리를 위해 두 개의 서로 다른 해시 함수가 이용되고 두 개의 서로 다른 해시 동작이 수행될 수 있다. 전송 또는 송신측 처리 및 수신측 처리 양측에서 사용되는 특정 해시 함수뿐 아니라 해시 동작이 수행되는 연결 정보는, 필요하다고 생각될 때 변경 또는 변형될 수 있도록 흐름 분류기 엔진(392) 및 NIC 장치 드라이버(325)로 프로그래밍 될 수 있다.

일단 송신큐 선택이 NIC 장치 드라이버(325)에 의해 수행되면, NIC 장치 드라이버(325)는 선택된 송신큐(330-336)에 데이터 패킷을 큐잉한다. 이는 송신 버퍼 기술자를 선택된 송신큐(예를 들어, 송신큐(332))에 기록해 넣음으로써 선택된 송신큐(330-336)에 데이터 패킷을 큐잉한다. 송신 버퍼 기술자는 시스템 메모리(510)의 데이터 패킷의 주소 및 길이를 포함한다. 송신 버퍼 기술자 내의 정보는 데이터 패킷 헤더 및 페이로드(payload)의 DMA 판독 동작을 수행하기 위해 NIC(370)에 의해 사용된다.

NIC 장치 드라이버(325)는 이어서 데이터 패킷이 송신되기 위해 판독되었다는 것을 NIC에 알리기 위해 선택된 송신큐와 관련된 "도어벨을 울린다". 본질적으로, 선택된 송신큐(332)와 관련된 NIC(370) 내의 도어벨 레지스터(560)에 값이 기록된다. 이 값은 도어벨 레지스터(560)와 관련된 송신큐 내에 처리를 위해 이용가능한 데이터 패킷에 대한 송신 버퍼 기술자가 존재한다는 것을 NIC에 알린다.

이 도어벨 레지스터(560)에 값을 기록하는 것에 대응하여, 디스패처 엔진(378)은 선택된 송신큐(332)를 위해 데이터 패킷을 처리하도록 선택된 송신큐 관리자 엔진(SQM)(372)을 깨운다. SQM(372)는 DMA 동작을 수행하여 도어벨 레지스터(560)와 관련된 선택된 송신큐(332)의 헤드에서 송신 버퍼 기술자를 직접 메모리 액세스한다. SQM(372)는 이어서 송신 버퍼 기술자에서 발견되는 주소 및 길이 파라미터를 사용하여 시스템 메모리(510)로부터 데이터 패킷을 직접 메모리 액세스한다.

송신측 처리가 서로 다른 송신큐들(330-336)에서 동시에 수행될 수 있다는 것을 알아야 한다. 게다가, 송신측 처리는 서로 다른 프로세싱 코어들(310-314)에서 동시에 수행될 수 있다. 추가로, SQM들(372)은 서로 다른 송신큐들(330-336)에 동시에 동작할 수 있다. 병렬적으로 동작하는 다수의 SQM(372)는 NIC(370)가 시스템 메모리(510)로의 DMA 동작들과 관련된 지연을 숨길 수 있도록 한다. 이러한 방법으로, 연속적인 데이터 패킷의 전송이 데이터 네트워크 매체 상에서 패킷간 간격이 없이 가능해질 수 있다.

도 6A, 6B 및 7은 예시적인 일실시예에 따른 전송 및 수신 동작을 도시하는 순서도이다. 순서도의 각각의 블록 및 블록들의 조합은 하드웨어로 또는 컴퓨터 프로그램 명령어들에 의해 구현될 수 있다. 이러한 컴퓨터 프로그램 명령어들은, 프로세서 또는 기타 프로그램 가능 데이터 처리 장치 상에서 수행되는 명령어들이 순서도 블록 또는 블록들에 특정된 기능을 구현하기 위한 수단을 만들어 내도록, 프로세서 또는 기타 머신을 생산하기 위한 프로그램 가능 데이터 처리 장치로 제공될 수 있다. 이러한 컴퓨터 프로그램 명령어들은 또한, 컴퓨터 판독가능 메모리 또는 저장 매체에 저장된 명령어들이 순서도 블록 또는 블록들에 특정된 기능을 구현하는 명령어 수단을 포함하는 제조물품을 생산하도록, 프로세서 또는 기타 프로그램 가능 데이터 처리 장치가 특정 방식으로 기능하도록 할 수 있는 컴퓨터 판독가능 메모리 또는 저장 매체에 저장될 수 있다.

그에 따라, 순서도의 블록들은 특정 기능들을 수행하기 위한 수단들의 조합, 특정 기능들을 수행하기 위한 단계들의 조합 및 특정 기능들을 수행하기 위한 프로그램 명령어 수단들을 지원한다. 순서도의 각각의 블록 및 순서도의 블록들의 조합은 특정 기능들 또는 단계들을 수행하는 특수 목적 하드웨어 기반 컴퓨터 시스템에 의해 또는 특수 목적 하드웨어 및 컴퓨터 명령어들의 조합에 의해 구현될 수 있다.

더 나아가, 순서도는 예시적인 실시예 내에서 수행되는 동작들을 보여주기 위해 제공된다. 순서도는 특정 동작들, 보다 구체적으로는 동작들의 순서에 관하여 제한을 제시하거나 암시하도록 의도되지 않았다. 순서도의 동작들은 본 발명의 사상 및 범위를 벗어나지 않고 구체적인 구현에 적합하도록 변경될 수 있다.

도 6A 및 6B는 예시적인 일실시예에 따라 데이터 패킷들을 수신하기 위한 예시적인 동작의 개요를 나타내는 순서도이다. 도 6A 및 6B에 도시된 바와 같이, 동작은 NIC 또는 기타 데이터 네트워크 어댑터의 물리적 및/또는 가상적 포트를 통하여 데이터 패킷을 수신하면서 시작한다(단계(610)). NIC 또는 어댑터의 흐름 분류기 엔진은 데이터 패킷과 관련된 통신 프로토콜을 결정한다(단계(615)). 결정된 통신 프로토콜에 기초하여, 흐름 분류기 엔진은 데이터 패킷의 헤더로부터 연결 정보를 추출한다(단계(620)). 흐름 분류기 엔진은 이어서 데이터 패킷에 대응되는 연결을 위한 QP를 식별하기 위한 연결 룩업 동작을 수행하고(단계(625)), 추출된 연결 정보 및 수행된 연결 룩업 동작에 기초하여 데이터 패킷이 일부를 이루는 데이터 흐름에 수신큐가 할당되었는지 결정한다(단계(630)). 만약 그렇다면, 흐름 분류기 엔진은 데이터 흐름에 할당된 수신큐를 데이터 패킷이 라우팅될 수신큐로 선택하고(단계(635)), 스케줄러 엔진은 선택된 수신큐에 기초하여 RPP를 선택한다(단계(650)).

만약 데이터 흐름에 수신큐가 할당되지 않았다면, 흐름 분류기 엔진은 데이터 패킷의 헤더로부터 추출된 연결 정보에 해시 동작을 수행한다(단계(640)). 결과 해시 값은 이어서 데이터 패킷이 라우팅될 수신큐를 식별하는 라우팅 테이블 데이터 구조로 인덱싱하기 위해 흐름 분류기 엔진에 의해 사용된다(단계(645)).

흐름 분류기 엔진, 또는 만약 포함된다면 선택적인 스케줄러 엔진은 선택된 수신큐를 위한 데이터 패킷의 처리를 위한 수신 패킷 프로세서(RPP)를 선택한다(단계(650)). 만약 스케줄러 엔진이 사용된다면, 동일한 수신큐가 동시에 두 개의 서로 다른 RPP로 디스패치되지 않도록 보장할 것이다. 흐름 분류기 엔진 또는 스케줄러 엔진은 이어서 데이터 패킷을 처리를 위해 선택된 RPP로 제공한다(단계(655)).

선택된 RPP는 시스템 메모리로부터 수신큐 콘텍스트를 판독한다(단계(660)). 만약 수신큐가 만들어지지 않았거나 데이터 패킷의 수신을 허용하지 않는 상태에 있다면(단계(665)), 데이터 패킷은 무시되고(단계(680)) 동작은 끝난다. 그렇지 않다면, RPP는 시스템 메모리로부터 수신큐의 다음 수신 버퍼 기술자를 검색한다(단계(670)). 만약 그러한 수신 버퍼 기술자가 없다면(단계(675)), 데이터 패킷은 무시되고(단계(680)) 프로세스는 끝난다. 그렇지 않다면, RPP는 수신 버퍼 기술자에 존재하는 정보(DMA를 수행할 시스템 메모리 주소를 포함함)를 사용하여 선택된 수신큐 내에 데이터 패킷을 위치시키고, 선택된 수신큐와 관련된 수신 완료 큐로 완료 이벤트 엔트리를 포스팅한다(예를 들어, 데이터 패킷 길이를 기록함)(단계(685)).

그 후에, 인터럽트 기반 구현이 이용된다고 가정할 때, RPP는 완료 이벤트 엔트리가 포스팅된 수신 완료 큐와 관련된 프로세싱 코어로 인터럽트를 송신할 수 있다(단계(690)). 프로세싱 코어의 NIC 장치 드라이버는 인터럽트를 수신한 것에 대응하여 수신 완료 큐로부터 완료 이벤트 엔트리를 검색하고(단계(695)), 완료 이벤트 엔트리 정보 및 데이터 패킷을 NIC 장치 드라이버와 관련된 통신 프로토콜 스택 인스턴스로 제공한다(단계(697)). 통신 프로토콜 스택 인스턴스는 이어서 완료 이벤트 엔트리(예를 들어, 데이터 패킷 길이) 및 수신큐의 수신 버퍼 기술자로부터 검색된 일부 정보(예를 들어, 메모리의 주소, 하드웨어에서 오류가 감지됨 등)에 기초하여 데이터 패킷을 처리한다(단계(699)). 동작은 이어서 종료된다.

도 6A 및 6B에 개요가 나타난 동작은 하나의 데이터 패킷에 대한 것이라고 이해해야 한다. 이 동작은 동일 또는 상이한 데이터 흐름들의 복수의 서로 다른 데이터 패킷에 동시에 여러 번 수행될 수 있다. 따라서, 개요가 나타난 동작은 동일 또는 상이한 NIC, 네트워크 어댑터 및 프로세싱 코어 상에서 다른 유사한 동작들과 병렬로 수행될 수 있다.

도 7은 예시적인 일실시예에 따라 데이터 패킷들을 전송 또는 송신하기 위한 예시적인 동작의 개요를 나타내는 순서도이다. 도 7에 도시된 바와 같이, 전송 또는 송신 동작은 프로세싱 코어가 전송을 위한 데이터 패킷을 생성하면서 시작된다(단계(710)). 통신 프로토콜 스택이 데이터 패킷을 장치 드라이버로 넘겨줄 때, 특정 송신큐를 사용하고자 한다는 표시를 (예를 들어, 송신큐 인덱스를 제공함에 의해) 줄 수 있다. 만약 그러한 경우라면(단계(715)), 특정된 송신큐는 데이터 패킷의 전송에 사용하기 위해 선택되고 장치 드라이버 프로세스는 단계(735)로 이어진다. 그렇지 않다면, 장치 드라이버는 데이터 패킷의 헤더로부터 연결 정보를 추출한다(단계(720)). 장치 드라이버는 추출된 연결 정보에 해시 동작을 수행하고(단계(725)), 데이터 패킷을 전송하는데 사용될 송신큐를 식별하기 위한 라우팅 테이블 데이터 구조로 인덱싱하기 위해 결과 해시 값을 사용한다(단계(730)).

일단 송신큐가 (통신 프로토콜 스택에 의해 명시적으로 또는 위에 설명된 해시 메커니즘을 통하여) 식별되고 나면, 장치 드라이버는 다음으로 송신큐가 만들어졌는지 검증한다(단계(735)). 송신큐가 만들어지지 않았다면, 데이터 패킷은 무시되고(단계(740)), 동작은 끝난다. 송신큐가 만들어졌다면, 장치 드라이버는 데이터 패킷과 관련된 송신 버퍼 기술자를 만든다(단계(745)). 그 후에, 장치 드라이버는 송신 버퍼 기술자를 송신큐에 기록하고, 이어서 선택된 송신큐에 대응하는 네트워크 어댑터의 도어벨 레지스터에 값을 기록함으로써 데이터 패킷을 선택된 송신큐에 큐잉한다(단계(750)). 도어벨 레지스터의 값을 감지한 것에 대응하여, 네트워크 어댑터는, 동시에 동일한 송신큐를 처리하는 두 SQM이 없도록 하며, 선택된 송신큐를 위하여 데이터 패킷을 처리하기 위해 송신큐 관리자를 디스패치한다(단계(755)). 송신큐 관리자는 송신큐의 제일 앞에 있는 송신 버퍼 기술자를 직접 메모리 액세스하고(단계(760)), 송신 버퍼 기술자에 저장된 주소 및 길이 정보에 기초하여, 시스템 메모리부터 데이터 패킷을 직접 메모리 액세스한다(단계(765)). 동작은 이어서 데이터 패킷이 통신선 상으로 전송되고 나서 종료된다(단계(770)).

도 7에 개요가 나타난 동작은 하나의 데이터 패킷에 대한 것이라고 이해해야 한다. 이 동작은 동일 또는 상이한 데이터 흐름들의 복수의 서로 다른 데이터 패킷에 동시에 여러 번 수행될 수 있다. 따라서, 개요가 나타난 동작은 동일 또는 상이한 프로세싱 코어, NIC 및 네트워크 어댑터 상에서 다른 유사한 동작들과 병렬로 수행될 수 있다.

따라서, 예시적인 실시예의 MCS 메커니즘은 통신 흐름의 전송 및 수신 양측을 동시에 처리할 수 있게 함으로써 고성능을 제공한다. 게다가, MCS 메커니즘은 NIC와 프로세싱 코어들상에서의 동시적인 처리를 가능하게 함으로써 고성능을 제공한다. 더 나아가, MCS 메커니즘은 흐름들과 프로세서 캐시들간에 친화성을 만듦으로써 고성능을 가능하게 한다. 이러한 이점들 모두는 통신 링크 용량의 전부가 이용될 수 있도록 하여 예시적인 실시예의 MCS 메커니즘이 10 Gbps 이상의 고속 매체 대역폭을 포함하는 고속 매체 응용에 적합하도록 만든다.

예시적인 실시예는 전적으로 하드웨어인 실시예(NIC 및 프로세싱 코어 모두에) 또는 (NIC 내의) 하드웨어 및 (프로세싱 코어에서 실행되는) 소프트웨어 요소를 모두 포함하는 실시예의 형태를 가질 수 있다. 예시적인 일실시예에서, 예시적인 실시예의 메커니즘은 NIC에 제공되는 하드웨어 엔진 및 프로세싱 코어의 소프트웨어로 구현되는데, 소프트웨어는 펌웨어, 상주 소프트웨어, 마이크로코드 등을 포함하지만 이에 한정되지는 않는다.

더 나아가, 예시적인 실시예의 태양은, 컴퓨터 또는 임의의 명령어 실행 시스템에 의해 또는 이들과 함께 사용되는 프로그램 코드를 제공하는 컴퓨터 사용가능 또는 컴퓨터 판독가능 매체로부터 액세스될 수 있는 컴퓨터 프로그램 제품의 형태를 가질 수 있다. 이 설명을 위한 목적으로, 컴퓨터 사용가능 또는 컴퓨터 판독가능 매체는 명령어 실행 시스템, 기구 또는 장치에 의해 또는 이들과 함께 사용되는 프로그램을 포함, 저장, 통신, 전파 또는 수송할 수 있는 임의의 기구일 수 있다.

매체는 전자, 자기, 광학, 전자기, 적외선 또는 반도체 시스템(또는 기구 또는 장치) 또는 전파 매체일 수 있다. 컴퓨터 판독가능 매체의 예는 반도체 또는 고체 상태 메모리, 자기 테이프, 이동식 컴퓨터 디스켓, 랜덤 액세스 메모리(RAM), 읽기 전용 메모리(ROM), 강성 자기 디스크(rigid magnetic disk) 및 광학 디스크를 포함한다. 광학 디스크의 현재의 예는 CD-ROM, CD-R/W 및 DVD를 포함한다.

프로그램 코드를 저장 및/또는 실행하기에 적합한 데이터 처리 시스템은 시스템 버스를 통하여 메모리 요소에 직접적 또는 간접적으로 결합되는 적어도 하나의 프로세서를 포함할 것이다. 메모리 요소는 프로그램의 실제 실행 과정에서 이용되는 로컬 메모리, 벌크 저장소, 및 실행 과정에서 코드가 벌크 저장소로부터 검색되어야 하는 횟수를 감소시키기 위해 적어도 일부 프로그램 코드의 일시적 저장을 제공하는 캐시 메모리를 포함할 수 있다.

입력/출력 또는 I/O 장치(키보드, 디스플레이, 포인팅 장치 등을 포함하지만 이에 한정되지는 않음)는 직접 또는 중간의 I/O 제어기를 통하여 시스템에 결합될 수 있다. 데이터 처리 시스템이 중간의 사설 또는 공중 네트워크를 통하여 다른 데이터 처리 시스템 또는 원거리 프린터 또는 저장 장치에 결합될 수 있도록 하기 위해 네트워크 어댑터가 또한 시스템에 결합될 수 있다. 모뎀, 케이블 모뎀 및 이더넷 카드는 현재 이용가능한 네트워크 어댑터의 종류들 중 일부이다.

본 발명의 설명은 예시와 설명의 목적으로 제시된 것이고, 개시된 형태로 발명이 완전하거나 이에 한정되도록 의도된 것은 아니다. 많은 변경 및 변화가 당업자에게 자명할 것이다. 실시예는 본 발명의 원리, 실질적인 응용을 가장 잘 설명하기 위해, 그리고 당업자가 구체적인 용도에 적합한 다양한 변경이 있는 다양한 실시예들에 대해 본 발명을 이해할 수 있도록 선택되고 설명되었다.

Claims (10)

1. 데이터 처리 시스템에서 데이터 패킷을 전송하기 위한 방법으로서,

   프로세싱 코어에서, 외부 장치로의 전송을 위한 데이터 패킷을 생성하는 단계;

   상기 데이터 패킷의 헤더로부터 추출된 연결 정보에 기초하여 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하는 단계;

   상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하는 단계; 및

   네트워크 어댑터의 관련 하드웨어 구현 송신큐 관리자에 의해 상기 선택된 송신큐의 엔트리를 처리하여, 상기 데이터 패킷을 외부 장치로 전송하는 단계

   를 포함하고,

   상기 관련 하드웨어 구현 송신큐 관리자는 상기 네트워크 어댑터에 제공되는 복수의 하드웨어 구현 송신큐 관리자 중의 하나이며, 상기 복수의 하드웨어 구현 송신큐 관리자의 각각의 하드웨어 구현 송신큐 관리자는 서로 다른 송신큐에 관련되는

   방법.
2. 제1항에 있어서,

   상기 프로세싱 코어는 복수의 프로세싱 코어 중의 하나이고, 상기 방법은 상기 복수의 프로세싱 코어 각각에 대해 실질적으로 병렬 방식(parallel manner)으로 구현되는, 방법.
3. 제1항 또는 제2항에 있어서,

   상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하는 단계는,

   시스템 메모리로부터 송신 버퍼 기술자 정보를 검색하는 단계;

   상기 연결 정보 및 상기 송신 버퍼 기술자 정보에 기초하여, 송신큐가 상기 데이터 패킷에 관련된 연결을 위해 이전에 할당되었는지를 결정하는 단계; 및

   송신큐가 상기 연결을 위해 이전에 할당되었다면, 상기 이전에 할당된 송신큐를 선택하는 단계

   를 포함하는, 방법.
4. 제3항 또는 제4항에 있어서,

   송신큐가 상기 연결을 위해 이전에 할당되지 않았다면, 상기 방법은,

   해시 값을 생성하기 위해 상기 연결 정보에 대해 해시 동작(hash operation)을 수행하는 단계;

   상기 생성된 해시 값에 기초하여 라우팅 테이블 데이터 구조로 인덱싱하는 단계; 및

   상기 해시 값과 관련된 상기 라우팅 테이블 데이터 구조에 저장된 엔트리의 값에 기초하여 송신큐를 선택하는 단계

   를 포함하는 방법.
5. 제1항에 있어서,

   상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하는 단계 및 상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하는 단계는, 상기 프로세싱 코어에서 실행되는 소프트웨어에 의해 수행되는, 방법.
6. 제1항 내지 제5항 중 어느 한 항에 있어서,

   상기 데이터 처리 시스템의 네트워크 인터페이스에서 인입 데이터 패킷을 수신하는 단계;

   상기 인입 데이터 패킷을 위치시킬 수신큐를 선택하기 위해 하드웨어 구현 데이터 흐름 분류기 엔진을 사용하여 상기 인입 데이터 패킷을 처리하는 단계; 및

   하드웨어 구현 수신 패킷 프로세서에 의해, 상기 데이터 흐름 분류기 엔진에 의해 수행된 상기 선택에 기초하여 상기 인입 데이터 패킷을 선택된 수신큐에 위치시키는 단계

   를 더 포함하는 방법.
7. 제6항에 있어서,

   상기 데이터 흐름 분류기 엔진은,

   상기 인입 데이터 패킷이 수신된 연결을 위한 수신큐가 이전에 할당되었는지 결정하고,

   수신큐가 상기 연결을 위해 이전에 할당되었다면, 상기 이전에 할당된 수신큐를 선택함으로써

   수신큐를 선택하는, 방법.
8. 제7항에 있어서,

   상기 연결을 위한 수신큐가 이전에 할당되지 않았다면, 상기 데이터 흐름 분류기 엔진은,

   상기 인입 데이터 패킷으로부터 연결 정보를 추출하고,

   해시 값을 생성하기 위해 상기 추출된 연결 정보에 대해 해시 동작을 수행하며,

   상기 생성된 해시 값에 기초하여 상기 인입 데이터 패킷이 라우팅될 수신큐를 선택하기 위해 라우팅 테이블로 인덱싱하는

   방법.
9. 제6항, 제7항, 또는 제8항 있어서,

   상기 선택된 수신큐와 관련된 프로세싱 코어로 인터럽트를 송신하는 단계;

   상기 선택된 수신큐와 관련된 수신 완료 큐에 완료 이벤트 엔트리를 포스팅하는 단계; 및

   통신 프로토콜 스택에 의해, 상기 선택된 수신큐에 위치된 상기 인입 데이터 패킷을 처리하는 단계

   를 더 포함하는 방법.
10. 컴퓨터 판독가능 프로그램이 저장된 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품으로서,

    상기 컴퓨터 판독가능 프로그램은 컴퓨팅 장치에서 실행되었을 때 상기 컴퓨팅 장치로 하여금,

    프로세싱 코어에서, 외부 장치로의 전송을 위한 데이터 패킷을 생성하고,

    상기 데이터 패킷의 헤더로부터 추출된 연결 정보에 기초하여 상기 데이터 패킷을 전송하기 위해 사용하는 송신큐를 선택하며,

    상기 데이터 패킷을 위한 상기 선택된 송신큐에 엔트리를 생성하고,

    네트워크 어댑터의 관련 하드웨어 구현 송신큐 관리자에 의해 상기 선택된 송신큐의 엔트리를 처리하여 상기 데이터 패킷을 외부 장치로 전송하도록 하고,

    상기 관련 하드웨어 구현 송신큐 관리자는 상기 네트워크 어댑터에 제공되는 복수의 하드웨어 구현 송신큐 관리자 중의 하나이며, 상기 복수의 하드웨어 구현 송신큐 관리자의 각각의 하드웨어 구현 송신큐 관리자는 서로 다른 송신큐에 관련되는,

    컴퓨터 프로그램 제품.