>ZjQcmQRYFpfptBannerEnd >On Wed, Jul 31, 2024 at 06:06:33PM +0200, Thomas Monjalon wrote: >> 31/07/2024 13:01, Thomas Monjalon: >> > 30/07/2024 19:27, Jerin Jacob: >> > > On Tue, Jul 30, 2024 at 8:25 PM Amit Prakash Shukla >> > > <[email protected]> wrote: >> > > > >> > > > A new flag RTE_DMA_CAPA_QOS will be introduced to advertise dma >> > > > device's QoS capability. In order to support the parameters for >> > > > this flag, new fields will be added in rte_dma_info and >> > > > rte_dma_conf structures to get device supported priority levels >> > > > and to configure the required priority level. >> > > > >> > > > Signed-off-by: Vamsi Attunuru <[email protected]> >> > > > Signed-off-by: Amit Prakash Shukla <[email protected]> >> > > >> > > >> > > Acked-by: Jerin Jacob <[email protected]> >> > >> > Acked-by: Thomas Monjalon <[email protected]> >> >> The RFC and the deprecation notices are sent a bit late. >> We cannot conclude there is consensus. >> >> I propose to raise it to the techboard if an ABI breakage is still required >> for >24.11. >> As dmadev is quite new, I don't think it is big issue. >> >No objection to changing the structures. However, for the actual >implementation we'll have to review the changes to ensure they are clear >enough to allow potential alternative implementations. For example, I worry >about just having one "QoS" flag defined - how would we manage if different >QoS schemes are implemented by various hw vendors in different ways? > >For the notice about structure changes though: >Acked-by: Bruce Richardson <[email protected]>
This feature was renamed because it required consideration of advanced scheduling schemes, Strict priority support was added at a later stage. https://inbox.dpdk.org/dev/[email protected]/
