From: David Marchand <david.marchand@redhat.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev <dev@dpdk.org>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
"Xia, Chenbo" <chenbo.xia@intel.com>,
Ray Kinsella <mdr@ashroe.eu>, Xiao Wang <xiao.w.wang@intel.com>,
Matan Azrad <matan@nvidia.com>,
Vijay Kumar Srivastava <vsrivast@xilinx.com>,
Ferruh Yigit <ferruh.yigit@xilinx.com>
Subject: Re: [PATCH v2] doc: announce transition to vDPA device name function
Date: Wed, 13 Jul 2022 15:26:33 +0200 [thread overview]
Message-ID: <CAJFAV8ytSvd9+uj_fWgTWbb5Y7DjTN6H64Z5Y1SHOALt9Ob01w@mail.gmail.com> (raw)
In-Reply-To: <20220712133610.4175033-1-thomas@monjalon.net>
On Tue, Jul 12, 2022 at 3:36 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> There is a layer violation in the vDPA API for getting the device name.
> Instead of providing the name at vDPA level,
> a function returns the low-level device object.
Exposing a rte_device (as an opaque pointer) in upper device classes
seems a good thing to me.
With the API rework I proposed, we will have accessors to get this
object characteristics (like here, a name identifying it).
Having the vDPA API returns a pointer to a rte_device object makes it
possible to reuse those accessors, nothing more needed.
If the rte_device object is extended in any (unforeseen at the moment)
way in the future, it would still be a matter of using the relevant
accessor.
No update needed in the vDPA API at this point in the future.
On the other hand, what you propose here seems to go the other way.
With each device classes needing to expose, through its own means /
API, the underlying rte_device characteristics.
--
David Marchand
next prev parent reply other threads:[~2022-07-13 13:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 7:34 [dpdk-dev] [PATCH] doc: announce transition to vDPA port close function Thomas Monjalon
2021-05-18 7:42 ` Andrew Rybchenko
2021-08-02 22:49 ` Thomas Monjalon
2022-07-12 9:16 ` Maxime Coquelin
2022-07-12 12:26 ` Thomas Monjalon
2022-07-12 12:28 ` Thomas Monjalon
2022-07-12 12:40 ` Maxime Coquelin
2022-07-12 13:36 ` [PATCH v2] doc: announce transition to vDPA device name function Thomas Monjalon
2022-07-13 12:10 ` Maxime Coquelin
2022-07-13 12:37 ` Matan Azrad
2022-07-13 13:26 ` David Marchand [this message]
2022-07-13 14:07 ` Thomas Monjalon
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=CAJFAV8ytSvd9+uj_fWgTWbb5Y7DjTN6H64Z5Y1SHOALt9Ob01w@mail.gmail.com \
--to=david.marchand@redhat.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=chenbo.xia@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=matan@nvidia.com \
--cc=maxime.coquelin@redhat.com \
--cc=mdr@ashroe.eu \
--cc=thomas@monjalon.net \
--cc=vsrivast@xilinx.com \
--cc=xiao.w.wang@intel.com \
/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).