On Thu, Apr 19, 2018 at 7:41 PM, Eric Dumazet <eduma...@google.com> wrote: > On Thu, Apr 19, 2018 at 6:07 PM Amritha Nambiar <amritha.namb...@intel.com> > wrote: > >> This patch series implements support for Tx queue selection based on >> Rx queue map. This is done by configuring Rx queue map per Tx-queue >> using sysfs attribute. If the user configuration for Rx queues does >> not apply, then the Tx queue selection falls back to XPS using CPUs and >> finally to hashing. > >> XPS is refactored to support Tx queue selection based on either the >> CPU map or the Rx-queue map. The config option CONFIG_XPS needs to be >> enabled. By default no receive queues are configured for the Tx queue. > >> - /sys/class/net/eth0/queues/tx-*/xps_rxqs > >> This is to enable sending packets on the same Tx-Rx queue pair as this >> is useful for busy polling multi-threaded workloads where it is not >> possible to pin the threads to a CPU. This is a rework of Sridhar's >> patch for symmetric queueing via socket option: >> https://www.spinics.net/lists/netdev/msg453106.html > I suspect this is an artifact of flow director which I believe required queue pairs to be able to work (i.e. receive queue chose hardware is determined send queue). But that was only required because of hardware design, I don't see the rationale for introducing queue pairs in the software stack. There's no need to correlate the transmit path with receive path, no need to enforce a 1-1 mapping between RX and TX queues, and the OOO mitigations should be sufficient when TX queue changes for a flow.
Tom >> --- > >> Amritha Nambiar (3): >> net: Refactor XPS for CPUs and Rx queues >> net: Enable Tx queue selection based on Rx queues >> net-sysfs: Add interface for Rx queue map per Tx queue > > >> include/linux/netdevice.h | 82 +++++++++++++++ >> include/net/sock.h | 18 +++ >> net/core/dev.c | 240 > +++++++++++++++++++++++++++++++-------------- >> net/core/net-sysfs.c | 85 ++++++++++++++++ >> net/core/sock.c | 5 + >> net/ipv4/tcp_input.c | 7 + >> net/ipv4/tcp_ipv4.c | 1 >> net/ipv4/tcp_minisocks.c | 1 >> 8 files changed, 357 insertions(+), 82 deletions(-) > > > Without a clear documentation (for example in > Documentation/networking/scaling.txt) > , I really do not understand what problem you want to solve, and why we > need ~300 additional LOC in kernel. > > Referring to an old thread ( > https://www.spinics.net/lists/netdev/msg453106.html ) is not the way to go. > > Sorry :/
