NAPI เทียบกับ Adaptive Interrupts

ใครช่วยอธิบายหน่อยได้ไหมว่าเทคโนโลยีสองอย่างต่อไปนี้ถูกใช้เพื่อลดค่าใช้จ่ายของอินเตอร์รัปต์ภายใต้โหลดเครือข่ายสูง

1. Adaptive-rx / Adaptive-tx และ
2. Napi;

ฉันจะขอบคุณคำตอบที่อธิบายถึงความแตกต่างใกล้กับระดับที่มาของเคอร์เนล linux หรือไม่ นอกจากนี้ฉันอยากได้ยินวิธีการบังคับให้ NIC เข้าสู่โหมดการโพล / ขัดจังหวะการรวมตัวกันที่โหลดที่ ~ 400Mbps

พื้นหลังเพิ่มเติม:

ปัญหาน่าจะเป็นที่ไดรเวอร์ bnx2 และ e1000 ไม่สนใจคำสั่ง "ethtool -C adaptive-rx on" อาจเป็นเพราะไดรเวอร์เหล่านี้ไม่รองรับการขัดจังหวะแบบปรับตัว ถึงแม้ว่าคู่มืออ้างอิงของ Broadcom Programmer กล่าวว่าคุณลักษณะนี้ควรได้รับการสนับสนุนโดยฮาร์ดแวร์ BCM5709 NIC

ดังนั้นฉันจึงตัดสินใจลอง NAPI และลดน้ำหนักจาก 64 เป็น 16 ในการเรียกใช้ฟังก์ชัน netif_napi_add () เพื่อบังคับให้ NIC ในโหมดการโพลภายใต้ภาระที่ต่ำกว่ามาก แต่น่าเสียดายที่ไม่ได้ผล ฉันเดาว่า NAPI ไม่ต้องการการสนับสนุนฮาร์ดแวร์พิเศษใน NIC นั้นถูกต้องหรือไม่

ฮาร์ดแวร์ที่ฉันใช้คือ BCM5709 NIC (ใช้ไดรเวอร์ bnx2) และระบบปฏิบัติการคือ Ubuntu 10.04 ซีพียูคือ XEON 5620

หลักการหลักที่อยู่เบื้องหลังการควบคุมการขัดจังหวะคือการสร้างการขัดจังหวะน้อยกว่าหนึ่งต่อเฟรมที่ได้รับ (หรือหนึ่งขัดจังหวะต่อการเสร็จสิ้นการส่งเฟรม) ลดค่าใช้จ่าย OS พบเมื่อการขัดจังหวะการให้บริการ คอนโทรลเลอร์ BCM5709 รองรับสองวิธีในฮาร์ดแวร์สำหรับการรวมการขัดจังหวะรวมถึง:

• สร้างการขัดจังหวะหลังจากรับ X frames (rx-frames ใน ethtool)
• สร้างการขัดจังหวะเมื่อไม่ได้รับเฟรมเพิ่มเติมหลังจาก X usecs (rx-usecs ใน ethtool)

ปัญหาเกี่ยวกับการใช้วิธีการฮาร์ดแวร์เหล่านี้คือคุณต้องเลือกวิธีการเหล่านี้เพื่อเพิ่มประสิทธิภาพการรับส่งข้อมูลหรือเวลาแฝงคุณไม่สามารถทำได้ทั้งสองอย่าง การสร้างหนึ่งอินเทอร์รัปต์สำหรับแต่ละเฟรมที่ได้รับ (rx-frames = 1) จะลดเวลาในการตอบสนอง แต่ลดค่าใช้จ่ายสูงในแง่ของค่าบริการขัดจังหวะ การตั้งค่าที่มีขนาดใหญ่กว่า (say rx-frames = 10) ลดจำนวนรอบของ CPU ที่ใช้ไปโดยสร้างเพียงหนึ่งอินเทอร์รัปต์สำหรับแต่ละเฟรมสิบเฟรมที่ได้รับ แต่คุณจะต้องเผชิญกับเวลาแฝงที่สูงขึ้น

การใช้งาน 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 สำหรับการตั้งค่าที่ดีที่สุดสำหรับภาระงานของคุณ ดูที่ทั้งโอเวอร์เฮดของ ISR รวมถึงความไวของแอปพลิเคชันของคุณ (httpd? ฯลฯ ) ถึงความหน่วง

เดฟ