Nguyên tắc chính đằng sau kiểm duyệt ngắt là tạo ra ít hơn một ngắt trên mỗi khung nhận được (hoặc một ngắt cho mỗi lần hoàn thành khung truyền), giảm chi phí hệ điều hành gặp phải khi phục vụ ngắt. Bộ điều khiển BCM5709 hỗ trợ một số phương thức trong phần cứng để ngắt liên kết, bao gồm:
- Tạo ngắt sau khi nhận khung X (khung rx trong ethtool)
- Tạo một ngắt khi không nhận được nhiều khung hơn sau X usecs (rx-usecs trong ethtool)
Vấn đề với việc sử dụng các phương pháp phần cứng này là bạn cần chọn chúng để tối ưu hóa thông lượng hoặc độ trễ, bạn không thể có cả hai. Tạo một ngắt cho mỗi khung nhận được (rx-frames = 1) giảm thiểu độ trễ, nhưng nó làm như vậy với chi phí cao về chi phí dịch vụ ngắt. Đặt giá trị lớn hơn (giả sử rx-frames = 10) sẽ giảm số chu kỳ CPU được tiêu thụ bằng cách chỉ tạo một ngắt cho mỗi mười khung nhận được, nhưng bạn cũng sẽ gặp độ trễ cao hơn cho các khung đầu tiên trong nhóm mười.
Việc triển khai NAPI cố gắng thúc đẩy thực tế là lưu lượng truy cập thành từng bó, do đó bạn tạo ra một ngắt ngay lập tức trên khung đầu tiên nhận được, sau đó bạn ngay lập tức chuyển sang chế độ bỏ phiếu (tức là vô hiệu hóa các ngắt). Sau khi bạn đã bỏ phiếu cho một số khung (16 hoặc 64 trong câu hỏi của bạn) hoặc một khoảng thời gian, trình điều khiển sẽ kích hoạt lại các ngắt và bắt đầu lại.
Nếu bạn có khối lượng công việc có thể dự đoán được thì các giá trị cố định có thể được chọn cho bất kỳ trường hợp nào ở trên (NAPI, rx-frames, rx-usecs) mang lại cho bạn sự đánh đổi đúng, nhưng hầu hết khối lượng công việc khác nhau và cuối cùng bạn sẽ phải hy sinh. Đây là nơi thích nghi-rx / thích nghi-tx phát huy tác dụng. Ý tưởng là trình điều khiển liên tục theo dõi khối lượng công việc (khung hình nhận được mỗi giây, kích thước khung hình, v.v.) và điều chỉnh sơ đồ liên kết ngắt phần cứng để tối ưu hóa độ trễ trong tình huống lưu lượng thấp hoặc tối ưu hóa thông lượng trong tình huống lưu lượng truy cập cao. Đó là một lý thuyết tuyệt vời nhưng có thể khó thực hiện trong thực tế. Chỉ có một vài trình điều khiển thực hiện nó (xem http://fxr.watson.org/fxr/search?v=linux-2.6&opes=use_adaptive_rx_coalesce ) và trình điều khiển bnx2 / e1000 không có trong danh sách đó.
Để biết mô tả tốt về cách mỗi trường kết hợp ethtool hoạt động, hãy xem các định nghĩa cho cấu trúc ethtool_coalesce tại địa chỉ sau:
http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111
Đối với tình huống cụ thể của bạn (thông lượng ~ 400Mb / giây) Tôi khuyên bạn nên điều chỉnh các khung rx và các giá trị rx-usecs để có các cài đặt tốt nhất cho khối lượng công việc của bạn. Nhìn vào cả chi phí hoạt động của ISR cũng như độ nhạy của ứng dụng của bạn (httpd? V.v.) với độ trễ.
Dave