[PATCH v1 0/8] Support VFIO cdev API in DPDK
Burakov, Anatoly
anatoly.burakov at intel.com
Thu Oct 30 11:11:45 CET 2025
On 10/30/2025 10:21 AM, David Marchand wrote:
> On Tue, 28 Oct 2025 at 17:43, Anatoly Burakov <anatoly.burakov at intel.com> wrote:
>>
Hi David,
<snip>
>
> Do we really need to expose all this as "applications" API?
> All I see is EAL and/or drivers concerns.
> Could we hide all of this as drivers API or at least clearly separate
> what is driver-only stuff from other API that do make sense for an
> application?
These are indeed mostly driver-related API's, so I agree that this would
be better. The problem is that VFIO is in EAL, and drivers depend on EAL
not the other way around, so we can't do any driver-related stuff in
VFIO directly.
If you're suggesting to make most of this API exported as internal
symbols and deal with it on a bus level, sure, we can do that. It would
require some plumbing change in bus, because buses would need to keep
metadata around to know which device is supposed to use which container,
and be explicitly aware of the concept of DMA mapping - buses already do
have DMA map/unmap API, but it's not custom container-aware and always
uses default container for everything.
The original idea was to give "the user" control over containers and DMA
mapping in context of other memory types (external memory, some specific
device memory etc), but perhaps we can observe that pretty much all such
usage happens in drivers anyway so we don't lose anything by just making
all of this driver-internal. Thoughts?
> But we can't break ABI during 26.03, so maybe my suggestion would have
> to wait 26.11.
The deprecation notice would have to go in in any case, that was the
intention. The patchset is developed around the idea of getting the
changes in as soon as possible, but obviously it's subject to ABI policy
etc so if that can only go in during 26.11, so be it. We can get it
right till then.
>
>
> Two nits on the series:
> - you'll have to update the vhost documentation, for the vDPA driver API update.
Yep, will come in v2.
> - I also saw those inconsistencies: double check the experimental
> symbol marks, the next release is 26.03, not 26.02 (this is no warning
> in checkpatch atm, maybe something to add).
>
Yes, I noticed that after submitting, will be fixed in v2 (already fixed
in fact).
--
Thanks,
Anatoly
More information about the dev
mailing list