KR101502808B1

KR101502808B1 - 단일 모뎀 보드 상의 개선된 멀티-셀 지원을 위한 방법 및 시스템

Info

Publication number: KR101502808B1
Application number: KR1020137016740A
Authority: KR
Inventors: 모하마드 알. 카워; 무구르 아불리우스
Original assignee: 알까뗄 루슨트
Priority date: 2010-11-29
Filing date: 2011-10-27
Publication date: 2015-03-24
Also published as: US8861434B2; EP2814214B1; EP2814214A1; TWI479850B; CN103348641B; EP2647163B1; WO2012074632A1; US20120134320A1; JP2014506346A; KR20130099185A; CN103348641A; EP2647163A1; JP5726320B2; TW201238295A

Abstract

통신 네트워크의 단일 SMP 파티션에서 멀티-셀 지원을 제공하기 위한 시스템이 개시된다. 전형적으로 모뎀 보드 및 복수의 프로세서 코어들을 갖는 멀티-코어 프로세서를 포함하고, 상기 멀티-코어 프로세서는 복수의 데이터 플레인 코어들 상에 도착하는 비-필수 인터럽트들을 디스에이블하고 복수의 제어 플레인 코어들로 상기 비-필수 인터럽트들을 라우팅하도록 구성된다. 선택적으로, 상기 멀티-코어 프로세서는 모든 비-실시간 쓰레드들 및 프로세스들이 모든 제어 플레인 동작들에 전용된 프로세서 코어들에 결합되고 모든 데이터 플레인 동작들에 전용된 프로세서 코어들이 데이터 경로 구현 또는 계층2 프로세싱에 직접적으로 필요하지 않은 어떠한 쓰레드들도 호스팅하거나 실행하지 않도록 구성된다.

Description

단일 모뎀 보드 상의 개선된 멀티-셀 지원을 위한 방법 및 시스템{A METHOD AND SYSTEM FOR IMPROVED MULTI-CELL SUPPORT ON A SINGLE MODEM BOARD}

본 발명의 예시적인 실시예들은 일반적으로 무선 통신에 사용하기 위한 모뎀 보드들에 관한 것이다. 특히, 다양한 실시예들이 멀티-코어 프로세서를 사용하여 단일 모뎀 보드 상의 멀티-셀 지원을 위해 PREEMPT RT를 갖는 SMP 리눅스(Linux)와 같은 운영체제들의 실시간 성능을 향상시키기 위한 기술들로 지향되었다. 본 발명이 특히 무선 통신 분야로 지향되고, 따라서 그에 대한 특정한 참조로 설명되지만, 본 발명이 다른 분야들 및 애플리케이션들에서 유용성을 갖는다는 것이 이해될 것이다.

배경으로서, LTE(Long Term Evolution)는 미래 통신 네트워크 요구들에 대응하기 위해 UMTS(Universal Mobile Telecommunications System) 모바일 폰 표준을 개선하는 것을 목적으로 하는 빠르게 진화하는 3GPP 프로젝트이다. LTE는 무선 네트워크 효율성 및 대역폭을 개선하고, 비용을 감소시키고, 서비스 경험을 향상시킨다. 구체적으로, LTE는 새로운 스펙트럼 기회들을 사용하고 다른 공개 표준들과의 더 나은 통합을 제안한다. LTE는 일반적으로 EPS(Evolved Packet System, Evolved Packet Core라고도 함)와 함께 LTE RAN(Radio Access Network)(또한 E-UTRAN 으로 알려진)을 포함한다.

통신 시스템들은 일반적으로 2개의 주요 기능들: 데이터 플레인 기능들 및 제어 플레인 기능들로 분할된다. 이전의 LTE 제품들에서, 적어도 2개의 프로세서들이 상기 모뎀 보드 상에서 사용되었고: 하나는 상기 제어 플레인 기능들(비-실시간, 예를 들어, OA&M(Operations, Administration, and Management) 및 호출 프로세싱 관리-관련된 기능들)을 지원하기 위한 것이고 다른 하나는 데이터 플레인 기능들(실시간, 예를 들어, LTE 계층2 프로세싱)을 종료 및 지원하기 위한 것이다. 상기 제어 및 데이터 플레인들 모두는 제어 플레인에 대한 리눅스 및 데이터 플레인 코어에 대한 vXWorks(캘리포니아, 아라미다(Alameda)의 Wind River Systems에 의해 생산 및 판매됨)와 같은 실시간 OS와 같은 상이한 운영체제(OS) 인스턴스들을 사용했다. 전형적으로, 하나의 모뎀 보드는 하나의 섹터 또는 셀에 지지된다. 따라서 멀티-셀(예를 들어, 3셀들 또는 6셀들) 구성들을 지원하기 위해, 셀들의 수만큼 많은 모뎀 보드들을 제공할 필요가 있다.

개선으로서, 멀티-코어 프로세서가 모뎀 보드 상의 LTE 무선 기지국에 이용될 수 있다. 그 경우, PREEMPT RT 패치를 갖는 SMP 리눅스와 같은 운영체제는 모든 8개의 코어들을 포함하는 하나의 SMP(symmetric multiprocessing) 파티션 상에서 실행한다. 이러한 구성에서 상기 제어 플레인(비-실시간 쓰레드들 및 프로세스들) 및 상기 데이터 플레인(실시간 쓰레드들 및 프로세스들)은 상이한 코어들 상에서 실행하도록 결합되더라도(bound to) 동일한 운영체제 인스턴스들을 공유한다.

그러나, PREEMPT RT를 갖는 공개 소스 SMP 리눅스는 vxWorks와 같은 핵심 실시간 운영체제는 아니다. 따라서, PREEMPT RT를 갖는 SMP 리눅스로부터 최적의 실시간 성능을 보장하기 위해, 전형적으로 이러한 운영체제의 이용 결과인 무제한 레이턴시 급증들을 감소 또는 심지어 제거하도록 다수의 기술들이 채용될 수 있다. 상기 무제한 레이턴시 급증들은 해결되고 제거되지 않으면, 배치 불가능한 상기 시스템을 아마도 렌더링하는, 상기 LTE 계층2 스케줄러와 같은 애플리케이션들의 전체 시스템 행동에 부정적인 영향을 주는 경향이 있다.

따라서, 예를 들어, (a) 상기 실시간 프로세스들 또는 쓰레드들만을 실행하도록 전용된 상기 데이터 플레인 코어들 상에서 비-필수 인터럽트들(interrupts)을 디스에이블하고 이들 인터럽트들을 상기 제어 플레인 코어로 라우팅하고, (b) 디폴트 "인터럽트" 모드에 반대되는 "폴링(polling)" 모드에서 특정한 하드웨어 구성요소들을 실행하여, 특정한 데이터 코어에 대해 생성된 인터럽트들의 수를 감소시킴으로써, PREEMPT RT 패치를 갖는 SMP 리눅스와 같은 운영체제의 실시간 성능을 향상시키기 위한 방법 및 시스템이 필요하다.

