Add limited support for Intel I226-V

[chrisjlapp]

Summary:
This PR adds documented Intel I226-V limited support for both DPDK and native AF_XDP operation.
This is not intended to support ST 2110-21 Support, but is sufficient for ST 2110-30, and compressed video media types.

Changes include:

• Add an I226-V build helper and Ubuntu setup documentation.
• Add a complete I226-V runtime guide covering DPDK, VFIO, AF_XDP, MTL Manager, PTP, and queue configuration.
• Fix the DPDK IGC hardware-timesync initialization order.
• Document external ptp4l/phc2sys synchronization for AF_XDP.
• Add the I226 guide to the documentation index.

DPDK root cause and fix:
The IGC PMD cannot enable timesync at the same point as the existing PF path. Enabling timesync before RX queues are configured can access uninitialized queues. Enabling it only after rte_eth_dev_start() fails to reserve the RX timestamp prefix, corrupting received packets. IGC port start also resets timestamp registers.
The new IGC-specific sequence is:

1. Configure RX and TX queues.
2. Enable timesync before port start.
3. Start the Ethernet device.
4. Enable timesync again to restore the reset timestamp registers.
   This behavior is gated on MT_DRV_IGC. The existing ICE/E800 startup path is unchanged.

AF_XDP notes:

Native AF_XDP keeps the I226 under the kernel igc driver, allowing Linux ptp4l and phc2sys to manage the PHC and system clock. Multiple MTL applications can share that disciplined clock without using RxTxApp’s built-in --ptp mode.
The guide also documents:

• MTL Manager and BPF object installation.
• AF_XDP queue allocation.
• Avoiding competing NTP/systemd clock servos.
• PTP v2.0 compatibility using --ptp_minor_version 0.
• UTC-versus-TAI clock handling.
  Validation:
• Standard DPDK build passed.
• AF_XDP-enabled build passed.
• I226-V tested at 1GbE with DPDK 25.11.
• DPDK built-in UDP/IPv4 multicast PTP reached working Sync, Follow Up, Announce, Delay Request, and Delay Response
  exchanges in domain 0.
• DPDK audio transmission held approximately 1000 frames/s.
• Native AF_XDP completed a 120-second ST 2110-30 audio TX test.
• AF_XDP held 1000 frames/s at 1.968 Mb/s.
• RxTxApp exited successfully.
• XDP remained attached while ptp4l stayed in SLAVE.
• Final observed master offset was approximately −71 ns.
• Mean path delay was approximately 109 ns.

Files changed:

• doc/build.md
• doc/run.md
• doc/run_i226.md
• index.rst
• lib/src/dev/mt_dev.c
• script/build_i226v.sh

Known observation:
AF_XDP teardown reported outstanding RX mbufs and full TX-ring warnings after transmission stopped. These warnings did not cause runtime packet loss or a nonzero application exit during the validated run.
Investigation:
The warnings should not prevent later streams in the normal “new RxTxApp process” model.
Evidence from five consecutive AF_XDP start/stop cycles:

• All five initialized queues 1–3 successfully.
• No no free queue errors.
• Every process exited with code 0.
• Steady-state audio returned to 1000 fps / 1.968 Mb/s.
• MTL Manager memory stayed effectively flat: 4,856 → 4,876 KiB.
• Teardown added approximately two seconds per process.
  Impact:
• tx prod full: shutdown padding retries after media stops; it does not represent runtime media loss or a permanently full
  queue.
• Outstanding RX mbufs: approximately 25–30 MB remains process-local because XSK fill-ring buffers are not reclaimed
  before mempool cleanup. Process exit releases it.
• Repeated full mtl_init()/mtl_uninit() cycles inside one long-lived process could accumulate memory and should be treated as
  a real cleanup defect.
• Creating new streams inside an existing MTL instance should reuse the existing XSK queues and buffers, so this warning
  alone should not block them.

Conclusion: low operational risk for separately launched applications, but worth a separate AF_XDP cleanup issue for long-lived daemons and repeated in-process initialization.

This behavior is pre-existing and unrelated to the I226v itself

[DawidWesierski4]

Hi, sorry for the "abandonment" of this PR. We are trying to prepare our CI/CD to be able to test and validate the jobs on these cards. This requires us to first create a hardware setup and custom testing scopes, as the limited throughput of this card is making most tests we run impossible.
I am working on it right now, and I plan to first validate your PR against it, then merge it.
The timeline to have that all figured out is up to September. But if you need this functionality in main before that, I am fine with reviewing this PR earlier and adding the tests afterward.
Again, sorry for the long delay.

[chrisjlapp]

no worries,
I am not in any rush, I am it already anyway.
I mostly finished the PR for Maciej,

If you cant get your hands on any hardware and need a machine to test on, let me know, i can provide access.

[DawidWesierski4]

Hi i wanted to add some testing and other functionality so i cherry picked your changes into my branch
#1677
i preserved the auther and plan to rebase the chagne so the change will have your name on it but i changed them tad bit so it passes our doc/coding-standard.md

please review it, and don't hesitate to be brutal about feedback