Problem
For switchdev-based SR-IOV with hardware-offloaded network policy (tc-flower skip_sw on VF representors), a workload's VF in the pod must be correlated with its host-side representor netdev so the offload datapath (tc-flower rules, stateful CT offload) can be programmed. Today the driver allocates the VF but does not surface/allocate the representor, so an operator/CNI cannot deterministically find the representor for an allocated VF.
Ask
Expose the VF→representor correlation as part of allocation (e.g. a device attribute carrying the representor netdev name / phys_port_name, or a ResourceClaim.status.devices[].data), so downstream tooling can program tc-flower offload rules against the representor.
Context
Part of a coexistence design where DRA runs alongside the legacy Multus + sriov-network-device-plugin stack; the switchdev + tc-flower offload path currently has no DRA equivalent. Relates to eswitch-mode detection (#120).
Happy to help implement once there's agreement on the shape.
Problem
For switchdev-based SR-IOV with hardware-offloaded network policy (tc-flower
skip_swon VF representors), a workload's VF in the pod must be correlated with its host-side representor netdev so the offload datapath (tc-flower rules, stateful CT offload) can be programmed. Today the driver allocates the VF but does not surface/allocate the representor, so an operator/CNI cannot deterministically find the representor for an allocated VF.Ask
Expose the VF→representor correlation as part of allocation (e.g. a device attribute carrying the representor netdev name / phys_port_name, or a
ResourceClaim.status.devices[].data), so downstream tooling can program tc-flower offload rules against the representor.Context
Part of a coexistence design where DRA runs alongside the legacy Multus + sriov-network-device-plugin stack; the switchdev + tc-flower offload path currently has no DRA equivalent. Relates to eswitch-mode detection (#120).
Happy to help implement once there's agreement on the shape.