Index | Thread | Search

From:
Andy Lemin <andrew.lemin@gmail.com>
Subject:
Re: PF Queue bandwidth now 64bit for >4Gbps queues
To:
Alexandr Nedvedicky <sashan@fastmail.net>
Cc:
tech@openbsd.org, Theo Buehler <tb@openbsd.org>
Date:
Fri, 20 Mar 2026 22:42:21 +1100

Download raw body.

Thread
Thanks for spotting and fixing the display bug. Sorry I missed it..
Fun to see how changes like this show up little legacy bugs that didn’t matter before :)

Looking forward to the 7.9 release!

Happy packet shaping.. 
Andy.


> On 20 Mar 2026, at 18:49, Alexandr Nedvedicky <sashan@fastmail.net> wrote:
> 
> Hello,
> 
>> On Thu, Mar 19, 2026 at 12:46:03PM +0000, Stuart Henderson wrote:
>>> On 2026/03/18 11:28, Stuart Henderson wrote:
>>> On 2026/03/18 11:01, Stuart Henderson wrote:
>>>> On 2026/03/18 00:57, Andrew Lemin wrote:
>>>>> struct hfsc_sc grows from 12 to 24 bytes (with a 4-byte padding hole
>>>>> between d and m2 due to alignment - should we reorder?).
>>>> 
>>>> yes.
>>>> 
>>>> from style(9):
>>>> 
>>>>   When declaring variables in structures, declare them sorted by use, then
>>>>   by size (largest to smallest), then by alphabetical order.  The first
>>>>   category normally doesn't apply, but there are exceptions.
>>>> 
>>>> (+ i'll see if I can figure out what's needed in ports-land for this).
>>>> 
>>> 
>>> +Values up to 999G are supported, allowing configuration of PF queues on
>>> +10G, 25G, 40G, and 100G interfaces.
>>> 
>>> I don't think the clause about interface speeds is needed
>> 
>> Actually I think the manual change should just be dropped, it's not
>> needed. Diff below drops that and reorders the struct. This version is
>> ok sthen and I would like this to coincide with library bumps that are
>> about to take place, so that most packages will get updated anyway
>> (i.e. commit this first or at the same time as the bumps).
> 
>    the diff also works for me. OK sashan
> 
>> 
>> +Values up to 999G are supported.
>> 
>> There is a pre-existing issue with pfctl silently mishandling bandwidth
>> specs above this. That should be fixed rather than rely on someone
>> reading docs. I think not a blocker for committing the uint64 change.
>> I'll send a separate mail about this.
>> 
> 
>    ... and the fix is separate commit now.
> 
> thanks a lot
> regards
> sashan
>