From: Eric Biggers <ebiggers@kernel.org>
To: Zhu Yanjun <yanjun.zhu@linux.dev>
Cc: linux-rdma@vger.kernel.org,
Mustafa Ismail <mustafa.ismail@intel.com>,
Tatyana Nikolova <tatyana.e.nikolova@intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Zhu Yanjun <zyjzyj2000@gmail.com>,
Bernard Metzler <bmt@zurich.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] RDMA/rxe: handle ICRC correctly on big endian systems
Date: Wed, 29 Jan 2025 19:02:15 +0000 [thread overview]
Message-ID: <20250129190215.GB2619178@google.com> (raw)
In-Reply-To: <d0d05601-0eee-4684-9ed0-d6da8938603b@linux.dev>
On Wed, Jan 29, 2025 at 07:27:20PM +0100, Zhu Yanjun wrote:
> 在 2025/1/27 23:38, Eric Biggers 写道:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > The usual big endian convention of InfiniBand does not apply to the
> > ICRC field, whose transmission is specified in terms of the CRC32
> > polynomial coefficients. The coefficients are transmitted in
> > descending order from the x^31 coefficient to the x^0 one. When the
> > result is interpreted as a 32-bit integer using the required reverse
> > mapping between bits and polynomial coefficients, it's a __le32.
> In InfiniBand Architecture Specification, the following
> "
> 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.
> "
> and
> "
> The 32 Flip-Flops are initialized to 1 before every ICRC generation. The
> packet is fed to the reference design of Figure 57 one bit at a time in the
> order specified in Section 7.8.1 on page 222. The Remainder is the bitwise
> NOT of the value stored at the 32 Flip-Flops after the last bit of the
> packet was clocked into the ICRC Generator. ICRC 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.
> "
>
> It seems that big endian byte ordering is needed in ICRC field. I am not
> sure if MLX NIC can connect to RXE after this patchset is applied.
As I mentioned in my response to Jason, it's a least-significant-bit first CRC,
so the mapping between bits and polynomial coefficients is reversed from the
natural order. So that needs to be kept in mind.
In "Figure 56 ICRC Generator" (looking at
https://www.afs.enea.it/asantoro/V1r1_2_1.Release_12062007.pdf) that shows the
sample hardware, it looks like what's going on is that the bytes are already
reversed in the hardware, i.e. what it calls bits 0 through 7 are the
coefficients of x^0 through x^7, which in a software implementation are actually
in bits 31 through 24. Thus in software it would be a __le32.
- Eric
next prev parent reply other threads:[~2025-01-29 19:02 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
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 [this message]
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=20250129190215.GB2619178@google.com \
--to=ebiggers@kernel.org \
--cc=bmt@zurich.ibm.com \
--cc=jgg@ziepe.ca \
--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