Re: [EXT] Re: [net PATCH] octeon_ep: fix tx dma unmap len values in SG

[Shinas Rasheed]

Hi Paolo, Hi Simon,


From: Paolo Abeni <pabeni@xxxxxxxxxx>
Sent: Tuesday, September 12, 2023 2:15 PM
To: Shinas Rasheed <srasheed@xxxxxxxxxxx>; horms@xxxxxxxxxx <horms@xxxxxxxxxx>
Cc: Abhijit Ayarekar <aayarekar@xxxxxxxxxxx>; davem@xxxxxxxxxxxxx <davem@xxxxxxxxxxxxx>; edumazet@xxxxxxxxxx <edumazet@xxxxxxxxxx>; egallen@xxxxxxxxxx <egallen@xxxxxxxxxx>; Haseeb Gani <hgani@xxxxxxxxxxx>; kuba@xxxxxxxxxx <kuba@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; mschmidt@xxxxxxxxxx <mschmidt@xxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx <netdev@xxxxxxxxxxxxxxx>; Satananda Burla <sburla@xxxxxxxxxxx>; Sathesh B Edara <sedara@xxxxxxxxxxx>; Veerasenareddy Burru <vburru@xxxxxxxxxxx>; Vimlesh Kumar <vimleshk@xxxxxxxxxxx>
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!