@bz I'd rebase this review and commit if you don't have time now.

In D56383#1293150, @bz wrote:

You could write this "This is effectively a refined version of the code written by bz@ in D55320." as part of the final commit message as:

Obtained from: bz (initial version, D55320)
or
Based on: initial version from bz (D55320)

I'll try to give it a pass again tonight once I am done with merges from vendor trees but I think we are good to go if @tuexen has not further comments.

As soon as we were interested in the FD[ERR} field, I added another counter to track other ingress frames with errors. It can be detailed in future.

In D56383#1292511, @bz wrote:

In D56383#1292509, @dsl wrote:

Uhh, I've double-checked and dpaa2_ni_setup_if_caps is actually called on my side and reports correct changes in the csum validation/generation, but it doesn't affect the ingress frames at all:

dpaa2_ni_update_csum_flags: frc=0x10a000, fas=0x400000a00021100, csum_flags=0xf000000, csum_data=0xffff
dpaa2_ni_update_csum_flags: frc=0x10a000, fas=0x400000a00021100, csum_flags=0xf000000, csum_data=0xffff
dpaa2_ni_update_csum_flags: frc=0x30a000, fas=0x400000200021100, csum_flags=0xc000000, csum_data=0xffff

These FAS values make no sense if you look at the bits. Is this on the 2160 or on 1088?

In D56383#1292507, @bz wrote:

Unrelated but is that

1637         (void)DPAA2_CMD_NI_CLOSE(dev, child, &cmd);

at the end of dpaa2_ni_setup_if_caps correct passing &cmd instead of DPAA2_CMD_TK(&cmd, ni_token) ? I think that should be fixed.
Reported by: bz

Uhh, I've double-checked and dpaa2_ni_setup_if_caps is actually called on my side and reports correct changes in the csum validation/generation, but it doesn't affect the ingress frames at all:

In D56383#1292028, @tuexen wrote:

When enabling rx csum offload, I do the the expected flags in incoming TCP segments. So this works now. But when disabling rx csum offload, I still see the flags:

tuexen@ten64:~ % ifconfig dpni1
dpni1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
	options=48002a<TXCSUM,VLAN_MTU,JUMBO_MTU,LINKSTATE,TXCSUM_IPV6>
	ether 00:0a:fa:24:2f:c6
	inet 212.201.121.124 netmask 0xffffffe0 broadcast 212.201.121.127
	inet6 fe80::20a:faff:fe24:2fc6%dpni1 prefixlen 64 scopeid 0x2
	inet6 2a02:c6a0:4015:10::124 prefixlen 64
	media: Ethernet autoselect (1000baseT <full-duplex,master>)
	status: active
	nd6 options=821<PERFORMNUD,AUTO_LINKLOCAL,STABLEADDR>

Output of:

#!/usr/sbin/dtrace -s

#pragma D option quiet

/* 
 * Trace tcp_input to capture incoming segments. 
 * arg0 is typically a pointer to the mbuf (struct mbuf *).
 */
fbt::tcp_input:entry
{
    /* Cast arg0 to access the mbuf structure and its packet header */
    this->m = *(struct mbuf **)arg0;
    this->flags = this->m->m_pkthdr.csum_flags;

    printf("%-20Y  Flags: 0x%08x\n", walltimestamp, this->flags);
}
fbt::tcp6_input:entry
{
    /* Cast arg0 to access the mbuf structure and its packet header */
    this->m = *(struct mbuf **)arg0;
    this->flags = this->m->m_pkthdr.csum_flags;

    printf("%-20Y  Flags: 0x%08x\n", walltimestamp, this->flags);
}

is:

2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000
2026 Apr 16 22:04:38  Flags: 0x0c000000

This is for TCP/IPv6. I would have expected 0. Is my expectation wrong?

In D56383#1291193, @tuexen wrote:

Looks good to me, will test it tomorrow. Right now my test system is not reachable and I am only back to my lab tomorrow.

Fixed

I've fixed the comments and added another review (D56383) which is currently in progress.

Usually, there's drm-drivers.adoc report which summarizes activities regarding the drm-kmod drivers. It might be a good idea to include mine if the drm-drivers.adoc will appear.

@tuexen Thanks for a quick response!

Okay, I see. if_inc_counter() is implemented with counter_u64_add which is atomic on arm64, i.e. no synchronization is required. I don't think there's noticeable overhead either, i.e. lgtm.

Can we hide those counters behind a macro (e.g. DPAA2_DEBUG)?

e.g. sysctl dev.dpaa2_ni.0 is not enough?

@bz you meant IFCAP_HWCSUM_IPV6, didn't you? Hmm, I haven't tested it yet. Probably a good idea before committing changes.

In D53436#1224250, @bz wrote:

Beware that this (L4), if I read it correctly, will also enable RX/TX checksum validation/generation for upper layer protocols for IPv6 packets even if that is not not advertised or enabled.

This change seems trivial to me. I'd simply commit it if there are no objections.

I'd like to know objections, if any.

Updated to 0.1.4

Ping

Ping

Successfully compiled on:

In D51631#1179574, @diizzy wrote:

Comment out this line, https://github.com/vchimishuk/loderunner-ng/blob/master/CMakeLists.txt#L24

World for arm64 can be built with 905541dd6ba4 without my changes. I'll abandon this review then.

Could you add a short test plan to follow?

I can build a kernel with ACPI_DEBUG without any troubles, but my Honeycomb has to be revived. Could you give it a try @phk @bz ?

LGTM, but why "half-working"? Is there BFP_MTAP on Rx somewhere?

LGTM, thanks @bz