<meta http-equiv="Content-Type" content="text/html; charset=GB18030"><div><span style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">Hello DPDK / net_ice maintainers,</span></div><div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">We are seeing a reproducible and concerning issue when using the net_ice PMD with DPDK 22.11.2, and we would appreciate your help diagnosing it.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">Summary</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Environment:</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- DPDK: 22.11.2</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- net_ice PCI device: 8086:159b</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- ice kernel driver: 1.12.7</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- NIC firmware: FW 7.3.6111681 (NVM 4.30)</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- IOVA mode: PA, VFIO enabled</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Multi-process socket: /var/run/dpdk/PGW/mp_socket</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- NUMA: 2, detected lcores: 112</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Bonding: pmd_bond with bonded devices created (net_bonding0 on port 4, net_bonding1 on port 5)</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Driver enabled AVX2 OFFLOAD Vector Tx (log shows "ice_set_tx_function(): Using AVX2 OFFLOAD Vector Tx")</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Problem statement:</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Our application calls rte_eth_tx_prepare before calling rte_eth_tx_burst as part of the normal transmission path.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- After the application has been running for some time (not immediate), the kernel/driver emits the following messages repeatedly:</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- ice_interrupt_handler(): OICR: MDD event</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- ice_interrupt_handler(): Malicious Driver Detection event 3 by TCLAN on TX queue 1025 PF# 1</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- We are using a single TX queue (application-level single queue) and are sending only one packet per burst (burst size = 1).</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- The sequence is: rte_eth_tx_prepare (returns) -> rte_eth_tx_burst -> MDD events occur later.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- The events affect stability and repeat over time.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">Relevant startup logs (excerpt)</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">EAL: Detected CPU lcores: 112</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">EAL: Detected NUMA nodes: 2</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">EAL: Selected IOVA mode 'PA'</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">EAL: VFIO support initialized</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">EAL: Probe PCI driver: net_ice (8086:159b) device: 0000:3b:00.1 (socket 0)</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">ice_load_pkg_type(): Active package is: 1.3.45.0, ICE COMMS Package (double VLAN mode)</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">ice_dev_init(): FW 7.3.6111681 API 1.7</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">...</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">bond_probe(3506) - Initializing pmd_bond for net_bonding0</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">bond_probe(3592) - Create bonded device net_bonding0 on port 4 in mode 1 on socket 0.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">...</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">ice_set_tx_function(): Using AVX2 OFFLOAD Vector Tx (port 0).</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">TELEMETRY: No legacy callbacks, legacy socket not created</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">What we have tried / preliminary observations</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Confirmed application calls rte_eth_tx_prepare prior to rte_eth_tx_burst.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- Confirmed single TX queue configuration and small bursts (size = 1) бк not high-rate, not a typical high-burst/malicious pattern.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- The MDD log identifies "TX queue 1025"; unclear how that maps to our DPDK queue numbering (we use queue 0 in the app).</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- No obvious other DPDK errors at startup; interface initializes normally and vector TX is enabled.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">- We suspect the driver's Malicious Driver Detection (MDD) is triggering due to some descriptor/doorbell ordering or offload interaction, possibly related to AVX2 Vector Tx offload.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">Questions / requests to the maintainers</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">1. What specifically triggers "MDD event 3 by TCLAN" in net_ice? Which driver check/threshold corresponds to event type 3?</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">2. How is the "TX queue 1025" value computed/mapped in the log? (Is it queue id + offset, VF mapping, or an internal vector id?) We need to map that log value to our DPDK queue index.</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">3. Can the rte_eth_tx_prepare + rte_eth_tx_burst call pattern cause MDD detections under any circumstances? If so, are there recommended usage patterns or ordering constraints to avoid false positives?</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">4. Are there known firmware/driver/DPDK version combinations with similar MDD behavior? Do you recommend specific NIC firmware, kernel driver, or DPDK versions as a workaround/fix?</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">5. Any suggested workarounds we can test quickly (e.g., disable vector TX offload, disable specific HW offloads, change interrupt/queue bindings, or adjust doorbell behavior)?</div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";"><br></div><div style="font-family: "lucida Grande", Verdana, "Microsoft YaHei";">Best regards.</div></div>