dpaa2: dpaa2_ni_rx() RX checksum EN/ERR information for L3/4

[bz]

Summary

In order to enable RX checksum offloading we need to check the
meta-information for the (good) frames to see if the L3/4 checksums
were calculated and if there was an error.

The way the buffere are setup, the needed frame meta-information is
already requested. All we have to do is make sure it is really part
of the RX frame, that it is valid, and if the respective bits are set.

Also do not forget to set the (dummy) csum_data as otherwise upper
layers will just be cranky. An artefact of the past which likely
should disappear.

MFC after: 3 days

[tuexen]

I tested it on a ten64 machine, it works as expected.

[dsl]

sys/dev/dpaa2/dpaa2_ni.c

3239

I'd prefer struct dpaa2_fa to be updated like https://codeberg.org/dsl/freebsd-src/commit/187a7365a9df4876d67c9ae9297d5176efff7fdb#diff-7f8a4f78823a47cee01cc1985ef9b8a0912dcd5d

[bz]

sys/dev/dpaa2/dpaa2_ni.c

3239

Are always all fields part of the reply and just not valid if the bit is not set in the FRC? I thought the reason of ASAL was that the length be flexible. And then the idea of that struct breaks as soon as one adds any of the later fields but FAS not being valid. I need to go and read the datasheet again to see.

[bz]

sys/dev/dpaa2/dpaa2_ni.c

3239

I'll rework this and a few other bits.

[dsl]

sys/dev/dpaa2/dpaa2_ni.c

3228

Where did you get those bits documented? I'm looking at the 7.31.2 WRIOP FD frame context (FRC) of LX2160A DPAA2 Low-Level Hardware Reference Manual, Rev. 0, 06/2020 and bits 24-31 described as "other DPAA2.0 accelerators annotation valid" only.

[bz]

sys/dev/dpaa2/dpaa2_ni.c

3228

I assume Table 7-7. FD[FRC] WRIOP Description from
LS1088A Family DPAA2 Low-Level Hardware Reference Manual (LS1088ADPAA2RM), Rev. 0, 02/2021