PREEMPT RT 패치를 갖는 SMP 리눅스와 같은 운영체제(OS)의 실시간 성능을 향상시키기 위해 채용될 수 있는 다양한 기술들이 본원에 설명된다. PREEMPT RT를 갖는 SMP 리눅스는 핵심, 실시간 운영체제는 아니다. 따라서, PREEMPT RT를 갖는 SMP 리눅스의 사용으로 인해 다르게 발생할 수 있는 상기 무제한 레이턴시 문제들을 해결하기 위한 기술들을 도입하는 것이 중요하다. 이들 무제한 레이턴시 급증들은 매우 엄격한 실시간 성능 요구들을 가져 배치 불가능한 시스템을 렌더링하는, 상기 LTE 계층2 스케줄러의 적절한 시스템 행동에 용이하게 영향을 줄 수 있다. 특히, PREEMPT RT를 갖는 SMP 리눅스와 같은 운영체제의 실시간 성능을 향상시키기 위해 채용될 수 있는 소프트웨어 기술들 중 하나는 상기 실시간 프로세스들 또는 쓰레드들만을 실행하도록 전용된, 상기 데이터 플레인 코어들 상의 비-필수 인터럽트들을 디스에이블하는 것을 수반한다. 대신, 소프트웨어 DMA 인터럽트들과 같은, 이들 비-필수 인터럽트들은 상기 제어 플레인 코어로 라우팅된다. 게다가, 적어도 하나의 하드웨어 구성요소들(예를 들어, 큐 관리자)이 상기 디폴트 "인터럽트" 모드에 반대되는 "폴링" 모드에서 실행될 수 있어서, 특정한 데이터 코어에 대해 발생된 인터럽트들의 수를 감소시킨다.

일 실시예에서, 모뎀 보드 상의 멀티-코어 프로세서로 무선 네트워크의 데이터 패킷들을 처리하는 컴퓨터-구현 방법이 제공된다. 폴링 모드에서 큐 관리자를 실행하는 동안, 인입 데이터 패킷을 위한 버퍼가 획득되고 상기 데이터 패킷은 프레임 큐에 인큐잉되고(enqueued), 상기 프레임 큐는 상기 큐 관리자에 의해 처리될 프레임 기술자들(frame descriptors)의 링크된 리스트를 포함한다. 대기하는 프레임 기술자들에 대해 상기 큐 관리자를 주기적으로 폴링하기 위해 커널 쓰레드(kernel thread)가 사용되고 상기 하드웨어 구성요소로부터 N 개(N은 조정가능한 파라미터)의 프레임 기술자들을 디큐잉(dequeuing)한다. 커널 스페이스의 각각의 디큐잉된 프레임 기술자와 연관된 콜백(callback) 기능이 실행될 수 있고, 상기 콜백 기능은 상기 프레임 기술자 내의 상기 데이터 패킷의 버퍼 포인터를 프로세싱을 위해 버퍼 기술자들의 커널-사용자 맵핑된 링에 인큐잉한다. 마지막으로, 상기 데이터 패킷이 콘텍스트 스위치 없이 메시징 모듈로 전달된다.

다른 실시예에서, 무선 네트워크의 데이터 패킷들을 프로세싱하기 위한 시스템이 제공된다. 상기 장치는 일반적으로 모뎀 보드 및 상기 모뎀 보드에 부착된 복수의 프로세서 코어들을 포함하는 멀티-코어 프로세서를 포함하고, 상기 모뎀 보드는 커널 스페이스 및 사용자 스페이스를 포함한다. 게다가 상기 시스템은 큐들을 관리하고 폴링 모드에서 실행하도록 구성된 큐 관리자 및 인입 데이터 패킷을 위한 버퍼를 획득하고 상기 데이터 패킷을 프레임 큐에 인큐잉하도록 구성된 프레임 관리자를 포함할 수 있고, 프레임 큐는 상기 하드웨어 구성요소에 의해 처리될 프레임 기술자들의 링크된 리스트를 포함한다. 또한, 커널 쓰레드는 대기하는 프레임 기술자들에 대해 상기 큐 관리자를 주기적으로 폴링하고 상기 하드웨어 구성요소로부터 N 개(N은 조정가능한 파라미터)의 프레임 기술자들을 디큐잉하도록 구성된다. 커널 스페이스에서 각각의 디큐잉된 프레임 기술자와 연관된 콜백 기능이 상기 프레임 기술자 내의 상기 데이터 패킷의 버퍼 포인터를 프로세싱을 위해 버퍼 기술자들의 커널-사용자 맵핑된 링에 인큐잉하도록 구성된다. 마지막으로, 상기 시스템은 콘텍스트 스위치 없이 상기 데이터 패킷을 메시징 모듈로 전달하기 위한 수단을 포함할 수 있다.

또 다른 실시예에서, 통신 네트워크의 단일 SMP 파티션에서 멀티-셀 지원을 제공하기 위한 시스템이 개시된다. 상기 시스템은 전형적으로 모뎀 보드 및 복수의 프로세서 코어들을 갖는 멀티-코어 프로세서를 포함하고, 상기 멀티-코어 프로세서는 복수의 데이터 플레인 코어들 상에 도착하는 비-필수 인터럽트들을 디스에이블하고 복수의 제어 플레인 코어들로 상기 비-필수 인터럽트들을 라우팅하도록 구성된다.

본 예시적인 실시예의 적용가능성의 추가 범위는 이하에 제공된 상세한 설명으로부터 명백해질 것이다. 그러나, 본 발명의 정신 및 범위 내의 다양한 변경들 및 수정들이 당업자에게 명백해지기 때문에 본 발명의 바람직한 실시예들을 나타내는, 상세한 설명 및 특정 예들이 단지 예로서 주어졌다는 것이 이해될 것이다.

도 1은 본 발명의 양태들에 따른 플랫폼 아키텍처의 일 실시예를 도시한 도면.
도 2는 본 발명의 양태들에 따른 코어 예비 및 코어 친밀감을 갖는 예시적인 아키텍처를 도시하는 도면.
도 3은 코어 추상화 계층을 구현하기 위한 예시적인 아키텍처를 도시한 도면.
도 4는 하드웨어가 디폴트 인터럽트 모드에 반대되는 폴링 모드에서 실행하도록 구성될 때 인입 데이터 패킷에 대해 상기 프로세스 흐름의 고-레벨 설명을 나타내는 도면.

본 발명은 상기 디바이스의 다양한 부분들, 및 상기 방법의 단계들의 구성, 배치, 및 조합으로 존재할 수 있고, 고려된 목적들은 이하에 더 충분히 설명되고, 청구항들에서 특별히 지적되고, 첨부된 도면들에 예시된 바와 같이 달성된다.

예시적인 실시예들을 예시할 목적일 뿐 청구된 주제를 제한할 목적이 아닌 도면들을 이제 참조하면, 도 1은 현재 설명된 실시예들이 통합될 수 있는 시스템도를 제공한다.

이제 도 1을 참조하면, 예시적인 플랫폼 아키텍처(100)가 도시된다. 이 아키텍처는 일반적으로 모뎀 보드에 사용되지만, 다른 애플리케이션들에 사용될 수 있다는 것이 이해될 것이다. 본 실시예에서 하나의 파티션이 모두 8개의 코어들을 갖는 것으로 규정된다. 그러나, 멀티-코어 프로세서(100)는 임의의 수의 코어들을 가질 수 있다는 것이 이해될 것이다. 본 실시예로, 따라서 모든 코어들(예를 들어, 8개의 코어들) 상에서 실행하는 단일 SMP(symmetric multiprocessing) 운영체제(OS) 인스턴스(102)를 사용할 수 있다. 상기 제어 및 데이터 플레인들이 하나의 OS 인스턴스 하에 있기 때문에, 상기 데이터 플레인이 상기 제어 플레인을 또한 고장내지 않는 문제를 보장하기 위해 일반적으로 주의가 필요하다.

본 예에서, 상기 멀티-코어 프로세서(100)는 3개의 셀들(도면에서 104, 106, 및 108로 도시됨)을 서빙한다. 각각의 셀은 업링크(UL) 스케줄러(도면에서 110, 112, 및 114로 도시됨) 및 다운링크(DL) 스케줄러(도 1에서 116, 118, 및 120으로 도시됨)를 필요로 한다.

