물리적 네트워크 어댑터에 하드웨어 오프로드 OID 요청 관리
이 항목에서는 Hyper-V 확장 가능 스위치 전달 확장이 확장 가능한 스위치 제어 경로를 통해 기본 물리적 어댑터의 하드웨어 오프로드 기술에 대한 OID(개체 식별자) 요청을 관리하는 방법에 대해 설명합니다.
예를 들어 외부 네트워크 어댑터는 MUX(NDIS 멀티플렉서) 중간 드라이버의 가상 미니포트 에지에 바인딩할 수 있습니다. MUX 드라이버는 호스트에 있는 하나 이상의 물리적 네트워크 팀에 바인딩됩니다. 이 구성을 확장 가능한 스위치 팀이라고 합니다.
이 구성에서는 확장 가능한 스위치 확장이 팀의 모든 네트워크 어댑터에 노출됩니다. 이렇게 하면 확장에서 팀의 개별 네트워크 어댑터 구성 및 사용을 관리할 수 있습니다. 예를 들어 전달 확장은 나가는 패킷을 개별 어댑터에 전달하여 팀을 통해 LBFO(부하 분산 장애 조치( failover) 솔루션을 지원할 수 있습니다. 확장 가능한 스위치 팀을 관리하는 전달 확장을 팀 공급자라고 합니다. 팀 공급자에 대한 자세한 내용은 팀 공급자 확장을 참조 하세요.
다음 그림에서는 NDIS 6.40(Windows Server 2012 R2) 이상용 확장 가능한 스위치 팀의 예를 보여 줍니다.
다음 그림에서는 NDIS 6.30(Windows Server 2012)에 대한 확장 가능한 스위치 팀의 예를 보여 줍니다.
참고 확장 가능한 스위치 인터페이스에서 NDIS 필터 드라이버를 확장 가능한 스위치 확장 이라고 하며 드라이버 스택을 확장 가능한 스위치 드라이버 스택이라고 합니다.
OID_SWITCH_NIC_REQUEST OID 요청을 처리하면 전달 확장이 하드웨어 오프로드에 대한 확장 가능한 스위치 팀의 구성에 참여할 수 있습니다. 예를 들어 확장이 확장 가능한 스위치 팀의 물리적 네트워크 어댑터를 관리하는 경우 OID_SWITCH_NIC_REQUEST 요청을 하드웨어 오프로드를 지원하는 물리적 어댑터로 전달할 수 있습니다.
NDIS 및 지나치게 많은 프로토콜 및 필터 드라이버는 하드웨어 오프로드 기술에 대한 OID 요청을 기본 물리적 네트워크 어댑터에 발급할 수 있습니다. 이러한 OID 요청이 확장 가능한 스위치 인터페이스에 도착하면 NDIS_SWITCH_NIC_OID_REQUEST 내에서 OID 요청을 캡슐화합니다. 그런 다음 확장 가능한 스위치의 프로토콜 에지가 이 구조를 포함하는 OID_SWITCH_NIC_REQUEST OID 요청을 실행합니다.
확장 가능한 스위치 인터페이스는 다음과 같은 하드웨어 오프로드 기술에 대한 OID를 캡슐화합니다.
IPsec(인터넷 프로토콜 보안) 오프로드(버전 2)
다음 IPsec OID 요청이 캡슐화됩니다.
전달 확장은 이러한 OID 요청에 실패하거나 거부해서는 안 됩니다.
IPsec 하드웨어 오프로드 기술의 버전 2에 대한 자세한 내용은 IPsec 오프로드 버전 2를 참조하세요.
단일 루트 I/O 가상화(SR-IOV)
다음 SR-IOV OID 요청은 캡슐화됩니다.
전달 확장은 NDIS_STATUS_SUCCESS 이외의 상태 코드로 요청을 완료하여 OID_NIC_SWITCH_ALLOCATE_VF 및 OID_NIC_SWITCH_CREATE_VPORT OID 요청을 거부할 수 있습니다. 그러나 확장은 다른 SR-IOV OID 요청을 거부해서는 안 됩니다.
SR-IOV 하드웨어 오프로드 기술에 대한 자세한 내용은 SR-IOV(단일 루트 I/O 가상화)를 참조하세요.
가상화된 머신 큐(VMQ)
다음 VMQ OID 요청이 캡슐화됩니다.
전달 확장은 NDIS_STATUS_SUCCESS 이외의 상태 코드로 요청을 완료하여 OID_RECEIVE_FILTER_ALLOCATE_QUEUE 및 OID_RECEIVE_FILTER_SET_FILTER OID 요청을 거부할 수 있습니다. 그러나 확장은 다른 VMQ OID 요청을 거부해서는 안 됩니다.
VMQ 하드웨어 오프로드 기술에 대한 자세한 내용은 VMQ(Virtual Machine Queue)를 참조하세요.
전달 확장은 하드웨어 오프로드 OID 요청을 처리하기 위해 다음 지침을 따라야 합니다.
Microsoft IM 플랫폼은 전체 팀의 일반적인 오프로드 기능만 보급합니다. 그러나 확장은 팀의 각 어댑터 기능을 쿼리하는 OID 요청을 생성할 수 있습니다.
확장에서 팀의 물리적 어댑터의 하드웨어 기능을 결정하면 하드웨어 오프로드에 대한 OID 집합 요청을 오프로드에 가장 적합한 어댑터로 전달할 수 있습니다.
프로토콜 또는 필터 드라이버를 과도하게 사용하여 시작된 모든 하드웨어 오프로드 OID 요청은 NDIS_SWITCH_NIC_OID_REQUEST 구조 내에서 캡슐화됩니다. 전달 확장에서 시작된 모든 하드웨어 오프로드 OID 요청도 NDIS_SWITCH_NIC_OID_REQUEST 구조에 캡슐화되어야 합니다.
확장은 OID_SWITCH_NIC_REQUEST OID 집합 요청을 통해 캡슐화된 OID 요청을 기본 실제 네트워크 어댑터로 전달합니다. 이 절차에 대한 자세한 내용은 물리적 네트워크 어댑터에 OID 요청 전달을 참조하세요.
확장은 오프로드 리소스 할당을 지우거나, 해제하거나, 완료하기 위해 하드웨어 오프로드 OID 요청을 수정하거나 실패해서는 안 됩니다. 예를 들어 확장은 OID_RECEIVE_FILTER_CLEAR_FILTER 또는OID_NIC_SWITCH_DELETE_VPORT OID 요청을 실패하지 않아야 합니다. 확장 가능한 스위치 인터페이스는 이러한 리소스에 대한 상태 정보를 클린 위해 이러한 OID 요청을 처리해야 합니다.
확장은 하드웨어 오프로드 OID 요청을 수정하거나 실패하여 리소스를 할당, 이동 또는 설정할 수 있습니다. 예를 들어 확장은 OID_NIC_SWITCH_ALLOCATE_VF 또는OID_TCP_TASK_IPSEC_OFFLOAD_V2_ADD_SA OID 요청을 실패하거나 수정할 수 있습니다.
이 확장은 모든 하드웨어 오프로드 OID를 기본 물리적 네트워크 어댑터로 오프로드할 수 있습니다. 그러나 확장은 확장이 할당하지 않은 오프로드 리소스를 지우거나 해제하는 하드웨어 오프로드 OID를 시작해서는 안 됩니다.
예를 들어 확장은 동일한 큐에 대한 OID_RECEIVE_FILTER_ALLOCATE_QUEUE 요청을 시작하지 않은 경우 OID_RECEIVE_FILTER_FREE_QUEUE 하드웨어 오프로드 OID 요청을 시작 해서는 안 됩니다.
참고 확장은 지나치게 드라이버에서 발급한 것과 동일한 OID 요청을 필터링하는 경우에만 자체 캡슐화된 하드웨어 오프로드 OID 요청을 발생시킬 수 있습니다. 이 경우 확장은 원래 OID 요청을 전달해서는 안됩니다. 대신 NDIS가 FilterOidRequestComplete를 호출하여 원래 OID 요청을 완료할 때 확장이 NdisFOidRequestComplete를 호출하여 이 요청을 완료해야 합니다.
확장이 하드웨어 오프로드 OID 요청을 기본 물리적 네트워크 어댑터로 전달하는 경우 NDIS_SWITCH_NIC_OID_REQUEST 구조의 DestinationNicIndex 멤버를 어댑터의 0이 아닌 인덱스 값으로 설정해야 합니다. 이러한 인덱스 값에 대한 자세한 내용은 네트워크 어댑터 인덱스 값을 참조하세요.
또한 DestinationPortId 멤버는 외부 네트워크 어댑터가 연결된 확장 가능한 스위치 포트의 식별자로 설정해야 합니다.
확장이 Hyper-V 자식 파티션에 대한 리소스를 할당하기 위한 하드웨어 오프로드 OID 요청을 시작하는 경우 NDIS_SWITCH_NIC_OID_REQUEST 구조의 SourcePortId 멤버를 파티션이 연결된 확장 가능한 스위치 포트의 식별자로 설정해야 합니다.
SourceNicIndex 멤버는 NDIS_SWITCH_DEFAULT_NIC_INDEX 설정해야 합니다.
확장이 NdisFOidRequest를 호출하여 OID 요청을 전달하는 경우 OidRequest 매개 변수를 OID_SWITCH_NIC_REQUEST OID 요청에 대한 NDIS_OID_REQUEST 구조체에 대한 포인터로 설정해야 합니다.
확장이 OID 요청을 필터링하는 방법에 대한 자세한 내용은 NDIS 필터 드라이버에서 OID 요청 필터링을 참조하세요.
MUX 드라이버에 대한 자세한 내용은 NDIS MUX 중간 드라이버를 참조하세요.