Hi Simon,
This change is required in octep_iq_process_completions, as given in the patch,
since the scatter gather pointer lengths arrive as big-endian in hardware.
On Tue, 2023-09-12 at 00:04 -0700, Shinas Rasheed wrote:
> This change is required in octep_iq_process_completions, as given in the patch,
> since the scatter gather pointer lengths arrive as big-endian in hardware.
I guess Simon intended asking about octep_iq_free_pending(), and AFAICT
your reply confirm that the change is required there, too.
Additionally the changelog really need to be expanded. I don't
understand how this change relates to endianess: if the ring format is
big endian I expect some be16_to_cpu(len) instead of complement-to-4 of
indexes.
Please clarify and expand the changelog, thanks!
Paolo
Hi Paolo, Hi Simon,
From: Paolo Abeni <[email protected]>
Sent: Tuesday, September 12, 2023 2:15 PM
To: Shinas Rasheed <[email protected]>; [email protected] <[email protected]>
Cc: Abhijit Ayarekar <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Haseeb Gani <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Satananda Burla <[email protected]>; Sathesh B Edara <[email protected]>; Veerasenareddy Burru <[email protected]>; Vimlesh Kumar <[email protected]>
Subject: [EXT] Re: [net PATCH] octeon_ep: fix tx dma unmap len values in SG
?
External Email
----------------------------------------------------------------------
>I guess Simon intended asking about octep_iq_free_pending(), and AFAICT
your reply confirm that the change is required there, too.
You are correct in that the change is also required in octep_iq_free_pending as well. Thanks for pointing that out!
I will submit another version of this patchset including that.
>Additionally the changelog really need to be expanded. I don't
understand how this change relates to endianess: if the ring format is
big endian I expect some be16_to_cpu(len) instead of complement-to-4 of
indexes.
The bytes are in itself not big endian, but rather the each of the 16 bytes are kept in memory in
a kind of big-endian order. Apologizing for the confusion.
63 48 47 32 31 16 15 0
| Len0 | Len1 | Len2 | Len3 |
I shall provide an ascii figure like above in the code to explain and also update the changelog accordingly. Thanks for your time!