무선 링크 제어(RLC: Radio Link Control) 계층이 LTE 무선 인터페이스를 거쳐 전송되고 수신된 패킷 프레임들 상의 에러들을 세그먼트, 연쇄 및 정정하도록 사용된다는 것이 공지된다. 상기 무선 링크 제어 및 매체 액세스 제어(RLC/MAC: Radio Link Control and Medium Access Control) 소프트웨어는 GPRS(2.5G) 무선 스택에서 사용된다. 이는 이동국과 기지국 제어기(BSC) 간의 수신확인된 및 수신확인되지 않은 데이터 전달을 제공한다. 따라서, 상기 아키텍처(100)는 또한 상기 이동국과 상기 네트워크 사이에 사용된 무선 인터페이스 상의 기본적인 전송 유닛인 RLC/MAC 블록(122)을 포함한다. 상기 RLC/MAC 블록(122)은 일반적으로 데이터 및 RLC/MAC 시그널링을 반송하도록 사용된다.

상기 멀티-코어 프로세서(100)는 또한 OA&M 모듈(124) 및 호출 프로세싱(또는 CALLP) 모듈(126)을 제공한다. OA&M은 일반적으로 통신 네트워크의 구성요소들을 동작, 운영, 관리 및 유지하는 것을 수반하는 프로세스들, 동작들, 툴들, 표준들, 등을 설명하도록 사용된다. 상기 CALLP 모듈(126)은 전형적으로 호출 프로세싱 동작들의 비-실시간 양태들을 관리한다.

게다가, 상기 멀티-코어 프로세서(100)는 일반적으로 상기 계층2(L2) 애플리케이션 소프트웨어로부터 상기 코어 특정 상세들을 감추는, 코어 추상화 계층(CAL: core abstraction layer)(128)을 포함한다. 계층2는 컴퓨터 네트워킹의 OSI(Open Systems Interconnection) 모델의 7-계층의 데이터 링크 계층이다. 상기 데이터 링크 계층은 광역 네트워크(wide area network)의 인접한 네트워크 노드들 간 또는 동일한 근거리 네트워크(local area network) 세그먼트 상의 노드들 간의 데이터를 전송하는 프로토콜 계층이다. 상기 데이터 링크 계층은 네트워크 엔티티들 사이에서 데이터를 전송하기 위한 기능적 및 절차적 수단을 제공하고 물리 계층에서 발생할 수 있는 에러들을 검출하고 아마도 정정할 수단을 제공할 수 있다. 데이터 링크 프로토콜들의 예들은 근거리 네트워크들(멀티-노드)을 위한 이더넷, 점-대-점 프로토콜(PPP: Point-to-Point Protocol), 점-대-점(듀얼-노드) 접속을 위한 HDLC 및 ADCCP이다. 이 경우, L2는 일반적으로 매우 엄격한 실시간 요건들을 갖는, LTE 무선 인터페이스에 필요한 L2 스케줄러 프로세싱을 참조한다.

이동 통신 디바이스와 네트워크 스위칭 서브시스템 사이의 트래픽 처리 및 시그널링에 책임이 있는 상기 기지국의 실시간 성능 요구들을 충족하기 위해, PREEMPT RT 패치를 갖는 SMP 리눅스와 같은 운영체제가 사용될 수 있다. 물론, 다른 운영체제들이 사용될 수 있다는 것이 이해될 것이다. 이러한 SMP 구성에서 결정론적인 행동을 달성하기 위해, 상기 시스템은 AMP(Asynchronous Multiprocessing)와 비슷한 시스템 행동을 달성하기 위해 코어 예비 및 코어 친밀도 구성들을 채용하는 방식으로 구현되는 것이 바람직하다. 이는 또한 예를 들어, PREEMPT RT를 갖는 SMP 리눅스에서 최상의 성능을 얻기에 바람직하다. 버퍼 관리 및 메시징 서비스들과 같은, 락리스 제로 카피 서비스들(lockless zero copy services)의 사용은 또한 PREEMPT RT를 갖는 SMP 리눅스 운영체제의 사용에 의해 제기될 수 있는 임의의 레이턴시 문제들을 해결하도록 도울 수 있다.

도 1에 도시된 바와 같은 코어 추상화 계층(128)의 주요 기능들 중 하나는 상기 멀티-코어 플랫폼의 전체 능력들을 활용하는 다양한 서비스들과 함께 L2 프로세싱과 같은 고-레벨 애플리케이션들을 제공하는 것이다. 따라서 상기 코어 추상화 계층은 몇가지 목적들을 달성하도록 설계된다. 첫째로, 더 높은 레벨 애플리케이션 소프트웨어(즉, L2 소프트웨어)로부터 멀티-코어 특정 구현들 및 상기 DPAA(Data Path Acceleration Architecture)를 감추면서, 새로운 DPAA에 기초하는 BED(Backplane Ethernet Driver) 인터페이스를 지원한다. (상기 DPAA는 네트워크 인터페이스들 및 하드웨어 가속기들을 포함하는, 리소스들의 부하 확산 및 공유와 같은 멀티-코어 네트워크 프로세싱을 최적화하도록 설계된다.) 두번째로, 진입(ingress) 및 진출(egress) 방향들 모두의 사용자-플레인 데이터에 대한 가속된 데이터 경로를 제공하기 위해 P4080의 DPAA 하드웨어 구성요소들을 활용한다. 세번째로, 구성 변화들(즉, 코드 변화들을 요구하지 않고)에 용이하게 적응하도록 가능한 많은 유연성을 제공한다. CAL 구성의 예는 버퍼 풀들(pools), 진입 프레임 큐들, 및 진출 프레임 큐들을 위한 DPAA 리소스 구성이다.

도 1에 도시된 바와 같이, 본 발명의 실시예는 하나의 파티션의 모든 프로세서 코어들을 사용한다. 단순한 리눅스가 모든 어려운 실시간 프로세싱 요구들을 충족하기는 어렵기 때문에, PREEMPT RT 패치를 갖는 SMP 리눅스와 같은 운영체제가 바람직하다. 공개 소스 운영체제가 또한 비용을 저감하기 위해 사용된다. 상기 시스템은 또한 6-셀 또는 심지어 9-셀 구성들도 허용하는, 상기 SMP 구성에서 AMP형 시스템 행동을 규정하기 위해, SMP 리눅스의 코어 친밀도 및 CPU 예비 능력들을 통합한다. 상기 운영체제 인스턴스가 비-실시간 코어들(제어 플레인과 같은)과 실시간 코어들(데이터 플레인들과 같은) 사이에서 공유되기 때문에, 락(lock)이 비-실시간 쓰레드들 및 프로세스들에 의해 취해질 때 문제들이 발생할 수 있다. 실시간 쓰레드 또는 프로세스가 상기 데이터 플레인 코어(들)에 대한 락의 해제를 기다려야 하기 때문에, 락은 실시간 쓰레드 또는 프로세스에 지연을 초래할 수 있다. TCP(Transmission Control Protocol), UDP(User Datagram Protocol)와 같은 전송 계층 프로토콜들이 그들의 패킷 헤더들에 소스 및 목적지 포트 번호를 명시한다는 것이 공지된다. 포트 번호는 16비트 무부호 정수(unsigned integer)이다. 바인딩(binding)으로 알려진 프로세스는 상기 네트워크를 통해 데이터를 전송 및 수신하기 위해 자신의 입력 또는 출력 채널 파일 기술자들(소켓들)을 포트 번호 및 IP 어드레스와 연관시킨다. 상기 운영체제의 네트워킹 소프트웨어는 모든 애플리케이션 포트들로부터 상기 네트워크 상으로 인출 데이터(outgoing data)를 송신하고 상기 패킷들 IP 어드레스 및 포트 번호들을 매칭함으로써 프로세스로 도착하는 네트워크 패킷들을 전송하는 업무를 갖는다. 상기 표준 리눅스 프로토콜 스택이 락-리스 구현을 보장하지 않기 때문에, 상기 예시적인 실시예들은 상기 리눅스 프로토콜 스택의 사용을 회피하면서, TCP/UDP IP 패킷들을 전송 및 수신하도록 데이터 플레인 코어들 상에서 실행하는 실시간 프로세스(LTE L2 스케줄러)에 대한 락-리스 메시징 스킴(scheme)을 규정한다. 상기 제어 플레인 코어 상에서 실행하는 OA&M과 같은, 상기 비-실시간 프로세스들이 정상 동작을 위해 상기 리눅스 프로토콜 스택의 사용을 계속할 것이다.

