KR20030071857A

KR20030071857A - 메모리를 통해 데이터 처리 시스템들간의 데이터 흐름을제어하기 위한 방법 및 장치

Info

Publication number: KR20030071857A
Application number: KR10-2003-7009848A
Authority: KR
Inventors: 지오라 바이란; 탈 소스테임
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2001-01-31
Filing date: 2001-01-31
Publication date: 2003-09-06
Also published as: CZ20032078A3; WO2002061592A1; EP1358562B8; CN1488105A; HUP0302879A3; EP1358562A1; EP1358562B1; CA2432387A1; PL362792A1; CN1307570C; JP2004523035A; JP4755390B2; HUP0302879A2; KR100773013B1; US20040057380A1; US7320041B2

Abstract

메모리를 통해 제1 및 제2 데이터 처리 시스템간의 데이터 흐름을 제어하기 위한 장치가 개시되어 있다. 상기 장치는 상기 메모리 내의 위치와 제2 데이터 처리 시스템 간에 통신될 데이터 패킷을 정의하는 프레임 설명자와 상기 메모리 내의 위치를 식별해주는 포인터 설명자를 포함하는 다수의 설명자를 생성하기 위한 설명자 로직을 포함한다. 상기 장치는 상기 제1 및 제2 데이터 처리 시스템에 의해 액세스될 수 있도록 상기 설명자 로직에 의해 생성된 설명자들을 저장하기 위한 설명자 테이블을 또한 포함한다.

Description

메모리를 통해 데이터 처리 시스템들간의 데이터 흐름을 제어하기 위한 방법 및 장치{Method and Apparatus for controlling flow of data between data processing systems via a memory}

종래의 데이터 처리 네트워크는 이더넷(Ethernet) 구조와 같은 상호연결 네트워크 구조에 의해 모두 연결되는 다수의 호스트 컴퓨터 시스템과 다수의 부수 장치들을 포함한다. 전형적으로, 네트워크구조는 하나 이상의 데이터 통신 스위치를 포함한다. 호스트 컴퓨터 시스템 및 부수 장치들 각각은 데이터 처리 네트워크의 노드를 형성한다. 각각의 호스트 컴퓨터 시스템은 전형적으로 PCI 버스 구조와 같은 버스 구조에 의해 상호연결된 다수의 중앙처리유닛과 데이터저장 메모리 장치를 포함한다. 또한, 네트워크 구조를 통해, 호스트 컴퓨터와 데이터 처리 네트워크내의 다른 노드들간의 데이터 교환을 위해, 네트워크 어댑터가 버스 구조에 연결된다. 호스트 컴퓨터 시스템과 네트워크 구조간의 데이터 및 제어 정보 전송은 가능한 효율적으로 이루어지는 것이 바람직하겠다.

본 발명은, 가령, 호스트 컴퓨터 시스템과 상기 호스트 컴퓨터 시스템과 데이터통신 네트워크간의 데이터를 전달하기 위한 데이터통신 인터페이스와 같은, 제1 및 제2 데이터 처리 시스템들간에 메모리를 통해 데이터 흐름을 제어하기 위한 방법 및 장치에 관한 것이다.

본발명의 바람직한 실시예는 이하의 도면을 예로써 참조하여 설명되겠다.

도 1은 데이터 처리 네트워크의 일예에 대한 블록도이다.

도 2는 데이터 처리 네트워크를 위한 네트워크 인터페이스 어댑터 카드의 블록도이다.

도 3은 데이터 네트워크를 위한 호스트 컴퓨터 시스템의 일례에 대한 블록도이다.

도 4는 네크워크 어댑터 카드를 위한 칩상의 집적 시스템(Integrated System on a Chip: ISOC)의 일례에 대한 블록도이다.

도 5는 ISOC의 또다른 블록도이다.

도 6은 ISOC를 통하는 정보 흐름을 설명하는 ISOC의 블록도이다.

도 7은 ISOC를 통하는 논리적 전송 경로의 블록도이다.

도 8은 ISOC를 통하는 논리적 수신 경로의 블록도이다.

도 9a는 순환형 설명자 테이블의 블록도이다.

도 10은 가상 버퍼 및 그이 물리적 대응 버퍼의 블록도이다.

도 11은 완료큐(completion queue)의 블록도이다.

도 12는 호스트로부터 네트워크로의 데이터 전송 흐름을 나타내는 블록도이다.

도 13은 호스트로부터 네트워크로의 데이터 전송 흐름을 나타내는 또다른 블록도이다.

도 14는 네트워크로부터 호스트로의 데이터 수신 흐름을 나타내는 블록도이다.

도 15는 네트워크로부터 호스트로의 데이터 수신 흐름을 나타내는 또다른 블록도이다.

본 발명에 따르면, 메모리를 통해 제1 및 제2 데이터 처리 시스템들간의 데이터 흐름을 제어하기 위한 장치가 제공되며, 상기 장치는 상기 제1 및 제2 데이터 처리 시스템에 의해 액세스되는 다수의 설명자(descriptor)를 저장하기 위한 설명자 테이블과, 상기 설명자 테이블에 저장되는 설명자들을 생성하기 위한 설명자 로직을 포함하고, 상기 설명자는 상기 테이블 내의 또다른 설명자로의 링크를 포함하는 브랜치 설명자를 포함한다.

설명자 로직 및 설명자 테이블은 호스트 컴퓨터 시스템과 상기 호스트 컴퓨터 시스템과 데이터통신 네트워크간의 데이터를 통신하기 위한 데이터통신 인터페이스와 같은 제1 및 제2 데이터 처리 시스템들간에 메모리를 통해 데이터 흐름 제어의 효율성을 개선시킨다.

설명자 로직에 의해 생성된 설명자들은 상기 메모리내의 위치와 상기 제2 데이터 처리 시스템간에 교환될 데이터 패킷을 정의하는 프레임 설명자와, 상기 메모리내의 위치를 식별하는 포인터 설명자를 포함한다. 설명자 테이블은 상기 제1 데이터 처리 시스템의 메모리내에 저장된다. 대안적으로, 설명자 테이블은 상기 제2 데이터 처리 시스템의 메모리내에 저장될 수 있다. 설명자 테이블은 내부의 브랜치 설명자들에 의해 서로 순차적으로 연결된 다수의 설명자 리스트를 포함한다. 대안적으로, 상기 설명자 테이블은 순환형(cyclic) 설명자 리스트를 포함한다.

본 발명은 메모리를 포함하는 호스트 컴퓨터 시스템, 상기 호스트 컴퓨터 시스템과 데이터 통신 네트워크사이의 데이터를 교환하기 위한 데이터 통신 인터페이스와, 상기 호스트 컴퓨터 시스템의 메모리와 상기 데이터 통신 인터페이스간의 데이터 흐름을 제어하기 위해 전술한 장치를 포함하는 데이터 처리 시스템까지 확장된다.

본 발명을 또다른 관점에서 보면, 메모리를 통해 제1 및 제2 데이터 처리 시스템간의 데이터 흐름을 제어하기 위한 방법이 제공되고, 상기 방법은, 설명자 로직에 의해, 메모리내의 위치와 제2 데이터 처리 시스템간에 통신될 데이터 패킷을 정의하는 프레임 설명자와 상기 메모리 내의 위치를 식별해주는 포인터 설명자를 포함하는 다수의 설명자를 생성하는 단계와, 상기 설명자 로직에 의해 생성된 설명자들을 상기 제1 및 제2 데이터 처리 시스템에 의해 액세스될 수 있는 설명자 테이블에 저장하는 단계를 포함한다.

이제, 도 1을 참조하면, 본 발명을 구현한 데이터 처리 네트워크가 도시되어 있는데, 데이터 처리 네트워크는 "인피니밴드(InfiniBand)" 네크워크 구조("인피니밴드"는 인피니밴드 트레이드 어소시에션의 상표임)와 같은 상호연결 네트워크 구조(30)에 의해 상호연결되는 다수의 호스트 컴퓨터 시스템(10)과 다수의 부수 디바이스(20)를 포함한다. 네트워크 구조(30)는 전형적으로 다수의 데이터 통신 스위치(40)를 포함한다.

호스트 컴퓨터 시스템(10)과 부수 장치(20) 각각은 데이터 처리 네트워크내의 노드를 형성한다. 각각의 호스트 컴퓨터 시스템(10)은 PCI 버스 구조와 같은 버스 구조(70)에 의해 상호연결되는 다수의 중앙처리유닛(CPU, 50)과 메모리(60)를 포함한다. 네트워크 구조(30)를 통해 호스트 컴퓨터 시스템(10)과 데이터 처리 네트워크내의 다른 노드들간의 데이터 교환을 위해, 네트워크 어댑터(80)가 또한 버스 구조에 연결된다.

이제, 도 2를 참조하면, 본 발명의 특히 바람직한 실시예에 따르면, 네트워크 어댑터(80)는 호스트 컴퓨터 시스템(10)의 버스 구조(70)내로 리무브블(removable) 삽입 가능한 에지 코넥터와 같은 코넥터를 구비한 플러그형 옵션 카드를 포함한다. 옵션 카드는 코넥터(270)를 통해 버스 구조(70)에 접속될 수 있는 ASIC(Application Specific Integrated Circuit) 또는 ISOC(Intergrated System on a Chip, 120)와, ISOC(120)에 접속되는 하나 이상의 제3 레벨 메모리 모듈들(250)과, 네트워크 구조(30)의 매체와 ISOC(120)간에 데이터를 교환하기 위해 ISOC(120)에 접속되는 중재기(interposer, 260)를 수반한다. 중재기(260)는 네트워크(30)에 대한 물리적 접속을 제공한다. 본 발명의 몇몇 실시예에서, 중재기(260)는 단일의 ASIC으로 구현된다. 그러나, 다른 실시예에서는, 중재기(260)가 몇 개의 컴포넌트들로 구현될 수 있다. 예를 들어, 네트워크(30)가 광학 네트워크를 포함하는 경우에, 중재기(260)는 별도의 광학 트랜시버를 구동시키는 리타이머(retimer)를 포함한다. 메모리(250)는 SRAM, SDRAM 또는 이들의 조합으로 구현될 수 있다. 또한, 메모리(250) 구현을 위해 다른 형태의 메모리들도 이용될 수 있다. ISOC(120)는 제1 및 제2 메모리를 포함한다. 어댑터(80)의 메모리 서브시스템에 대해서는 이후에 설명될 것이다. 이하의 설명으로부터 명백해지는 바와 같이, 이러한 구성은 데이터 처리 네트워크상에서 작동되는 분산 어플리케이션들의 성능을 향상시키고,시스템 확장성을 향상시키고, 다양한 통신 프로토콜들과의 호환성을 향상시키고, 호스트 컴퓨터 시스템에서 처리 조건을 감소시킨다. 좀더 구체적으로, 이러한 구성은 어댑터(80)와 호스트 시스템(10)간에 이종의 통신 프로토콜이 상존하는 것을 허용한다. 이러한 프로토콜들은 다양한 어플리케이션을 지원할 수 있으며, 동일한 어댑터(80)를 사용하고, 선정된 데이터 구조 집합을 이용함으로써 호스트와 어댑터(80)간의 데이터 전송을 향상시킨다. 병렬로 오픈될 수 있는 어플리케이션 채널수는 어댑터(80)에 할당되는 메모리 자원량에 의해 결정되며 어댑터에 구현된 처리 전력과는 무관하다. 이하의 설명으로부터, 여러개의 컴포넌트들을 하나의 집적회로칩 컴포넌트로 통합하는 ISOC(120)의 개념은 제조비용을 감소시키고 재사용가능한 시스템 구축 블록들을 제공한다는 점에서 유리하다는 것을 이해할 수 있을 것이다. 그러나, 본발명의 다른 실시예에서, ISOC(120)의 요소들은 별개의 컴포넌트들로 구현될 수도 있음을 또한 이해할 것이다.

