On Wed, Sep 13, 2023 at 3:43 AM Andrew Lemin <andrew.le...@gmail.com> wrote:
> Hi Stuart. > > On Wed, Sep 13, 2023 at 12:25 AM Stuart Henderson < > stu.li...@spacehopper.org> wrote: > >> On 2023-09-12, Andrew Lemin <andrew.le...@gmail.com> wrote: >> > Hi all, >> > Hope this finds you well. >> > >> > I have discovered that PF's queueing is still limited to 32bit bandwidth >> > values. >> > >> > I don't know if this is a regression or not. >> >> It's not a regression, it has been capped at 32 bits afaik forever >> (certainly was like that when the separate classification via altq.conf >> was merged into PF config, in OpenBSD 3.3). >> > > Ah ok, it was talked about so much I thought it was part of it. Thanks for > clarifying. > > >> >> > I am sure one of the >> > objectives of the ALTQ rewrite into the new queuing system we have in >> > OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I >> am >> > imagining it.. >> >> I don't recall that though there were some hopes expressed by >> non-developers. >> > > Haha, it is definitely still wanted and needed. prio-only based ordering > is too limited > I have noticed another issue while trying to implement a 'prio'-only workaround (using only prio ordering for inter-VLAN traffic, and HSFC queuing for internet traffic); It is not possible to have internal inter-vlan traffic be solely priority ordered with 'set prio', as the existence of 'queue' definitions on the same internal vlan interfaces (required for internet flows), demands one leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into the 'default' queue despite queuing not being wanted, and so unintentionally clamping all internal traffic to 4294M just because full queuing is needed for internet traffic. In fact 'prio' is irrelevant, as with or without 'prio' because queue's are required for internet traffic, all internal traffic becomes bound by the 'default' HSFC queue. So I would propose that the mandate on the 'default' keyword is relaxed (or a new keyword is provided for match/pass rules to force flows to not be queued), and/or implement the uint32 scale in bytes, instead of bits? I personally believe both are valid and needed? > > >> >> > Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN >> routing >> > with 10Gbps trunks, and I cannot set the queue bandwidth higher than a >> > 32bit value? >> > >> > Setting the bandwidth value to 4295M results in a value overflow where >> > 'systat queues' shows it wrapped and starts from 0 again. And traffic is >> > indeed restricted to such values, so does not appear to be just a >> cosmetic >> > 'systat queues' issue. >> > >> > I am sure this must be a bug/regression, >> >> I'd say a not-implemented feature (and I have a feeling it is not >> going to be all that simple a thing to implement - though changing >> scales so the uint32 carries bytes instead of bits per second might >> not be _too_ terrible). >> > > Following the great work to SMP unlock in the VLAN interface, and recent > NIC optimisations (offloading and interrupt handling) in various drivers, > you can now push packet filtered 10Gbps with modern CPUs without breaking a > sweat.. > > Ahhhh, thats clever! Having bandwidth queues up to 34,352M would > definitely provide runway for the next decade :) > > Do you think your idea is worth circulating on tech@ for further > discussion? Queueing at bps resolution is rather redundant nowadays, even > on the very slowest links. > > >> > 10Gbps on OpenBSD is trivial >> and >> > common nowadays.. >> >> While using interfaces with 10Gbps link speed on OpenBSD is trivial, >> actually pushing that much traffic (particularly with more complex >> processing e.g. things like bandwidth controls, and particularly with >> smaller packet sizes) not so much. >> >> >> -- >> Please keep replies on the mailing list. >> >> Thanks again, Andy.
