Add open-questions doc for pre-hardware deep-dive

2026-08-10 11:31:19 -07:00
parent 44e010caa9
commit 8c8e0c7d32
2 changed files with 31 additions and 0 deletions
@@ -8,5 +8,6 @@ Project knowledge that moves and versions with the repo.
 - [transports.md](transports.md) — how to reach module-PHY diagnostics, why the NIC choice governs it, and the register-level protocols.
 - [modules.md](modules.md) — per-module diagnostics, register maps, cable-length physics, and the Marvell brick hazard.
 - [measurement.md](measurement.md) — how to measure correctly; performance results and dead ends.
 - [open-questions.md](open-questions.md) — genuinely open problems worth deeper thinking before the X520 hardware arrives.
 Vendor PDFs (BCM84891L transport + command handler, Marvell 88E151x datasheet) live alongside these.
@@ -0,0 +1,30 @@
 # Open questions
 The genuinely open, thinking-worthy problems — not mechanical tasks. Read the rest of `docs/` first (`state.md`, `transports.md`, `modules.md`, `measurement.md`); this assumes that context.
 Short framing: cabletest stresses 10GBASE-T copper cables at full-duplex 10G and attributes loss/errors to the cable. We're swapping the E810 out for an Intel X520-DA2 (82599, `ixgbe`) so the host can bit-bang the SFP module I2C bus (the E810/i40e firmware blocked or couldn't frame it). Diagnostics clients and a raw-i2c kernel patch are prebuilt but untested. Test modules: FS SFP-10G-T-100 (Broadcom BCM84891L, fully documented) and replacement Wiiteks (Marvell CUX3610, brick-prone). All modules are copper lying as fiber.
 ## 1. Raw-L2 RX steering on 82599 (gates whether cabletest runs on the X520 at all)
 The tool steers raw ethertype 0x88b5 to per-queue NAPI contexts via Flow Director; ixgbe rejects ETHER_FLOW. But `FDIRCTRL_FLEX_SHIFT` is already set to 0x6 = byte offset 12 = the ethertype field, so the hardware samples it. Open: will a non-IP frame classify into an fdir flow_type the rule engine matches, and does pairing `flex_bytes` with a permissive base flow type need a driver change? Alternative: MAC→VMDq-pool steering (distinct dest MACs → queues, fully raw). Think through both against the 82599 datasheet before committing; UDP/bare-IP encap is the last resort we want to avoid. See the steering section of state.md.
 ## 2. Can 82599 sustain zero-baseline-loss 2×10G full duplex, and what happens to timestamping?
 It's older/Gen2 silicon. The whole tool depends on *exactly zero* host-side loss (see measurement.md). Separately: the cable-length-via-timestamp idea assumed two ports on one NIC sharing a PHC with usable TX+RX hardware timestamps — 82599's PTP is limited (largely PTP-only, sparse). Re-examine whether the timestamp path-delay length measurement is even viable on this NIC, or whether it dies with the E810.
 ## 3. Consolidate the cable-length strategy — currently three partial paths
 - **BCM ECD/DSP register** — real, but the ECD chapter is missing from FS's docs. What's the fallback if FS doesn't deliver: mine the Broadcom SDK/patents, or lean on the QCA/Marvell CDT analogy?
 - **Marvell VCT/DSP** — undocumented, and gated behind a firmware trap that permanently bricks the module on certain reads (`*.0x??64`, high window; see modules.md). Is there *any* safe route, or is it strictly vendor-docs-or-sacrificial-unit?
 - **Timestamp path-delay** — see item 2.
 Decide which is the product path vs. nice-to-have.
 ## 4. Two-master I2C safety + correctness of the untested clients
 The `ixgbe` driver polls the SFP EEPROM (DOM/qualification) on its own; our `sff_i2c` transactions share the bus. The swfw semaphore *should* serialize us, but verify the reasoning. Also scrutinize framing assumptions we couldn't test:
 - the BCM SMI read's >1 ms inter-transaction delay adequacy;
 - the EEPROM-read assumption that the word-address pointer persists across STOP;
 - whether RollBall's mailbox read (set-pointer-then-read as two separate transactions) matches what the module expects vs. the kernel `mdio-i2c` combined-transfer form.
 ## 5. Pre-FEC error visibility — design the experiment
 No module exposes a pre-FEC counter in reachable space; the Aquantia `3.e820` clear-on-read counter is the best candidate but is unclassified (pre- vs post-FEC) because it won't move on a healthy short link. cabletest's own noise pair can create a marginal channel — design the correlation (module counter vs. host CRC/loss under graded noise) that would classify it and turn it into a real leading indicator.
 ## 6. Architecture sanity check
 Is putting *both* test traffic and module diagnostics on the X520 right, given its steering/timestamp weaknesses, or is there a cleaner split (traffic on a NIC that steers well, diagnostics on the X520)? The tension: the modules under test are where the traffic physically flows, so splitting is awkward — but worth pressure-testing the assumption.