이하의 설명에서, 용어 "프레임"은 호스트 컴퓨터 시스템(10)에서 실행되는 소프트웨어와 어댑터(80)간에 전달되는 데이터 유닛 또는 메시지들을 일컫는다. 프레임은 프레임 헤더와 데이터 페이로드(payload)를 포함한다. 데이터 페이로드는 사용자 데이터, 상위레벨 프로토콜 헤더 데이터, 승인, 흐름 제어 또는 이들의 조합을 포함할 수 있다. 프레임 헤더의 내용은 이하에서 상세히 설명될 것이다. 어댑터(80)는 프레임 헤더만을 처리한다. 어댑터(80)는 프레임을 네트워크 구조(30)에서 좀더 효율적으로 전송되는 작은 패킷들로 쪼갤 수 있다. 그러나, 일반적으로 이러한 쪼갬이 데이터 페이로드를 변형하는 것은 아니다.

본 발명의 특히 바람직한 실시예에 따르면, 데이터는 본명세서에서 "패킷"이라 지칭되는 단위 유닛으로 네트워크 구조(30)상에서 전송된다. 각각의 패킷은 하드웨어 헤더 데이터와 페이로드 데이터가 뒤따르는 루트 정보를 포함한다. 본 발명의 전형적인 예에서, 최대 1024 바이트의 패킷 크기가 적용된다. 좀더 큰 크기의 프레임들은 1024 바이트 패킷들로 쪼개어진다. 본 발명의 또다른 실시예에서는 다른 패킷 크기가 적용될 수도 있다.

본 발명의 바람직한 실시예에서, 어댑터(80)와 호스트 컴퓨터 시스템(10)상에서 실행되는 다수의 어플리케이션들간의 통신은 로지컬 통신 포트 구조(Logical Communication Port: LCP) 구조를 통해 이루어진다. 어댑터(80)는 상이한 내부 데이터 구조들로 인한 액세스 지연의 최적화를 가능하게 하는 메모리 계층을 포함한다. 이러한 메모리 계층에 대해서는 이하에서 설명하겠다. 본 발명의 바람직한 실시예에서, 어댑터(80)는 네트워크 구조(30)을 목적지로 하는 아웃밴드(TX) 데이터와 호스트 컴퓨터 시스템(10)을 목적지로 하는 인바운드(RX) 데이터간의 별도 경로들을 제공한다. 각각의 경로는 그자신의 데이터 전송 엔진과, 헤더처리로직과 네트워크 구조물 인터페이스를 포함한다. 이들 경로에 대해서는 또한 이하에서 설명하겠다.

이제, 도 3을 참조하면, LCP 구조는 호스트 컴퓨터 시스템(10)상에서 실행되는 로컬 소비자들과 어댑터(80)간의 인터페이스를 위한 프레임워크를 정의한다. 이러한 소비자들의 예로서 어플리케이션과 스레드(thread)를 들 수 있다. 컴퓨터 시스템(10)은 사용자 어플리케이션 공간(90)과 커널 공간(110)로 세분화될 수 있다. LCP 구조는 이러한 소비자에게 네트워크 구조(30)로의 로직 포트를 제공한다. 이러한 포트는 사용자 공간(90)로부터 직접 액세스될 수 있다. 본 발명의 특히 바람직한 실시예에서, 하드웨어 보호 메커니즘이 액세스 허락을 관리한다. 데이터 프레임의 전송 이전에 LCP 등록이 커널 공간(110)에 의해 수행된다. LCP 구조는 통신 프로토콜을 정의할 필요가 없다. 오히려, 데이터 및 제어 정보 전송을 위한 어플리케이션들과 어댑터(80)간의 인터페이스를 정의한다. 통신 프로토콜의 상세사항은 어플리케이션 및 어댑터(80)에서 실행되는 프로그램 코드에 의해 설정된다. 어댑터(80)상에서 이용될 수 있는 채널 개수는 LCP 관련 정보를 위해 이용될 수 있는 어댑터 카드(80)상의 메모리 용량에 의해서만 제한된다. 각각의 LCP 포트는 구체적인 일단의 특징들을 갖도록 프로그래밍될 수 있다. 일단의 특징들은 호스트 컴퓨터 시스템의 메모리(60)와 어댑터(80)간의 데이터 전송을 가장 잘 지원하는 특정 프로토콜에 따라 선택된다. 다양한 통신 프로토콜들이 동시에 지원될 수 있으며, 각각의 프로토콜은 상이한 LCP 포트를 이용한다.

LCP 구조는 LCO 클라이언트(100), 커널 공간에 상주하는 LCP 관리자(130), 어댑터(80)에 상주하는 하나 이상의 LCP 콘텍스트(140)를 포함한다.

각각의 LCP　클라이언트(100)는 LCP 포트에 연결되는 단방향 어플리케이션 종단지점이다. LCP　클라이언트(100)는 사용자 어플리케이션 공간(90) 또는 커널(110)에 위치할 수 있다. 동작에 있어서, 각각의 LCP 클라이언트(100)는 메모리(60)로부터 판독되어 TX LCP 채널을 통해 어댑터(80)에 의해 전송될 명령어 및 데이터를 생성하거나, RX LCP 채널을 통해 어댑터(80)에 의해 메모리(60)로 전송되는 데이터를 소비한다.

LCP　관리자(130)는 LCP 채널 할당 및 할당해제 및 각각의 채널을 위한 메모리(60)내의 판독/기록 영역 등록을 처리해주는 신뢰 컴포넌트이다. LCP 관리자(130)는 다른 통신 동작, 어플리케이션 또는 호스트 컴퓨터 시스템(10)의 운영체제에 손해를 주지 않고 사용자 공간의 어플리케이션이 어댑터(80) 자원을 사용할 수 있도록 해준다.

각각의 LCP 콘텍스트(140)는 특정 LCP　클라이언트(100)에 서비스하기 위해 어댑터(80)에 의해 요구되는 일단의 제어정보이다. LCP 콘텍스트(140)는 가능한 명령들, 포인터 구조 및 버퍼 설명자 정의와 같은, 채널이 존재하는 동안 일정한 LCP 채널 속성들을 포함한다. 또한, LCP 콘텍스트(140)는 서비스를 기다리는 데이터량과 같은 LCP 채널에 대한 구체적인 LCP 서비스 정보와 관련 LCP 채널을 액세스를 위한 다음 어드레스를 포함한다. LCP 콘텍스트(140)는 어댑터(80)에 존재하는 메모리내에 저장되어 있어서, 어댑터(80)가 하나의 채널에 대한 서비스를 중지하고 또다른 채널에 대한 서비스를 개시할 때 신속한 LCP 콘텍스트 스위칭을 가능하게 한다.

LCP 포트의 개시를 필요로 하는 LCP 클라이언트(100)는 LCP 관리자(130)에 LCP 채널 할당을 요청한다. LCP 채널 속성이 이 시점에서 결정되고 LCP 포트의 동작 및 LCP 클라이언트(100)가 LCP 포트와 관련하여 수행하도록 허가받은 연산을 규정한다. 고유의 안전한 방식에 따라 어댑터(80)를 액세스하기 위해 이용될 어드레스가 LCP 클라이언트(100)에게 부여된다. 이러한 어드레스를 도어벨(Doorbell) 어드레스라 한다.

또한, LCP 관리자(130)는 호스트 메모리(60)의 등록을 담당함으로써 어댑터가 가상 어드레스를 물리적 어드레스로 변환할 수 있도록 해주고 사용자 공간의 클라이언트들이 다른 프로그램들을 간섭하지 않고 이들 호스트 메모리 영역에 액세스할 수 있도록 해준다.

신규 버퍼들의 등록과 이전 버퍼들의 등록 해제는 실행시간중에 각각의 LCP 클라이언트(100)에 의해 요청될 수 있다. 이러한 변화는 LCP 클라이언트(100), LCP 관리자(130) 및 어댑터(80)간의 일련의 정보 교환을 필요로 한다.

각각의 LCP 클라이언트(100)과 포트는 명령어 실행을 위해 LCP 포트에 의해 전송되어 대기중인(pending) 요청들을 처리하기 위해 어댑터(80)가 필요로 하는 모든 정보를 제공하는 LCP 콘텍스트(140)와 연관되어 있다.

LCP 클라이언트(100)와 어댑터(80)간의 메모리 전송을 개시하고 프레임 전송을 개시하기 위해, LCP 클라이언트(100)는 특정 연산을 위한 정보를 저장하는 설명자를 작성한다. LCP 클라이언트(100)는 어댑터(80)에 매핑되는 도어벨 어드레스에 I/O 기록을 수행한다. 도어벨 어드레스에 기록함으로써, 어댑터(80)상의 LCP 콘텍스트(140)가 갱신되고, 새로운 실행요청이 추가된다.

어댑터(80)는 대기중인 요청들을 갖는 여러 전송 LCP 포트간을 중재하고 다음 서비스 대상을 선택한다.

데이터를 수신하면, 수신된 패킷에 대한 프레임 및 LCP가 초기화된다. 수신 LCP를 위해 필요한 연산을 정의하기 위해 설명자들이 생성된다. 어댑터(80)의 LCP 엔진이 이러한 설명자들을 실행함으로써 호스트 컴퓨터 시스템(10)의 메모리(60)내에 LCP 채널에 할당된 적절한 데이터 버퍼에 인입 데이터가 저장된다.

서비스되는 각각의 LCP 채널에 대해, 어댑터(80)는 연관된 LCP 콘텍스트 정보를 로드하고 이러한 정보를 이용하여 소정의 데이터 집합 전송을 수행한다. 그 다음에, 어댑터(80)는 다음에 선택되는 LCP 콘텍스트(140)를 계속해서 처리한다.

이제, 도 3을 참조하면, 상기에서 언급한 바와 같이, ISOC(120)가 제1 메모리 공간(220, 230) 및 제2 메모리 공간(240)를 포함하고 어댑터(80)는 또한 제3 레벨 메모리(250)를 포함한다. 제1, 제2 및 제3 메모리는 어댑터(80)의 메모리 서브시스템(210)의 일부를 차지한다. 본 발명의 바람직한 실시예에 의하면, ISOC(120)는 데이터 전송 동작에 전용되는 TX 프로세서(TX MPC, 150)와 데이터 수신 동작에 전용되는 RX 프로세서(RX MPC, 160)를 포함한다. 본 발명의 바람직한 실시예에서, 프로세서(150, 160)는 IBM 파워PC 405 RISC 마이크로프로세서와 같은 RISC(Reduced Instruction Set Computing) 마이크로프로세서에 의해 구현된다. 메모리 서브시스템(210)내에,ISOC(120)는, 제1 및 제2 메모리 공간에 부가하여, TX 프로세서(150)에 연관된 데이터 캐쉬(180) 및 명령어 캐쉬(170)와, RX 프로세서(160)에 연관된제2 데이터 캐쉬(180) 및 제2 명령어 캐쉬(200)를 포함한다. 세 개의 레벨들간의 차이점은 메모리 크기 및 이에 연관된 액세스 시간이다. 이하에서 명백해지겠지만, 메모리 서브시스템(210)은 TX 프로세서(150) 및 RX 프로세서(160)에 의한 명령어 및 데이터의 편리한 액세스, 확장성, 제조비용을 줄이는 잇점으로 TX 프로세서(150) 및 RX 프로세서(160)간의 자원 공유를 돕는다.

