SR-IOV este una dintre tehnologiile care apar des în infrastructuri cu trafic mare: virtualizare, containere cu acces direct la rețea, NFV, storage rapid sau workload-uri care au nevoie de latență mică și throughput ridicat. Ideea este simplă la nivel conceptual: o placă PCI Express fizică poate expune mai multe funcții virtuale, fiecare văzută de sistem ca un dispozitiv separat.
În Linux, dispozitivul fizic este numit Physical Function, sau PF. Funcțiile create din el sunt Virtual Functions, sau VF. Documentația kernelului explică faptul că SR-IOV este o capabilitate PCI Express prin care un dispozitiv fizic poate apărea ca mai multe dispozitive virtuale. După activare, fiecare VF primește propriul identificator PCI și poate fi tratată de kernel ca un dispozitiv PCI hot-plug.
De ce contează pentru workload-uri rapide
Într-o configurație obișnuită de virtualizare, pachetele de rețea sau operațiile de I/O pot trece prin mai multe straturi software: bridge, switch virtual, emulare, driver generic, hipervizor. SR-IOV reduce o parte din acest traseu, pentru că o VF poate fi atribuită direct unei mașini virtuale sau unui workload compatibil.
Asta poate aduce latență mai mică și performanță mai apropiată de hardware, dar vine cu o condiție importantă: izolarea trebuie verificată atent. Faptul că o VF apare ca dispozitiv separat nu înseamnă automat că întreaga topologie PCI este izolată corect pentru scenariul tău. IOMMU-ul, grupurile IOMMU, driverul, firmware-ul, BIOS/UEFI și suportul plăcii contează toate.
Cum verifici dacă placa suportă SR-IOV
Primul indiciu este în sysfs. Pentru o placă PCI care suportă SR-IOV, Linux expune fișiere precum sriov_totalvfs și sriov_numvfs în directorul dispozitivului. Documentația ABI a kernelului spune că sriov_totalvfs arată numărul maxim de VF-uri suportate de PF, iar sriov_numvfs permite citirea și controlul numărului de VF-uri activate.
Practic, administratorul identifică interfața sau dispozitivul PCI, apoi verifică dacă există aceste fișiere. Pentru o placă de rețea, calea este de obicei sub:
/sys/class/net/INTERFATA/device/
Dacă fișierul sriov_totalvfs există și are o valoare mai mare decât zero, dispozitivul expune suport SR-IOV. Numărul exact depinde de hardware, driver și uneori de setările din firmware.
Cum creezi Virtual Functions
Metoda recomandată în documentația kernelului pentru dispozitivele noi este scrierea valorii dorite în sriov_numvfs. De exemplu, pentru a crea 4 VF-uri pe o interfață compatibilă:
echo 4 > /sys/class/net/INTERFATA/device/sriov_numvfs
Valoarea trebuie să fie mai mică sau egală cu sriov_totalvfs. Kernelul validează operația și respinge valori invalide. Un detaliu important: dacă există deja VF-uri active, de regulă nu schimbi direct numărul la o altă valoare arbitrară. Procedura sigură este să dezactivezi întâi VF-urile, apoi să setezi noul număr:
echo 0 > /sys/class/net/INTERFATA/device/sriov_numvfs
echo 4 > /sys/class/net/INTERFATA/device/sriov_numvfs
Această operație trebuie făcută în fereastră de mentenanță sau pe un sistem de test, pentru că poate întrerupe workload-uri care folosesc deja acele VF-uri.
Cum verifici că VF-urile au apărut
După activare, lspci ar trebui să arate noile funcții virtuale. În funcție de placă, ele pot apărea ca „Virtual Function” sau ca dispozitive PCI separate cu același producător și model apropiat. Poți corela interfața PF cu dispozitivele create verificând linkurile din sysfs, de exemplu în directorul dispozitivului PF, unde apar intrări de tip virtfn.
Pentru configurări persistente, distribuțiile folosesc abordări diferite: udev rules, systemd units, NetworkManager, netplan sau mecanisme specifice vendorului. Red Hat documentează, de exemplu, o regulă udev care setează ATTR{device/sriov_numvfs}. Pe sisteme de producție, soluția persistentă trebuie adaptată distribuției și driverului folosit, nu copiată mecanic.
Partea critică: izolarea PCI/IOMMU
Pentru passthrough sau acces direct sigur, nu este suficient ca VF-ul să existe. Trebuie verificat grupul IOMMU. Documentația VFIO din kernel explică faptul că un grup IOMMU este setul de dispozitive care poate fi izolat de restul sistemului, iar pentru VFIO grupul este unitatea minimă de ownership.
Verificarea se face în:
/sys/kernel/iommu_groups/
Fiecare grup conține dispozitivele PCI asociate. Dacă VF-ul tău este singur în grup, situația este mai curată. Dacă în același grup apar și alte dispozitive, trebuie analizată topologia. Bridge-urile PCI, lipsa ACS sau anumite combinații de sloturi pot reduce granularitatea izolării.
În BIOS/UEFI trebuie să fie activate opțiunile relevante pentru virtualizare I/O, cum ar fi Intel VT-d sau AMD-Vi, în funcție de platformă. În Linux, IOMMU trebuie să fie activ și vizibil în logurile kernelului. Fără IOMMU funcțional, passthrough-ul și izolarea pentru acces direct pierd o parte esențială din protecția așteptată.
Bune practici pentru producție
Testează întâi pe staging, notează mappingul PF–VF–workload și păstrează configurația reproductibilă. Nu aloca același VF către două workload-uri. Monitorizează driverul, firmware-ul și erorile PCIe. Pentru throughput ridicat, verifică și partea de CPU affinity, NUMA, cozi hardware, MTU și configurarea driverului, dar fără să sari peste izolarea IOMMU.
SR-IOV poate fi o soluție foarte eficientă, însă nu este o bifă magică de performanță. Câștigul real apare când hardware-ul, kernelul, driverul, IOMMU-ul și orchestrarea sunt configurate coerent. Înainte de producție, verificarea grupurilor IOMMU și testarea cu trafic real sunt la fel de importante ca activarea VF-urilor.
Surse
- https://docs.kernel.org/PCI/pci-iov-howto.html
- https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci
- https://docs.kernel.org/driver-api/vfio.html
- https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-pci_devices-pci_passthrough
