DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Harris, James R" <james.r.harris@intel.com>,
	"Walker, Benjamin" <benjamin.walker@intel.com>,
	"Xia, Chenbo" <chenbo.xia@intel.com>
Cc: "Liu, Changpeng" <changpeng.liu@intel.com>,
	David Marchand <david.marchand@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Aaron Conole <aconole@redhat.com>,
	"Zawadzki, Tomasz" <tomasz.zawadzki@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
Date: Thu, 14 Oct 2021 08:41:40 +0200	[thread overview]
Message-ID: <1656274.a7FMDE9GDv@thomas> (raw)
In-Reply-To: <SN6PR11MB3504AB8C0B259657D6987C049CB89@SN6PR11MB3504.namprd11.prod.outlook.com>

14/10/2021 04:21, Xia, Chenbo:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 13/10/2021 19:56, Walker, Benjamin:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > >
> > > > In order to be perfectly clear, all the changes done around this option
> > > > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI
> > becomes
> > > > better manageable.
> > > > I think that nobody want to annoy the SPDK project.
> > > > I understand that the changes effectively add troubles, and I am sorry
> > about
> > > > that. If SPDK and other projects can manage with this change, good.
> > > > If there is a real blocker, we should discuss what are the options.
> > > >
> > > > Thanks for your understanding
> > >
> > > I completely understand the desire to make the ABI manageable. If I were in
> > your shoes, I'd be doing the same exact thing. What I don't currently
> > understand is the motivation behind this enable_driver_sdk option. My guess is
> > that it's one of two things.
> > >
> > > \1 ABI manageability: You say that's the purpose above, and that was my
> > initial assumption. But wouldn't that necessarily mean, over time, no longer
> > considering the symbols that were defined by the header files as part of the
> > stable ABI?
> > 
> > Absolutely. The idea is that we don't guarantee ABI for the drivers.
> > 
> > > If you still consider these symbols as part of the ABI in shared library
> > builds, then the enable_driver_sdk option does absolutely nothing to improve
> > the ABI situation, so why bother to have it at all? We can't have packaged
> > SPDK relying on symbols in a packaged DPDK that are not part of the official
> > ABI.
> > 
> > > \2 Not supporting out-of-tree drivers: Another option is that you just don't
> > want people writing out of tree drivers.
> > 
> > We don't want complications due to support of out-of-tree drivers,
> > but we don't want to forbid them.
> > 
> > > You can't just drop it outright because people already do it,
> > > but you'd like to not support it for shared library builds at least.
> > 
> > I didn't think about it in these terms.
> > But saying we don't offer compatibility for shared library drivers
> > is not too far of "no support" indeed.
> > 
> > > So I'd like to really understand which of these two motivated the
> > enable_driver_sdk option . Maybe it's not even one of the two above. If it is
> > #1, then I think maybe we can work with DPDK to define a very small set of
> > out-of-tree driver APIs/ABIs that need to continue to exist in the shared
> > libraries by default. I do think SPDK needs only a very small number. If it's
> > #2, then that's the entire SPDK use case and I'd ask you to reconsider the
> > direction.
> > 
> > Yes I think we need to agree on functions to keep as-is for compatibility.
> > Waiting for your input please.
> 
> So, do you mean currently DPDK doesn't guarantee ABI for drivers

Yes

> but could have driver ABI in the future?