제1 레벨의 메모리 공간(M1, 220 및 230)는 TX-M1 메모리 공간(220)와 RX-M1 메모리 공간(230)을 포함한다. TX-M1 메모리(220)는 TX 프로세서(150)에 의해서만 액세스될 수 있고 RX-M1 메모리(230)는 RX 프로세서(160)에 의해서만 액세스될 수 있다. 동작에 있어서, 제1 레벨 메모리 공간(220, 230)는 임시 데이터 구조, 헤더 템플릿, 스택 등을 저장하기 위해 이용된다. 제1 레벨 메모리 공간(220, 230) 모두는 대기 상태를 제로화하기 위해 동작한다. 제1 레벨 메모리 공간(220, 230)의 각각은 프로세서(150, 160)중 대응하는 것의 데이터 인터페이스에만 접속되며 명령어 인터페이스에는 접속되지 않는다. 이러한 구성은, 제1 레벨 메모리 공간(230, 240)의 데이터에 대한 효율적인 액세스를 유지주면서, 캐쉬가능 및 캐시불가능한 제1 레벨 메모리 영역 모두가 이용가능하게 해준다.

제2 레벨 메모리 공간(M2, 240)은 양쪽 프로세서(150, 160) 모두에, 어댑터(80)의 다른 콤포넌트에, 그리고 호스트 컴퓨터 시스템(10)에 이용가능한 공유 메모리이다. 제2 레벨 메모리 공간(240)으로의 액세스는 제2 레벨 메모리 공간(240) 공유 내부 버스에 의해 보다 많은 에이전트에 의해 이용되기 때문에 제1 레벨 메모리 영역(220, 230)으로의 액세스보다 느리다. 또한, 제3 레벨의 메모리공간(250)이 공유 자원이다. 특히, 본 발명의 바람직한 실시예에서, 어댑터(80)는 제1 레벨 메모리 공간(220, 230)과 제2 레벨 메모리 공간(240)이 모두 프로세서(150, 160)와 동일한 ASIC상에 집적되는 컴퓨터 주변회로카드를 포함한다. 공유 메모리 공간(240, 250)은 신속하고 빈번한 액세스 사이클을 필요로 하지 않는 데이터 유형을 이해 일반적으로 이용된다. 이러한 데이터 유형에는 LCP 콘텍스트(140) 및 가상 어드레스 변환 테이블이 포함된다. 공유 메모리 공간(240,250)은 프로세서(150, 160)의 명령어 및 데이터 인터페이스 모두에 액세스가능하다.

어댑터(80)는 전송 및 수신 데이터 흐름을 별도로 처리한다. 전송 및 수신 경로에 대한 각각의 프로세서(150, 150)는 타스크간의 스위칭 오버헤드를 방지하고, 하나의 경로내의 일시적인 처리 로드를 다른 경로로부터 분리하며, 인입 및 인출 데이터 스트림을 처리하기 위해 2개의 임베딩된 프로세서들을 이용한다. 이제 도 5를 참조하면, ISOC(120)는 전송경로 로직(280), 수신경로 로직(290) 및 공유로직(300)을 포함한다. 전송경로 로직(280)은 각각의 LCP 채널의 상세사항을 디코딩하고 실행을 위해 LCP 관련 명령어를 가져오기 위한 LCP TX 엔진(310)과, 어댑터(80)로 프레임들을 전송하는 것을 제어하기 위한 TX 로직(320)과, TX 프레임 및 패킷 처리를 관리하기 위한 전술한 TX 프로세서(150)와, 명령어 및 임시 데이터 구조를 저장하기 위한 전술한 제1 레벨 TX 메모리(220)와, 링크 로직(330)과, 데이터 흐름을 관리하고 프레임을 데이터 패킷으로 쪼개는 것을 위한 라우팅 처리와 같은 패킷을 관리하기 위해 TX 프로세서(150)를 보조하기 위한 로직을 포함한다. TX프로세서(150)는 예외 및 오류의 경우에만 프로세서가 인터럽트되는 폴링 온니(polling only) 방식에 근거하여 일련의 타스크들을 처리한다. 제1 레벨 TX 메모리(220)가 TX 로직(320)과의 통신을 위해 프로세서(150)에 의해 이용된다. 수신경로 로직(290)은 링크 로직(340)과, 인입 패킷의 헤더를 처리하고 이러한 패킷들을 프레임으로 변환 또는 조립하는데 있어서 전술한 RX 프로세서(160)를 지원하기 위한 하드웨어와, RX 프레임 및 패킷 처리를 위한 전술한 RX 프로세서(160)와, 명령어들을 저장하기 위한 전술한 제1 레벨 RX 메모리(230)와, 네트워크 구조(30)로부터 프레임 전송을 제어하기 위한 RX 로직(350)과, 각각의 LCP 채널의 상세사항을 디코딩하고 호스트 컴퓨터 시스템의 메모리(60)내에 관련 LCP 데이터 구조들로 인입 데이터를 저장하고 어댑터(80)에 의해 사용되기 위해 LCP 클라이언트(100)에 의해 빈 프레임 버퍼들이 제공될 때, 이러한 빈 프레임 버퍼들에 대한 포인터를 받아서 등록하기 위한 LCP RX 엔진(360)을 포함한다. RX 프로세서(160)는 예외 및 오류의 경우에만 RX 프로세서(160)가 인터럽트되는 폴링 온니(polling only) 방식에 근거하여 일련의 타스크들을 처리한다. 제1 레벨 RX 메모리(230)가 RX 로직(350)과의 통신을 위해 RX 프로세서(160)에 의해 이용된다.

전술한 바와 같이, ISOC 방식은 어댑터(80) 및 회로 보드 및 기타 지원 모듈들과 같은 기타 부품들에 연관된 제조 비용을 감소시켜준다. 또한, ISOC 방식은 어댑터(80)의 단순성을 증가시킴으로써 신뢰성을 증가시킨다. ISOC(120)의 요소들간의 접속 개수는 효율적으로 비제한된다. 따라서, 다수의 광범위한 상호접속경로가 구현될 수 있다. 호스트 컴퓨터 시스템(10)에서 데이처 처리 오버헤드를 감소시키기 위해, 호스트 메모리(60)와의 데터 전송 동작은 ISOC(120)에 의해 주도적으로 수행된다. ISOC(120)는 인입 및 인출 패킷들의 헤더를 처리한다. 전송중에, ISOC(120)는 헤더를 작성하고 이를 네트워구 구조(30)에 라우팅한다. 수신중에, 어댑터(80)는 시스템 메모리내의 그의 위치를 판단하기 위해 헤더를 처리한다. 레벨 1 메모리(220, 230)는 프로세서에 스택, 탬플릿, 테이블 및 일시 저장 위치를 제공하는 제로(zero) 대기 상태 메모리이다. 본 발명의 특정의 바람직한 실시예에 따르면, 전송경로 로직(280), 수신경로 로직(290) 및 공유 로직(300)은 코어(core)라 지칭되는 작은 로직 요소들로 구성된다. 이들 요소가 상이한 어플리케이션들을 위해 사용될 수 있는 독립적인 속성을 갖고 있는 개별적인 로직 조각들로 설계되기 때문에 "코어"라는 용어가 이용된다.

상기에서 언급한 바와 같이, 전송경로 로직(28)은 송출 또는 인출 프레임들을 처리한다. 프레임 전송은 호스트 컴퓨터 시스템(10)의 CPU(50)와 같은 CPU에 의해 버스 구조(70)를 통해 초기화된다. ISOC(120)는 버스 구조(70)와 통신하기 위한 인터페이스 로직(370)을 포함한다. ISOC(120)는 버스 인터페이스 로직(370)을 ISOC(120)의 프로세서 로컬 버스(PLB, 390)에 연결시키는 버스 브리징 로직(390)을 또한 포함한다. TX LCP 엔진(310)은 호스트 메모리(60)로부터 명령어 및 프레임을 가져온다. TX 프로세서(150)는 네트워크 구조(30)상에 패킷들과 같은 전송에 적합한 포맷으로 각각의 프레임 헤더를 처리한다. TX 로직(320)은 변경없이 프레임 데이터를 전송한다. 링크 로직(330)은 네트워크 구조(30)상에 전송될 최종 형태로 전송될 각각의 프레임을 처리한다. 링크 로직(330)은 각각이 네트워크 구조(30)에접속가능한 하나 이상의 포트를 포함한다.

상기에서 언급한 바와 같이, 수신경로 로직(29)은 인입 패킷들을 처리한다. 초기에, 네트워크 구조(30)로부터 수신되는 패킷들은 링크 로직(340)에 의해 처리된다. 링크 로직(340)은 헤더와 페이로드 포맷으로 패킷을 재생성한다. 패킷 포맷 및 호스트 메모리(60)내의 목적지를 결정하기 위해, 헤더가 RX 프로세서(230)에 의해 처리된다. 링크 로직(340)은 네트워크 구조(30)에 각각 접속가능한 하나 이상의 포트를 포함한다. RX LCP 엔진은 버스 구조(70)를 통해 호스트 메모리로 데이터를 전송한다.

전송경로 로직(280)은 TX LCP 엔진(310)과 TX 프로세서(220) 사이에 헤더인(HeaderIn) 선입선출 메모리(FIFO,400)를 포함한다. 수신경로 로직은 RX 프로세서(230)와 RX LCP 엔진(360) 사이에 헤더아웃(HeaderOut) FIFO(410)을 포함한다. TX 로직(320) 및 RX 로직(350)에 부가적인 FIFO 및 큐들이 제공된다. 이러한 FIFO들 및 큐는 이하에서 설명되겠다.

공유로직(300)은 전송경로 로직(280)과 수신경로 로직(290)에 의해 공유되는 모든 로직 요소들을 포함한다. 이들 요소들은 전술한 버스 인터페이스 로직(370), 버스 브리징 로직(380), PLB(390), 제2 레벨 메모리(240) 및 원격 제3 레벨 메모리(250)에 대한 액세스를 제공하기 위한 제어기(420)를 포함한다. 버스 인터페이스 로직(370)은 버스 구조(70)상에 버스 마스터 및 슬레이브로서 동작한다. 슬레이브로서, 버스 인터페이스 로직은 CPU로 하여금 제2 레벨 메모리(240), 제어기를 통한 제3 레벨 메모리(250) 및 ISOC(120)의 상태 레지스터 및 구성 레지스터를 액세스할 수 있도록 해준다. 이러한 레지스터들은 일반적으로 CPU(50), TX 프로세서(150) 및 RX 프로세서(160)에 의해 액세스될 수 있다. 마스터로서, 버스 인터페이스 로직은 TX LCP 엔진(310) 및 RX LCP　엔진(360)으로 하여금 호스트 컴퓨터 시스템(10)의 메모리(60)에 액세스할 수 있도록 해준다. 도 5에서, "M"은 마스터 접속을 의미하고, "S"는 슬레이브 접속을 의미한다.

