Thanks for testing so far. Looks quite ok for the moment, but for extra testing we will skip kernel updates in 24.7.7 this week so this batch will likely land in 243.7.8.Cheers,Franco
igc: Add AIMigc is derived from igb and has never had an AIM implementation. Thesame algorithm from e1000 is appropriate here.Upon more detailed study of the Linux driver which has a newer AIMimplementation, it finally became clear to me this is actually aholdoff timer and not an interrupt limit as it is conventionally(statically) programmed and displayed as an interrupt rate. The datasheets also make this somewhat clear.Thus, AIM accomplishes two beneficial things for a wide variety ofworkloads[1]:1. At low throughput/packet rates, it will significantly lower latency(by counter-intuitively "increasing" the interrupt rate.. betterthought of as decreasing the holdoff timer because you will modulatedown before coming anywhere near these interrupt rates).2. At bulk data rates, it is tuned to achieve a lower interrupt rate(by increasing the holdoff timer) than the current static 8000/s. Thisdecreases processing overhead and yields more headroom for other worksuch as packet filters or userland.For a single NIC this might be worth a few sys% on common CPUs, but maybe meaningful when multiplied such as if_lagg, if_bridge and forwardingsetups.The AIM algorithm was re-introduced from the older igb or out of treedriver, and then modernized with permission to use Intel code from otherdrivers.[1]: http://iommu.com/datasheets/ethernet/controllers-nics/intel/e1000/gbe-controllers-interrupt-moderation-appl-note.pdf
# opnsense-update -zkr 24.7.6-intel3# opnsense-shell reboot
New kernelQuote from: 42bf31316a551230f13e247dba5cb11e8e1b06e8 igc: Add AIMigc is derived from igb and has never had an AIM implementation. Thesame algorithm from e1000 is appropriate here.Upon more detailed study of the Linux driver which has a newer AIMimplementation, it finally became clear to me this is actually aholdoff timer and not an interrupt limit as it is conventionally(statically) programmed and displayed as an interrupt rate. The datasheets also make this somewhat clear.Thus, AIM accomplishes two beneficial things for a wide variety ofworkloads[1]:1. At low throughput/packet rates, it will significantly lower latency(by counter-intuitively "increasing" the interrupt rate.. betterthought of as decreasing the holdoff timer because you will modulatedown before coming anywhere near these interrupt rates).2. At bulk data rates, it is tuned to achieve a lower interrupt rate(by increasing the holdoff timer) than the current static 8000/s. Thisdecreases processing overhead and yields more headroom for other worksuch as packet filters or userland.For a single NIC this might be worth a few sys% on common CPUs, but maybe meaningful when multiplied such as if_lagg, if_bridge and forwardingsetups.The AIM algorithm was re-introduced from the older igb or out of treedriver, and then modernized with permission to use Intel code from otherdrivers.[1]: http://iommu.com/datasheets/ethernet/controllers-nics/intel/e1000/gbe-controllers-interrupt-moderation-appl-note.pdfhttps://github.com/opnsense/src/commit/42bf31316a551230f13e247dba5cb11e8e1b06e8Code: [Select] # opnsense-update -zkr 24.7.6-intel3# opnsense-shell reboot
No trouble at all, 24.7.7 has no new kernel.For those already on the 24.7.6-intel2 kernel there are two options:a) Install 24.7.7 which will revert your kernel to 24.7.6b) Temporary lock the kernel in the GUI until 24.7.8 is available, so you can upgrade to 24.7.7 without issues. Don't forget to unlock before upgrading to 24.7.8 though
# opnsense-update -zkr 24.7.6-intel4# opnsense-shell reboot
# opnsense-update -zkr 24.7.6-intel5
