NAPI vs Ngắt thích ứng


12

Bất cứ ai cũng có thể giải thích làm thế nào hai công nghệ sau đây được sử dụng để giảm thiểu tình trạng gián đoạn dưới tải mạng cao?

  1. Thích nghi-rx / Thích ứng-tx, và
  2. NAPI;

Tôi sẽ đánh giá cao một câu trả lời giải thích sự khác biệt gần hơn với mức nguồn kernel linux? Ngoài ra, tôi muốn nghe làm thế nào để buộc NIC chuyển sang chế độ kết hợp bỏ phiếu / ngắt ở mức tải ~ 400Mbps.

Thêm nền tảng:

Vấn đề dường như là trình điều khiển bnx2 và e1000 bỏ qua lệnh "ethtool -C Adaptive-rx on". Điều này có thể là do những trình điều khiển đó không hỗ trợ ngắt thích ứng. Mặc dù hướng dẫn tham khảo của Lập trình viên Broadcom nói rằng tính năng này phải được hỗ trợ bởi phần cứng BCM5709 NIC.

Vì vậy, tôi đã quyết định thử NAPI và giảm trọng lượng từ 64 xuống 16 trong lệnh gọi hàm netif_napi_add () để buộc NIC ở chế độ bỏ phiếu dưới tải thấp hơn nhiều, nhưng thật không may, nó không hoạt động. Tôi đoán rằng NAPI không cần bất kỳ sự hỗ trợ phần cứng đặc biệt nào trong NIC, điều đó có đúng không?

Phần cứng tôi đang sử dụng là BCM5709 NIC (nó sử dụng trình điều khiển bnx2). Và HĐH là Ubuntu 10.04. CPU là XEON 5620.

Câu trả lời:


18

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


1
Bạn nói rằng "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 ". Nhưng trong wiki nói rằng NAPI không sử dụng ngắt phần cứng, không bao giờ, nhưng thăm dò ý kiến ​​trong một khoảng thời gian nhất định : en.wikipedia.org/wiki/New_API Trích dẫn chính xác: "Hạt nhân có thể kiểm tra định kỳ sự xuất hiện của các gói mạng đến mà không bị gián đoạn , giúp loại bỏ chi phí xử lý ngắt. " Đâu là sự thật?
Alex

1
@Alex Ngắt phần cứng phải được sử dụng để thông báo cho kernel có lưu lượng để nhận. Một trình xử lý ngắt "kiểu cũ" lập lịch nhận gói sau đó kích hoạt lại các ngắt. Trình xử lý ngắt NAPI sẽ vô hiệu hóa các ngắt, lên lịch trình đẩy và kích hoạt lại các ngắt. Xe đẩy thực hiện nhận gói cho một số lượng gói nhất định và miễn là có lưu lượng để phục vụ cho xe đẩy tiếp tục chạy, mục đích là để ngăn chặn các ngắt cứng bằng cách luôn rút lưu lượng ra khỏi NIC. Khi giao thông ngừng hoạt động, xe đẩy sẽ thoát ra và hệ thống quay trở lại để chờ ngắt.
suprjami
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.