Bug 2185411

Summary: per-pod annotation "irq-load-balancing.crio.io: disabled" is not effective for virt-launcher pod
Product: Container Native Virtualization (CNV) Reporter: Marcelo Tosatti <mtosatti>
Component: NetworkingAssignee: Petr Horáček <phoracek>
Status: CLOSED DUPLICATE QA Contact: Nir Rozen <nrozen>
Severity: high Docs Contact:
Priority: high    
Version: 4.10.9CC: ailan, danken, fdeutsch, iholder, jortialc, ngu, phoracek, ralavi, vromanso
Target Milestone: ---   
Target Release: 4.14.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-06-15 12:21:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marcelo Tosatti 2023-04-09 01:02:26 UTC
Description of problem:

Its not possible to disable IRQs for KubeVirt pods, on a per-pod basis ("irq-load-balancing.crio.io: disabled", as documented in the Performance Addon Operator documentation).

This might require use of globallyDisableIrqLoadBalancing=true, which globally disables irqs for any isolated CPUs of a worker node (and therefore any non-infrastructure pods scheduled on that node).

This might reduce performance of pods deployed on such worker nodes. 


Version-Release number of selected component (if applicable):

Steps to Reproduce:

Start a KubeVirt pod with "irq-load-balancing.crio.io: disabled" annotation, 
feature won't be functional (CPUs assigned to such a KubeVirt pod will not be protected
from IRQs of the host system).

1.
2.
3.

Actual results:


Expected results:

That for KubeVirt pods with "irq-load-balancing.crio.io: disabled" annotation, the CPUs assigned for the pod have no IRQs which can be fired on them.


Additional info:

Comment 1 Vladik Romanovsky 2023-04-12 15:44:36 UTC
As it was previously discussed in [1]

We've agreed to follow the idea of a policy based solution.
The cluster admin who knows which runtime class maps to what functionality would provide a policy - similar to a migration policy.
The VM user will add a label or an annotation that will provide a hint about the application (where it requires cpu/irq balancing disabled, etc...)
Virt-controller will match the correct policy and will set the runtime class.


[1] https://github.com/kubevirt/kubevirt/pull/9402

Comment 2 Fabian Deutsch 2023-06-14 12:33:49 UTC
Moving this to network, as it relates to SR-IOV and the networking epic https://issues.redhat.com/browse/CNV-24676