From: Jason Gunthorpe <jgg@ziepe.ca>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Zhu Yanjun <yanjun.zhu@linux.dev>,
linux-rdma@vger.kernel.org,
Mustafa Ismail <mustafa.ismail@intel.com>,
Tatyana Nikolova <tatyana.e.nikolova@intel.com>,
Leon Romanovsky <leon@kernel.org>,
Zhu Yanjun <zyjzyj2000@gmail.com>,
Bernard Metzler <bmt@zurich.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/6] RDMA/rxe: handle ICRC correctly on big endian systems
Date: Wed, 29 Jan 2025 21:29:51 -0400 [thread overview]
Message-ID: <20250130012951.GF2120662@ziepe.ca> (raw)
In-Reply-To: <20250129222147.GC2619178@google.com>
On Wed, Jan 29, 2025 at 10:21:47PM +0000, Eric Biggers wrote:
> > To be most clear this should be written as:
> >
> > u32 ibta_crc = swab32(~crc32_le(..)) // Gives you the IBTA defined value
> > *packet = cpu_to_be32(ibta_crc); // Puts it in the packet
> >
> > It follows the spec clearly and exactly.
> >
> > Yes, you can get the same net effect using le:
> >
> > u32 not_ibta_crc = ~crc32_le(..)
> > *packet = cpu_to_le32(not_ibta_crc)
> >
> > It does work, but it is very hard to follow how that relates to the
> > specification when the u32 is not in the spec's format anymore.
> >
> > What matters here, in rxe, is how to use the Linux crc32 library to
> > get exactly the value written down in the spec.
> >
> > IMHO the le approach is an optimization to avoid the dobule swap, and
> > it should simply be described as such in a comment:
> >
> > The crc32 library gives a byte swapped result compared to the IBTA
> > specification. swab32(~crc32_le(..)) will give values that match
> > IBTA.
> >
> > To avoid double swapping we can instead write:
> > *icrc = cpu_to_le32(~crc32_le(..))
> > The value will still be big endian on the network.
> >
> > No need to talk about coefficients.
>
> We are looking at the same spec, right? The following is the specification for
> the ICRC field:
>
> The resulting bits are sent in order from the bit representing the
> coefficient of the highest term of the remainder polynomial. The least
> significant bit, most significant byte first ordering of the packet does not
> apply to the ICRC field.
>
> So it does talk about the polynomial coefficients.
Of course it does, it is defining a CRC.
The above text is reflected in Figure 57 which shows the Remainder
being swapped all around to produce the ICRC.
The spec goes on to say:
CRC Field is obtained from the Remainder as shown in Figure 57. ICRC
Field is transmitted using Big Endian byte ordering like every field
of an InfiniBand packet.
From a spec perspective is *total nonsense* to describe something the
spec explicitly says is big endian as little endian.
Yes from a maths perspective coefficients are reversed and whatever,
but that doesn't matter to someone reading the code. Clearly state
how to calculate the u32 "ICRC Field" as called out in the spec using
Linux. That is swab32(~crc32_le(..)) - that detail clarifies everything.
> It sounds like you want to add two unnecessary byteswaps to match
> the example in Table 25, which misleadingly shows a byte-swapped
> ICRC value as a u32 without mentioning it is byte-swapped.
There are an obnoxious number of ways to make, label and describe
these LFSRs. IBTA choose their representation, Linux choose a
different one.
It isn't misleadingly byte-swapped, it is self consistent with the
rest of the spec, and different from Linux.
> I don't agree that would be clearer, but we can do it if you prefer.
If you want to keep the le32 optimization, then keep it, but have a
comment to explain that it is an optimization based on the logical
be32 double swap that matches the plain text of the spec.
I gave an example comment above.
Jason
next prev parent reply other threads:[~2025-01-30 1:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 22:38 [PATCH 0/6] RDMA: switch to using CRC32 library functions Eric Biggers
2025-01-27 22:38 ` [PATCH 1/6] RDMA/rxe: handle ICRC correctly on big endian systems Eric Biggers
2025-01-29 9:44 ` Zhu Yanjun
2025-01-29 18:30 ` Jason Gunthorpe
2025-01-29 18:51 ` Eric Biggers
2025-01-29 19:43 ` Jason Gunthorpe
2025-01-29 20:25 ` Eric Biggers
2025-01-29 21:16 ` Jason Gunthorpe
2025-01-29 22:21 ` Eric Biggers
2025-01-30 1:29 ` Jason Gunthorpe [this message]
2025-01-30 2:04 ` Eric Biggers
2025-01-30 13:52 ` Jason Gunthorpe
2025-01-30 9:17 ` Zhu Yanjun
2025-01-30 7:27 ` Zhu Yanjun
2025-01-29 18:27 ` Zhu Yanjun
2025-01-29 19:02 ` Eric Biggers
2025-01-27 22:38 ` [PATCH 2/6] RDMA/rxe: consolidate code for calculating ICRC of packets Eric Biggers
2025-01-29 18:11 ` Zhu Yanjun
2025-01-30 2:15 ` Eric Biggers
2025-01-30 7:24 ` Zhu Yanjun
2025-01-31 2:42 ` Eric Biggers
2025-01-27 22:38 ` [PATCH 3/6] RDMA/rxe: switch to using the crc32 library Eric Biggers
2025-01-29 18:30 ` Zhu Yanjun
2025-01-27 22:38 ` [PATCH 4/6] RDMA/irdma: switch to using the crc32c library Eric Biggers
2025-01-27 22:38 ` [PATCH 5/6] RDMA/siw: fix type of CRC field Eric Biggers
2025-01-31 12:24 ` Bernard Metzler
2025-01-27 22:38 ` [PATCH 6/6] RDMA/siw: switch to using the crc32c library Eric Biggers
2025-01-31 14:17 ` Bernard Metzler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250130012951.GF2120662@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=bmt@zurich.ibm.com \
--cc=ebiggers@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mustafa.ismail@intel.com \
--cc=tatyana.e.nikolova@intel.com \
--cc=yanjun.zhu@linux.dev \
--cc=zyjzyj2000@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox