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 804FDA034C; Tue, 30 Aug 2022 17:10:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1BE4F40F18; Tue, 30 Aug 2022 17:10:15 +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 CE79440F17 for ; Tue, 30 Aug 2022 17:10:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661872212; 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: in-reply-to:in-reply-to:references:references; bh=sPz1hcvRG4Bfr7RznN8eWPDwtsAwtnIGWcit/rKJJbs=; b=A+hkq8yWGEK+yBddKG42Yk0RGXYfqJTA1ei3gy3S9AexKKljJC71uqVCk0w/vPR/vLgAoB mEK3UcqXIrESvKRK+u3wAHeE/peRfG4FBxueEroSkQXLCa1dHBzyu7VXyiDJLnTP5w77S2 WIJHs4gloM1VCiKvhDG0UbpubSy5hGU= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-522-yQ-TCMZMNWm9jOo8H7oaWA-1; Tue, 30 Aug 2022 11:10:09 -0400 X-MC-Unique: yQ-TCMZMNWm9jOo8H7oaWA-1 Received: by mail-lf1-f70.google.com with SMTP id p36-20020a05651213a400b004779d806c13so2728647lfa.10 for ; Tue, 30 Aug 2022 08:10:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=sPz1hcvRG4Bfr7RznN8eWPDwtsAwtnIGWcit/rKJJbs=; b=Jx0adjS4y6O3BHnTQNCYjPVbkhUmhdahv6dTKqMOMu/qjeDsoI6X9Psnhb/czJXqrH na9DMXaOcgzFYNnKGqWbaEQeGS4pb/19iqpJ5/X4ESILK/vlhI/gErceb6L8Jcib/VJ/ 7wlDanRv4gAyJvrEMqS/B7NaKfg2ziATaB275Z265lUukH+ddeSS/DuLh9Dwq1IsVkb0 S+tOQMzXHIfvCrbPFj708osJBj2qWuLSHqguOkk8Dy8tF3uaRcv+rZPU0z73/W2YKEPC L2nJH9ml++PM2o5AIw+AuxXuSXQgl3h6L89ucAaa0MxWd3dwhUe8yV5TEfK7W2gezwm8 HgQA== X-Gm-Message-State: ACgBeo1Q1HyH7yAL3CJwnn0ilVdZq9WdxwMsJCjGHyfdaFEzJXWjbHGa LUFdwB0njFom80uH0NsT2SR00du5gyOQFHP5yi0J8pQXqD6GeKaLY4Eu3SgseQz/SPbCDnDf+R4 CZVMmp2GkNvxAYLRxeXM= X-Received: by 2002:a2e:84c7:0:b0:265:1210:c31d with SMTP id q7-20020a2e84c7000000b002651210c31dmr2931929ljh.333.1661872208288; Tue, 30 Aug 2022 08:10:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR7ryFKt0OHrUuVP1gayv2OeoYnkm1i7fobkUILTtcTS1Ov5xwIGHd0IzvqGexOg31thjJFzmNaO69seRZUAGug= X-Received: by 2002:a2e:84c7:0:b0:265:1210:c31d with SMTP id q7-20020a2e84c7000000b002651210c31dmr2931919ljh.333.1661872208031; Tue, 30 Aug 2022 08:10:08 -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: Tue, 30 Aug 2022 17:09:56 +0200 Message-ID: Subject: Re: [RFC v3 00/26] Bus and device cleanup for 22.11 To: "Walker, Benjamin" Cc: "Harris, James R" , "dev@dpdk.org" , "Liu, Changpeng" , Alexey Marchuk , Shuhei Matsumoto , Thomas Monjalon , Bruce Richardson , Stephen Hemminger X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 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() would > > > 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 is 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? -- David Marchand