> From: Jerin Jacob [mailto:jerinjac...@gmail.com] > Sent: Monday, 29 July 2024 17.20 > > On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru <vattun...@marvell.com> > wrote: > > > > Announce addition of new capability flag and fields in > > rte_dma_info and rte_dma_conf structures. > > The new capability flag won't break ABI. We can mention only fields > update rte_dma_info and rte_dma_conf structures. > > Another option is new set APIs for priority enablement. The downside > is more code. All, opinions?
I think that this feature should be simple enough to expand the rte_dma_info and rte_dma_conf structures with a few new fields, rather than adding a new set of APIs for it. It seems to become 1-level weighted priority scheduling of a few QoS classes, not hierarchical or anything complex enough to justify a new set of APIs. Just a simple array of per-class properties. The max possible number of QoS classes (i.e. the array size) should be build time configurable. Considering Marvell hardware, it seems 4 would be a good default.