I don't think so, not general compatibility,
but we can think about a way to avoid breaking SPDK specifically,
which has less requirements.




  reply	other threads:[~2021-10-14  6:41 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  2:23 [dpdk-dev] [PATCH 0/8] " Chenbo Xia
2021-09-10  2:23 ` [dpdk-dev] [PATCH 1/8] bus/pci: add new memory resource access APIs Chenbo Xia
2021-09-13 11:59   ` Kinsella, Ray
2021-09-10  2:23 ` [dpdk-dev] [PATCH 2/8] app/testpmd: use PCI " Chenbo Xia
2021-09-16  6:10   ` Li, Xiaoyun
2021-09-16  6:38     ` Xia, Chenbo
2021-09-10  2:23 ` [dpdk-dev] [PATCH 3/8] examples/ethtool: use PCI library API to get PCI address Chenbo Xia
2021-09-10  2:23 ` [dpdk-dev] [PATCH 4/8] examples/kni: remove unused PCI bus header Chenbo Xia
2021-09-17 15:38   ` Ferruh Yigit
2021-09-10  2:23 ` [dpdk-dev] [PATCH 5/8] test/kni: remove setting of PCI ID and address Chenbo Xia
2021-09-10  7:12   ` David Marchand
2021-09-17 15:38   ` Ferruh Yigit
2021-09-10  2:24 ` [dpdk-dev] [PATCH 6/8] examples/ip_pipeline: " Chenbo Xia
2021-09-10  7:18   ` David Marchand
2021-09-10  8:21     ` Xia, Chenbo
2021-09-17  3:09     ` Xia, Chenbo
2021-09-17 11:55       ` David Marchand
2021-09-17 15:37         ` Ferruh Yigit
2021-09-10  2:24 ` [dpdk-dev] [PATCH 7/8] kni: replace unused variable definition with reserved bytes Chenbo Xia
2021-09-10  2:24 ` [dpdk-dev] [PATCH 8/8] bus/pci: remove ABIs in PCI bus Chenbo Xia
2021-09-13 12:06   ` Kinsella, Ray
2021-09-14  8:15   ` Xu, Rosen
2021-09-18  2:24 ` [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 1/7] bus/pci: add new memory resource access APIs Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 2/7] app/testpmd: use PCI " Chenbo Xia
2021-09-18  2:44     ` Li, Xiaoyun
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 3/7] examples/ethtool: use PCI library API to get PCI address Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 4/7] examples/kni: remove unused PCI bus header Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 5/7] kni: remove unused PCI info from test and example Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 6/7] kni: replace unused variable definition with reserved bytes Chenbo Xia
2021-09-18  2:24   ` [dpdk-dev] [PATCH v2 7/7] bus/pci: remove ABIs in PCI bus Chenbo Xia
2021-09-29  7:38   ` [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs Xia, Chenbo
2021-09-30  8:45     ` David Marchand
2021-10-04 13:37       ` David Marchand
2021-10-04 15:56         ` Harris, James R
2021-10-06  4:25           ` Xia, Chenbo
2021-10-08  6:15             ` Liu, Changpeng
2021-10-08  7:08               ` David Marchand
2021-10-08  7:44                 ` Liu, Changpeng
2021-10-11  6:58                   ` Xia, Chenbo
2021-10-11 12:55                     ` Thomas Monjalon
2021-10-12  0:35                       ` Harris, James R
2021-10-12  7:04                         ` Thomas Monjalon
2021-10-12 16:59                           ` Walker, Benjamin
2021-10-12 18:43                             ` Thomas Monjalon
2021-10-12 19:26                               ` Walker, Benjamin
2021-10-12 21:50                                 ` Thomas Monjalon
2021-10-13 17:56                                   ` Walker, Benjamin
2021-10-13 18:59                                     ` Thomas Monjalon
2021-10-13 22:48                                       ` Walker, Benjamin
2021-10-14  6:41                                         ` Thomas Monjalon
2022-07-11 12:11                                           ` Thomas Monjalon
2021-10-14  2:21                                       ` Xia, Chenbo
2021-10-14  6:41                                         ` Thomas Monjalon [this message]
2021-10-14  7:00                                           ` Xia, Chenbo
2021-10-14  7:07                                             ` Thomas Monjalon
2021-10-14  8:07                                               ` Xia, Chenbo
2021-10-14  8:25                                                 ` Thomas Monjalon
2021-10-27 12:03                                                   ` Xia, Chenbo

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=1656274.a7FMDE9GDv@thomas \
    --to=thomas@monjalon.net \
    --cc=aconole@redhat.com \
    --cc=benjamin.walker@intel.com \
    --cc=changpeng.liu@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=james.r.harris@intel.com \
    --cc=tomasz.zawadzki@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).