Re: [PATCH 1/2] doc: fix ice scheduler rate-limiter burst size description

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jul 08, 2026 at 07:19:25PM -0400, Dawid Wesierski wrote:
> The paragraph describing the ``rl_burst_size`` devarg was mangled
> (a mid-sentence line break split "favours throughput" across two
> lines with no space), 

Are you sure? It looks fine to me in output generated on my machine. Also,
it's unlikely that changing the source text to add a line break between
"favours" and "throughput" will cause a line break to be removed in the
output.

> and it did not mention that out-of-range
> values are rejected by the driver, which can otherwise look like a
> silent no-op to a reader.
> 

Yes, that extra note about invalid values being rejected is missing.

However, the rest of the patch rewrapping the text actually goes against
DPDK documentation policy. In order to keep doc diffs small, we try to
always start a sentence on a new line, and to only break lines at
punctuation marks, or between clauses generally. This saves having massive
diffs as the source text is re-wrapped following a change at the start of a
paragraph.

See https://doc.dpdk.org/guides/contributing/documentation.html#line-length-and-wrapping

> Fixes: b3f2afb3b7ea ("net/ice: add scheduler rate-limiter burst size devarg")
> 
> Signed-off-by: Dawid Wesierski <dawid.wesierski@intel.com>
> ---
>  doc/guides/nics/ice.rst | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
> index 5589ce934f..6c2063d47e 100644
> --- a/doc/guides/nics/ice.rst
> +++ b/doc/guides/nics/ice.rst
> @@ -160,9 +160,10 @@ Runtime Configuration
>  
>  - ``Scheduler rate-limiter burst size`` (default ``0``)
>  
> -  The hardware Tx scheduler uses a default rate-limiter burst size that favours throughput.
> -  Time-sensitive applications can lower this value to reduce Tx latency jitter
> -  at the cost of throughput by setting the ``rl_burst_size`` devargs parameter, in bytes.
> +  The hardware Tx scheduler uses a default rate-limiter burst size that favours
> +  throughput. Time-sensitive applications can lower this value to reduce Tx
> +  latency jitter at the cost of throughput by setting the ``rl_burst_size``
> +  devargs parameter, in bytes. Values that are out of range are rejected.

When they are rejected, is an error just logged, or does the driver fail to
load due to an incorrect value? IF it's just a log message, is it better to
have the driver do a hard-failure so the user can't miss the issue? That
would be better than just noting this in the docs.

Regards,
/Bruce

>    A value of ``0`` (the default) keeps the hardware default.
>  
>    For example::
> -- 
> 2.47.3
>