On Tue, 23 Jun 2026 17:21:59 +0000 Gagandeep Singh <[email protected]> wrote:
> It seems that AI reviewed the V2 series instead of the V3 series. I have > manually verified that the first two issues are fixed in the V3 series. For > the last issue, I will submit a separate patch as a new feature, introducing > KEEP_CRC for the enetc4 driver. Additionally, AI has acknowledged that there > will be no functional issue as of now, since crc_len will be only 0. It was my bad, was looking earlier in that chat. Looks clean will apply For V3: v3 re-review. I diffed every patch against v2; the only substantive code change is in 7/9, and the rest of the delta is documentation. Both v2 blockers are resolved: The kvlist leak in enetc4_vf_dev_init() (was Error) is fixed — rte_kvargs_free(kvlist) now precedes both the invalid-timeout and invalid-delay return -1 paths. The missing devargs documentation (was Warning) is now in doc/guides/nics/enetc4.rst: a new "Driver Arguments (devargs)" section split into VF-specific (enetc4_vsi_disable, enetc4_vsi_timeout, enetc4_vsi_delay) and PF/Common (enetc4_txq_prior, nc) subsections, each with a usage example. Section underlines are the correct length (19/19 and 17/17), so it builds clean under -W; defaults and applicability match the code. No new issues introduced — patches 1–6 and 8 are byte-identical to v2 apart from the doc hunks, and patch 9's only delta is the nc doc plus line-number offsets shifted by patch 7's two added lines. For the record, the one item carried over from v2 is unchanged and remains non-blocking: in the RX reassembly paths, first_seg->pkt_len -= crc_len at frame-last doesn't adjust the final segment's data_len, so pkt_len != sum(data_len) if crc_len != 0. This stays latent because enetc4 doesn't advertise RTE_ETH_RX_OFFLOAD_KEEP_CRC (crc_len is always 0). Worth a guard only if KEEP_CRC is ever added; not a reason to hold the series. No open errors, no open warnings.
