https://bugs.dpdk.org/show_bug.cgi?id=1126
Bug ID: 1126
Summary: i40e: Rx interrupt behaviour is possibly wrong
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: ivan.ma...@oktetlabs.ru
Target Milestone: ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
