On Thu, Jun 06, 2024 at 03:11:21PM -0700, Dan Williams wrote: > Leon Romanovsky wrote: > > On Wed, Jun 05, 2024 at 09:56:14PM -0700, Dan Williams wrote: > > > Jason Gunthorpe wrote: > > > > <...> > > > > > So my questions to try to understand the specific sticking points more > > > are: > > > > > > 1/ Can you think of a Command Effect that the device could enumerate to > > > address the specific shenanigan's that netdev is worried about? In other > > > words if every command a device enables has the stated effect of > > > "Configuration Change after Reset" does that cut out a significant > > > portion of the concern? > > > > It will prevent SR-IOV devices (or more accurate their VFs) > > to be configured through the fwctl, as they are destroyed in HW > > during reboot. > > Right, but between zero configurability and losing live SR-IOV > configurabilitiy is there still value? Note, this is just a thought > experiment on what if any Command Effects Linux can comfortably tolerate > vs those that start to be more spicy and dip into removing stimulus / > focus on the commons, or otherwise injuring collaboration. I like the idea of "takes effect on _function_ reset". VFs and PFs both often have configuration that can become current once the fuction is reset. A VF is usually reset by something like VFIO while a PF is usually reset by a power cycle. The fact configuration doesn't change until reset is, IMHO, a very strong barrier from making some backdoor into a subsystem driver. Jason
