pf ALTQ bandwidth limited to a 32bit value (4294Mb)

[Calomel Org]

Ermal,

Thanks for the diff. When we tried it on FreeBSD 8.2-p2, ALTq would no
long start. We also looked into the source under
/usr/src/sys/contrib/altq/altq. Sadly, most of the changes we made
either broke altq completely or had no effect. 

If you have any other ideas we would be happy to try them out.

--
   Calomel @ https://calomel.org
   Open Source Research and Reference


On Thu, Jul 07, 2011 at 09:28:13AM -0400, Ermal Lu?i wrote:
>On Wed, Jul 6, 2011 at 5:25 PM, Calomel Org
><infallibilismindefeasibility at calomel.org> wrote:
>> ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb.
>> This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any
>> higher, altq will flip back to zero. This "bug" was found when trying
>> to test 10 gigabit and 40 gigabit bandwidth models. These tests were
>> done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit.
>>
>> If anyone else can verify this independently and agree with the
>> results I would be happy to register it as a bug.
>>
>>
>> How to replicate:
>>
>> A quick test is setting the bandwidth to 4294Mb and doing a pfctl -sq
>> to check altq.
>>
>> ?altq on $ExtIf bandwidth 4294Mb hfsc queue { ack, web}
>> ?queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web}
>>
>> Now set the bandwidth to 4295Mb and notice altq has flip to zero and
>> add the 32.70Kb difference.
>>
>> ?altq on $ExtIf bandwidth 4295Mb hfsc queue { ack, web }
>> ?queue root_em0 on em0 bandwidth 32.70Kb priority 0 {ack, web}
>>
>> Again, we can set the bandwidth to a multiple of two(2) to 8589Mb.
>> The bandwidth value flips to zero once and the result is 4.29Gb.
>>
>> ?altq on $ExtIf bandwidth 8589Mb hfsc queue { ack, web}
>> ?queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web}
>>
>> If we add one more megabit to 8590Mb the value flips twice and we are
>> left with 65.41Kb.
>>
>> ?altq on $ExtIf bandwidth 8590Mb hfsc queue { ack, web}
>> ?queue root_em0 on em0 bandwidth 65.41Kb priority 0 {ack, web}
>>
>
>It is true that there is a limit because of data type used.
>Though it cannot be fixed easily on i386 but on amd64 this should work.
>
>Index: sys/contrib/pf/net/pfvar.h
>===================================================================
>--- sys/contrib/pf/net/pfvar.h  (revision 223824)
>+++ sys/contrib/pf/net/pfvar.h  (working copy)
>@@ -1491,13 +1491,13 @@
>        /* scheduler spec */
>        u_int8_t                 scheduler;     /* scheduler type */
>        u_int16_t                tbrsize;       /* tokenbucket regulator size */
>-       u_int32_t                ifbandwidth;   /* interface bandwidth */
>+       u_int64_t                ifbandwidth;   /* interface bandwidth */
>
>        /* queue spec */
>        char                     qname[PF_QNAME_SIZE];  /* queue name */
>        char                     parent[PF_QNAME_SIZE]; /* parent name */
>        u_int32_t                parent_qid;    /* parent queue id */
>-       u_int32_t                bandwidth;     /* queue bandwidth */
>+       u_int64_t                bandwidth;     /* queue bandwidth */
>        u_int8_t                 priority;      /* priority */
> #ifdef __FreeBSD__
>        u_int8_t                 local_flags;   /* dynamic interface */
>
>
>>
>> Thanks.
>>
>> --
>> ? Calomel @ https://calomel.org
>> ? Open Source Research and Reference
>> _______________________________________________
>> freebsd-pf at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>>
>
>
>
>-- 
>Ermal
>_______________________________________________
>freebsd-pf at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"