From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; 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> In-Reply-To: From: David Marchand Date: Fri, 23 Sep 2022 09:13:40 +0200 Message-ID: Subject: Re: [RFC v3 00/26] Bus and device cleanup for 22.11 To: "Harris, James R" Cc: "Walker, Benjamin" , "dev@dpdk.org" , "Liu, Changpeng" , Alexey Marchuk , Shuhei Matsumoto , Thomas Monjalon , "Richardson, Bruce" , Stephen Hemminger 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Sep 22, 2022 at 12:29 AM Harris, James R wrote: > > On Aug 30, 2022, at 8:09 AM, David Marchand = wrote: > > > > On Mon, Aug 29, 2022 at 7:12 PM Walker, Benjamin > > 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