Re: [PATCH net v3 1/9] net/sched: fq: clamp quantum and initial_quantum in change path

On Wed, Sep 2, 2026 at 9:04 AM Eric Dumazet [off-list ref] wrote:

On Wed, Sep 2, 2026 at 2:40 PM Jamal Hadi Salim [off-list ref] wrote:

quoted

Trying to understand your concern: Are you arguing for
stylistic/readability improvement or robustness?
The only place i can see where the multiplies you describe could
happen is what the 709f34f7c28d patch closed. i.e this part:

-       q->quantum              = 2 * psched_mtu(qdisc_dev(sch));
-       q->initial_quantum      = 10 * psched_mtu(qdisc_dev(sch));

IIRC, you are suggesting restoring the original logic (x2 and x10) and
i am likely missing why that is a must do? Does it break anything?

It does not break anything; it just causes a cascade of various clamps.

After your patch we will have:

       mtu = clamp_t(u32, psched_mtu(qdisc_dev(sch)), 1, 1 << 20);
       q->quantum              = clamp_t(u32, 2 * mtu, 256, 1 << 20);
       q->initial_quantum      = min_t(u32, 10 * mtu, 1 << 20);

So @mtu is no longer the psched mtu anymore.

This is fine.

The u64 variant would read cleaner for sure.  If i didnt misread you
though you are saying the current the mtu-no-longer-psched_mtu
aliasing is fine. So would it be ok to see if any other comments
spring up from says sashiko that are worth reviewing the patch before
I proceed with this? Or do you want a v4 or a followup?

cheers,
jamal