netdev - Re: Multicast packet reordering

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]

Message-ID: <20221202103429.1887d586@kernel.org>
Date:   Fri, 2 Dec 2022 10:34:29 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Etienne Champetier <champetier.etienne@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Multicast packet reordering

On Thu, 1 Dec 2022 23:45:53 -0500 Etienne Champetier wrote:
> Using RPS fixes the issue, but to make it short:
> - Is it expect to have multicast packet reordering when just tuning buffer sizes ?
> - Does it make sense to use RPS to fix this issue / anything else / better ?
> - In the case of 2 containers talking using veth + bridge, is it better to keep 1 queue
> and set rps_cpus to all cpus, or some more complex tuning like 1 queue per cpu + rps on 1 cpu only ?

Yes, there are per-cpu queues in various places to help scaling, 
if you don't pin the sender to one CPU and it gets moved you can 
understandably get reordering w/ UDP (both on lo and veth).

As Andrew said that's considered acceptable.
Unfortunately it's one of those cases where we need to relax 
the requirements / stray from the ideal world if we want parallel
processing to not suck..