Re: [dpdk-dev] [RFC 0/7] make rte_intr_handle internal

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 26 Aug 2021 20:27:19 +0530
Harman Kalra <hkalra@marvell.com> wrote:

> Moving struct rte_intr_handle as an internal structure to
> avoid any ABI breakages in future. Since this structure defines
> some static arrays and changing respective macros breaks the ABI.
> Eg:
> Currently RTE_MAX_RXTX_INTR_VEC_ID imposes a limit of maximum 512
> MSI-X interrupts that can be defined for a PCI device, while PCI
> specification allows maximum 2048 MSI-X interrupts that can be used.
> If some PCI device requires more than 512 vectors, either change the
> RTE_MAX_RXTX_INTR_VEC_ID limit or dynamically allocate based on
> PCI device MSI-X size on probe time. Either way its an ABI breakage.
> 
> Change already included in 21.11 ABI improvement spreadsheet (item 42):
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_s
> preadsheets_d_1betlC000ua5SsSiJIcC54mCCCJnW6voH5Dqv9UxeyfE_edit-23gid-
> 3D0&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=5ESHPj7V-7JdkxT_Z_SU6RrS37ys4U
> XudBQ_rrS5LRo&m=7dl3OmXU7QHMmWYB6V1hYJtq1cUkjfhXUwze2Si_48c&s=lh6DEGhR
> Bg1shODpAy3RQk-H-0uQx5icRfUBf9dtCp4&e=
> 
> 
> This series makes struct rte_intr_handle totally opaque to the outside
> world by wrapping it inside a .c file and providing get set wrapper APIs
> to read or manipulate its fields.. Any changes to be made to any of the
> fields should be done via these get set APIs.
> Introduced a new eal_common_interrupts.c where all these APIs are defined
> and also hides struct rte_intr_handle definition.

I agree rte_intr_handle and eth_devices structure needs to be hidden.
But there does not appear to be an API to check if device supports
receive interrupt mode.

There is:
   RTE_ETH_DEV_INTR_LSC  - link state
   RTE_ETH_DEV_INTR_RMV  - interrupt on removal

but no
   RTE_ETH_DEV_INTR_RXQ  - device supports rxq interrupt

There should be a new flag reported by devices, and the intr_conf should
be checked in rte_eth_dev_configure

Doing this would require fixes many drivers and there is risk of exposing
existing sematic bugs in applications.


code