> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Thursday, January 27, 2022 8:48 AM > > On Thu, Jan 27, 2022 at 12:38:24AM +0000, Tian, Kevin wrote: > > > So.. this vPRI requirement is quite a big deviation. We can certainly > > > handle it inside the FSM framework, but it doesn't seem backward > > > compatible. I wouldn't worry too much about defining it now at least > > > > Now I see your point. Yes, we have to do some incompatible way to > > support vPRI. In the end we need part of arc in FSM can run with > > active vCPUs. > > I still think the right answer is a new state that stops new PRIs from > coming, I'm just not sure what that means. If the device can't > actually stop PRIs until it has completed PRIs - that is pretty messed > up - but it means at least we have this weird PRI state that might > timeout on some devices, and better devices might immediately return. > > This is even quite possibly the same HW function as NDMA.. We can discuss in detail after the base FSM is merged. With actual code it'd be easier to identify the right approach of supporting that usage. The output from current discussion is that I know what the compatibility means in current FSM. 😊 > > Anyhow, due to this discussion I redid our v2 draft to use cap bits > instead of the arc_supported ioctl, as it seems like it is more robust > against the notion in future some devices won't even support the basic > mandatory transitions. So we'd turn off old bits and turn on new bits > for these devices.. > This makes sense. Just one thing related to my another reply. I don't know how many devices today uses the draining model to stop the device. But given so many device classes and vendors in the market, is it reasonable to consider certain timeout interface in this v2 draft now so the user can be left in a better position in case of potential SLA violation when following certain FSM arc? Thanks Kevin