도 6을 참조하면, ISOC(120)를 통하는 패킷 흐름은 일반적으로 대칭적(symmetrical)이다. 즉, 흐름의 일반적인 구조는 전송 및 수신 방향에서 유사하다. ISOC(120)은 제1 인터페이스 로직(440), 제1 제어 로직(4600, 프로세서 로직(480), 제2 제어 로직(470) 및 제2 인터페이스 로직(450)을 포함하는 것으로 간주될 수 있다. 패킷들은 다음의 방식에 따라 처리된다.

a. 전송방향에서, 정보가 버스 구조(70)로부터 제1 인터페이스 로직을 통해 ISOC(120)로 제공된다. 수신방향에서, 정보가 네트워크 구조(30)로부터 제2 인터페이스 로직(450)을 통해 ISOC(120)로 제공된다.

b. 전송방향에서, 제1 인터페이스 로직(440)을 통해 ISOC(120)로 제공된 정보는 제1 제어 로직(460)에 의해 처리된다. 수신방향에서, 제2 제어 인터페이스(450)을 통해 ISOC(120)로 제공된 정보는 제2 제어 로직(470)에 의해 처리된다.

c. 전송방향에서, 프레임 헤더는 제1 제어 로직(460)에서 인출 프레임에 대해 추출되어 프로세서 로직(480)에 의해 처리된다. 프로세서 로직(480)은 프레임 헤더에근거하여 제2 제어 로직(470)에 대한 명령어를 생성한다. 인출 프레임의 페이로드는 제2 인터페이스 로직(470)으로 전달된다. 수신방향에서, 제2 제어 로직(470)에서 인입 프레임으로부터 프레임 헤더가 추출되어 프로세서 로직(480)에 의해 처리된다. 프로세서 로직(480)은 프레임 헤더에 기하여 제1 제어 로직(460)에 대한 명령어를 생성한다. 인입 프레임의 페이로드는 제1 제어 로직(460)에 전달된다. 양쪽 방향에서, 프로세서(480)가 직접적으로 페이로드 데이터를 처리하지는 않는다.

d. 전송방향에서, 제2 제어 로직(470)은 프로세서 로직(480)으로부터 수신된 명령에 따라 인출 페이로드 데이터를 패키징한다. 수신방향에서, 제1 제어로직(460)은 프로세서 로직(480)으로부터 수신된 명령에 따라 인입 페이로드 데이터를 패키징한다.

e. 전송방향에서, 정보는 제2 인터페이스 로직(450)으로부터 그의 목적지로 네트워크 구조(30)를 경유하여 이동된다. 수신방향에서, 정보는 제1 인터페이스 로직으로부터 그의 목적지로 버스 구조(70)를 통해 이동된다.

호스트 컴퓨터 시스템(10)상에서 동작하는 소프트웨어에 대한 인터페이스가 부호(430)에 도시되어 있다. 유사하게, 프로세서 입력 및 출력상에서 동작하는 마이크로코드에 대한 인터페이스가 (490) 및 (500)으로 도시되어 있다.

이제 도 7을 참조하여, ISOC(120)를 통한 전송 데이터 프레임의 gm름의 일례에 대한 좀더 상세한 설명이 이루어진다. ISOC(120)는 ISOC(120)내의 다양한 포맷의 정보에 근거하여, LCP 콘텍스트 도메인(510), 프레임 도메인(520) 및 네트워크 도메인(530)으로 나뉠 수 있다. TX LCP 엔진(310)은 LCP 요청 FIFO(550), 직접액세스메모리(DMA) 로직(560), 프레임 로직(580), 및 전술한 LCP 콘텍스트 로직(140)을 포함한다. LCP 요청 FIFO(550), 직접액세스메모리(DMA) 로직(560) 및 LCP TX 콘텍스트 로직(590)은 LCP 콘텍스트 도메인(510)에 있다. 프레임 로직(580)은 프레임 도메인(520)에 있다. TX 로직(320), 제1 레벨 TX 메모리 공간(220) 및 TX 프로세서(150)은 프레임 도메인(520)과 네트워크 도메인(530) 사이의 경계부분에 걸쳐 있다. TX 링크 로직(330)은 네트워크 도메인(530)에 있다. 본 발명의 특정 실시예에서, 헤더인 버퍼(400)는 제1 레벨 TX 메모리 공간(220)에 포함되어 있다. 일반적으로, 호스트 컴퓨 시스템(10)상에서 실행되는 어플리케이션은 프레임을 생성한다. 프레임은 어댑터(80)상의 TX LCP 채널을 이용하여 전송된다. 어플리케이션과 어댑터(80)간의 핸드쉐이킹은 LCP 관리자(130)에 의해 수행되는 우선 초기화를 가정한다. LCP 서비스 요청을 추가하기 위해, LCP 클라이언트(100)는 하나 이상의 부가적인 전송 프레임이 실행될 준비가 되어 있음을 어댑터(80)에 알린다. 이는 도어벨내에 제어 워드를 기록함으로써 수행된다. LCP 포트에 유일하게 연관되며 다른 프로세스에 의한 액세스로부터 보호되는 어드레스를 이용하여, 기록 연산이 버스 구조(70)상의 물리적 기록 사이클로 번역되는 방식으로, 도어벨의 어드레스가 할당된다. 어댑터(80)는 기록 연산을 감지하고 특정 LCP 클라이언트(100)에 대한 이전 요청에 대한 엔트리를 증가시킴으로써 신규 요청을 기록한다. 이는 관련 LCP 콘텍스트(140)의 일부분이다. 어댑터(80)의 메모리 서브 시스템(210)에 유지되는 중재 리스트 또한 갱신된다. 간단한 예에서, 중재는 대기중인 요청들을 갖는 모든 전송 LCP 채널들간에 전술한 FIFO 방식(550)을 이용한다. 하나의 LCP 채널이 서비스되는 동안, 다음 LCP 채널이 선택된다. 해당 LCP 콘텍스트가 TX LCP 엔진(310)으로 로딩될 때 서비스 사이클이 시작된다. 그후에, LCP 채널을 서비스하기 위한 기본 연산을 도출하고 이러한 연산을 위한 파라미터들을 결정하기 위해 LCP 콘텍스트(140)가 액세스된다. 예를 들어, 이러한 기본 연산들은 LCP 콘텍스트(140)에 기록된 LCP 채널 속성에 기초한 것일 수 있다. 전형적으로, 완료서비스사이클은 LCP 클라이언트(140)에 의해 생성된 다수의 기본 설명자들을 페치(fetch)하여 실행시키는 어댑터(80)에 의해 수행되는 일단의 동작들을 포함한다. TX LCP 채널의 경우에, 서비스 사이클은 일반적으로 호스트 메모리(60)로부터 어댑터(80)의 메모리 서브시스템(210)으로 다수의 프레임을 판독하는 것을 포함한다. 결론에 따르면, 수정을 필요로 하는 모든 LCP 콘텍스트 정보(즉, LCP 서비스 정보)가 어댑터(80)의 메모리 서브시스템(210)내에서 갱신된다. 일반적으로, LCP 서비스 사이클내에서 어댑터(80)에 의해 수행되는 제1 동작은 처리될 다음 설명자를 가져오는 것이다.

ISOC(120)에 의한 전송 프레임 처리는 일반적으로 다음의 단계들을 포함한다.

a. 후속 LCP 포트 프레임 설명자 가져오기(fetch)

페치될 다음 설명자의 어드레스는 LCP 채널 콘텍스트(140)의 일부분으로서저장되어 있다. 어댑터(80)는 호스트 메모리(60)로부터 설명자를 판독하고 LCP 채널 속성에 근거하여 설명자를 해독한다. 설명자는 새로운 프레임 헤더의 크기, 데이터 페이로드 크기 및 이들 항목들의 위치를 정의한다.

b. 가상 어드레스에서 실제 어드레스로의 변환

데이터 버퍼가 어플리케이션의 가상 메모리 어드레스에 의해 참조되는 경우에, 어드레스는 부가적인 어드레스 변환 단계를 거쳐야 한다. 이러한 경우에, 어플리케이션에 의해 이용된 가상 어드레스는 어댑터(80)에 의해 이용가능한 물리적 어드레스로 변환되고 어댑터(80)는 호스트 메모리(60)를 액세스한다. 이는 페이지 경계 크로싱(boundary crossing)을 모니터링하고 LCP 관리자(130)에 의해 어댑터(80)의 메모리 서브시스템(210)으로 기록된 물리적 페이지 위치 정보를 이용함으로써 행해진다. 가상 어드레스에서 물리적 어드레스로의 변환 처리는 설명자 테이블이 신뢰되지 않는 LCP 클라이언트(100)에 의해 생성된 경우에 보안 수단으로서도 역할을 한다. 이는 호스트 메모리(60)의 관련없는 영역에 대한 권한없는 액세스를 방지해준다.

c. 프레임 헤더 판독

물리적 어드레싱을 이용하여, TX 프레임의 헤더와 페이로드 데이터가 호스트 메모리(60)내의 버퍼로부터 판독된다. 헤더는 TX 헤더인 FIFO(400)에 저장된다. 헤더 페치가 완료되면, 어댑터(80)는 헤더 처리가 TX 프로세서(150)에 의해 개시될 수 있음을 나타내는 내부 플래그를 세팅한다.

d. 프레임 데이터 판독

페이로드 데이터가 호스트 메모리(60)로부터 판독되어 어댑터(80)에 의해 데이터 FIFO(570)에 저장된다. 데이터 FIFO(570)는 TX 로직(320) 내에 있는 것으로 도 7에 도시되어 있다. 그러나, 데이터 FIFO(570) 또한 제1 레벨 TX 메모리 공간(220)에 포함될 수 있다. 전송될 모든 데이터가 어댑터(80)의 메모리 서브시스템(210)에 저장될 때까지 데이터 판독 트랜잭션이 계속된다. 판독동작이 완료되면, 상태 표시자가 LCP 클라이언트(100)에 리턴된다. 헤더가 헤더인 FIFO(400)로 판독되자마자 헤더 처리가 시작될 수 있다. 전체 데이터가 판독되기를 기다릴 필요는 없다.

e. 프레임 헤더 처리

헤더 처리는 TX 프로세서(150)에 의해 수행된다. 헤더 처리는 프로토콜에 따라 달라지며 LCP 구조에 외부적인 프로토콜 정보에 관련된다. TX 프로세서(150)는 TX 프로토콜 헤더 마이크로코드를 실행시키고 프로토콜 및 라우팅 초기화 시퀀스동안에 어댑터(80)의 메모리 서브시스템(210)에 이미 저장되어 있는 라우팅 테이블 및 기타 관련 정보를 액세스한다. TX 프로세서(150)가 새로운 헤더가 헤더인 FIFO(400)에 대기중임을 나타내는 표시자를 수신하면, 헤더 처리를 시작한다. 헤더 처리는 네트워크 구조(30)를 통해 패킷을 전송하고 라우팅 정보를 포함하기 위해 적용되는 포맷으로 하나 이상의 패킷 헤더를 산출한다. 페이로드 크기가 네트워크 구조(30)에 의해 허용되는 최대 패킷 크기보다 큰 경우에, 페이로드는 쪼개어져서 여러개의 패킷 헤더들을 생성하며, 각각은 원래의 페이로드 데이터의 연속적인 세그먼트들과 연관되어 사용되어 네트워크 구조(30)을 통한 통신을 위한 패킷을형성한다.

f. 전송을 위한 패킷 헤더의 대기(queuing)

패킷에 대한 헤더 워드의 개수 및 데이터 워드의 개수를 정의하는 명령어 및 패킷 헤더 그 자체가 TX 프로세서(150)에 의해 제1 레벨 메모리 공간(220)의 TX 헤더아웃 FIFO(540)로 기록된다.

g. 전송을 위한 패킷 헤더와 패킷 데이터의 병합

네트워크 구조(30)상에서의 패킷 전송은 헤더아웃 FIFO(540)내에 명령이 준비될 때마다 개시되고, 데이터 FIFO(570)는 관련 패킷의 전송을 완료시킬 수 있는 충분한 량의 데이터를 포함한다. 사이클릭 리던던시 검사(Cyclic Redundancy Check: CRC) 비트가 각각 패킷의 헤더 및 데이터에 추가될 수 있다. 각각의 완료된 패킷은 TX 링크 로직(330)을 통해 네트워크 구조(30)에 전달된다.

각 프레임에 대한 전송 프로세스는, 하나 이상의 패킷들에 의해, 모든 프레임 데이터가 네트워크 구조(30)상으로 전송될 때 완료된다. 어댑터(80)에 의해 처리되는 각 프레임에 대해, 제2 LCP 클라이언트(100)을 통해 어플리케이션으로 상태가 리턴될 수 있다. 이러한 상태는 호스트 메모리(60)로부터 어댑터(80)상으로 프레임 데이터 전송의 완료, 프레임 전송 자체의 완료 또는 다른 레벨의 전송 상태를 나타낸다.

임의의 시점에서, 어댑터(80)는, 서비스될 다음 LCP의 선택, LCP 채널 A에 대한 서비스 개시, LCP 채널 B의 마지막 프레임에 대한 데이터의 DMA 페치(fetch)실행, LCP 채널 C에 대한 프레임 헤더 및 프레그멘테이션 처리, 그리고 LCP 채널 D에 의해 발생한 패킷 전송 등의 동작중 일부 또는 전부를 동시에 실행할 수 있다.

도 8을 참조하면, RX LCP 포트를 이용하여 어플리케이션에 의해 데이터 프레임을 수신하는 것에 관한 설명이 예시적으로 이루어진다. ISOC(120)의 연산은 LCP 에 의해 지원되는 프로토콜 유형에 따라 달라질 수 있다. 어플리케이션과 어댑터(80)간의 핸드쉐이킹은 LCP 관리자(130)에 의해 수행되는 사전(priori) 초기화를 가정한다. RX LCP 엔진(360)은 LCP 할당로직(620), LCP 콘텍스트 로직(610) 및 DAM 로직(630)을 포함하며, 이들 모두는 LCP 도메인(520)에 존재한다. RX 프로세서(160), 제1 레벨 RX 메모리 공간(230) 및 RX 로직(350)은 모두 프레임 도메인(520)과 네트워크 도메인(530)의 경계에 걸쳐 있다. RX링크로직(340) 및 패킷지원로직(600)은 네트워크 도메인(530)내에 있다. 본 발명의 바람직한 실시예에서, 헤드아웃 FIFO(410)은 제1 레벨 RX 메모리 공간(230) 내에 위치한다. 네트워크 구조(30)로부터 ISOC(120)에 의해 수신된 프레임들은 호스트 메모리(60)내의 LCP 클라이언트 버퍼로 기록된다. 메모리 버퍼의 가용성은 LCP RX 클라이언트(100)에 의해 결정되고 인입 데이터 프레임의 삽입을 위해 어댑터(80)에 표시된다. LCP 클라이언트(100)는, 전송경로로직(280)에 전송 준비된 새로운 프레임이 알려지는 전술한 방식과 유사하게, ISOC(120)상의 수신 도어벨로 기록함으로써 버퍼를 제공한다. 도어벨 레지스터 어드레스가 할당되어 기록 동작이 버스 구조(70)상의 물리적 기록 사이클로 변환된다. 어댑터(80)는 기록 동작을 감지하고 특정 LCP RX 클라이언트(100)에 대해 가용한 워드 엔트리 수를 증가시킴으로써 빈메모리 영역의 신규 제공을 기록한다. 가용한 워드 카운트는 관련 LCP 콘텍스트(140)의 일부이다. 어플리케이션이 버퍼내에 수신된 프레임 처리를 완료할때마다, 도어벨에 기록한다. 기록 사이클은 새롭게 이용가능해진 메모리 공간의 워드 개수를 나타낸다. LCP 콘텍스트내의 카운트는 그양만큼 증가한다. 네트워크 구조(30)로부터수신된 패킷은 어댑터(80)에 의해 호스트 메모리내의 연속공간으로 조립될 큰 프레임의 일부가 될 수 있다. ISOC(120)에 의한 수신 프레임 처리는 일반적으로 다음 단계를 포함한다.

a. 패킷의 헤더와 데이터의 분리

RX 링크로직(340)은 네트워크 구조(30)로부터의 정보를 패킷 스트림으로 변환한다. 각각의 수신 패킷은 RX 링크 로직(340)에 의해 처리되어 패킷 헤더를 페이로드 데이터로부터 분리해낸다. 헤더는 제1 레벨 RX 메모리 공간(230)내의 헤더인 FIFO(640)내로 삽입된다. 페이로드는 RX 로직(350)내의 RX 데이터 FIF(650)내로 삽입된다. RX 데이터 FIFO(650)도 제1 레벨 RX 메모리 공간(230)내에 구현될 수 있다.

b. 패킷 헤더 디코딩 및 LCP 프레임 헤더생성

패킷 헤더는 패킷이 속한 프레임의 ID, 페이로드의 크기 및 프레임 데이터의 크기를 나타내느 필드를 제공하기 위해 디코딩된다. 패킷 헤더가 RX 헤더인 FIFO(640)에 읽혀지면, RX 프로세서(160)에 지시자가 전송된다. RX 프로세서는 패킷 헤더 정보를 처리하고 패킷 데이터를 전송하기 위해 필요한 정보를 포함하는 LCP 관련 명령어를 생성한다. 이러한 정보에는 패킷 어드레스 및 길이가 포함된다. 헤더처리의 끝부분에, 설명자 또는 일단의 설명자가 LCP RX 헤더아웃 FIFO(410)에 기록되고, 지시(indication)가 트리거된다.

c. RX LCP 콘텍스트내의 데이터 전송

RX LCP 엔진(360)에 의해 RX 헤더아웃 FIFO(410)로부터 설명자들이 페치된 후에 디코딩된다. 설명자들은 LCP 번호, 패킷 어드레스, 패킷 데이터 길이 및 어댑터(80)의 메모리 서브시스템(210)에 전송될 데이터의 소스 어드레스를 포함한다. RX LCP　엔진(340)은 LCP　콘텍스트 정보를 이용하여 호스트 메모리(60)내에 기록될 목표 물리적 어드레스(또는 페이지가 크로스되는 경우에는 어드레스들)를 생성한다.

d. ISOC DMA 트랜잭션

ISOC(120)는 적합한 버스 명령어들을 선택하고 가능한 긴 버스트(bursts)를 수행함으로써 버스 구조(70)상의 트랜잭션을 최적화시키는 것을 목적으로 한다.

임의의 시점에서, 어댑터(80)는, LCP 채널 X에 대한 버스 할당, LCP 채널 A에 대한 인바운드 데이터 기록 서비스 개시, LCP 채널 B에 대한 DMA 데이터 저장 실행, LCP 채널 C를 목적지로 하는 패킷의 프레임 조립 처리 및 LCP 채널 D에 대한 패킷 수신 동작들중에서 일부 또는 전부를 동시에 수행할 수 있다.

RX 프로세서(160) 및 TX 프로세서(150)상에서의 프레임 처리 오버헤드를 최소화하기 위해, 패킷지원로직(600)은 프레임 프레그멘테이션 로직, CRC 및 체크섬 계산 로직 및 다중캐스트 처리 로직을 포함한다.

TX 및 RX LCP 엔진(310, 360) 및 호스트(10)간의 데이터 흐름이 상세하게 설명될 것이다. TX 및 RX LCP 포트 모두는 메모리 버퍼를 이용하여 이러한 메모리 버퍼를 가리키는 설명자 구조 및 데이터를 전송한다. 데이터 제공자 및 데이터 소비자간의 데이터 버퍼를 관리하고 데이터 제공자에 의해 이용될 빈 메모리 버퍼를 리턴시키기 위해 설명자 구조가 이용된다. 설명자들은 물리적 또는 가상 어드레스상에 기초하여 메모리 버퍼를 가리킨다.

TX LCP 채널들은 호스트 메모리(60)로부터 ISOC(120)의 버퍼들에 데이터를 전송한다. 로직의 다른층들은 ISOC(120)의 버퍼로부터 네트워크(30)로 데이터를 전송한다. RX LCP 채널들은 네트워크(30)로부터 수신된 데이터를 호스트 메모리(60)에 전송한다.

TX 및 RX LCP 엔진(310, 360)은 비교적 많은 수의 LCP 채널들을 처리할 수 있다. 각각의 LCP 채널은 그에 특정된 모든 정보를 포함하는 일단의 파라미터들을 포함한다. 정보는 채널 구성 및 현재 상태를 포함한다. 채널과 연관된 LCP 콘텍스트(140)는 채널의 초기화동안 LCP 관리자(130)에 의해 세팅된다. 채널 동작중에, LCP 콘텍스트(140)의 콘텐트는 ISOC(120)에 의해서만 갱신된다. LCP 콘텍스트(140)는 어댑터(80)의 메모리 서브시스템(210)내의 콘텍스트 테이블에 저장된다. LCP 채널의 LCP 콘텍스트(140)에 대한 액세스는 LCP 번호에 따라 수행된다. LCP RX 및 TX 채널은 상이한 LCP 콘텍스트 구조를 이용한다.

데이터 버퍼는 호스트(10)의 메모리(60)내의 정의된 영역이다. 전송버퍼는 전송용 데이터를 저장한다. TX LCP 엔진(310)은 이들 버퍼내의 데이터를ISOC(120)의 내부 버퍼로 이동시킨다. 네트워크(30)로부터 수신된 인입 데이터는 RX LCP 엔진(360)에 의해 호스트(10)의 메모리(60) 내의 버퍼로 이동된다. 버퍼의 소유권은 호스트(10)의 소프트웨어와 ISOC(120)간에 바뀐다. LCP TX 채널상에서의 이벤트 순서는 다음과 같다.

a. 호스트(10)의 소프트웨어는 호스트(10)의 메모리(60)내에 전송될 데이터를 갖는 버퍼를 준비한다.

b. 소프트웨어는 ISOC(120)에 버퍼내의 데이터가 전송될 준비가 되었음을 통지한다.

c. ISOC(120)는 버퍼로부터 데이터를 판독한다.

d. ISOC(120)는 판독된 버퍼가 새로운 데이터 전송을 위해 호스트(10)내의 소프트웨어에 의해 다시 사용될 수 있음을 호스트(10)의 소프트웨어에 확인해준다.

LCP RX 채널상의 이벤트 순서는 다음과 같다.

a. 호스트(10)내의 소프트웨어는 ISOC(120)가 수신된 데이터를 기록할 수 있는 버퍼를 준비한다.

b. 소프트웨어는 호스트의 메모리(60)내에 빈 버퍼가 준비되어 있음을 ISOC(120)에 통지한다.

c. ISOC(120)는 버퍼에 데이터를 기록한다.

d. ISOC(120)는 수신된 데이터로 가득찬 버퍼가 소프트웨어에 의해 처리될 수 있음을 호스트(10)의 소프트웨어에 확인해준다.

소프트웨어가 ISOC(120)에 의해 이용될 버퍼를 준비하면, 버퍼 정보가 도어벨 레지스터들을 통해 추적된다. ISOC(120)에 의해 이용된 버퍼에 관한 정보는 완료큐를 통해 또는 상태 갱신을 이용하여 소프트웨어에 리턴된다. TX LCP 채널의 경우에, 버퍼는 TX LCP　엔진(310)에 의해 ISOC(120)에 전송되어 네트워크(30)상에 전송하기 위한 하나 이상의 패킷들이 되도록 처리되는 데이터 및 헤더 정보를 포함한다. 헤더는 ISOC(120)의 TX 프로세서(150)에 의해 이용되어 네트워크(30)상에서 전송될 패킷 헤더를 생성한다. RX LCP 채널의 경우에, 빈 버퍼들이 호스트(10)의 소프트웨어에 의해 어댑터(80)에 할당된다. 어댑터(80)는 수신된 패킷으로 데이터를 채운다.

설명자들은 ISOC(120) 및 호스트(10)내의 소프트웨어 모두에 공지되는 데이터 구조를 정의한다. 소프트웨어는 설명자를 이용하여 ISOC(120)에 제어 정보를 전송한다. 제어 정보는 프레임 설명자, 포인터 설명자 또는 소정의 기능에 따라 달라지는 브랜치 설명자의 유형으로 될 수 있다. 소프트웨어 및 ISOC(120)내의 설명자 로직은 수행될 제어 수단에 따라 설명자들을 생성하고 수정할 수 있다. 이러한 수단은 이하에 설명될 것이다. 프레임 설명자는 패킷에 대한 설명(예, 데이터 길이, 헤더 길이등)을 포함한다. 포인터 설명자는 데이터 위치에 대한 설명을 포함한다. 브랜치 설명자는 설명자 위치에 대한 설명(예, 설명자 링크 리스트)을 포함한다. 설명자 내의 정보는 호스트(10)의 소프트웨어가 TX 및 RX LCP 엔진들(310, 360)에 의해 수행되는 데이터 이동 연산들을 제어하기 위해 이용된다. TX 패킷 헤더를 생성하기 위해 프레임을 처리하는데 이용되는 정보는 프레임의 헤더내에 위치한다. 도 9a를 참조하면, 설명자들은 단일 테이블(700)로 테이블(700)의 헤더를가리키는 LCP 콘텍스트(140)과 함께 제공된다. 도 9b를 참조하면, 설명자들은 링크된 설명자 테이블(720-740)의 구조로 구성될 수도 있다. LCP 채널 초기화 이후에, LCP 콘텍스트(140)는 구조내의 제1 설명자 테이블(720)의 헤더를 가리킨다. 브랜치 설명자(750-7700)는 테이블(720-270)의 링크 리스트를 생성하는데 이용되고, 설명자 테이블(720-740) 끝부분의 브랜치 설명자(750-770)는 또다른 테이블(720-740)의 시작을 가리킨다. 다시 도 9a를 참조하면, 브랜치 설명자는 브랜치 테이블(700)의 끝부분의 브랜치 설명자(710)가 동일한 테이블(700)의 시작지점을 가리키는 순환형 버퍼를 생성하는데 이용될 수도 있다. 순환형 버퍼는 수신 경로에서도 이용될 수 있다. 이러한 경우에, LCP(140) 콘텍스트는 버퍼의 헤더를 가리키기 위해 초기화된다. ISOC(120)이 종단지점에 도달하면, 버퍼는 도되돌아 감긴다(wrap around). 호스트(10)의 소프트웨어는 (수신 및 전송 경로 모두에 대하여) 호스트(10)의 메모리(60)에 또는 (전송 경로의 경우에만) 어댑터(80)의 메모리(250)로 설명자를 기록할 수 있다. 설명자를 어댑터(80)의 메모리 서브시스템(210)에 기록하는 것은 호스트(10)의 소프트웨어에 의한 I/O 연산에 관련되며, 어댑터(80)의 메모리 서브시스템(210)을 차지한다. 호스트(80)의 메모리(60)에 설명자를 기록하는 것은 어댑터(80)가 새로운 설명자를 읽어야 할때마다 호스트(10)의 메모리(60)를 액세스할 것을 필요로 한다. 소프트웨어 설명자의 위치는 각각의 LCP 채널에 대해 독립적으로 LCP 관리자(130)에 의해 정의된다. 설명자의 위치는 시스템 성능 최적화에 따라 정의된다. 설명자는 큐의 구성에 있어서 유연성을 제공한다.

RX 및 TX LCP 엔진(310, 360)은 설명자 테이블의 설명자들을 액세스하고 데이터 버퍼를 액세스하기 위해 어드레스를 이용한다. 어드레스는 물리적이거나 가상의 어드레스일 수 있다. 용어 "물리적 어드레스"는 ISCO(120)가 그 자체로서 버스(70)을 통해 도출해낼 수 있는 어드레스를 설명한다. 용어 "가상 어드레스"는 물리적 어드레스를 생성하기 위해 매칭과정을 겪어야 한다. TX 및 RX LCP 엔진(310, 360)에 의해 이용되는 어드레스는, LCP 채널 콘텍스트(140)내의 포인터, 호스트(10)상에서 실행되는 소프트웨어에 의해 준비된 설명자 내의 포인터, RX 프로세서(160)에 의해 준비된 설명자 내의 포인터, (완료큐에 리턴하기 위해 이용되는) TX 프로세서(150)에 의해 준비된 설명자 내의 포인터와 같이 다양한 소스를 갖는다. 포인터는 설명자 또는 데이터 버퍼를 가리킬 수 있다. TX 및 RX LCP 엔진(310, 360)에 의해 이용되는 모든 어드레스들은 버스(70)상의 물리적 어드레스로서 이용되는 새로운 어드레스로 선택적 매핑될 수 있다. 어드레스 매핑은 TX 및 RX LCP 엔진(310, 360)에 의해 수행된다. ISOC(120)는 변환테이블을 저장하기 위해 로컬 메모리(210)를 이용한다. LCP 관리자(130)는 메모리 등록동안 어댑터(80)에 변환 테이블을 기록한다. 어드레스 매핑은 버퍼 또는 설명자 테이블들을 위해 가상 어드레싱이 사용될 수 있도록 해준다. 가상 어드레싱은 물리적으로는 하나 이상의 물리적 페이지에 위치한 가상 버퍼들의 관리를 가능하게 해준다. 또한, 어드레스 매핑은 호스트(10)가 소프트웨어를 위한 변환 프로세서 필요없이 가상 어드레스를 이용하여 어플리케이션들과 직접 작업할 수 있도록 해준다.

도 10을 참조하면, 호스트(10)의 소프트웨어에게 보이는 버퍼(880)의이미지(800)가 도시되어 있다. 또한, 호스트(10)의 메모리(60)를 액세스하기 위해 이용되는 어드레스의 물리적 매핑(810)이 도시되어 있다. 가상 포인터(820)는 버퍼내의 위치를 가리킨다. 상기 예에서의 버퍼는 호스트(10)의 메모리내에 소수의 비연속적인 페이지(840-870)를 차지하는 가상 버퍼이다. LCP 엔진(310, 360)은 변환 테이블(830)을 통해 어드레스를 변환함으로써 매핑을 수행한다. 변환 테이블은 가상 버퍼(88)로부터 매핑되는 각각의 물리적 버퍼(840-870)의 헤더에 대한 물리적 어드레스 포인터를 저장한다. 어댑터(80)의 어드레스 매핑은 호스트(10)의 메모리(60)의 설명자 및 데이터 버퍼를 매핑시킬때 유연성을 허용한다. 또한, 어댑터(80)의 어드레스 매핑은 호스트(10)의 소프트웨어가 물리적 어드레스로의 어드레스 변환을 수행할 것을 필요로 하지 않고 가상 어드레스를 이용하는 소프트웨어 버퍼에 대한 직접 접속을 허용한다.

어댑터(80)가 호스트의 메모리(60)에 기록하는 각각의 패킷은 그와 연관된 상태를 갖고 있다. 그 상태는 어댑터(80)와 호스트(10)의 소프트웨어간의 동기화를 가능하게 한다. 상태는 패킷들의 상이한 신뢰성 레벨을 표시하게 위해 이용될 수 있다. ISCO(120)는 다음의 상태 재기록(write back)을 제공한다. 전송 DMA 완료(Transmit DMA Completion)는 TX 패킷내의 데이터가 어댑터(80)로 판독되었음을 나타낸다. 네트워크(30)내의 데이터 전송 완료를 나타내기 위해 신뢰 전송(Reliable Transmission)이 리턴된다. 수신 DMA 완료(Receive DMA Completion)는 메모리(60)로 수신 데이터 전송이 완료됨을 나타낸다. 신뢰 수신(Reliable Reception)은 네트워크(30)내에 목적지 노드에 의해 전송 패킷이 수신되었음을 나타낸다.

TX 프레임 설명자는 2 바이트의 상태 필드를 포함한다. 상태 재기록은 트랜잭션 상태가 설명자에 다시 기록됨을 의미한다. 상태는 호스트(10)의 소프트웨어에 의해 폴링될 수 있는 완료 비트를 포함한다. 호스트(10)의 소프트웨어가 일단의 완료 비트를 찾으면, 프레임 설명자에 의해 정의된 프레임과 연관된 버퍼를 재사용할 수 있다.

완료큐는 RX LCP 채널에 의해 구현된다. 완료 큐에 의해 이용되는 LCP 채널은 임의의 RX LCP 채널에 의해 구현될 수 있는 모든 유연성 및 속성을 갖는다. TX 및 RX 프로세서(150, 160)는, 신뢰적인 전송, 신뢰적인 수신, 수신 DMA 완료, 또는 전송 DMA 완료를 나타내기 위해 상태 재기록을 발생시킨다. 프레임들에 관한 상이한 표시들이 상이한 경우에 이용된다. 예를 들어, 신뢰적인 전송의 경우에, TX 프로세서(150)는 패킷 전송의 상태를 나타내는 내부 레지스터들을 판독한다. 신뢰적인 수신의 경우에, RX 프로세서(160)는 승인을 포함하는 수신 패킷으로서 완료 표시자를 얻는다. 수신 DMA 완료의 경우에, RX 프로세서(160)는 프레임 완료 정보를 사용한다. 전송 DAM 완료의 경우에, TX 프로세서(150)는 어댑터(80)내의 전송을 위한 프레임 수신을 나타낸다. 완료큐는 단일의 TX 또는 RX LCP 채널에 의해 이용될 수 있거나 다수의 채널들에 의해 공유될 수 있다. 어댑터(80)내의 마이크로코드는 프레임 설명자를 RX LCP 엔진(360)의 명령큐에 전함으로써 상태 큐를 갱신한다. 도 11을 참조하면, 완료큐(920)를 포함하는 완료상태 LCP(900)을 통해 호스트(10)의 메모리(60)로 상태가 전달된다. 완료큐(900)는 (물리적 또는 가상적으로) 연속적이며 호스트(10)의 메모리(60)에 위치한다. 예를 들어, 완료큐는 연속적인 버퍼내에 유지될 수 있다. 완료큐내의 엔트리(930)들은 바람직하게는 고정된 크기를 갖는다. 각각의 엔트리는 수신기 LCP(910)와 연관된 버퍼(950)의 헤더에 대한 포인터(940)를 저장한다. 버퍼(950)는 완료상태와 연관된 패킷(960)들로 채워진다.

TX 소프트웨어/어댑터 핸드쉐이크는 TX LCP 포트와 완료 RX LCP 포트를 포함한다. 각각의 LCP 전송 채널은 다음의 데이터 구조를 이용한다.

도어벨 엔트리. 이는 메모리 매핑 어드레스로 구현되며, 어댑터80)에 설명자 및 데이터를 처리하기 위한 증가 요청을 알린다. 각각의 프로세스는 도어벨 액세스에 대해 이용되는 단일 페이지의 메모리 매핑 어드레스로의 유일한 액세스를 갖는다.