일반적으로, 리눅스 GPL(General Public License) 문제들을 회피하기 위해, 상기 LTE L2 스케줄러는 사용자 스페이스에서 동작된다. 따라서, 상기 LTE L2 스케줄러로부터 TCP/UDP IP 데이터를 전송 및 수신하기 위해, 데이터가 사용자-커널 스페이스 경계를 가로질러야 한다. 이 단계는 전형적으로 데이터 카피를 필요로 한다. 따라서, 하나의 메모리 위치로부터 다른 위치로 데이터를 카피하기 위해 프로세서 전력을 소비하는 것은 귀중한 리소스들을 낭비한다. 따라서, 상기 제어 플레인이 정상적인 방식으로 동작하도록 하면서(전통적인 리눅스 프로토콜 스택을 사용하는 것과 같이), 상기 데이터 플레인 코어들 상에서 실행하는 실시간 쓰레드들 및 프로세스들에 대한 효율적인 락-리스, 제로 카피 및 비-차단 메시징 서비스를 허용하는 방법 및 시스템을 제공하는 것이 바람직하다.

상기 제어 플레인(OA&M 및 호출 프로세싱과 같은, 비-실시간 프로세스들 및 쓰레드들)과 상기 데이터 플레인(LTE L2 스케줄러와 같은, 실시간 프로세스 및 쓰레드들) 모두가 동일한 운영체제 인스턴스를 공유하기 때문에, 두가지 유형들의 동작들이 수행되는 코어들의 적어도 일부 물리적인 분리가 있다는 것을 보장하는 것이 유용하다.

이 점에서, 도 2는 코어 예비 및 코어 친밀도 구성을 채용하는 아키텍처를 도시한다. 이 예에서, 8개의 코어 프로세서가 사용된다. 코어들(0 내지 7)은 도면에서 202, 204, 206, 208, 210, 212, 214, 및 216으로 라벨링된다. 모든 비-실시간 쓰레드들 또는 프로세스들은 상기 제어 플레인 동작들(218)에 전용된 코어들에 결합될 것이다. 즉, 데이터 플레인 동작들(도면에서 220, 222, 224, 및 226으로 라벨링됨)에 전용된 코어 그룹이 "고속 경로(fast path)"(데이터 경로) 구현 또는 L2 프로세싱에 직접적으로 필요하지 않은 어떠한 쓰레드들도 호스팅하거나 실행하지 않을 것이다. "고속 경로"는 "정상 경로"와 비교하여 프로그램을 통해 더 짧은 명령 경로 길이를 갖는 경로를 설명하기 위해 사용된 용어이다. 고속 경로가 효과적이기 위해, 흔하지 않은 케이스들, 정상 범위 밖의 케이스들(corner cases), 에러 처리, 및 다른 변칙들을 처리하도록 마지막을 남기고, 가장 흔히 발생하는 업무들을 정상 경로보다 더 효율적으로 처리해야 한다. 고속 경로들은 최적의 형태이다. 고속 경로 드라이버에 의해 사용된 진입 버퍼 풀들은 시스템-전역에 공유된 리소스들의 예이다. 이들은 사용자-플레인 패킷들을 수신하도록 전용된다.

코어 친밀도 및 코어 예비를 달성하기 위해, 제어 플레인 코어 그룹(218)에 대한 디폴트 친밀도 마스크가 규정된다. 이러한 방식으로 특정한 바인딩들이 할당되지 않은 임의의 쓰레드 또는 프로세스들은 제어 플레인 코어(들)로 디폴트될 것이다. 코어 추상화 계층(CAL; 220)은 상기 L2 애플리케이션 소프트웨어로부터 코어 특정 상세들을 감춘다. 이 구성에서 단 하나의 운영체제 인스턴스(222)가 실행된다.

주어진 셀에 대응하는 상기 실시간 프로세스들 및 쓰레드들이 코어 예비 및 코어 친밀도를 통해 상기 특정한 코어들에 결합된다. 예를 들어, 셀 1 및 셀 4의 업링크 스케줄러 쓰레드는 코어 2에 결합되고, 상기 다운링크 스케줄러 쓰레드는 코어 3에 결합된다. 따라서, 도 2는 상기 SMP 구성에서 AMP형 구성을 도시한다. 본 실시예에서, 예를 들어, OA&M 및 호출 관리 프로세스들과 같은 모든 제어 플레인 프로세스들 및 쓰레드들이 코어 0(202) 상에서 실행할 것이다. 각각의 셀 실시간 프로세스들 및 쓰레드들은 전용 코어 상에서 실행하고, 비-실시간 프로세스 또는 쓰레드는 실행하지 않을 것이다. 이러한 방식으로, (1) 상기 비-실시간 쓰레드들이 프로세싱 시간을 갈구하지 않을 것이고 (2) 상기 비-실시간 쓰레드가 상기 실시간 쓰레드들로부터 어떠한 가치있는 프로세싱 시간도 취하지 않고 엄격한 실시간 프로세싱 요건들을 갖는 데이터 코어 상의 상기 프로세싱 레이턴시 급증에 더하지 않을 것이다.

리눅스와 같은 운영체제의 시스템 메모리가 2개의 분명한 영역들: 커널 스페이스 및 사용자 스페이스로 분할될 수 있다는 것이 일반적으로 공지된다. 커널 스페이스는 서비스들을 실행하고(즉, 실행하고) 제공하는 커널(즉, 상기 운영체제의 코어)이다.

메모리는 일반적으로 콘텐츠가 매우 고속으로 액세스(즉, 판독 및 기록)될 수 있지만 일시적으로만 유지되는(즉, 사용시, 또는 기껏해야 전원장치가 온으로 유지되는 동안) RAM(random access memory) 셀들로 구성된다. 현재 사용중인 프로그램들 및 데이터를 유지하는 것이 목적이다.

사용자 스페이스는 사용자 프로세스들(즉, 커널 이외의 모든 것)이 실행하는 메모리 위치들의 세트이다. 프로세스는 프로그램의 실행하는 인스턴스이다. 상기 커널의 역할들 중 하나는 이 스페이스 내의 개별 사용자 프로세스들을 관리하고 이들이 서로 간섭하는 것을 방지하는 것이다.

커널 스페이스는 상기 시스템 호출들의 사용을 통해서만 사용자 프로세스들에 의해 액세스될 수 있다. 시스템 호출들은 입력/출력(I/O) 또는 프로세스 생성과 같은 커널에 의해 수행된 서비스에 대해 액티브 프로세스에 의한 유닉스형 운영체제에서의 요청들이다. 액티브 프로세스는 상기 CPU에서 다음 차례를 위해 대기하는 프로세스와 반대로, 상기 CPU에서 현재 진행하는 프로세스이다. I/O는 CPU로/로부터 및 주변 디바이스(디스크 드라이브들, 키보드들, 마우스들 및 프린터들과 같은)로/로부터 데이터를 전송하는 임의의 프로그램, 동작 또는 디바이스이다.

