tc doesn't support vif quota values bigger than 32 bits unsigned

technically these flavor extra specs are ment to be hypervisor independent and we in generall should not enforce limits based on any one implementaiton such as tc.

with that said uint32_max is proably an ok limit to enforce in the general case.

the correct way to enforece this in nova is via the flavor extra spec json schema validations

in addtion to that a second check should be implemented when assigning to nova config object in the libvirt driver that model the xml elements.

we should fail the boot of the server in this case setting it to error and stating that the flavor extra specs exceed the maxium allowable value.

we should also likely update the documentaiton for the extra specs to not that for the libvirt driver the values should be specifed in KB not bytes

https://github.com/openstack/nova/blob/3a14c1a4277a9f44b67e080138b28b680e5e6824/nova/api/validation/extra_specs/quota.py#L169-L187

this is where the validation code currently is

by the way as the comment suggest we dont really advice that anyone use the vif quotas anymore and are considering removing them eventually but just have not seen it as a priority.

as an aside this does not work with ovn, hardware offloade ovs, ovs-dpdk or ml2/ovs with ovs firewall.

when using kernel ovs if the tap device is added ot ovs the tc rules do not work.
for vhost-user which is entirely impemented in userspce tc rules obvioulsy do not work
for hard ware offloaded ovs libvirt based qos has never been supported and i dont think it can be impleted this way either.

so while this technically can be used with ml2/ovs with iptable or linux bridge in generall the quta functional does not work with most network backend which is why we want to eventually remvoe this in foavor of neutron qos which does work in many of those cases.

that is why i have marked this as which list as really its just a documentaiton issue where we have not specified the allowed range. we can add validation as i have suggested but in general this is more operator error then anythign else for configuring vaules outside the rage.
we dont however expect operators to look at the internal of nova to discover that so we should document the preconditions and detct invalid values which is why i have triaged this as whishlist instead of markign it as invalid