어댑터 메모리 공간(210)내의 LCP 콘텍스트 엔트리. 이는 LCP 속성과 상태 필드를 포함한다.

전송 설명자 구조. 이러한 구조는 호스트(10)의 메모리(60)내의 다수의 물리적 페이지에 걸쳐 있을 수 있다. 설명자에 대해 가상 어드레싱이 이용되는 경우에, 하나의 페이지로부터 다른 페이지로 이동하기 위해 변환 테이블이 이용된다. 설명자에 대해 물리적 어드레싱이 이용되는 경우에, 하나의 메이지로부터 다른 페이지로 이동하기 위해 브랜치 설명자가 이용된다. 전송 설명자는 어댑터(80)에 모든 설명자 관련 데이터를 전송한 이후에 갱신될 수 있는 상태 필드를 포함한다.

포인터 설명자에 의해 가리켜지는 호스트(10)의 메모리(60)내에 지정된 전송데이터 버퍼. 이러한 데이터 버퍼들을 위해 가상 어드레싱이 이용되는 경우에, 변환 테이블이 포인터를 호스트(10)의 메모리(60)에 액세스하기 위해 어댑터(80)에 의해 이용되는 물리적 어드레스로 변환시킨다.

어드레스 매핑에 이용되는 어댑터 메모리 공간(210)내의 변환 테이블 및 보호 블록들.

