summaryrefslogtreecommitdiff
path: root/rust/helpers/helpers.c
diff options
context:
space:
mode:
authorAlexander Lobakin <aleksander.lobakin@intel.com>2025-02-25 18:17:45 +0100
committerPaolo Abeni <pabeni@redhat.com>2025-02-27 14:03:14 +0100
commit4f8ab26a034f04f918c8d36c051ec84e4082eed5 (patch)
tree66c7488b8c10c36ce7d0b3e608bb4eea9d8a45f8 /rust/helpers/helpers.c
parent388d31417ce0f1d08a1a86cab4c1dd700e9e9481 (diff)
bpf: cpumap: switch to GRO from netif_receive_skb_list()
cpumap has its own BH context based on kthread. It has a sane batch size of 8 frames per one cycle. GRO can be used here on its own. Adjust cpumap calls to the upper stack to use GRO API instead of netif_receive_skb_list() which processes skbs by batches, but doesn't involve GRO layer at all. In plenty of tests, GRO performs better than listed receiving even given that it has to calculate full frame checksums on the CPU. As GRO passes the skbs to the upper stack in the batches of @gro_normal_batch, i.e. 8 by default, and skb->dev points to the device where the frame comes from, it is enough to disable GRO netdev feature on it to completely restore the original behaviour: untouched frames will be being bulked and passed to the upper stack by 8, as it was with netif_receive_skb_list(). Tested-by: Daniel Xu <dxu@dxuuu.xyz> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'rust/helpers/helpers.c')
0 files changed, 0 insertions, 0 deletions