From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 116BC4565E; Mon, 29 Jul 2024 15:15:03 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B8F0640A6D; Mon, 29 Jul 2024 15:14:59 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id F31BA4069F for ; Mon, 29 Jul 2024 15:14:57 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id D6043209C1; Mon, 29 Jul 2024 15:14:57 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC] dmadev: add QoS capability Date: Mon, 29 Jul 2024 15:14:55 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F5BA@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20240729115558.263574-1-vattunuru@marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] dmadev: add QoS capability Thread-Index: Adrhrk/UiZkOxSgfSl2imypE6VpMHQAB2qEg References: <20240729115558.263574-1-vattunuru@marvell.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Vamsi Attunuru" , , , , Cc: , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Vamsi Attunuru [mailto:vattunuru@marvell.com] > Sent: Monday, 29 July 2024 13.56 >=20 > 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). >=20 > Signed-off-by: Vamsi Attunuru > --- > lib/dmadev/rte_dmadev.c | 10 ++++++++++ > lib/dmadev/rte_dmadev.h | 19 +++++++++++++++++++ > 2 files changed, 29 insertions(+) >=20 > diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c > index 845727210f..9ff62efcb4 100644 > --- a/lib/dmadev/rte_dmadev.c > +++ b/lib/dmadev/rte_dmadev.c > @@ -491,6 +491,16 @@ rte_dma_configure(int16_t dev_id, const struct > rte_dma_conf *dev_conf) > "Device %d configure too many vchans", dev_id); > return -EINVAL; > } > + if (dev_conf->priority && - if (dev_conf->priority && + if (dev_conf->priority !=3D 0 && > + !(dev_info.dev_capa & RTE_DMA_CAPA_QOS)) { > + RTE_DMA_LOG(ERR, "Device %d don't support QoS", dev_id); > + return -EINVAL; > + } > + if (dev_conf->priority >=3D dev_info.nb_priorities) { > + RTE_DMA_LOG(ERR, > + "Device %d configure invalid priority", dev_id); > + return -EINVAL; > + } > if (dev_conf->enable_silent && > !(dev_info.dev_capa & RTE_DMA_CAPA_SILENT)) { > RTE_DMA_LOG(ERR, "Device %d don't support silent", dev_id); > diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h > index 5474a5281d..08db8ead0a 100644 > --- a/lib/dmadev/rte_dmadev.h > +++ b/lib/dmadev/rte_dmadev.h > @@ -268,6 +268,16 @@ int16_t rte_dma_next_dev(int16_t start_dev_id); > #define RTE_DMA_CAPA_OPS_COPY_SG RTE_BIT64(33) > /** Support fill operation. */ > #define RTE_DMA_CAPA_OPS_FILL RTE_BIT64(34) > +/** Support QoS at DMA HW channel level > + * > + * If device supports QoS then application could configure priority = to the > + * DMA HW channel using 'priority' field in struct rte_dma_conf. = Number of > + * supported prioirty levels will be known from 'nb_priorities' field = in > + * struct rte_dma_info. > + * DMA devices which support QoS at HW channel level can advertise = this > + * capability. > + */ > +#define RTE_DMA_CAPA_QOS RTE_BIT64(35) > /**@}*/ >=20 > /** > @@ -297,6 +307,8 @@ struct rte_dma_info { > int16_t numa_node; > /** Number of virtual DMA channel configured. */ > uint16_t nb_vchans; > + /** Number of priority levels supported by DMA HW channel. */ > + uint16_t nb_priorities; This value must be 0 or > 1, never 1. Please mention in the comment, = e.g.: /** Number of priority levels, if supported by DMA HW channel. 0 = otherwise. */ Please add a test case to verify that the DMA device reports = nb_priorities > 1 if it has CAPA_PRIO, and 0 if not. Alternatively: Assuming we don't foresee anything more advanced than Strict Priority... Remove the CAPA_PRIO capability flag. Reading nb_priorities should = suffice. > }; >=20 > /** > @@ -332,6 +344,13 @@ struct rte_dma_conf { > * @see RTE_DMA_CAPA_SILENT > */ > bool enable_silent; > + /* The prioirty of the DMA HW channel. > + * This value cannot be greater than or equal to the field > 'nb_priorities' > + * of struct rte_dma_info which get from rte_dma_info_get(). > + * Among the values between '0' and 'nb_priorities - 1', lowest = value > + * indicates higher priority and vice-versa. > + */ > + uint16_t priority; > }; >=20 > /** > -- > 2.25.1