Re: [PATCH RFC bpf-next 32/52] bpf, cpumap: switch to GRO from netif_receive_skb_list()
From: Jesper Dangaard Brouer <hawk@kernel.org>
Date: 2024-08-09 09:32:16
Also in:
bpf, lkml
On 08/08/2024 22.44, Daniel Xu wrote:
Hi Lorenzo, On Thu, Aug 8, 2024, at 12:54 AM, Lorenzo Bianconi wrote:quoted
quoted
Hi Alexander, On Tue, Jun 28, 2022, at 12:47 PM, Alexander Lobakin wrote:
[...]
quoted
quoted
AFAICT the cpumap + GRO is a good standalone improvement. I think cpumap is still missing this. I have a production use case for this now. We want to do some intelligent RX steering and I think GRO would help over list-ified receive in some cases. We would prefer steer in HW (and thus get existing GRO support) but not all our NICs support it. So we need a software fallback.
I want to state that Cloudflare is also planning to use cpumap in production, and (one) blocker is that CPUMAP doesn't support GRO.
quoted
quoted
Are you still interested in merging the cpumap + GRO patches?Hi Daniel and Alex, Recently I worked on a PoC to add GRO support to cpumap codebase: - https://github.com/LorenzoBianconi/bpf-next/commit/a4b8264d5000ecf016da5a2dd9ac302deaf38b3e Here I added GRO support to cpumap through gro-cells. - https://github.com/LorenzoBianconi/bpf-next/commit/da6cb32a4674aa72401c7414c9a8a0775ef41a55 Here I added GRO support to cpumap trough napi-threaded APIs (with a some changes to them).Cool!quoted
Please note I have not run any performance tests so far, just verified it does not crash (I was planning to resume this work soon). Please let me know if it works for you.I’ll try to run an A/B test on your two approaches as well as Alex’s. I’ve still got some testbeds with production traffic going thru them.
It is awesome that both Olek and you are stepping up for testing this. (I'm currently too busy on cgroup rstat lock related work, but more people will be joining my team this month and I hope they have interest in contributing to this effort). --Jesper