Re: [PATCH net-next v3 5/6] net: sched: rename QDISC_DROP_FQ_* to generic names

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Jesper Dangaard Brouer <hawk@kernel.org> writes:

> Rename FQ-specific drop reasons to generic names:
> - QDISC_DROP_FQ_BAND_LIMIT -> QDISC_DROP_BAND_LIMIT
> - QDISC_DROP_FQ_HORIZON_LIMIT -> QDISC_DROP_HORIZON_LIMIT
>
> This follows the principle that drop reasons should describe the drop
> mechanism rather than being tied to a specific qdisc implementation.
> These concepts (priority band limits, timestamp horizon) could apply
> to other qdiscs as well.
>
> Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
> ---
>  include/net/dropreason-qdisc.h |   21 +++++++++++----------
>  net/sched/sch_fq.c             |    2 +-
>  2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/dropreason-qdisc.h b/include/net/dropreason-qdisc.h
> index 2e2f4fc36e0d..8661797193b1 100644
> --- a/include/net/dropreason-qdisc.h
> +++ b/include/net/dropreason-qdisc.h
> @@ -12,8 +12,8 @@
>  	FN(FLOW_LIMIT)			\
>  	FN(MAXFLOWS)			\
>  	FN(FLOOD_PROTECTION)		\
> -	FN(FQ_BAND_LIMIT)		\
> -	FN(FQ_HORIZON_LIMIT)		\
> +	FN(BAND_LIMIT)			\
> +	FN(HORIZON_LIMIT)		\
>  	FNe(MAX)
>  
>  #undef FN
> @@ -82,17 +82,18 @@ enum qdisc_drop_reason {
>  	 */
>  	QDISC_DROP_FLOOD_PROTECTION,
>  	/**
> -	 * @QDISC_DROP_FQ_BAND_LIMIT: FQ (Fair Queue) dropped packet because
> -	 * the priority band's packet limit was reached. Each priority band
> -	 * in FQ has its own limit.
> +	 * @QDISC_DROP_BAND_LIMIT: packet dropped because the priority band's
> +	 * limit was reached. Used by qdiscs with priority bands that have
> +	 * per-band packet limits (e.g., FQ).
>  	 */
> -	QDISC_DROP_FQ_BAND_LIMIT,
> +	QDISC_DROP_BAND_LIMIT,
>  	/**
> -	 * @QDISC_DROP_FQ_HORIZON_LIMIT: FQ dropped packet because its
> -	 * timestamp is too far in the future (beyond horizon). This prevents
> -	 * packets with unreasonable future timestamps from blocking the queue.
> +	 * @QDISC_DROP_HORIZON_LIMIT: packet dropped because its timestamp
> +	 * is too far in the future (beyond horizon). This prevents packets
> +	 * with unreasonable future timestamps from occupying queue space.

Why change "blocking the queue" to "occupying queue space"? The former
seems worse, so worth calling out?

-Toke