netdev - Re: [net-next PATCH v3 0/5] Symmetric queue selection using XPS for Rx queues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 05 Jun 2018 12:33:35 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     amritha.nambiar@...el.com
Cc:     netdev@...r.kernel.org, alexander.h.duyck@...el.com,
        willemdebruijn.kernel@...il.com, sridhar.samudrala@...el.com,
        edumazet@...gle.com, hannes@...essinduktion.org,
        tom@...bertland.com
Subject: Re: [net-next PATCH v3 0/5] Symmetric queue selection using XPS
 for Rx queues

From: Amritha Nambiar <amritha.nambiar@...el.com>
Date: Tue, 05 Jun 2018 01:37:45 -0700

> This patch series implements support for Tx queue selection based on
> Rx queue(s) map. This is done by configuring Rx queue(s) 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
> CPUs map or the Rx-queues map. The config option CONFIG_XPS needs to be
> enabled. By default no receive queues are configured for the Tx queue.
> 
> - /sys/class/net/<dev>/queues/tx-*/xps_rxqs
> 
> A set of receive queues can be mapped to a set of transmit queues (many:many),
> although the common use case is a 1:1 mapping. This will 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
 ...

Thanks for doing this work.

I think this needs more time to sit and get reviews, and therefore needs
to be deferred to the next merge window.