From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH v1 0/8] Support VFIO cdev API in DPDK
Date: Thu, 30 Oct 2025 11:11:45 +0100	[thread overview]
Message-ID: <ba7695ab-1233-45f9-a899-ab550af5c364@intel.com> (raw)
In-Reply-To: <CAJFAV8wQiRZoeZD0uOxi_aa05XsE50_LbAQLxa1b12-vet-WkQ@mail.gmail.com>
On 10/30/2025 10:21 AM, David Marchand wrote:
> On Tue, 28 Oct 2025 at 17:43, Anatoly Burakov <anatoly.burakov@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
     prev parent reply	other threads:[~2025-10-30 10:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 16:43 Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 1/8] uapi: update to v6.17 and add iommufd.h Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 2/8] vfio: add container device assignment API Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 3/8] vhost: remove group-related API from drivers Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 4/8] vfio: do not setup the device on get device info Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 5/8] vfio: cleanup and refactor Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 6/8] vfio: introduce cdev mode Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 7/8] doc: deprecate VFIO group-based APIs Anatoly Burakov
2025-10-28 16:43 ` [PATCH v1 8/8] vfio: deprecate group-based API Anatoly Burakov
2025-10-29  9:50 ` 回复:[PATCH v1 0/8] Support VFIO cdev API in DPDK Dimon
2025-10-29 12:03   ` Burakov, Anatoly
2025-10-30  9:21 ` [PATCH " David Marchand
2025-10-30 10:11   ` Burakov, Anatoly [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox
  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):
  git send-email \
    --in-reply-to=ba7695ab-1233-45f9-a899-ab550af5c364@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY
  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).