RE: [RFC] dmadev: add QoS capability

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 29 July 2024 15.27
> 
> On Mon, Jul 29, 2024 at 03:14:55PM +0200, Morten Brørup wrote:
> > > From: Vamsi Attunuru [mailto:vattunuru@marvell.com]
> > > Sent: Monday, 29 July 2024 13.56
> > >
> > > Some DMA controllers support QoS at HW command queue level to
> > > differentiate the performance on different HW queues based on
> > > the priority configured. Patch adds required fields in dmadev
> > > structures to get hardware supported priority levels and the
> > > provision to configure the priority from the applications.
> >
> > Do we foresee anything more advanced than Strict Priority scheduling for DMA
> anytime in the future?
> >
> > If not, then consider calling this new capability Prioritization (CAPA_PRIO)
> instead of Quality Of Service (CAPA_QOS). Then we don't need to add and
> describe QoS parameters for a more advanced QoS scheduling algorithm (e.g. the
> "weight" for weighted fair queueing).
> >
> 
> There could be more than just regular prioritization settings involved, so
> I think it's best to leave some options open. Even with just a
> "prioritization" setting, it could be used as a weighting vs strict priority.
> Question is whether in such a case - of a single-value number for high vs
> low priority - it's better to explicitly separate out a weight priority vs
> a strict priority, or give a simpler interface by allowing just a single
> number value.

If we leave some options open, we need to define the API for them.
Let's not go overboard with this, but stay within what could be realistic for a DMA engine.

Remember, the API needs to be cross-platform, so simply replacing the "Priority" parameter with a "QoS Class ID" also requires adding configuration parameters to map each QoS Class ID to a generically defined behavior (e.g. priority, weight).

@Vamsi, how many priority levels does your DMA hardware support?