net: xilinx: axienet: Query about checksum partial implementation

Simon Horman horms at kernel.org
Fri Jul 26 05:07:00 PDT 2024


Hi Radhey, all,

I am wondering if you could shed some light on the following
checksum partial handling in the axienet_rx_poll():

                        /* if we're doing Rx csum offload, set it up */
                        if (lp->features & XAE_FEATURE_FULL_RX_CSUM) {
				...
                        } else if ((lp->features & XAE_FEATURE_PARTIAL_RX_CSUM) != 0 &&
                                   skb->protocol == htons(ETH_P_IP) &&
                                   skb->len > 64) {
                                skb->csum = be32_to_cpu(cur_p->app3 & 0xFFFF);
                                ...
                        }

In particluar the "skb->csum =" line.

The type of cur_p->app3 is u32, and 0xFFFF is also host byte order.
So far so good. But after the bitwise operation it is treated
as a big-endian value by passing it to be32_to_cpu.

Perhaps I am missing something obvious, but my question is how does that work?

* Was it only tested on big endian sysgtems where be32_to_cpu() is a no-op

* Was it only tested on little endian systems where be32_to_cpu()
  is a byteswap and somehow that works (how?).

* Is the code unecessised because the XAE_FEATURE_FULL_RX_CSUM branch is
  always taken?

  A grep of dts files shows up arch/microblaze/boot/dts/system.dts which
  sets sets xlnx,rxcsum to 0, which corresponds to XAE_NO_CSUM_OFFLOAD.

* Something else

Flagged by Sparse

The in quesoitn code seems to have been introduced by
8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")





More information about the linux-arm-kernel mailing list