따라서, 커널 스페이스는 커널, 커널 확장들, 및 대부분의 디바이스 드라이버들을 실행하기 위해 엄격하게 예비된다. 반대로, 사용자 스페이스는 모든 사용자 모드 애플리케이션 작업 및 메모리가 필요할 때 교환될 수 있는 메모리 영역이다.

도 3을 참조하여, 이들 및 다른 목적들을 달성하는 예시적인 아키텍처(300)가 도시된다. 이 점에서, 상기 코어 추상화 계층(CAL; 301)은 LTE 네트워크 구성 및 임의의 정적인 파싱, 분류 및 분배(PCD: Parsing, Classification and Distribution) 규칙들을 상기 프레임 관리자들(FMan)(330 및 332)로 로딩하고 구성 파일들의 세트에 기초하여 CAL 프레임워크를 셋업하는 코어 추상화 계층 초기화(CALInit) 모듈(302), 코어 추상화 계층 버퍼(CALBuf) 모듈(304), 다른 보드(즉, eCCM)로/로부터 사용자-플레인 데이터를 전송 및 수신하기 위한 L2 소프트웨어로 메시징 서비스들을 제공하는 코어 추상화 계층 메시징(CALMsg) 모듈(306), 인입 프레임들을 적절한 코어들로 라우팅하기 위해 각각의 FMan(330, 332)에 의해 사용될 PCD 규칙들 및 구성들을 제공하는 코어 추상화 계층 파싱, 분류 및 분배(CALPcdFmc) 모듈(308) 및 커널 스페이스 모듈인 코어 추상화 계층의 DPAA 드라이버(CALDpaaDriver)(312)에서 추적을 인에이블 및 디스에이블하는 추적 능력들을 제공하는 코어 추상화 계층 DPAA 추적(CALDpaaTrace) 모듈(310)을 포함하지만 이들로 제한되지 않는 다양한 모듈들을 사용자 스페이스에 포함한다.

또한, 상기 CAL(301)은 버퍼 풀들, 진입 프레임 큐들, 및 진출 프레임 큐들을 관리하기 위한 DPAA 리소스 구성 툴(313)을 또한 포함할 수 있다.

상기 아키텍처(300)는 PREEMPT RT 패치를 갖는 SMP 리눅스와 같은, 적절한 운영체제(314)를 더 포함한다. 상기 운영체제(314)는 차례로 전술한 CALDPaa 드라이버(312), 적어도 하나의 프레임 관리자(FMan) 드라이버(316), 적어도 하나의 버퍼 관리자(BMan) 드라이버(318), 및 적어도 하나의 큐 관리자(QMan) 드라이버(320)와 같은 다양한 드라이버들을 지원한다. 버퍼 기술자들의 링(321)은 CALMsg 모듈(306)과 같은 사용자 스페이스 구성요소들 및 CALDpaaDriver(312)와 같은 커널 스페이스 구성요소들로 하여금 데이터 카피를 필요로 하지 않고 어떠한 문제들도 처리하지 않고 액세스하도록 하는 맵핑된 커널-사용자(K-U) 스페이스이다.

도 3에 도시된 바와 같이, 상기 아키텍처(300)는 다수의 전력 아키텍처 프로세싱 코어들을 캐시들, 독립 캐시들 및 메모리 서브시스템들과 접속하기 위해 스케일가능한 온-칩 네트워크(scalable on-chip network)에 적절한 상호접속 아키텍처인 P4080 CoreNet 패브릭(fabric)(322)을 적절히 포함할 수 있다.

상기 P4080 프로세서는 DPAA의 구현을 포함한다. 따라서, 상기 아키텍처(200)는 P4080 DPAA(224)를 더 포함할 수 있다. 상기 DPAA(324)는 네트워크 인터페이스들 및 하드웨어 가속기들을 포함하는, 부하 스프레딩 및 리소스들의 공유와 같은 멀티코어 네트워크 프로세싱을 최적화하도록 설계된다. 도시된 바와 같이, 상기 DPAA(324)는 일반적으로 BMan(326), QMan(328), 및 제 1 및 제 2 FMan(330 및 332)과 같은 다양한 관리자들을 각각 포함한다.

무선 다중-액세스 통신 시스템에서, 송신기들 및 수신기들이 다중 계층 통신 스택을 사용하여 통신할 수 있다는 것이 공지된다. 상기 계층들은 예를 들어, 물리 계층, 매체 액세스 제어(MAC; medium access control) 계층, 무선 링크 제어(RLC; Radio Link Control) 계층, 프로토콜 계층(예를 들어, 패킷 데이터 수렴 프로토콜(PDCP; packet data convergence protocol) 계층), 애플리케이션 계층 등을 포함할 수 있다. 상기 RLC 계층은 상기 PDCP 계층으로부터 서비스 데이터 유닛들(SDU; service data units)을 수신하고, 상기 MAC 계층으로 송신하기 위해 상기 SDU들을 RLC 프로토콜 데이터 유닛들(PDU)로 연쇄 또는 세그먼트한다.

따라서, 상기 CALBuf 모듈(304)은 상기 RLC SDU 프로세싱에서 사용하기 위해 L2 애플리케이션들에 대한 락-리스 버퍼 관리 서비스들을 용이하게 한다. 당업계에 공지된 바와 같이, 공유된 리소스를 경쟁하는 쓰레드들이 상호 배제에 의해 무기한 연기된 실행을 갖지 않는다는 것을 비-차단 알고리즘이 보장한다. 시스템-전체의 진행이 보장된다면 비-차단 알고리즘은 락-리스(또는 락-프리(lock-free))이다. 상기 CALBuf 모듈(304)은 또한 버퍼 풀 통계 데이터(예를 들어, 풀 고갈 상태(pool depletion state), 고갈 수치(depletion count), 풀 가용 상태, 풀 할당 에러 수치, 등)에 대한 쿼리(query)를 지원한다. 상기 CALBuf 모듈(304)은 일반적으로 상기 서비스들을 구현하기 위해 상기 CALDPAADriver(312)와 인터페이스한다. 상기 CALBuf 모듈(304)은 또한 비-실시간 프로세스에 의해 취해진 락이 락 해제를 기다리는 실시간 프로세스에 대한 레이턴시 문제들을 유발하는, 멀티-코어 환경에서 적절한 시스템 동작을 위해 바람직한 락-리스 버퍼 관리 스킴을 제공한다.

상기 CALMsg 모듈(306)은 사용자-플레인 데이터를 다른 보드(즉, eCCM)로/로부터 전송 및 수신하기 위해 L2 소프트웨어로 메시징 서비스들을 제공한다. 상기 CALMsg 모듈(306)은 일반적으로 DPAA를 통해 락-리스 제로 카피 메시징 서비스들을 제공하기 위해 상기 CALDPAADriver(312)와 인터페이스한다. 상기 CALDpaaDriver(312)는 상기 버퍼 기술자들의 링(321)의 생산자이다. 이 점에서, 상기 CALDpaaDriver(312)는 상기 진입 데이터 흐름 패킷을 상기 버퍼 기술자들의 링(321)에 인큐잉한다. CALMsg API로부터의 도움을 받는 LTE L2 스케줄러와 같은 사용자 스페이스 애플리케이션은 상기 버퍼 기술자들의 링(321)의 전형적인 소비자이다. 상기 사용자 애플리케이션은 상기 버퍼 기술자들의 링(321)에 인큐잉된 각각의 패킷들을 주기적으로 실행 및 프로세싱한다. 이러한 특징은 상기 L2 애플리케이션 소프트웨어로 하여금 무제한 레이턴시 지연들을 회피하기 위해 락 프리, 제로 데이터 카피 방식으로 프로토콜 스택을 사용하지 않고 TCP/UDP IP 패킷들을 전송 및 수신하게 한다.

