> From: Alex Williamson <alex.williamson@xxxxxxxxxx> > Sent: Friday, May 5, 2023 11:28 PM > > On Fri, 5 May 2023 08:10:33 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > From: Chatre, Reinette <reinette.chatre@xxxxxxxxx> > > > Sent: Saturday, April 29, 2023 2:35 AM > > > > > > Hi Kevin, > > > > > > On 4/27/2023 11:50 PM, Tian, Kevin wrote: > > > > > > > Should this behavior be something configurable? > > > > > > This is not clear to me and I look to you for guidance here. From practical > > > side it looks like configuration via module parameters is supported but > > > whether it should be done is not clear to me. > > > > > > When considering this we need to think about what the user may expect > > > when > > > turning on/off the configuration. For example, MSI-X continues to > allocate a > > > range of interrupts during enabling. These have always been treated as a > > > "cache" (interrupts remain allocated, whether they have an associated > > > trigger > > > or not). If there is new configurable behavior, do you expect that the > > > driver needs to distinguish between the original "cache" that the user is > > > used to and the new dynamic allocations? That is, should a dynamic MSI- > X > > > capable device always free interrupts when user space removes an > eventfd > > > or should only interrupts that were allocated dynamically be freed > > > dynamically? > > > > That looks tricky. Probably that is why Alex suggested doing this simple > > scheme and it is on par with the old logic anyway. So I'll withdraw this > > comment. > > Don't forget we're also releasing the irq reservations when the guest > changes interrupt mode, ex. reboot, so the "caching" is really only > within a session of the guest/userspace driver where it would be > unusual to have an unused reservation for an extended period. Thanks, > Yeah, that makes sense.
