I have a machine with 32G physical RAM that's trying to run the following pf.conf: scrub in all altq on tun20 cbq bandwidth 20Mb queue { std_out, sip_out, dns_out, tcp_ack_out, rtp_out } queue rtp_out bandwidth 1Mb priority 5 cbq(borrow) queue tcp_ack_out bandwidth 1Mb priority 4 cbq(borrow) queue dns_out bandwidth 1Mb priority 3 cbq(borrow) queue sip_out bandwidth 1Mb priority 2 cbq(borrow) queue std_out bandwidth 16Mb priority 1 cbq(ecn, default, borrow) pass in quick on tun20 proto udp from any to any tos 46 queue rtp_out pass in quick on tun20 proto udp from any to any tos 26 queue sip_out pass in quick on tun20 proto {udp, tcp} from any port 53 to any queue (dns_out, tcp_ack_out) pass in quick on tun20 from to any queue (std_out, tcp_ack_out) ... which isn't too much to ask. Pretty much the same table is being used by a 10.3 host controlling the other end of the connection (changing 20Mb for 9 Mb, for instance). But on the 11.0 machine (and on 11-STABLE) it gives: pfctl: DIOCADDALTQ: Cannot allocate memory
I've been able to reproduce this. Initial investigation shows 'rmc_newclass: CODEL not configured for CBQ!'. I'm not sure if it's a bug or a configuration error at this point.
There seems to be some confusion between CBQCFL_BORROW (#defined to 0x20) and RMFC_CODEL (also #defined to 0x20). I think the rmc_newclass() is looking at the wrong flags variable. CC-ing loos, because he knows more about the CODEL changes.
Created attachment 178681 [details] Remove bogus checks I'm very confused by these checks. The RMCF_* flags they check for are never actually set anywhere. This patch should at least unblock you.
This needs to be looked at closer, because something is very wrong with these checks.
same problem on 10.3
I got same problem on 10.3-STABLE (r311921). My kernel's config was: options ALTQ options ALTQ_CBQ options ALTQ_NOPCC sys/contrib/altq/altq on stable/10 was last changed by r298133: Add ALTQ(9) support for the CoDel algorithm. Adding "options ALTQ_CODEL" to kernel's configuration can be used as workaround (solved this problem for me)
I created review https://reviews.freebsd.org/D17758 with a fix for this problem.
A commit references this bug: Author: karels Date: Fri Nov 16 03:42:30 UTC 2018 New revision: 340474 URL: https://svnweb.freebsd.org/changeset/base/340474 Log: Fix flags collision causing inability to enable CBQ in ALTQ The CBQ BORROW flag conflicts with the RMCF_CODEL flag; the two sets of definitions actually define the same things. The symptom is that a kernel with CBQ support and not CODEL fails to load a QoS policy with the obscure error "pfctl: DIOCADDALTQ: Cannot allocate memory." If ALTQ_DEBUG is enabled, the error becomes a little clearer: "rmc_newclass: CODEL not configured for CBQ!" is printed by the kernel. There really shouldn't be two sets of macros that have to be defined consistently, but the include structure isn't right for exporting CBQ flags to altq_rmclass.h. Re-align the definitions, and add CTASSERTs in the kernel to ensure that the definitions are consistent. PR: 215716 Reviewed by: pkelsey MFC after: 2 weeks Sponsored by: Forcepoint LLC Differential Revision: https://reviews.freebsd.org/D17758 Changes: head/sys/net/altq/altq_cbq.h head/sys/net/altq/altq_rmclass.h
Fixed by r340474
A commit references this bug: Author: karels Date: Sat Dec 8 14:54:33 UTC 2018 New revision: 341737 URL: https://svnweb.freebsd.org/changeset/base/341737 Log: MFC r340474: Fix flags collision causing inability to enable CBQ in ALTQ The CBQ BORROW flag conflicts with the RMCF_CODEL flag; the two sets of definitions actually define the same things. The symptom is that a kernel with CBQ support and not CODEL fails to load a QoS policy with the obscure error "pfctl: DIOCADDALTQ: Cannot allocate memory." If ALTQ_DEBUG is enabled, the error becomes a little clearer: "rmc_newclass: CODEL not configured for CBQ!" is printed by the kernel. There really shouldn't be two sets of macros that have to be defined consistently, but the include structure isn't right for exporting CBQ flags to altq_rmclass.h. Re-align the definitions, and add CTASSERTs in the kernel to ensure that the definitions are consistent. PR: 215716 Reviewed by: pkelsey Sponsored by: Forcepoint LLC Differential Revision: https://reviews.freebsd.org/D17758 Changes: stable/12/sys/net/altq/altq_cbq.h stable/12/sys/net/altq/altq_rmclass.h