On 12/1/20 3:48 PM, Herbert Xu wrote:
On Wed, Dec 02, 2020 at 12:41:36AM +0100, Ard Biesheuvel wrote:
You just explained that TX typically runs in process context, whereas
RX is handled in softirq context. So how exactly are these going to
end up on the same core?
When you receive a TCP packet via RX, this should wake up your user-
space thread on the same CPU as otherwise you'll pay extra cost
on pulling the data into memory again.
Yes, but IPsec will not use the synchronous interface.
That doesn't matter when the underlying wireless code is using
the sync interface. An async user is completely capable of making
the aesni code-path unavailable to the sync user.
Fair enough. But it is unfortunate that we cannot support Ben's use
case without a lot of additional work that serves no purpose
otherwise.
To the contrary, I think to fully support Ben's use case you must
use the async code path. Otherwise sure you'll see good numbers
when you do simple benchmarks like netperf, but when you really
load up the system it just falls apart.
I can generate some very complicated traffic to test this, including bi-directional
traffic, mix of tcp/udp/https, etc. If numbers will sway your opinion, let me know what
traffic tests will make you happy and I'll do the testing.
I know for sure that in download traffic (which is normal dominant direction for wifi stations),
Ard's patch gives me about 3x increase of throughput. Without the patch, softirqd is pegged
100% futzing around with enabling and disabling the fpu.
The wifi stack people do not want any extra complexity in their code,
and async processing of this would be a lot of complexity. So, even if I wanted
to implement it, likely it would never make it upstream anyway.
I also suspect that general users may benefit from this aesni patch since
many older wifi chipsets don't support wpa3 in hardware and wpa3 is the new
hotness in wifi.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
