Page MenuHomeVyOS Platform

Adding the possibility to configure RSS under the interface
Open, NormalPublicFEATURE REQUEST

Description

Adding the possibility to configure RSS under the interface

  1. Check if nic supports RSS and if it is not enabled by default, turn it on. Commands to enable and check RSS
ethtool -k ethX | grep receive-hashing
ethtool -K ethX rx-hashing on
  1. If NIC supports, set the RSS queue count equal to the number of cores by default and allow to change this value
Check command: ethtool -l ethX
Change command: ethtool -L ethX

3.If NIC supports, enable ntuple by default. Adding possibility to switch off it.

Check if enabled command: ethtool -k ethX | grep ntuple-filters
Enabling command: ethtool -K ethX ntuple on

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Feature (new functionality)

Related Objects

StatusSubtypeAssignedTask
OpenFEATURE REQUESTNone
OpenFEATURE REQUESTNone

Event Timeline

Should RSS/ntuple be the default or should it be an opt-in "offload" setting?

I spent some time exploring RSS as part of optimizing the work-in-progress Suricata IDS implementation. In general, it is a nice implementation that seems to benefit single flow throughput, however it does so by shifting the load for a single class of flows on to a single core, as opposed to spraying it across all cores randomly. In certain cases where traffic is poorly distributed, it could perform worse.

Also a future ticket that may be worth filing, some interfaces allow customizing the hashing rules (with default that vary by interface, e.g. for my X553 NIC, UDP flows do not consider the port as part of the hash unless you manually change the setting). And it's also possible to program a particular flow to be pinned to a specific queue.

Another note—our current RPS implementation intentionally excludes core 0 from packet processing. If we want the default RSS behavior to mimic, this might mean we should be using N-1 queues where N is the number of cores. Whether this makes sense to carry over to RSS I'll leave open for debate.