Re: [PATCH net-next 00/10] net: faster and simpler CRC32C computation

Eric Biggers
2025-05-11T17:29:37Z

On Sun, May 11, 2025 at 06:30:25PM +0200, Andrew Lunn wrote:
> On Sat, May 10, 2025 at 05:41:00PM -0700, Eric Biggers wrote:
> > Update networking code that computes the CRC32C of packets to just call
> > crc32c() without unnecessary abstraction layers. The result is faster
> > and simpler code.
>
> Hi Eric
>
> Do you have some benchmarks for these changes?
>
> Andrew

Do you want benchmarks that show that removing the indirect calls makes things
faster? I think that should be fairly self-evident by now after dealing with
retpoline for years, but I can provide more details if you need them.

Removing the inefficient use of crc32c_combine() makes a massive difference on
fragmented sk_buffs, since crc32c_combine() is so slow (much slower than the CRC
calculation itself). However, reverting the workaround commit 4c2f24549644
("sctp: linearize early if it's not GSO") is beyond the scope of this patchset,
so for now the sctp stack doesn't actually call skb_crc32c() on fragmented
sk_buffs. I can provide microbenchmarks of skb_crc32c() on a fragmented sk_buff
directly though, if you don't think it's clear already.

Of course, please also keep in mind the -118 line diffstat. Even if it wasn't
faster we should just do it this way anyway.

- Eric