상기 CALDpaaDriver(312)는 상기 CAL(301)의 커널 스페이스 구성요소이고 Bman 및 Qman API들을 사용하여 버퍼 관리 서비스들 및 메시징 서비스들의 제공 및 구현을 돕는다. 본원에 사용된 바와 같이, 상기 용어 API(또는 애플리케이션 프로그래밍 인터페이스)는 다른 소프트웨어와 상호작용하도록 인에이블하는, 소프트웨어 프로그램에 의해 구현된 인터페이스를 의미한다. 이는 사용자 인터페이스가 사용자들과 컴퓨터들 사이의 상호작용을 용이하게 하는 방식과 유사하게 상이한 소프트웨어 프로그램들 간의 상호작용을 용이하게 한다. API는 그들의 어휘들 및 호출 관습들을 결정하기 위해 애플리케이션들, 라이브러리들, 및 운영체제들에 의해 구현되고, 그들의 서비스들에 액세스하기 위해 사용된다. 이는 상기 API의 소비자와 구현자 사이의 통신에 사용된 루틴들, 데이터 구조들, 객체 클래스들, 및 프로토콜들에 대한 명세를 포함할 수 있다.

상기 CALDpaaDriver(312)는 일반적으로 사용자-플레인 데이터 분배를 위해 사용되는 DPAA 리소스들(버퍼 풀들 및 프레임 큐들)을 관리; 초기화, 버퍼 관리, 및 메시징 서비스들을 위해 공개, 폐쇄, ioctl(i-o-control)와 같은 다양한 파일 동작들을 통해 다른 CAL 모듈들로 사용자 스페이스 인터페이스를 제공; 커널-사용자 스페이스(K-U) 버퍼 맵핑을 수행; DPAA 버퍼 풀 및 수신기 및 송신기 통계 데이터를 제공; 및 링 버퍼들을 관리하기 위한 서비스들을 구현할 책임이 있다. 링 버퍼들이 일반적으로 상기 CAL의 계층2 소프트웨어 큐를 나타내고, 특정한 계층2 다운링크 스케줄러 쓰레드를 향하는 FD들을 저장하도록 사용된다는 것을 주의해야 한다. 상기 CALMsg 모듈(306)은 링으로부터 버퍼 기술자들을 검색하기 위해 상기 계층2 다운링크 스케줄러를 위한 API들을 제공한다.

상기 CALBuf 모듈(304)은 "고속 경로" 데이터 프로세싱을 위해 독점적으로 사용되는 버퍼 관리 서비스들을 제공한다. 상기 CALBuf 모듈(304)은 L2 애플리케이션으로 사용자 스페이스 API들을 제공한다. 상기 CALBuf 모듈(304)은 상기 CALDpaaDriver(312)가 생성하지만 상기 Bman(326)에 의해 관리되는 버퍼들에 대한 제로 카피 및 락-리스 버퍼 관리 서비스를 제공하기 위해 상기 CALDpaaDriver(312)와 협력한다.

상기에 설명된 모든 CAL 구성요소들은 일반적으로 상기 CALDpaaDriver(312)를 제외하고, 플랫폼 미들웨어(사용자 스페이스에서 실행하는)이다. 상기 CALDpaaDriver(312)는 커널 스페이스에서 실행하는 커스텀 드라이버(custom driver)이고, 상기 CAL 사용자 스페이스 미들웨어에 의해 필요한 서비스들-특히 P4080 DPAA 하드웨어 구성요소들에 의존하는 서비스들-을 구현하고 제공하도록 설계된다.

이러한 새로운 아키텍처에 대한 상기 코어 추상화 계층의 일부로서 락-리스 버퍼 관리 및 메시징 서비스들의 도입은 SMP 환경에서 무제한 레이턴시 급증들을 방지하는 것을 돕고, 상기 제어 플레인 및 상기 데이터 플레인 모두 동일한 OS 인스턴스를 공유한다. SMP 환경에서, 하나의 코어(상기 제어 플레인 상에서 발견되는 것 같은) 상의 비-실시간 프로세스 또는 쓰레드에 의해 취해진 락(lock)은 상이한 코어(상기 데이터 플레인 상에서 발견되는 것 같은) 상에서 해제될 락을 기다리는 실시간 쓰레드 또는 프로세스에 대한 레이턴시 급증을 유발할 것이다. 따라서, 하나의 파티션을 사용하는 멀티-코어 프로세서-기반 모뎀 보드의 성능 요건들을 만족하기 위해 상기 데이터 플레인 코어 상의 고속 데이터 경로에 대해 리눅스 프로토콜 스택을 사용하지 않는, 락-리스, 제로 카피, 비-차단 메시징 스킴이 필요하다. 이러한 스킴 없이 상기 시스템은, 특히 상기 LTE L2 스케줄러의 프로세싱에 대한, 전체 시스템을 파괴할 수 있는 무제한 레이턴시 급증들을 겪을 것이다.

제로 카피 메시징 스킴의 이용은 커널 스페이스의 이더넷 인터페이스에 도착하는 패킷이 데이터 카피를 필요로 하지 않고 사용자 스페이스의 계층2 다운링크 스케줄러와 같은 목적지에 이르도록 한다. 리눅스 GPL 문제들로 인해, 상기 LTE L2 스케줄러는 사용자 스페이스에서 동작된다. 따라서, 상기 LTE L2 스케줄러로부터 TCP/UDP IP 데이터를 전송 및 수신하기 위해, 데이터는 상기 사용자-커널 스페이스 경계를 가로질러야 한다. 이러한 동작은 전형적으로 데이터 카피를 필요로 한다. 따라서, 하나의 메모리 위치에서 다른 메모리 위치로 데이터를 카피하기 위해 프로세서 전력을 소비하는 것은 소중한 리소스들을 낭비한다. 따라서, 상기 제어 플레인이 정상적인 방식(전통적인 리눅스 프로토콜 스택을 사용하는 것과 같은)으로 여전히 동작하도록 하면서, 상기 데이터 플레인 코어들 상에서 실행하는 실시간 쓰레드들 및 프로세스들에 대한 효율적인 락-리스, 제로 카피 및 비-차단 메시징 서비스를 허용하는 방법 및 시스템을 제공하는 것이 바람직하다.

고속 데이터 경로 구현을 위해 상기 리눅스 프로토콜 스택을 바이패스(bypass)하는 것은 데이터 플레인 코어들 상에서 실행하는 상기 LTE L2 스케줄러로 하여금 대안적인 락-리스 메시징 스킴을 사용하여 TCP 및 UDP IP 패킷들을 전송 및 수신하도록 한다. 상기 리눅스 프로토콜 스택의 사용은 상기 LTE L2 스케줄러의 프로세싱을 고장낼 수 있는 무제한 레이턴시 급증들을 발생시킬 수 있다. 이는 상기 리눅스 프로토콜 스택이 락-리스로 설계되지 않았다는 사실 때문이다. 또한, 상기 프로토콜 스택이 상기 제어 플레인 코어 상에서 실행하는 OA&M 및 호출 프로세싱 엔티티들과 같은 비-실시간 프로세스들 및 쓰레드들에 의해 또한 사용되기 때문에, 실시간 프로세스들 및 쓰레드들에 대한 무제한 레이턴시 급증들을 유발할 수 있다. 상기 프로토콜 스택은 상기 제어 플레인 코어 상에서 실행하도록 결합될 수 있어서, OA&M 및 호출 프로세싱과 같은 상기 비-실시간 프로세스들 및 쓰레드들이 상기 시스템 행동 및/또는 동작을 고장 내지 않고 가끔 무제한 레이턴시 급증들을 용이하게 견딜 수 있어서 프로토콜 스택의 사용을 계속할 것이다.

