From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 69A1CA0544;
	Fri, 23 Sep 2022 09:13:57 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 0A05E400D7;
	Fri, 23 Sep 2022 09:13:57 +0200 (CEST)
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by mails.dpdk.org (Postfix) with ESMTP id BBCD74003C
 for <dev@dpdk.org>; Fri, 23 Sep 2022 09:13:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1663917235;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=/re1YGPCCy1DZgkvPSFWpZS1+8jlVpBdEKVMQNoL8so=;
 b=P3n0Izf37aegxndmK6geFMjOsE06HrLrLEA9SwqhX+bZrpFxMexveDqmfQM9RJ7VZJsf5t
 7zICKDWe8xsIFfs4VI3eAfo0VV4qav6eK5daq2/X+aDFLwX0Zr6Fk2FV57EunO8XJJJ4nn
 sFeEx2dh+h+YP2JS+n7DhRcE/50JmvU=
Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com
 [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id
 us-mta-584-k-NqSq1uN7-S4PbsgggpLQ-1; Fri, 23 Sep 2022 03:13:53 -0400
X-MC-Unique: k-NqSq1uN7-S4PbsgggpLQ-1
Received: by mail-lj1-f197.google.com with SMTP id
 a13-20020a2ebe8d000000b0026bfc93da46so3677034ljr.16
 for <dev@dpdk.org>; Fri, 23 Sep 2022 00:13:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date;
 bh=/re1YGPCCy1DZgkvPSFWpZS1+8jlVpBdEKVMQNoL8so=;
 b=K+niIML6BmY3WzHxTr5732O+NHZmqPJk/kei8YfAzw/v2RXwW+1vnXeJ+QtGBaD1ry
 O2hnq0qAWAkmiLDv2TkKs3tkHEAD4crKwyKPwNjJSgMpwboSq2QQl++Yz92jy988RWMH
 cLpEOJC7wETJkOMUodgFPLLDX+ub12MobtFcrZyeuUePupgstGJ7udoJTWgIBSFQ0L5R
 mnVRWWaQUfxB/LH9UE3VTAyXBkReZMhGtwZcE2EqxLMcEhuL2k44nOiGC4LoRTDXYSC+
 X2AWH34/gfjpj2Yru6J8nBPEiqVl5LwIYxw9RosvewdyucDAW/zDsKYJo8IR0/h7h144
 b3HA==
X-Gm-Message-State: ACrzQf3A3VLLRQ/J2P1DyTkiQZjBd6OfI7QpTaZjLiPBHCk6cTyzpz98
 W9RDa6IvKD3ht+zC2VRLIVj7pqtH8bcGPAYaHjAhqWMxjFzCpZ7CC9ouOji3Ce29TmvCnpb1aLK
 pJPnvYBaFSEpCZmetMfk=
X-Received: by 2002:a2e:9a88:0:b0:26a:c4d2:3418 with SMTP id
 p8-20020a2e9a88000000b0026ac4d23418mr2476898lji.81.1663917231960; 
 Fri, 23 Sep 2022 00:13:51 -0700 (PDT)
X-Google-Smtp-Source: AMsMyM5XnLLNENb85a4WtOFYOoI6PtnDeoQJ8fSbHX0+j9mn/2GwLjmMlUKpX6jS7+4qvw+ixC1W9HJL2ukwpMXYhsc=
X-Received: by 2002:a2e:9a88:0:b0:26a:c4d2:3418 with SMTP id
 p8-20020a2e9a88000000b0026ac4d23418mr2476891lji.81.1663917231706; Fri, 23 Sep
 2022 00:13:51 -0700 (PDT)
MIME-Version: 1.0
References: <20220628144643.1213026-1-david.marchand@redhat.com>
 <20220728152640.547725-1-david.marchand@redhat.com>
 <8AC9271A-AC63-4C5E-BF9C-E4E8027A1132@intel.com>
 <CAJFAV8wDm_A-fJvTugMxzxBCO_U0R7hcLo-aRK5xDPQKtyc0YQ@mail.gmail.com>
 <BYAPR11MB2824536FB90CDCC745C5B42AEF769@BYAPR11MB2824.namprd11.prod.outlook.com>
 <CAJFAV8yNoP5PKx4HN76gGb3iJfXEx2WF83Yep66qx31s-VrxVw@mail.gmail.com>
 <F932E29C-7F68-4715-8D66-96354ECFB77F@intel.com>
In-Reply-To: <F932E29C-7F68-4715-8D66-96354ECFB77F@intel.com>
From: David Marchand <david.marchand@redhat.com>
Date: Fri, 23 Sep 2022 09:13:40 +0200
Message-ID: <CAJFAV8zL4YWdxt0daU6vz31ybqRmqdLXHD0LDKf5GcjkEu9FRg@mail.gmail.com>
Subject: Re: [RFC v3 00/26] Bus and device cleanup for 22.11
To: "Harris, James R" <james.r.harris@intel.com>
Cc: "Walker, Benjamin" <benjamin.walker@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>, "Liu, Changpeng" <changpeng.liu@intel.com>,
 Alexey Marchuk <alexeymar@nvidia.com>, 
 Shuhei Matsumoto <smatsumoto@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>,
 "Richardson, Bruce" <bruce.richardson@intel.com>,
 Stephen Hemminger <stephen@networkplumber.org>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Thu, Sep 22, 2022 at 12:29 AM Harris, James R
<james.r.harris@intel.com> wrote:
> > On Aug 30, 2022, at 8:09 AM, David Marchand <david.marchand@redhat.com>=
 wrote:
> >
> > On Mon, Aug 29, 2022 at 7:12 PM Walker, Benjamin
> > <benjamin.walker@intel.com> wrote:
> >>>> Can we keep rte_pci_register(), or a new variation of it that keeps
> >>>> the rte_pci_driver structure hidden?  Hiding rte_pci_register() woul=
d
> >>>> mean SPDK can no longer work with a packaged DPDK.  Or the DPDK
> >>>> packages would need to set enable_driver_sdk which I suspect is not =
the
> >>> intent.
> >>>
> >>> What do you think if SPDK maintains a copy of the internal headers?
> >>>
> >>> The internal API are not supposed to change that often, but we (DPDK)=
 won't
> >>> guarantee it.
> >>> This would still put some maintenance burden on SPDK but I think it i=
s a good
> >>> compromise.
> >>>
> >>
> >> Would these internal symbols be considered part of the public/official=
 ABI? When
> >
> > What do you mean by "public/official"?
> > If you mean the "stable" ABI (as described in the ABI policy document
> > and for which compatibility is preserved across minor versions of the
> > ABI), the answer is no: internal symbols are not part of it.
> >
> >
> >> SPDK goes to dynamically load a shared DPDK library, how can we detect
> >> whether it's a version that we support linking against?
> >
> > The runtime version of a DPDK library is available via rte_version().
> >
> >
> > As for the PCI drivers that SPDK wants to register in DPDK, what do
> > you think if SPDK people added and maintained a "generic" PCI driver
> > in DPDK.
> > This driver would expose a new API (which can not re-expose internal
> > structures, like rte_pci_driver and consorts) and ensure its ABI is
> > maintained in the long term.
> > This makes me think of pci-stub, but in DPDK.
> >
> > I did not think too much about it and I don't understand what SPDK
> > requires, but is there something wrong with this approach?
>
> The stub driver idea is interesting. In the past we=E2=80=99ve needed acc=
ess to more
> than what a stub driver would provide - for example, to work around kerne=
l
> vfio + pci bugs when we probe 24 NVMe SSDs behind a PCIe switch that is
> hot-inserted, or conversely handling hot removal of that same switch.  So
> I=E2=80=99m worried that even if we do the stub driver, we end up running=
 into a
> case where we need these header file copies anyways.  Not ruling the stub
> driver out, but I think it's a longer-term goal, not something we would h=
ave
> ready for 22.11 obviously.
>
> So sticking with the internal header copies for now, this works fine
> for LTS and non-LTS releases.  What about stable releases (i.e. 22.11.1)?
> IIUC, these header files could change in a stable release since they are
> no longer part of the ABI?

In theory, yes they can change.
But this is a price to pay, as no one seems willing to invest and
maintain a stable API for PCI drivers.


I just noticed that some parts of the cleanups I had proposed have
been merged in SPDK.
Next time, I prefer getting some feedback from SPDK community before
my SoB is applied (or stripped) on modified patches.


Thanks.

--=20
David Marchand