On Sat, 4 Dec 2021 22:54:58 +0530 <jer...@marvell.com> wrote: > + /** > + * Maximum supported traffic class as per PFC (802.1Qbb) specification. > + * > + * Based on device support and use-case need, there are two different > + * ways to enable PFC. The first case is the port level PFC > + * configuration, in this case, rte_eth_dev_priority_flow_ctrl_set() > + * API shall be used to configure the PFC, and PFC frames will be > + * generated using based on VLAN TC value. > + * The second case is the queue level PFC configuration, in this case, > + * Any packet field content can be used to steer the packet to the > + * specific queue using rte_flow or RSS and then use > + * rte_eth_dev_priority_flow_ctrl_queue_set() to set the TC mapping > + * on each queue. Based on congestion selected on the specific queue, > + * configured TC shall be used to generate PFC frames. > + * > + * When set to non zero value, application must use queue level > + * PFC configuration via rte_eth_dev_priority_flow_ctrl_queue_set() API > + * instead of port level PFC configuration via > + * rte_eth_dev_priority_flow_ctrl_set() API to realize > + * PFC configuration. > + */ > + uint8_t pfc_queue_tc_max; > + uint8_t reserved_8s[7]; > + uint64_t reserved_64s[1]; /**< Reserved for future fields */ > void *reserved_ptrs[2]; /**< Reserved for future fields */
Not sure you can claim ABI compatibility because the previous versions of DPDK did not enforce that reserved fields must be zero. The Linux kernel learned this when adding flags for new system calls; reserved fields only work if you enforce that application must set them to zero.
