인터럽트 조정의 기본 원리는 수신 프레임 당 하나 미만의 인터럽트 (또는 전송 프레임 완료 당 하나의 인터럽트)를 생성하여 인터럽트를 처리 할 때 발생하는 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의 오버 헤드를 모두 살펴보십시오.
데이브