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 <[email protected]> > --- > 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 >
