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, 28 Jun 2022 10:03:11 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     James Yonan <james@...nvpn.net>
Cc:     netdev@...r.kernel.org, therbert@...gle.com,
        stephen@...workplumber.org
Subject: Re: [PATCH net-next v2] rfs: added /proc/sys/net/core/rps_allow_ooo
 flag to tweak flow alg

On Mon, 27 Jun 2022 23:17:54 -0600 James Yonan wrote:
> rps_allow_ooo (0|1, default=0) -- if set to 1, allow RFS (receive flow
> steering) to move a flow to a new CPU even if the old CPU queue has
> pending packets.  Note that this can result in packets being delivered
> out-of-order.  If set to 0 (the default), the previous behavior is
> retained, where flows will not be moved as long as pending packets remain.
> 
> The motivation for this patch is that while it's good to prevent
> out-of-order packets, the current RFS logic requires that all previous
> packets for the flow have been dequeued before an RFS CPU switch is made,
> so as to preserve in-order delivery.  In some cases, on links with heavy
> VPN traffic, we have observed that this requirement is too onerous, and
> that it prevents an RFS CPU switch from occurring within a reasonable time
> frame if heavy traffic causes the old CPU queue to never fully drain.
> 
> So rps_allow_ooo allows the user to select the tradeoff between a more
> aggressive RFS steering policy that may reorder packets on a CPU switch
> event (rps_allow_ooo=1) vs. one that prioritizes in-order delivery
> (rps_allow_ooo=0).

Can you give a practical example where someone would enable this?
What is the traffic being served here that does not care about getting
severely chopped up? Also why are you using RPS, it's 2022, don't all
devices of note have multi-queue support?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