Re: [PATCH v2] network: add rule to nftables backend that zeroes checksum of DHCP responses

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).