Re: [Announce] rxe dev tree available (soft RDMAoE)

Roland Dreier
2009-12-17T21:56:53Z

> We have thought that we could try CRC32C first and if that works then use
> that, otherwise fall back to CRC32 which would allow rxe to use CRC32C when
> talking to itself and get a speedup on new Intel CPUs.

How would you negotiate that? Is this being worked in the definition of
the IBoE spec? It seems in a final standard, having something stronger
than two CRC32s and something that can handle jumbo frames would be
worth it.

> The crc32 code we have is based on some suggestions from Intel and seems to
> be much faster than the 'standard' code in the kernel and we are/were
> planning to merge the crc computation with the data copy. It is actually
> less explicitly optimized than the code in the kernel but when we use the
> loop unrolling directive in the compiler we get better overall results. That
> core loop gives us about 5-6GB/sec for the copy/crc vs about 500MB/sec for
> the 'standard' crc + copy.

Interesting ... can the upstream kernel code be improved similarly?

> Our plan is to strip out all the trace and dump code when the driver is
> stable. We will keep the warn and error messages.

If you develop upstream and use the ftrace tracepoints stuff then the
overhead of (runtime) disabled trace points is nearly zero (one 5-byte
NOP, so a cycle or two). So you can keep them forever (which is
realistically how long you're going to be debugging this :)

- R.