NAPI와 적응 인터럽트


12

높은 네트워킹로드에서 인터럽트 오버 헤드를 완화하기 위해 다음 두 가지 기술을 어떻게 사용하는지 설명해 주시겠습니까?

  1. Adaptive-rx / Adaptive-tx 및
  2. NAPI;

리눅스 커널 소스 레벨에 가까운 차이점을 설명하는 답변에 감사드립니다. 또한 ~ 400Mbps 인로드에서 NIC를 폴링 / 인터럽트 통합 모드로 강제 설정하는 방법을 듣고 싶습니다.

더 많은 배경 :

문제는 bnx2 및 e1000 드라이버가 "ethtool -C adaptive-rx on"명령을 무시하는 것 같습니다. 이러한 드라이버는 적응 인터럽트를 지원하지 않기 때문일 수 있습니다. Broadcom Programmer의 참조 설명서에는이 기능이 BCM5709 NIC 하드웨어에서 지원되어야한다고 나와 있습니다.

그래서 netif_napi_add () 함수 호출에서 NAPI를 시도하고 무게를 64에서 16으로 줄이기로 결정하여 NIC를 훨씬 낮은 부하에서 폴링 모드로 강제 설정했지만 불행히도 제대로 작동하지 않았습니다. NAPI는 NIC에서 특별한 하드웨어 지원이 필요하지 않다고 생각합니다. 맞습니까?

내가 사용하는 하드웨어는 BCM5709 NIC입니다 (bnx2 드라이버 사용). 그리고 OS는 Ubuntu 10.04입니다. CPU는 XEON 5620입니다.

답변:


18

인터럽트 조정의 기본 원리는 수신 프레임 당 하나 미만의 인터럽트 (또는 전송 프레임 완료 당 하나의 인터럽트)를 생성하여 인터럽트를 처리 할 때 발생하는 OS 오버 헤드를 줄이는 것입니다. BCM5709 컨트롤러는 다음과 같은 인터럽트 통합 하드웨어를위한 몇 가지 방법을 지원합니다.

  • X 프레임 (ethtool의 rx-frames)을 수신 한 후 인터럽트 생성
  • X usecs (ethtool의 rx-usecs) 이후에 더 이상 프레임이 수신되지 않으면 인터럽트 생성

이러한 하드웨어 방법을 사용할 때의 문제점은 처리량 또는 대기 시간을 최적화하기 위해이를 선택해야한다는 것입니다. 둘 다 가질 수는 없습니다. 수신 된 각 프레임 (rx-frames = 1)에 대해 하나의 인터럽트를 생성하면 대기 시간이 최소화되지만 인터럽트 서비스 오버 헤드 측면에서 비용이 많이 듭니다. 더 큰 값을 설정하면 (rx-frames = 10) 수신 한 10 개의 프레임마다 하나의 인터럽트 만 생성하여 소비되는 CPU주기 수를 줄이지 만 10 개 그룹의 첫 번째 프레임에 대해서는 대기 시간이 길어집니다.

NAPI 구현은 트래픽이 다발이라는 사실을 활용하여 수신 한 첫 번째 프레임에서 즉시 인터럽트를 생성 한 다음 더 많은 트래픽이 가까워 지므로 폴링 모드 (즉, 인터럽트 비활성화)로 즉시 전환합니다. 몇 개의 프레임 (질문에 16 또는 64) 또는 시간 간격을 폴링 한 후 드라이버는 인터럽트를 다시 활성화하고 다시 시작합니다.

예측 가능한 워크로드가있는 경우 올바른 트레이드 오프를 제공하는 위의 모든 (NAPI, rx-frames, rx-usecs)에 대해 고정 값을 선택할 수 있지만 대부분의 워크로드는 다양하며 결국 희생이됩니다. 여기서 adaptive-rx / adaptive-tx가 시작됩니다. 드라이버는 작업량 (초당 수신 된 프레임, 프레임 크기 등)을 지속적으로 모니터링하고 트래픽이 적은 상황에서 대기 시간을 최적화하거나 트래픽이 많은 상황에서 처리량을 최적화하도록 하드웨어 인터럽트 통합 체계를 조정합니다. 멋진 이론이지만 실제로 구현하기가 어려울 수 있습니다. 일부 드라이버 만 구현하고 ( http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce 참조 ) bnx2 / e1000 드라이버는 해당 목록에 없습니다.

각 ethtool 통합 필드의 작동 방식에 대한 자세한 설명을 보려면 다음 주소에서 ethtool_coalesce 구조의 정의를 살펴보십시오.

http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111

특정 상황 (~ 400Mb / s 처리량)의 경우 워크로드에 가장 적합한 설정을 위해 rx-frames 및 rx-usecs 값을 조정하는 것이 좋습니다. 대기 시간에 대한 응용 프로그램의 민감도 (httpd? 등)와 ISR의 오버 헤드를 모두 살펴보십시오.

데이브


1
" NAPI 구현 은 트래픽이 다발 적으로 발생한다는 사실을 활용하여 수신 한 첫 번째 프레임에서 즉시 인터럽트생성 한 다음 즉시 폴링 모드로 전환합니다 "라고 말했습니다. 그러나 위키 말했다 NAPI가 하드웨어 인터럽트, 결코,하지만 여론 조사 시간마다 일정 기간 사용하지 않습니다 : en.wikipedia.org/wiki/New_API 정확한 견적을 "할 수있는 커널 주기적으로 확인 들어오는 네트워크 패킷의 도착을 중단하지 않고 인터럽트 처리의 오버 헤드를 제거합니다. " 진실은 어디에 있습니까?
Alex

1
커널에 수신 할 트래픽이 있음을 알리려면 @Alex 하드웨어 인터럽트를 사용해야합니다 . "이전 스타일"인터럽트 핸들러는 패킷 수신을 예약 한 다음 인터럽트를 다시 활성화합니다. NAPI 인터럽트 핸들러는 인터럽트를 비활성화하고 폴러를 예약하며 인터럽트를 다시 활성화합니다. 폴러는 특정 양의 패킷에 대해 패킷 수신을 수행하며, 폴러가 계속 서비스를 제공 할 트래픽이있는 한 항상 NIC에서 트래픽을 끌어 와서 하드 인터럽트를 방지하는 것이 목표입니다. 트래픽이 종료되면 폴러가 종료되고 시스템은 인터럽트 대기 상태로 돌아갑니다.
suprjami
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.