> Hi Alexander, > > On Tue, Jun 28, 2022, at 12:47 PM, Alexander Lobakin wrote: > > 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 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. > > It is most beneficial when a NIC which frame come from is XDP > > generic metadata-enabled, but in plenty of tests GRO performs better > > than listed receiving even given that it has to calculate full frame > > checksums on 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 point 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(). > > > > Signed-off-by: Alexander Lobakin <alexandr.lobakin@xxxxxxxxx> > > --- > > kernel/bpf/cpumap.c | 43 ++++++++++++++++++++++++++++++++++++++----- > > 1 file changed, 38 insertions(+), 5 deletions(-) > > > > 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. > > 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). 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. Regards, Lorenzo > > Thanks, > Daniel >
Attachment:
signature.asc
Description: PGP signature
