On Wed, Oct 30, 2024 at 07:41:02AM -0400, Laine Stump wrote: > On 10/30/24 4:43 AM, Daniel P. Berrangé wrote: > > On Tue, Oct 29, 2024 at 11:21:36PM -0400, Laine Stump wrote: > > > > > > We do already use tc for bandwidth control, and when a <bandwidth> element > > > is present in the interface (or the network) we run some tc commands as a > > > port is added to a network to (I *think*) reserve a portion of the bridge's > > > bandwidth for the new interface controls, and when a port is deleted we > > > again run some tc commands to remove it. (mprivozn added all of this and so > > > therefore knows the most about it) > > > > > > However, the tc commands on the network side (during the CreatePort API) I > > > believe are done with only the network's bridge + the MAC address of the > > > guest's NIC (and a "class_id" is created and sent back to QEMU and is there > > > I guess used for some *other* tc commands to setup bandwidth upper limits > > > for the tap after it's created.) > > > > > > More significantly, the tap device hasn't even been created yet at the time > > > QEMU allocates the port from the network driver, so we don't even have a > > > "name of future tap device" that we could send in the NetworkPortCreate API > > > XML. > > > > > > So, I guess what all that means is that having the network driver run a > > > tap-device-specific tc command won't be that simple. (Maybe we could add > > > "virNetworkPortStart|Stop" APIs or something) > > > > I would expect 'tc' rules to be set against virbr0, not the individual > > NICs. > > You may be right; I haven't looked at the qemu side to be honest. When I > went in to gather enough info to respond last night I was only interested in > figuring out how easy/difficult it would be to have the network driver issue > tc commands with the tap device rather than the bridge *since Phil suggested > that would be better/less bad/something like that. So I mainly looked at > what info the network driver currently uses for its tc commands, and whether > or not the tap device is created before or after the NetworkPortCreate > (thought I recalled "after", and this is correct - makes sense, since we > can't know until after virNetworkPortCreate whether or not the interface > will even be using a tap device). I wasn't thinking about the complexity, but rather the redundancy. We need this rule set for every NIC, as it is way too difficult for us to accurately predict exactly which scenarios will hit the DHCP checksumm problem. With that goal, then it is pointless to inject the same logic on every tap device, when we can inject it on the bridge device once and be done with it. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