이제 도 12를 참조하면, 전송 패킷 흐름은 단계(1000)에서 호스트(10)의 소프트웨어(1020)가 전송될 데이터를 버퍼(1030)에 채우는 것을 포함한다. 단계(1010)에서, 소프트웨어(1020)는 설명자(1040)를 갱신한다. 설명자(1040)는 호스트(10)의 메모리(60)내에 있거나 어댑터(80)의 메모리 서브시스템(210)내에 있을 수 있다. 단계(1050)에서, 소프트웨어(1020)는 도어벨을 울려 어댑터(80)에 새로운 데이터가 전송될 준비가 되었음을 통지한다. 단계(1060)에서, 어댑터(80)는 상이한 LCP 채널들로부터의 요청들간에 중재를 관리한다. 하나의 채널이 중재에서 이기면, 어댑터(80)는 새로운 설명자(1040)를 판독한다. 단계(1070)에서, 어댑터(80)는 데이터를 판독한다. 단계(1080)에서, 데이터가 네트워크(30)로 전송된다. 단계(1090)에서, 설명자(1040) 또는 완료 큐 내의 상태가 갱신된다.

TX LCP 채널은 데이터 버퍼를 어드레싱할 때 어드레스 변환을 이용할 수 있다. 이러한 경우에, 데이터 버퍼는 다수의 메모리 페이지들로 구성된다. 프로세스에 관한 한, 이들 메모리 페이지는 연속적인 가상 메모리 공간내에 있다. 그러나, 어댑터(80)에 관한 한, 이들 메모리 페이지는 비연속적인 물리적 메모리 공간내에 있을 수 있다. 완료상태구조는 전송 프레임의 상태를 나타내는 정보를 포함한다. 이는 별도의 LCP 채널로서 구현된다. 프레임 설명자는, 모든 프레임에 대한 제1 설명자이며, 프레임이 어댑터(80)으로 전송된 후에 갱신될 수 있는 선택적 상태 필드를 포함한다.

