|SUCCESS| [v2] ring: fix zero-copy burst API documentation

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164137

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-19

Reviewing the patch for DPDK coding standards and contribution guidelines.

commit 5113c4a6538511f1aa26b74ffac11d73
Author: jinzhiguang <jinzhiguang at kylinos.cn>
Subject: [PATCH v2] ring: fix zero-copy burst API documentation

The patch updates documentation for ring zero-copy burst APIs to clarify
that they return the actual number of objects processed rather than only
0 or n.

> diff --git a/.mailmap b/.mailmap
> index 4d26d9c286..a4f91f2131 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -756,6 +756,7 @@ Jing Chen <jing.d.chen at intel.com>
>  Jingguo Fu <jingguox.fu at intel.com>
>  Jingjing Wu <jingjing.wu at intel.com>
>  Jingzhao Ni <jingzhao.ni at arm.com>
> +jinzhiguang <jinzhiguang at kylinos.cn>
>  Jiri Slaby <jslaby at suse.cz>
>  Job Abraham <job.abraham at intel.com>
>  Jochen Behrens <jochen.behrens at broadcom.com> <jbehrens at vmware.com>

The mailmap entries should be alphabetically sorted within their section.
Is "jinzhiguang" the correct canonical name format? Typically, DPDK
contributors use capitalized given and family names. Should this entry
follow the pattern "Jinzhiguang <jinzhiguang at kylinos.cn>" or include
separate given/family names?

> diff --git a/lib/ring/rte_ring_peek_zc.h b/lib/ring/rte_ring_peek_zc.h
> index 3254fe0481..43d6a53075 100644
> --- a/lib/ring/rte_ring_peek_zc.h
> +++ b/.lib/ring/rte_ring_peek_zc.h
> @@ -235,7 +235,7 @@ rte_ring_enqueue_zc_bulk_start(struct rte_ring *r, unsigned int n,
>   *   If non-NULL, returns the amount of space in the ring after the
>   *   reservation operation has finished.
>   * @return
> - *   The number of objects that can be enqueued, either 0 or n
> + *   The actual number of objects that can be enqueued.
>   */

[ ... ]

> @@ -265,7 +265,7 @@ rte_ring_enqueue_zc_burst_elem_start(struct rte_ring *r, unsigned int esize,
>   *   If non-NULL, returns the amount of space in the ring after the
>   *   reservation operation has finished.
>   * @return
> - *   The number of objects that can be enqueued, either 0 or n.
> + *   The actual number of objects that can be enqueued.
>   */

[ ... ]

> @@ -442,7 +442,7 @@ rte_ring_dequeue_zc_bulk_start(struct rte_ring *r, unsigned int n,
>   *   If non-NULL, returns the number of remaining ring entries after the
>   *   dequeue has finished.
>   * @return
> - *   The number of objects that can be dequeued, either 0 or n.
> + *   The actual number of objects that can be dequeued.
>   */

[ ... ]

> @@ -471,7 +471,7 @@ rte_ring_dequeue_zc_burst_elem_start(struct rte_ring *r, unsigned int esize,
>   *   If non-NULL, returns the number of remaining ring entries after the
>   *   dequeue has finished.
>   * @return
> - *   The number of objects that can be dequeued, either 0 or n.
> + *   The actual number of objects that can be dequeued.
>   */

The updated return value descriptions are vague. For API documentation,
should these explicitly state the range as "between 0 and n (inclusive)"
to match other burst API documentation patterns in DPDK? The current
wording "actual number" doesn't clearly communicate that partial success
is possible.