Bug 2185411 - per-pod annotation "irq-load-balancing.crio.io: disabled" is not effective for virt-launcher pod
Summary: per-pod annotation "irq-load-balancing.crio.io: disabled" is not effective fo...
Keywords:
Status: CLOSED DUPLICATE of bug 2203291
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Networking
Version: 4.10.9
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.14.0
Assignee: Petr Horáček
QA Contact: Nir Rozen
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-04-09 01:02 UTC by Marcelo Tosatti
Modified: 2023-06-15 12:21 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-15 12:21:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CNV-24676 0 None None None 2023-04-24 09:13:40 UTC
Red Hat Issue Tracker CNV-27978 0 None None None 2023-04-09 01:05:02 UTC

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


Note You need to log in before you can comment on or make changes to this bug.