Description of problem:
Hello mates
This is another day i'm trying to resolve this issue related to ingress QoS.

What you did that make the problem appear.
We using OpenStack Neutron + OVS to add connectivity for our instances and we have to add QoS which handled by OVS. Our actions are to create QoS policy with ingress/egress rules with type bandwidth-limit but ingress QoS isn't working at all. Looking back to our normally working cluster i've noticed about linux interface options difference. In normally working environment all of our instances interfaces have next options:
tap15614faf-92: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb master ovs-system
# tc qdisc show dev tap15614faf-92
qdisc htb 1: root refcnt 2 r2q 10 default 0x1 direct_packets_stat 0 direct_qlen 1000
qdisc ingress ffff: parent ffff:fff1 ----------------

# tc class show dev tap15614faf-92
class htb 1:1 parent 1:fffe prio 0 rate 12Kbit ceil 102400Kbit burst 1563b cburst 1561b
class htb 1:fffe root rate 102400Kbit ceil 102400Kbit burst 1497b cburst 1497b

But another cluster have issue with noqueue option assigned to instance interfaces
tapf3690fb2-dd: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system
# tc qdisc show dev tapf3690fb2-dd
qdisc noqueue 8004: root refcnt 2
qdisc ingress ffff: parent ffff:fff1 ----------------

# tc class show dev tapf3690fb2-dd (output is empty)
Digging deeper we started to look logs for some errors and we got some. When we trying to anyway edit or create QoS policy or interfaces with that QoS policy we seeing weird logs
2022-10-27T13:09:22.273Z|00077|netdev_linux|DBG|unknown qdisc "noqueue"
2022-10-27T13:17:11.626Z|00078|netdev_linux|DBG|unknown qdisc "noqueue"
2022-10-27T13:20:07.190Z|00080|netdev_linux|DBG|unknown qdisc "noqueue"
I suspect that this is somehow is root of the problem why ingress rules aren't working.


What you expected to happen.
Expected behavior is ingress rules are actually being created without errors.

What actually happened.
Ingress QoS rules aren't working or even added to tc qdisc/class

Some handy detais about environment:
# ovs-vswitchd --version
ovs-vswitchd (Open vSwitch) 2.17.2
# cat /proc/version
Linux version 5.4.0-131-generic (also tried 5.4.0-120-generic as on working environment) (buildd@lcy02-amd64-108) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #147-Ubuntu SMP Fri Oct 14 17:07:22 UTC 2022
ovsdb content located in gist by url
https://gist.github.com/frct1/4b26949b97fc88d86471f05b51b68a97
# ovs-dpctl show
system@ovs-system:
  lookups: hit:6731384 missed:162168 lost:16
  flows: 233
  masks: hit:50191740 total:18 hit/pkt:7.28
  port 0: ovs-system (internal)
  port 1: br-ex (internal)
  port 2: eno49
  port 3: br-int (internal)
  port 4: br-tun (internal)
  port 5: tapd405d07c-e3 (internal)
  port 6: tapf3690fb2-dd

# ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:00001e808363c444
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(int-br-ex): addr:d6:66:17:71:72:ae
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 2(patch-tun): addr:96:ed:2b:0e:1a:9f
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 3(tapd405d07c-e3): addr:00:00:00:00:00:00
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
 7(tapf3690fb2-dd): addr:fe:16:3e:7d:e8:bc
     config:     0
     state:      0
     current:    10MB-FD COPPER
     speed: 10 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:1e:80:83:63:c4:44
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
 
# ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00003ca82a2450b8
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(eno49): addr:3c:a8:2a:24:50:b8
     config:     0
     state:      0
     current:    10GB-FD
     advertised: 10GB-FD FIBER
     supported:  1GB-FD 10GB-FD FIBER AUTO_PAUSE AUTO_PAUSE_ASYM
     speed: 10000 Mbps now, 10000 Mbps max
 2(phy-br-ex): addr:2e:b2:b5:ec:b7:95
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-ex): addr:3c:a8:2a:24:50:b8
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

Thank you very much for any possible suggestions or workarounds!

Version-Release number of selected component (if applicable):
OpenStack (Zed), OvS: 2.17.2


Additional info:
More catched logs:
bridge|WARN|could not open network device tapdef3cecd-ba (No such device)
netdev_linux|DBG|unknown qdisc "noqueue"
bridge|INFO|bridge br-int: added interface tapdef3cecd-ba on port 16

--- 

There is possible workaround which totally bad it shows that tc is working correctly:
1. Delete 
# tc qdisc dev tap1337-ya root
2. Restart neutron-ovs-agent
3. Now interface is under linux-htb queue and tc qdisc is present for this virtual interface as classes for ingress QoS