On Thu, Mar 26, 2026 at 10:34:20PM -0700, Dixit, Ashutosh wrote: > On Wed, 25 Mar 2026 01:38:51 -0700, Michal Wajdeczko wrote: > > > > Hi Michal, > > > On 3/24/2026 10:17 PM, Dixit, Ashutosh wrote: > > > On Sun, 15 Mar 2026 23:41:02 -0700, Satyanarayana K V P wrote: > > >> > > >> --- > > >> V5 -> V6: > > >> - Updated commit message. > > >> - Return number of engines and memory regions as zero instead of > > >> returning > > >> query size as zero (Michal Wajdeczko). > > >> - Allow all other query IOCTLs excepts query_engines and > > >> query_mem_regions > > >> (Michal Wajdeczko). > > > > > > Can someone explain the reason to move away from the approach in v5? Afais > > > v6 has issues of this sort: > > > > > > * query_engines will return 0 engines but query_hwconfig will return > 0 > > > engines > > > > but those are separate queries on purpose, right? > > and I guess that even today there could be a mismatch between these numbers: > > > > * query_engines = engines available for use by the user software > > * query_hwconfig.engines = report engines present on the hardware > > OK, agreed. > > > > > > * query_engines will return 0 engines but query_oa_units will list out the > > > engines > > > > and that IMO should be considered as a desired outcome, as I guess (again) > > that this will allow us to do some OA reporting, even if PF alone is not > > submitting any workloads and we want to monitor how VFs are doing > > > > > * query_oa_units will return valid oa support but observation ioctl will > > > fail > > > > my initial idea [1] was to expose observation ioctl as well, maybe we need > > to add it back? > > > > [1] > > https://patchwork.freedesktop.org/patch/706445/?series=160349&rev=2#comment_1299475 > > OK, maybe I am thinking, we can expose the observation ioctl, though there > are both pros and cons to doing this. > > Pros: get some OA reporting out of the box. Though the tools etc. will > likely not work out of the box because of other missing > queries/ioctl's. > > Cons: Not sure if it is ok to "snoop" on VF information out of the > box. Customers might insist this is not ok and insist on the > observation ioctl be removed. Also, on platforms on which OA is > supported in VF, there might be a conflict between OA in PF vs VF. > > Also, even if we add the observation ioctl, only the base OA feature will > work. But there are other OA features which require other ioctl's (say > exec) which will not work in the admin-only-pf mode. > > The other option is not add the OA ioctl. And insist that to get regular OA > reporting/tools to work, the device must be unbound and rebound in the > normal (non-admin-only) mode. > > So we could go with either of these approaches. I am ok either way. Maybe > just add the observation ioctl for now and revisit after feedback from > customers/UMD's?
yes, that's probably the way to go since we still only have the oa in the PF. In the future we might add a knob to steer where the oa is-or-not available. > > Thanks. > -- > Ashutosh > > > > > > > > > > > v5 seems to have avoided contradictions of this sort. Or this doesn't > > > matter? Thanks. > > > > but since I'm not using any of those ioctls on daily basis, I might be wrong > >
