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 61A924569B; Mon, 29 Jul 2024 15:53:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E935240674; Mon, 29 Jul 2024 15:53:19 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 22F6A4066D for ; Mon, 29 Jul 2024 15:53:19 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id E3B3F209C1; Mon, 29 Jul 2024 15:53:18 +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:53:15 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F5C0@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] dmadev: add QoS capability Thread-Index: Adrhuw2mblH4m8wvTkmBTvFk32Le/wAAkneQ References: <20240729115558.263574-1-vattunuru@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35E9F5BA@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" Cc: "Vamsi Attunuru" , , , , , 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: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Monday, 29 July 2024 15.27 >=20 > On Mon, Jul 29, 2024 at 03:14:55PM +0200, Morten Br=F8rup 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). > > >=20 > 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?