doc: announce dmadev new capability addition

Message ID 20240729124927.264458-1-vattunuru@marvell.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series doc: announce dmadev new capability addition |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/intel-Functional success Functional PASS
ci/github-robot: build success github build: passed
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-marvell-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-compile-amd64-testing pending Testing pending
ci/iol-sample-apps-testing success Testing PASS

Commit Message

Vamsi Krishna July 29, 2024, 12:49 p.m. UTC
Announce addition of new capability flag and fields in
rte_dma_info and rte_dma_conf structures.

Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
---
RFC:
https://patchwork.dpdk.org/project/dpdk/patch/20240729115558.263574-1-vattunuru@marvell.com/

 doc/guides/rel_notes/deprecation.rst | 5 +++++
 1 file changed, 5 insertions(+)
  

Comments

Jerin Jacob July 29, 2024, 3:20 p.m. UTC | #1
On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru <vattunuru@marvell.com> wrote:
>
> Announce addition of new capability flag and fields in

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?


> rte_dma_info and rte_dma_conf structures.
>
> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> ---
> RFC:
> https://patchwork.dpdk.org/project/dpdk/patch/20240729115558.263574-1-vattunuru@marvell.com/
>
>  doc/guides/rel_notes/deprecation.rst | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 6948641ff6..05d28473c0 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -147,3 +147,8 @@ Deprecation Notices
>    will be deprecated and subsequently removed in DPDK 24.11 release.
>    Before this, the new port library API (functions rte_swx_port_*)
>    will gradually transition from experimental to stable status.
> +
> +* dmadev: A new flag ``RTE_DMA_CAPA_QOS`` will be introduced to advertise
> +  dma device's QoS capability. Also 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.
> --
> 2.25.1
>
  
Morten Brørup July 29, 2024, 5:17 p.m. UTC | #2
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Monday, 29 July 2024 17.20
> 
> On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru <vattunuru@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.
  
Thomas Monjalon July 31, 2024, 10:24 a.m. UTC | #3
29/07/2024 17:20, Jerin Jacob:
> On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru <vattunuru@marvell.com> wrote:
> >
> > Announce addition of new capability flag and fields in
> 
> 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?
> 
> > rte_dma_info and rte_dma_conf structures.

I'm fine with just updating these structs.

> > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>

Acked-by: Thomas Monjalon <thomas@monjalon.net>

Any other opinions?
  

Patch

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 6948641ff6..05d28473c0 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -147,3 +147,8 @@  Deprecation Notices
   will be deprecated and subsequently removed in DPDK 24.11 release.
   Before this, the new port library API (functions rte_swx_port_*)
   will gradually transition from experimental to stable status.
+
+* dmadev: A new flag ``RTE_DMA_CAPA_QOS`` will be introduced to advertise
+  dma device's QoS capability. Also 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.