Hi Laine, On Fri, Nov 01, 2024 at 11:44:12AM -0400, Laine Stump wrote: > On 10/29/24 11:12 AM, Phil Sutter wrote: [...] > > FWIW, I just tested an alternative workaround using tc. This works for > > me with a FreeBSD guest and NIC switched to either e1000 or virtio: > > > > # tc qd add dev vnetbr0 root handle 1: htb > > # tc filter add dev vnetbr0 prio 1 protocol ip parent 1: \ > > u32 match ip sport 67 ffff match ip dport 68 ffff \ > > action csum ip and udp > > This did work for me. However, since we support bandwidth management of > the interfaces connected to a virtual netowkr using tc, I decided to try > doing the same on a network configured with bandwidth management > enabled. I did this by adding the following to the <network> XML before > starting the network: > > <bandwidth> > <inbound average='1000' peak='2000' burst='5120'/> > <outbound average='500' peak='1000' burst='2560'/> > </bandwidth> > > This resulted in the following tc-related stuff being setup: > > # tc filter show dev virbr13 > filter parent 1: protocol all pref 1 fw chain 0 > filter parent 1: protocol all pref 1 fw chain 0 handle 0x1 classid :1 > ======= > > # tc qd show dev virbr13 > qdisc htb 1: root refcnt 2 r2q 10 default 0x2 direct_packets_stat 0 > direct_qlen 1000 > qdisc sfq 2: parent 1:2 limit 127p quantum 1514b depth 127 divisor 1024 > perturb 10sec > qdisc ingress ffff: parent ffff:fff1 ---------------- > ======= > > # tc class show dev virbr13 > class htb 1:1 root rate 8Mbit ceil 16Mbit burst 1600b cburst 1600b > class htb 1:2 parent 1:1 leaf 2: prio 0 rate 8Mbit ceil 16Mbit burst 5Mb > cburst 1600b > ======= > > (obviously my network is using virbr13). Now when I try running the > commands above, I see this: > > # tc qd add dev virbr13 root handle 1: htb > Error: Exclusivity flag on, cannot modify. No big deal: You're just trying to recreate the already existing HTB qdisc and it fails. But my quoted commands create one merely because we need one to attach the filter to. > So how does this all need to change in order to have our > per-bridge-device bandwidth management coexist with the qdisc/filter to > re-compute dhcp response checksums? (sorry for requesting that you ELI5; > that's just easier than digging through all the documentation to figure > out what is probably a simple solution :-P) It should just work if we attach the extra filter to the existing qdisc (untested due to laziness): # tc filter add dev virbr13 prio 2 protocol ip parent 1: \ u32 match ip sport 67 ffff match ip dport 68 ffff \ action csum ip and udp I forgot the meaning of the prio value again. Lower value may be higher prio, but IIRC all filters apply anyway and ordering doesn't matter in this case. In practice, you may just change the code to always add the HTB qdisc and the checksum update filter/action. If <bandwidth> is specified, also add the classes, leave qdisc(s) and fwmark filter. Let me know if things work this way. Cheers, Phil
Attachment:
signature.asc
Description: PGP signature