도 4는 진입 데이터 패킷 흐름에 대한 상기 데이터 플레인 코어들 상의 인터럽트들을 디스에이블하는 예시적인 방법을 도시한다. 상기 진입 데이터 흐름 패킷들은 각각의 인터럽트와 연관된 상기 콘텍스트 스위치 프로세싱 오버헤드를 감소시키기 위해 상기 패킷들에 대해 상기 하드웨어를 폴링하는, 커널 쓰레드에 의해 처리된다.

처음에, 상기 하드웨어(예를 들어, 상기 QMan(328))는 디폴트 "인터럽트" 모드에 반대되는, "폴링" 모드에서 실행하도록 구성된다(410). 상기 QMan(328)은 시작 시, 즉, 상기 프로세서가 재부팅될 때 소프트웨어 초기화 동안, 폴링 모드에서 실행하도록 구성될 수 있다. 상기 디폴트 인터럽트 모드는 본원에 참조로서 통합된, 2010년 11월 12일 출원된 미국 특허 No. 12/945,146에 더 상세히 설명된다는 것을 주의해야 한다.

데이터 패킷들이 외부 이더넷 인터페이스 상에 연속적으로 도착함에 따라, FMan(330)과 같은 프레임 관리자는 (1) BMan(326)과 같은 버퍼 관리자로부터 버퍼를 획득하고, (2) 상기 패킷을 상기 버퍼로 카피하고, (3) 상기 패킷을 프레임 큐(FQ)에 인큐잉해야 한다. 상기 프레임 큐는 QMan(328)과 같은 큐 관리자에 의해 처리될 프레임 기술자들의 하드웨어 링크된 리스트이다(420). 본원에 사용된 바와 같이, "링크된 리스트"는 데이터 기록들의 시퀀스로 구성된 데이터 구조를 참조하여, 각각의 기록에 상기 시퀀스의 다음 기록에 대한 참조(즉, "링크")를 포함하는 필드가 있다. 이 경우, 각각의 프레임 기술자는 상기 데이터 패킷을 유지하는 버퍼에 대한 포인터를 포함한다. 상기 QMan(328)은 상기 시스템에 대해 생성된 모든 프레임 큐들을 관리한다. 상기 FMan(330)은 각각의 도착하는 데이터 패킷의 IP 어드레스를 시험하기 위해 상기 CAL 모듈(301)에 의해 규정된 PCD 규칙들(예를 들어, 진입 프레임 큐 맵핑을 위한 IP 어드레스)을 사용한다. 그 후, 상기 Fman(330)은 상기 데이터 패킷을 유지하는 상기 버퍼로의 포인터를 포함하고 상기 적절한 프레임 큐에 이를 인큐잉하는 프레임 기술자를 생성한다.

상기 QMan(328)은 상기 패킷이 하드웨어 큐의 앞에 도달할 때까지 내부 하드웨어 큐를 통해 상기 패킷을 푸시(push)한다(430). 중요하게, 상기 하드웨어는 상기 데이터 플레인 코어에 대한 어떠한 관문 인터럽트들도 생성하지 않을 것이다.

본 실시예에서 폴링 모드에서 실행하도록 일반적으로 구성된, 상기 QMan(328)을 서비스하기 위해 커널 쓰레드가 CALDpaaDriver(312)의 일부로 생성된다(440).

상기 CALDpaaDriver(312)의 커널 쓰레드는 주기적으로(ΔΤ의 주기적인 시간 간격으로) 웨이크 업하고(wake up) 상기 하드웨어 큐의 앞에 도달한 임의의 대기하는 프레임 기술자들에 대해 폴링하도록 상기 QMan API를 불러온다(invoke)(450).

그 후 상기 커널 쓰레드는 상기 QMan(328)으로부터 "N" 개의 엔트리들(프레임 기술자들)을 디큐잉(즉, 큐로부터 아이템을 제거)한다(460). 이 점에서, "N"은 조정가능한 파라미터를 나타낸다(예를 들어, N=100). 특히, N은 상기 커널 쓰레드가 "웨이크 업"할 때마다 서비스할 상기 QMan(328)으로부터의 프레임 기술자 엔트리들의 수를 나타낸다.

다음에, 서비스될 임의의 프레임 기술자들이 있는지 여부에 대해 결정된다(470). 없다면, 상기 커널 쓰레드는 다시 슬립(sleep)한다(490).

그렇지 않으면, 각각의 디큐잉된 프레임 기술자 엔트리와 연관된 등록된 콜백 기능이 실행된다. 상기 콜백 기능은 어떠한 콘텍스트 스위치도 없이 락-리스, 제로 카피 방식으로 상기 CALMsg 모듈(306)로 상기 패킷을 전달한다. 이는 예를 들어, 결국 상기 사용자 스페이스 계층2 다운링크 스케줄러에 의해 소비되도록 상기 프레임 기술자로부터 상기 데이터 패킷의 버퍼 포인터를 버퍼 기술자로 카피하고 이를 상기 적절한 K-U 맵핑된 버퍼 기술자들의 링(321)에 인큐잉함으로써 달성될 수 있다(490).

인터럽트 모드에서 각각의 진입 데이터 패킷의 도착은 전형적으로 상기 데이터 플레인 코어에 대한 인터럽트를 초래한다. 최대 15개의 데이터 패킷들이 하나의 인터럽트 서비스 루틴(ISR: Interrupt Service Routine)에서 처리되는, 인터럽트 복합 모드에서도 사용자-커널-사용자 스페이스 콘텍스트 스위치에 대한 프로세싱 오버헤드가 매우 중요하다. 이는 4G LTE 무선 시스템이 많은 수의 사용자들을 지원하기 때문에, 각각 높은 데이터 레이트를 유지할 수 있다(약 2 MBits/sec의 평균 데이터 레이트). 그러나, 상기 디폴트 인터럽트 모드에 반대인 폴링 모드에서 실행하도록 상기 QMan(328)을 구성함으로써 몇가지 장점들을 제안한다. 예를 들어, 상기 개괄된 스킴은 진입 데이터 흐름에 대한 특정한 데이터 코어에 대해 발생된 인터럽트들의 수를 상당히 감소시킨다. 이는 상기 데이터 플레인 코어에서 발생하는 콘텍스트 스위칭(사용자-커널-사용자 스페이스)에서 상당한 감소를 초래한다. 이는 상기 데이터 플레인 코어들 상의 프로세싱 오버헤드의 상당한 감소에 이르고 상기 LTE 시스템의 실시간 성능을 향상시킨다.

부가적으로, 상기 소프트웨어 DMA 인터럽트들과 같은 비-필수 인터럽트들이 상기 실시간 프로세스들 또는 쓰레드들만을 실행하도록 전용되고 대신 이들 인터럽트들이 상기 제어 플레인 코어 상에서 발생하도록 라우팅하는 상기 데이터 플레인 코어들 상에서 디스에이블된다. 이는 커널 스페이스에서 실행하는 ISR에 대한 LTE L2 스케줄러와 같은, 사용자 스페이스 애플리케이션으로부터 이들 인터럽트들의 결과로서 상기 데이터 플레인 코어들 상에서 불필요한 콘텍스트 스위치가 발생하지 않을 것이라는 것을 보장하는 것을 도울 것이다. 각각의 콘텍스트 스위치는 주목할 만한 프로세싱 오버헤드를 수반한다. 이러한 불필요한 프로세싱 오버헤드를 제거함으로써, 상기 LTE L2 스케줄러와 같은, 실시간 프로세스들 및 쓰레드들을 위한 상기 데이터 플레인 코어들에 더 많은 프로세싱 시간 및 전력이 주어진다.