이제 도 13을 참조하면, 전송 LCP 채널 흐름의 예에서, 설명자(1100)는 호스트(10)의 메모리(60)내에 위치한다. 설명자(1100) 및 패킷(1120)을 저장하는 버퍼(1110)에 대한 액세스는 어댑터(80)에 위치한 변환 테이블을 통한 어드레스 변환을 필요로 한다. 버퍼(1110)는 호스트(10)의 소프트웨어의 가상 어드레스 공간에 연속적인 공간을 이용한다. 각각의 프레임(1120)은 2개 유형의 설명자, 패킷에 관한 정보를 제공하는 프레임 설명자(1140)와 데이터를 저장하는 버퍼(1110)를 가리키는 포인터 설명자(1150에 의해 기술된다. 각 패킷은 동일한 버퍼(1180) 내에 헤더(1160)가 앞서는 데이터 페이로드(1170)를 포함한다.

도어벨에 대한 기록 트랜잭션(1190)은 어댑터(80)에 의해 이용될 수 있는 워드(1200) 개수를 갱신한다. 이러한 정보는 LCP 콘텍스트(140)내에 저장된다. 전송 LCP 콘텍스트(140)는 전송될 데이터를 저장하는 버퍼(1110)의 헤더에 대한 포인터(1210)를 포함한다. LCP 채널이 ISOC(120)의 내부 채널 중재에서 승리하면, ISOC(120)는 LCP 콘텍스트(140)의 포인터(1210)에 따라 LCP 채널의 설명자를 판독한다. LCP 채널에 대한 설명자(1100) 및 버퍼(1110) 모두에 대한 가상 어드레스는 어댑터(80)의 메모리 서브시스템(210)에 위치한 변환테이블(1130)을 이용하여 물리적 어드레스로 변환된다. 변환테이블(1130)은 메모리 버퍼의 등록동안 LCP 관리자(140)에 의해 갱신된다. ISOC(120)는 버퍼(1110)로부터 어댑터(80)로 데이터및 프레임 헤더를 판독한다. 그런 후에, 프레임 헤더(1160)는 네트워크(30)에 대한 헤더에 의해 ISOC(1320)상에서 교체된다. 패킷 헤더 및 대응 데이터는 네트워크(30)로 전송된다.

RX LCP 포트는 ISOC(120)로부터 호스트(10)상에서 실행되는 소프트웨어 어플리케이션에 의해 이용되는 메모리(60)로 인입 데이터를 전송하는데 이용된다. TX LCP 채널은 호스트(10)상의 소프트웨어에 의해 개시되는 설명자들을 통해 완전 제어된다. RX LCP 채널은 호스트(10)상의 소프트웨어 및 ISOC(120) 모두로부터 설명자를 이용한다. ISOC(120)에 의해 개시되는 설명자는 호스트(10)의 메모리(60)내의 수신 프레임 목적지를 정의하기 위해 LCP　채널 동작을 제어하는데 이용된다. 호스트(10)의 소프트웨어에 의해 개시되는 설명자들은 버퍼가 변환 테이블의 매핑을 통해 정의되지 않은 경우에 버퍼의 위치를 정의하기 위해 이용될 수 있다. 호스트(10)의 소프트웨어와 어댑터(80)간의 핸드쉐이크를 구현하기 위해 2개의 LCP 채널들이 바람직하게 이용된다. 그 중 하나는 수신된 인입 데이터 구조를 다루기 위한 RX LCP 채널이고, 다른 하나는 완료 상태큐를 다루기 위한 RX LCP 채널이다. 완료상태는 호스트(10)의 메모리(60)로 프레임 전송이 완료됨을 호스트(10)의 소프트웨어에게 알리기 위해 어댑터(80)에 의해 이용된다. 엔트리들은 순차적 어드레스의 완료큐 구조에 삽입된다. 각각의 완료 상태 엔트리는 어댑터(80)에 의해 표시되고 엔트리의 소유권이 어댑터(80)로부터 호스트(10)의 소프트웨어로 이전되었는지를 검사하기 위해 호스트(10)의 소프트웨어에 폴링되는 필드를 포함한다. 하나 이상의 RX LCP 채널들이 동일한 완료상태큐를 이용할 수 있다. 다수의 RX LCP채널들에 의해 완료상태 큐를 공유하는 것은 ISOC(120)에 의해 수행된다.

RX LCP 채널들은 인입 패킷을 위한 목적지 어드레스를 가리키는 정보를 필요로 한다. ISOC(120)는 비어있는 버퍼의 위치를 찾기 위해, 직접 어드레싱 모드 및 간접 어드레싱 모드의 2가지 어드레싱을 갖는다. 직접 어드레싱 모드는 버퍼를 가리키기 위해 포인터 설명자를 이용하지 않는 LCP 채널들을 의미한다. 목적지 어드레스는 ISOC(120)내에 있거나 콘텍스트(140)로부터 판독된 마이크로코드에 의해 정의된다. 간접 어드레싱 모드는 설명자 구조내에 데이터 버퍼에 대한 포인터를 유지하는 LCP 채널을 의미한다. 바람직하게는, 설명자들은 호스트(10)의 메모리(60)내에 위치한다.

직접 어드레싱은 어댑터(80)를 통한 인입 패킷의 처리 지연을 실질적으로 단축시킨다. 그러나, 이는 어댑터(80)상에서 가상-실제 변환정보의 저장을 포함하는, LCP 관리자(130)에 의한 메모리 버퍼 등록을 필요로 한다. 호스트(10)내의 소프트웨어는 채널에 의해 이용될 수 있는 자유 버퍼에 추가되는 워드량을 표시하기 위해 채널들에 도어벨을 기록한다. 직접 모드에서, 목적지 버퍼의 어드레스를 판단하기 위해, 이하의 단계들이 이용된다.

a. 어드레스 A는 LCP 엔진에 대한 명령으로서 도출된다.

b. (선택적) 어드레스 A는 어드레스 A'로 매핑된다.

c. (단계 b가 실행되는 경우) 어드레스 A' 또는 (단계 b가 실행되지 않는 경우) A는 목적지 버퍼에 대한 기본 어드레스이다.

간접모드에서, 어댑터(80)는 데이터 버퍼의 어드레스를 찾기 위해 설명자를이용한다. 설명자는 호스트(10)의 소프트웨어에 의해 관리된다. 바람직하게는, 설명자들이 호스트(10)의 메모리(60)내에 위치한다. 용어 "간접"은 어댑터(80)가 목적지 어드레스를 정의하기 위해 부가적인 정보를 판독함을 강조하기 위해 사용된다. 어댑터(80)는 실행시간중에 이러한 정보를 액세스한다. 간접 어드레싱은 변환 테이블을 저장하기 위해 필요한 어댑터(80)내의 메모리량을 감소시킨다. 설명자는 일반적으로 호스트(10)의 메모리(60)내에 위치한다. 간접모드에서, 다음의 단계들이 목적지 버퍼의 어드레스를 판단하기 위해 이용된다.

a. 어드레스 A가 LCP 엔진에 대한 명령으로서 도출된다.

b.(선택적) 어드레스 A가 어드레스 A'로 매핑된다.

c. (단계 b가 실행되는 경우) 어드레스 A' 또는 (단계 b가 실행되지 않는 경우) 어드레스 A는 포인터 설명자의 어드레스이다.

d. 버퍼에 대한 포인터, 어드레스 B가 설명자로부터 판독된다.

e.(선택적) 어드레스 B가 어드레스 B'로 매핑된다.

f. (단계 e가 실행되는 경우) 어드레스 B' 또는 (단계 e가 실행되지 않는 경우) 어드레스 B는 목적지 버퍼의 기본 어드레스이다.

각각의 RX LCP 채널은 다음의 데이터 구조를 이용한다.

메모리 매핑된 어드레스로서 구현되는 도어벨에 대한 액세스는 어댑터(80)에 패킷 데이터를 기록하는데 가용한 부가적인 데이터 또는 설명자를 알린다.

어댑터(80)의 메모리공간(210)내의 LCP 콘텍스트 엔트리는 LCP 속성, 상태, 구성 및 상태 필드를 포함한다.

간접모드에서 사용되는 메모리 버퍼들을 가리키는 설명자.

호스트(10)의 메모리(60)내의 계속적인 가상 어드레스 공간내의 버퍼.

어드레스 매핑을 위해 어댑터(80)의 메모리 공간(210)내의 변환 테이블 및 보호 블

패킷 수신 흐름은 다음의 특성에 따라 달라진다.

직접/간접 어드레싱 모드

간접 모드의 경우, 설명자는 호스트(10)의 메모리(60)내에 위치한다.

직접 모드의 경우, 설명자에 대한 액세스중에 어드레스 매핑이 이용되거나 이용되지 않을 수 있다.

버퍼에 대한 액세스중에 어드레스 매핑이 이용되거나 이용되지 않을 수 있다.

간접 모드의 경우, 설명자에 대한 액세스중에 어드레스 보호가 이용되거나 이용되지 않을 수 있다.

버퍼에 대한 액세스중에 어드레스 보호가 이용되거나 이용되지 않을 수 있다.

이러한 특성들은 LCP 채널 초기화동안에 채널의 콘텍스트(140)의 일부로서 각각의 LCP 채널에 대해 설정된다.

도 14를 참조하면, 수신 패킷의 흐름은, 단계(1300)에서, 호스트(10)의 소프트웨어(1310)는 수신된 데이터를 위해 빈 버퍼(1320)를 준비한다. 단계(1330)에서, 간접모드의 경우에, 호스트(10)의 소프트웨어(1310)는 설명자(1340)를 갱신한다. 설명자(1340)는 호스트(10)의 메모리(60)내에 위치한다. 단계(1350)에서, 호스트(10)의 소프트웨어는 도어벨을 울려서 어댑터(80)에 비어있는 버퍼 공간을 알린다. 간접 모드의 경우에, 도어벨은 새로운 설명자(1340)를 나타내는 정보를 제공한다. 직접 모드의 경우에, 도어벨은 추가된 빈 버퍼 공간을 나타내는 정보를 제공한다. 이 단계에서, 어댑터(80)는 네트워크(30)로부터 호스트(10)의 메모리(60)에 수신 데이터를 전송할 준비가 된다. 단계(1300, 1330, 1350)는 호스트(10)의 소프트웨어(1310)가 RX LCP 채널에 빈(자유) 버퍼(1320)를 추가할때마다 반복된다. ISOC(120)는 각각의 수신 패킷에 대해 다음의 단계들을 반복한다. 단계(1360)에서, 어댑터(80)는 데이터를 수신한다. 단계(1370)에서, 간접 모드의 경우에, 어댑터(80)는 자유 데이터 버퍼의 위치를 가리키는 설명자(1340)를 판독한다. 단계(1380)에서, 데이터 및 헤더는 데이터 버퍼(1340)에 기록된다. 단계(1390)에서, 완료큐의 상태가 갱신된다.

도 15를 참조하면, 수신 LCP 채널 흐름의 예에서, 포인터 설명자들은 이용되지 않는다. 또한, 어떠한 변환 테이블도 이용되지 않는다. 데이터 버퍼(1400)는 버퍼(1400)를 이용하는 호스트(10)의 소프트웨어의 물리적 어드레스 공간 내의 연속공간을 이용한다. 헤더 및 데이터 페이로드가 데이터버퍼(1400)에 기록된다. 도어벨에 대한 기록 트랜잭션(1410)은 어댑터(80)에 의해 이용가능한 데이터 공간을 갱신한다. 정보는 LCP 콘텍스트(140)내에 저장된다. 수신/완료 LCP콘텍스트(140)는 버퍼(1400)의 헤더를 가리키는 포인터(1420)와 새로운 데이터/완료 엔트리를 기입하기 위해 이용되는 다음/현재 어드레스에 대한 오프셋(1430)을 포함한다. 어댑터(80)가 패킷을 수신하면, 다음 패킷 위치에 대한 오프셋(1430)을 증가시키고 가용한 데이터 공간을 갱신한다. 프레임 수신 완료 이후, 프레임 타임아웃 이후 또는 LCP 클라이언트로부터의 자각(awareness)을 필요로 하는 임의의 다른 프레임 이벤트에 대해, 완료 LCP(1450)에 완료 엔트리(1440)가 추가된다. 완료 엔트리(1440)는 LCP 데이터 버퍼(1400)내의 프레임을 찾기 위해 LCP 클라이언트(100)에 의해 필요한 모든 정보를 포함한다. 호스트(10)의 소프트웨어는 완료 엔트리(1440) 내의 필드를 이용하여 완료 엔트리(1440)의 소유권이 승인되었음을 인식한다.

ISOC(120)는 LCP 채널이 어댑터(80)의 메모리 서브시스템(210)과 호스트(10)의 메모리(60)간의 데이터 이동을 위해 이용될 수 있도록 허용한다. 호스트(10)의 메모리(60)로부터 어댑터(80)에 데이터를 전송하기 위해, 전송 채널이 이용된다. 어댑터(80)로부터 호스트(10)의 메모리(60)에 데이터를 전송하기 위해, 수신 채널이 이용된다. 호스트(10)의 메모리(60)로부터 어댑터(80)에 데이터가 전송되려고 할때, 프레임 설명자는 ISOC(120)의 버스(340)상에 목적지 어드레스를 포함한다. 이러한 어드레스는 프레임 데이터 페이로드의 목적지를 정의한다. 패킷 헤더는 보통의 방식으로 전송된다. 이는 테이블 및 코드를 ISOC(120)의 메모리 공간으로 로딩하는 것을 허용한다. 수신채널을 이용하여 ISOC(120)의 메모리 공간으로부터 호스트(10)의 메모리(60)에 데이터를 전송하기 위해, RX 프로세서(160)에 의해 설명자가 개시된다. 설명자는 호스트(10)의 메모리(60)내의 목적지 어드레스 및 소스 어드레스 모두를 나타내는 정보를 포함한다.

이제까지 설명한 본 발명의 바람직한 실시예에서, 어댑터(80)는 버스 구조(70)를 통해 호스트 컴퓨터 시스템(10)의 CPU(50) 및 메모리(60)에 접속된다. 그러한, 본 발명의 다른 실시예에서는, 어댑터(80)가 버스 구조(70)와 무관하게 호스트 컴퓨터 시스템(10)으로 통합될 수도 있다. 예를 들어, 본 발명의 다른 실시예에서는, 어댑터(80)가 호스트 메모리(60)에 연결되는 메모리 제어기를 통해 호스트 컴퓨터 시스템으로 통합될 수 있다.

또한, 이제까지 설명한 본 발명의 바람직한 실시예에서, 어댑터(80)는 호스트 컴퓨터 시스템(10)으로 삽입되는 플러그형 어댑터 카드 형태로 구현되었다. 그러나, 다른 실시예에서는 어댑터(80)의 상이한 구현들이 가능함을 이해할 것이다. 예를 들어, 어댑터(80)는 CPU(50) 및 메모리(60)와 함께 호스트 컴퓨터 시스템의 마더보드에 위치할 수도 있다.

Claims

메모리를 통해 제1 및 제2 데이터 처리 시스템간의 데이터 흐름을 제어하기 위한 장치에 있어서,

상기 메모리 내의 위치와 제2 데이터 처리 시스템 간에 통신될 데이터 패킷을 정의하는 프레임 설명자와 상기 메모리 내의 위치를 식별해주는 포인터 설명자를 포함하는 다수의 설명자를 생성하기 위한 설명자 로직과,

상기 제1 및 제2 데이터 처리 시스템에 의해 액세스될 수 있도록 상기 설명자 로직에 의해 생성된 설명자들을 저장하기 위한 설명자 테이블

을 포함하는 장치.
제1항에 있어서, 상기 설명자 테이블은 상기 제1 데이터 처리 시스템내에 저장되는 장치.
제1항에 있어서, 상기 설명자 테이블은 상기 제2 데이터 처리 시스템 내에 저장되는 장치.
전술한 항들중 어느 한 항에 있어서, 상기 설명자 로직은 상기 설명자 테이블 내의 또다른 설명자로의 링크를 포함하는 브랜치 설명자를 생성하는 장치.
제4항에 있어서, 상기 설명자 테이블은 내부의 브랜치 설명자를 통해 함께 순차적으로 연결되는 다수의 설명자 리스트를 포함하는 장치.
제4항에 있어서, 상기 설명자 테이블은 순환형(cyclic) 설명자 리스트를 포함하는 장치.
전술한 항들중 어느 한 항에 있어서, 상기 제1 데이터처리시스템은 호스트 컴퓨터 시스템을 포함하는 장치.
전술한 항들중 어느 한 항에 있어서, 상기 제2 데이터처리시스템은 상기 호스트 컴퓨터 시스템과 데이터 통신망사이의 데이터 통신을 위한 데이터 통신 인터페이스를 포함하는 장치.
메모리를 구비한 호스트 컴퓨터 시스템과, 상기 호스트 컴퓨터 시스템과 데이터 통신망사이의 데이터 통신을 위한 데이터 통신 인터페이스와, 상기 호스트 컴퓨터 시스템의 메모리와 상기 데이터 통신 인터페이스간의 데이터 흐름을 제어하기 위한 전술한 항들중 어느 한 항에 따른 장치를 포함하는 데이터 처리 시스템.
메모리를 통해 제1 및 제2 데이터처리시스템간의 데이터 흐름을 제어하기 위한 방법에 있어서, 상기 방법은

설명자 로직에 의해, 상기 메모리 내의 위치와 상기 제2 데이터 처리 시스템간에 통신되는 데이터 패킷을 정의하는 프레임 설명자와 상기 메모리 내의 위치를 식별해주는 포인터 설명자를 포함하는 다수의 설명자들을 생성하는 단계와,

상기 설명자 로직에 의해 생성된 상기 설명자들을 상기 제1 및 제2 데이터 처리 시스템들에 의해 액세스될 수 있는 설명자 테이블에 저장하는 단계

를 포함하는 방법.
제10항에 있어서, 상기 설명자 테이블을 상기 제1 데이터 처리시스템에 저장하는 단계를 포함하는 방법.
제10항에 있어서, 상기 설명자 테이블을 상기 제2 데이터처리시스템에 저장하는 단계를 포함하는 방법.
제10항 내지 제12항중 어느 한 항에 있어서, 상기 설명자 로직에 의해, 상기 설명자 테이블 내의 또다른 설명자에 대한 링크를 포함하는 브랜치 설명자를 생성하는 단계를 포함하는 방법.
제10항 내지 제12항중 어느 한 항에 있어서, 내부의 브랜치 설명자를 통해 다수의 설명자 리스트를 일렬로 연결함으로써 설명자 테이블을 형성하는 단계를 포함하는 방법.
제10항 내지 제14항중 어느 한 항에 있어서, 상기 제1 데이터처리시스템은 호스트 컴퓨터 시스템을 포함하는 방법.
제10항 내지 제15항중 어느 한 항에 있어서, 상기 제2 데이터처리시스템은 상기 호스트 컴퓨터 시스템과 데이터 통신망사이의 데이터 통신을 위한 데이터 통신 인터페이스를 포함하는 방법.