We've been seeing odd behaviour of Rx interrupts on i40e rigs in the opensource ethdev test suite [1]. There's a test, "usecases/rx_intr", which checks various corner cases.

In particular, as shown in log [2], when the test enables Rx interrupts and attempts to receive two packets in a row (though, not in a single burst), an interrupt is triggered once, that is, for the 1st packet only. This result suggests that the driver does not automatically re-enable ("rearm") interrupts, which might be incorrect.

At the same time, according to the API contract, once the application has invoked rte_eth_dev_rx_intr_enable, interrupts are not supposed to stop working when the 1st packet arrives. Instead, it is only when the application invokes rte_eth_dev_rx_intr_disable that interrupts shall cease to arrive.

That is also supported by a statement found in Intel(R) Ethernet Controller X710/ XXV710/XL710 Datasheet, section 7.5.1.3, which is as follows: "At the end of the interrupt handler the software re-enables the interrupts by setting the INTENA".

Another corner case (see [3]) is to check whether normal poll mode Rx resumes working when the application first enables Rx interrupts and then opts to disable the feature. In the case of i40e, normal Rx poll mode is not restored: the test doesn't see the packet after disabling interrupts. Might be incorrect behaviour as well.

[1] https://mails.dpdk.org/archives/dev/2022-October/251663.html
[2] https://ts-factory.io/bublik/v2/log/189828?focusId=190963&mode=treeAndlog
[3] https://ts-factory.io/bublik/v2/log/189828?focusId=190961&mode=treeAndlog