당업자는 다양한 상술된 방법들의 단계들이 프로그래밍된 컴퓨터들에 의해 수행될 수 있다는 것을 용이하게 인식할 것이다. 본원에서, 일부 실시예들이 또한 프로그램 저장 디바이스들, 예를 들어, 머신 또는 컴퓨터 판독가능하고 머신-실행가능한 또는 컴퓨터-실행가능한 명령들의 프로그램들을 인코딩하는, 디지털 데이터 저장 매체를 커버하도록 의도되고, 상기 명령들은 상술된 방법들의 일부 또는 모든 단계들을 수행한다. 상기 프로그램 저장 디바이스들은 예를 들어, 디지털 메모리들, 자기 디스크들 및 자기 테이프들과 같은 자기 저장 매체, 하드 드라이브들, 또는 광 판독가능 디지털 데이터 저장 매체일 수 있다. 상기 실시예들이 또한 상술된 방법들의 단계들을 수행하도록 프로그램된 컴퓨터들을 커버하도록 의도된다.

상기 설명은 단순히 본 발명의 특정한 실시예들을 나타내고 이를 제한할 목적으로 의도되지 않는다. 이와 같이, 본 발명은 상술된 실시예들로만 제한되지 않는다. 오히려, 당업자가 본 발명의 범위 내에 있는 대안적인 실시예들을 구상할 수 있다는 것이 인식된다.

Claims

모뎀 보드 상의 멀티-코어 프로세서로 무선 네트워크 내의 데이터 패킷들을 프로세싱하는 컴퓨터-구현 방법에 있어서:
폴링 모드(polling mode)에서 큐 관리자(queue manager)를 실행하는 동안, 인입 데이터 패킷을 위한 버퍼를 획득하고 상기 데이터 패킷을 프레임 큐에 인큐잉(enqueue)하는 단계로서, 상기 프레임 큐는 상기 큐 관리자에 의해 처리될 프레임 기술자들(frame descriptors)의 링크된 리스트를 포함하는, 상기 버퍼 획득 및 데이터 패킷 인큐잉 단계;
대기하는 프레임 기술자들에 대해 상기 큐 관리자를 주기적으로 폴링하기 위해 커널 쓰레드(kernel thread)를 사용하는 단계;
하드웨어 구성요소로부터 N 개(N은 조정가능한 파라미터)의 프레임 기술자들을 디큐잉(dequeue)하는 단계;
커널 스페이스(kernel space)에서 각각의 디큐잉된 프레임 기술자와 연관된 콜백(callback) 기능을 실행하는 단계로서, 상기 콜백 기능은 상기 프레임 기술자 내의 상기 데이터 패킷의 버퍼 포인터를 프로세싱을 위해 버퍼 기술자들의 커널-사용자 맵핑된 링에 인큐잉하는, 상기 콜백 기능 실행 단계; 및
상기 데이터 패킷을 콘텍스트 스위치 없이 메시징 모듈로 전달하는 단계로서, 상기 멀티-코어 프로세서는 데이터 플레인 기능들(data plane functions)을 실행하도록 구성된 하나 이상의 데이터 플레인 코어들 및 제어 플레인 기능들을 실행하도록 구성된 하나 이상의 제어 플레인 코어들을 포함하고, 상기 데이터 플레인 코어들 상에서 수신된 비-필수 인터럽트들(non-essential interrupts)을 디스에이블하고 상기 비-필수 인터럽트들을 상기 제어 플레인 코어들 중 하나 이상으로 라우팅하는 것을 더 포함하는, 상기 데이터 패킷 전달 단계를 포함하는, 컴퓨터-구현 방법.
제 1 항에 있어서,
상기 큐 관리자는 하드웨어 구성요소를 포함하고 소프트웨어 초기화 동안 폴링 모드에서 실행하도록 구성되는, 컴퓨터-구현 방법.
제 1 항에 있어서,
상기 인입 데이터 패킷을 위한 버퍼를 버퍼 관리자가 제공하는, 컴퓨터-구현 방법.
삭제
제 1 항에 있어서,
상기 멀티-코어 프로세서는, 비-실시간 쓰레드들 및 프로세스들이 제어 플레인 동작들에 전용된 프로세서 코어들에 결합되고 데이터 플레인 동작들에 전용된 프로세서 코어들이 데이터 경로 구현 또는 계층2 프로세싱에 직접적으로 필요하지 않은 쓰레드들을 호스팅하거나 실행하지 않도록 구성되는, 컴퓨터-구현 방법.
무선 네트워크 내의 데이터 패킷들을 프로세싱하기 위한 시스템에 있어서,
모뎀 보드;
상기 모뎀 보드에 부착된 복수의 프로세서 코어들을 포함하는 멀티-코어 프로세서로서, 상기 모뎀 보드는 커널 스페이스 및 사용자 스페이스를 포함하고, 상기 프로세서 코어들 중 하나 이상은 데이터 플레인 기능들을 실행하도록 구성되고, 상기 프로세서 코어들 중 하나 이상은 제어 플레인 기능들을 실행하도록 구성되고, 상기 멀티-코어 프로세서는 데이터 플레인 코어들 상에서 수신된 비-필수 인터럽트들을 디스에이블하고 상기 비-필수 인터럽트들을 제어 플레인 코어들 중 하나 이상으로 라우팅하도록 구성되는, 상기 멀티-코어 프로세서;
큐들을 관리하고 폴링 모드에서 실행하도록 구성된 큐 관리자;
인입 데이터 패킷을 위한 버퍼를 획득하고 상기 데이터 패킷을 프레임 큐에 인큐잉하도록 구성된 프레임 관리자로서, 상기 프레임 큐는 하드웨어 구성요소에 의해 처리될 프레임 기술자들의 링크된 리스트를 포함하는, 상기 프레임 관리자;
대기하는 프레임 기술자들에 대해 상기 큐 관리자를 주기적으로 폴링하고 상기 하드웨어 구성요소로부터 N 개(N은 조정가능한 파라미터)의 프레임 기술자들을 디큐잉하도록 구성된 커널 쓰레드; 및
상기 프레임 기술자 내의 상기 데이터 패킷의 버퍼 포인터를 프로세싱을 위해 버퍼 기술자들의 커널-사용자 맵핑된 링에 인큐잉하고 상기 데이터 패킷을 콘텍스트 스위치 없이 메시징 모듈로 전달하도록 구성된, 커널 스페이스에서 각각의 디큐잉된 프레임 기술자와 연관된 콜백 기능을 포함하는, 시스템.
제 6 항에 있어서,
상기 멀티-코어 프로세서는, 비-실시간 쓰레드들 및 프로세스들이 제어 플레인 동작들에 전용된 프로세서 코어들에 결합되고 데이터 플레인 동작들에 전용된 프로세서 코어들이 데이터 경로 구현 또는 계층2 프로세싱에 직접적으로 필요하지 않은 쓰레드들을 호스팅하거나 실행하지 않도록 구성되는, 시스템.
제 6 항에 있어서,
상기 멀티-코어 프로세서는 상기 프로세서 코어들 상에서 실행하는 애플리케이션 소프트웨어로부터의 코어 특정 상세들을 감추는 코어 추상화 계층을 포함하도록 구성되는, 시스템.
제 6 항에 있어서,
상기 멀티-코어 프로세서는 상기 무선 네트워크의 적어도 6개의 셀들을 서빙하도록 구성되는, 시스템.
제 6 항에 있어서,
상기 멀티-코어 프로세서는 8개의 프로세서 코어들을 포함하는, 시스템.