높은 네트워킹로드에서 인터럽트 오버 헤드를 완화하기 위해 다음 두 가지 기술을 어떻게 사용하는지 설명해 주시겠습니까?
- Adaptive-rx / Adaptive-tx 및
- 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입니다.
답변
인터럽트 조정의 기본 원리는 수신 프레임 당 하나 미만의 인터럽트 (또는 전송 프레임 완료 당 하나의 인터럽트)를 생성하여 인터럽트를 처리 할 때 발생하는 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의 오버 헤드를 모두 살펴보십시오.
데이브
