[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