Details
Details
- Difficulty level
- Normal (likely a few hours)
- Version
- -
- Why the issue appeared?
- Will be filled on close
- Is it a breaking change?
- Unspecified (possibly destroys the router)
- Issue type
- Feature (new functionality)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In progress | FEATURE REQUEST | None | T3355 Remove all remaining legacy Vyatta code | ||
| Resolved | FEATURE REQUEST | None | T1579 Rewrite all interface types in new XML/Python style | ||
| Resolved | FEATURE REQUEST | c-po | T1637 Rewrite ethernet interface in new style XML syntax | ||
| Resolved | FEATURE REQUEST | c-po | T3048 Drop static smp-affinity for a more dynamic way using tuned | ||
| Wontfix | FEATURE REQUEST | c-po | T1677 Support configuration of Ethernet SMP affinity in new Python/XML implementation |
Event Timeline
Comment Actions
I also propose migrating the CLI interface from a bitmask (which IMHO no user understands)
[email protected]# cat /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/smp-affinity/node.def # # # Configuration template for interface.ethernet.name.smp-affinity # # Configure the CPUs that the associated interface will interrupt. # SMP affinity is configured by a hexidecimal bitmask that specifies the # CPUs that the system can interrupt. The SMP affinity bitmask must contain # at least one bits, and may only contain as many bits as there are CPUs on # the system. # priority: 319 # Failure barrier only - no ordering constraints type: txt help: CPU interrupt affinity mask val_help: auto; Automatic CPU affinity (default) val_help: <hex>; Bitmask representing CPUs that this NIC will interrupt val_help: <hex>,<hex>; Bitmasks representing CPUs for interrupt and receive processing default: "auto" syntax:expression: $VAR(@) == "auto" || pattern $VAR(@) "^[0-9a-f]+(|,[0-9a-f]+)$" ; "IRQ affinity mask must be hex value or auto" update: sudo /opt/vyatta/sbin/irq-affinity.pl $VAR(../@) $VAR(@)
to a multi: node where the user can just say cpu0, cpu1, cpuXX to specify which CPUs should service the NIC.
Comment Actions
I would not use cpu<numbe> but just <number> like is used for taskset for example, but it would be a real improvement for users.
An op command should be provided giving the affinity of CPU ( from lscpu ) and the documentation should warn about interrupt crossing numa domains (for the case where a network card is providing multiple interfaces).