| Message ID | 20230808173527.186042-1-stephen@networkplumber.org (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3E4BD4300E; Tue, 8 Aug 2023 19:35:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 16641410E6; Tue, 8 Aug 2023 19:35:41 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id 1771640DFD for <dev@dpdk.org>; Tue, 8 Aug 2023 19:35:39 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-686b643df5dso4144334b3a.1 for <dev@dpdk.org>; Tue, 08 Aug 2023 10:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1691516138; x=1692120938; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=btefie7vFcN1FBVuf7V91X/iAb2LlufFE1kiaJcSdlE=; b=dhQCDtvpAicSxXUwqURv0pTY0MxKquOxUv2MvaDZyf//WbAvFAVOm3PDSxDLMtqUhC MuaGD+rvL1afGjURC0ELpx8pznqN01OGe6ULAvd36EvlbEeoMwNoFqeU+qe9Tyb3MhxG syZFFKWwM19NtGj8LoZWYKK3MF9o/uSXYrxRcol2sTNMaYx5HQofVPAlcGbe/Qlb2Xmp 1wNqjSYnVQrueliP+Qn4PhxALp+/Uph3mv6qS7G/dVNosfnamZilkQrTtsGSvjpRTsLH iMhkA+psPSETUAahZz4xKEtYakxu31h/HIi+PFsQVF4cnkSgOVyzv9ruWtL9Ov4gIzp2 /smQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691516138; x=1692120938; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=btefie7vFcN1FBVuf7V91X/iAb2LlufFE1kiaJcSdlE=; b=A4g0JiSOFKHOC57+stkhhhSezQS6BOiLmTOgFFjKlQwyl35vBBAXWLp+kOcq8glYOR FTbB6x2pWPrkTudh3Kgjx0jgoK+GNeEU0FcWA/zEqWhU31jM7EgrRtgUU4rtlxnTUvx1 NysQL73VbcWpvC/4IWn8kje5eAbPMadmp2sDvsk5fNtHTnZknd833Wnj/k5AIKw4IpCk 2SSXzbpecJDNZqF+XVWcki5YjVN4zQwVAuKlDNDZPunPTuo8ChOXDrIxCninjfSF1Il2 b/pljbXHMz3Glp7uZcJMc+PV9wwxnP/wUb5LTHofqAC2xyfXiRlj/i5dyCIpBZ9D79RH o8hw== X-Gm-Message-State: AOJu0YyiX3qbTo9EFLM+o/sNT1o0FJgadDUQ1v9M6vxg2zj69V2GvVJZ qiWd9dbk5j/vWhoIXXiALr16Ky5FE/AVO8OQZI9n/g== X-Google-Smtp-Source: AGHT+IGkha37Zi8a04pViUXjMvNuKwwgB3+z54G06L4+kgLp00Cz2A4qtxzY5ctY41e9fyNxdJ/LXQ== X-Received: by 2002:a05:6a00:16c1:b0:687:1604:39eb with SMTP id l1-20020a056a0016c100b00687160439ebmr196244pfc.25.1691516138031; Tue, 08 Aug 2023 10:35:38 -0700 (PDT) Received: from hermes.local (204-195-127-207.wavecable.com. [204.195.127.207]) by smtp.gmail.com with ESMTPSA id m13-20020aa7900d000000b00682562bf479sm8328945pfo.53.2023.08.08.10.35.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Aug 2023 10:35:37 -0700 (PDT) From: Stephen Hemminger <stephen@networkplumber.org> To: dev@dpdk.org Cc: Stephen Hemminger <stephen@networkplumber.org> Subject: [PATCH 00/20] remove experimental flag from some API's Date: Tue, 8 Aug 2023 10:35:07 -0700 Message-Id: <20230808173527.186042-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 |
| Series |
remove experimental flag from some API's
|
|
Message
Stephen Hemminger
Aug. 8, 2023, 5:35 p.m. UTC
Since 23.11 is an LTS release it is time to remove the experimental bandaid off many API's. There are about 850 API's marked with experimental on current main branch. This addresses the easy to remove ones and gets it down to about 690 places. The rule is any API that has been in since 22.11 needs to have experimental removed (or deleted). The experimental flag is not a "get out of ABI stability for free" card. Stephen Hemminger (20): bpf: make rte_bpf_dump and rte_bpf_convert stable API's cmdline: make experimental API's stable ethdev: mark rte_mtr API's as stable ethdev: mark rte_tm API's as stable pdump: make API's stable pcapng: mark API's as stable net: remove experimental from functions rcu: remove experimental from rte_rcu_qbsr lpm: remove experimental mbuf: remove experimental from create_extbuf hash: remove experimental from toeplitz hash timer: remove experimental from rte_timer_next_ticks sched: remove experimental dmadev: mark API's as not experimental meter: remove experimental warning from comments power: remove experimental from API's kvargs: remove experimental flag ip_frag: mark a couple of functions stable member: remove experimental tag security: remove experimental flag lib/bpf/rte_bpf.h | 2 - lib/bpf/version.map | 9 +-- lib/cmdline/cmdline.h | 1 - lib/cmdline/cmdline_parse.h | 4 -- lib/cmdline/cmdline_rdline.h | 4 -- lib/cmdline/version.map | 26 +++------ lib/dmadev/rte_dmadev.h | 85 ---------------------------- lib/dmadev/version.map | 2 +- lib/ethdev/rte_mtr.h | 25 +------- lib/ethdev/rte_tm.h | 34 ----------- lib/ethdev/version.map | 88 ++++++++++++++--------------- lib/hash/rte_thash.h | 44 --------------- lib/hash/rte_thash_gfni.h | 8 --- lib/hash/rte_thash_x86_gfni.h | 8 --- lib/hash/version.map | 16 ++---- lib/ip_frag/rte_ip_frag.h | 2 - lib/ip_frag/version.map | 9 +-- lib/kvargs/rte_kvargs.h | 4 -- lib/kvargs/version.map | 8 +-- lib/lpm/rte_lpm.h | 4 -- lib/lpm/version.map | 7 +-- lib/mbuf/rte_mbuf.h | 1 - lib/mbuf/version.map | 8 +-- lib/member/rte_member.h | 54 ------------------ lib/member/version.map | 12 +--- lib/meter/rte_meter.h | 12 ---- lib/net/rte_ip.h | 19 ------- lib/pcapng/rte_pcapng.h | 11 ---- lib/pcapng/version.map | 6 +- lib/pdump/rte_pdump.h | 12 ---- lib/pdump/version.map | 11 +--- lib/power/rte_power.h | 4 -- lib/power/rte_power_guest_channel.h | 4 -- lib/power/rte_power_intel_uncore.h | 9 --- lib/power/rte_power_pmd_mgmt.h | 40 ------------- lib/power/version.map | 33 ++++------- lib/rcu/rte_rcu_qsbr.h | 20 ------- lib/rcu/version.map | 15 ++--- lib/sched/rte_pie.h | 8 --- lib/sched/rte_sched.h | 5 -- lib/sched/version.map | 18 ++---- lib/security/rte_security.h | 35 ------------ lib/security/version.map | 17 ++---- lib/timer/rte_timer.h | 4 -- lib/timer/version.map | 7 +-- 45 files changed, 97 insertions(+), 658 deletions(-)
Comments
On Tue, Aug 08, 2023 at 10:35:07AM -0700, Stephen Hemminger wrote: > Since 23.11 is an LTS release it is time to remove the experimental > bandaid off many API's. There are about 850 API's marked with experimental > on current main branch. This addresses the easy to remove ones and > gets it down to about 690 places. > > The rule is any API that has been in since 22.11 needs to have > experimental removed (or deleted). The experimental flag is not a > "get out of ABI stability for free" card. For the libraries here that are enabled for Windows are the APIs being marked stable have real implementations or just stubs on Windows? If they are just stubs then i think more review is necessary for the stubbed APIs to understand that they *can* be implemented on Windows. I would prefer not to have to encounter this later and have to go through the overhead of deprecation like with rte_thread_ctrl_create again. This obviously doesn't apply to libraries that are not currently enabled for Windows. If the implementations aren't stubs then that's okay too. Ty
On Tue, 8 Aug 2023 11:19:12 -0700 Tyler Retzlaff <roretzla@linux.microsoft.com> wrote: > On Tue, Aug 08, 2023 at 10:35:07AM -0700, Stephen Hemminger wrote: > > Since 23.11 is an LTS release it is time to remove the experimental > > bandaid off many API's. There are about 850 API's marked with experimental > > on current main branch. This addresses the easy to remove ones and > > gets it down to about 690 places. > > > > The rule is any API that has been in since 22.11 needs to have > > experimental removed (or deleted). The experimental flag is not a > > "get out of ABI stability for free" card. > > For the libraries here that are enabled for Windows are the APIs being > marked stable have real implementations or just stubs on Windows? > > If they are just stubs then i think more review is necessary for the > stubbed APIs to understand that they *can* be implemented on Windows. > > I would prefer not to have to encounter this later and have to go > through the overhead of deprecation like with rte_thread_ctrl_create > again. > > This obviously doesn't apply to libraries that are not currently enabled > for Windows. If the implementations aren't stubs then that's okay too. I don't see any stubs when looking. bpf: not built on Windows. Needs some libelf. pdump: not built on Windows. Needs bpf for filtering rte_tm: ok rte_mtr: ok cmdline: ok pcapng: ok net: ok rcu: ok lpm: ok mbuf: ok hash: ok timer: ok dmadev: ok meter: ok power: not on windows, probably need special API's kvargs: ok ip_frag: ok member: not build on windows, not sure why security: ok vhost: not build on windows, not sure why regexdev: not build on windows, not sure why node: not build on windows, not sure why Changes to eal need to be more selective.
On Tue, Aug 08, 2023 at 02:33:52PM -0700, Stephen Hemminger wrote: > On Tue, 8 Aug 2023 11:19:12 -0700 > Tyler Retzlaff <roretzla@linux.microsoft.com> wrote: > > > On Tue, Aug 08, 2023 at 10:35:07AM -0700, Stephen Hemminger wrote: > > > Since 23.11 is an LTS release it is time to remove the experimental > > > bandaid off many API's. There are about 850 API's marked with experimental > > > on current main branch. This addresses the easy to remove ones and > > > gets it down to about 690 places. > > > > > > The rule is any API that has been in since 22.11 needs to have > > > experimental removed (or deleted). The experimental flag is not a > > > "get out of ABI stability for free" card. > > > > For the libraries here that are enabled for Windows are the APIs being > > marked stable have real implementations or just stubs on Windows? > > > > If they are just stubs then i think more review is necessary for the > > stubbed APIs to understand that they *can* be implemented on Windows. > > > > I would prefer not to have to encounter this later and have to go > > through the overhead of deprecation like with rte_thread_ctrl_create > > again. > > > > This obviously doesn't apply to libraries that are not currently enabled > > for Windows. If the implementations aren't stubs then that's okay too. > > I don't see any stubs when looking. > > bpf: not built on Windows. Needs some libelf. > pdump: not built on Windows. Needs bpf for filtering > rte_tm: ok > rte_mtr: ok > cmdline: ok > pcapng: ok > net: ok > rcu: ok > lpm: ok > mbuf: ok > hash: ok > timer: ok > dmadev: ok > meter: ok > power: not on windows, probably need special API's > kvargs: ok > ip_frag: ok > member: not build on windows, not sure why > security: ok > vhost: not build on windows, not sure why > regexdev: not build on windows, not sure why > node: not build on windows, not sure why > > Changes to eal need to be more selective. Thanks Stephen I appreciate you checking it out it helps a lot. Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com> > >
On Tue, 8 Aug 2023 16:23:43 -0700 Tyler Retzlaff <roretzla@linux.microsoft.com> wrote: > > > > bpf: not built on Windows. Needs some libelf. > > pdump: not built on Windows. Needs bpf for filtering A different topic, is it possible to get pdump working on Windows? Is there a pcap and elf library? Might be possible to split out libelf dependency in bpf library. Libelf is used to load external file, but some uses just use internal data.
2023-08-09 08:34 (UTC-0700), Stephen Hemminger: > On Tue, 8 Aug 2023 16:23:43 -0700 > Tyler Retzlaff <roretzla@linux.microsoft.com> wrote: > > > > > > > bpf: not built on Windows. Needs some libelf. > > > pdump: not built on Windows. Needs bpf for filtering > > A different topic, is it possible to get pdump working on Windows? Unlikely with the current state of DPDK and pdump. The main issue is multiprocess, which is not implemented. Windows can share hugepages between processes (MapViewOfFile3) or map it to a fixed address in the reserved region (VirtualAlloc2), but not both, this was the blocker AFAIR. > Is there a pcap and elf library? net/pcap already uses libpcap. Looks like there are libelf ports too. > Might be possible to split out libelf dependency in bpf library. > Libelf is used to load external file, but some uses just use internal data. ELF library is an optional dependency already.
On 8/8/23 19:35, Stephen Hemminger wrote: > Since 23.11 is an LTS release it is time to remove the experimental > bandaid off many API's. There are about 850 API's marked with experimental > on current main branch. This addresses the easy to remove ones and > gets it down to about 690 places. > > The rule is any API that has been in since 22.11 needs to have > experimental removed (or deleted). The experimental flag is not a > "get out of ABI stability for free" card. > > Stephen Hemminger (20): > bpf: make rte_bpf_dump and rte_bpf_convert stable API's > cmdline: make experimental API's stable > ethdev: mark rte_mtr API's as stable > ethdev: mark rte_tm API's as stable > pdump: make API's stable > pcapng: mark API's as stable > net: remove experimental from functions > rcu: remove experimental from rte_rcu_qbsr > lpm: remove experimental > mbuf: remove experimental from create_extbuf > hash: remove experimental from toeplitz hash > timer: remove experimental from rte_timer_next_ticks > sched: remove experimental > dmadev: mark API's as not experimental > meter: remove experimental warning from comments > power: remove experimental from API's > kvargs: remove experimental flag > ip_frag: mark a couple of functions stable > member: remove experimental tag > security: remove experimental flag > > lib/bpf/rte_bpf.h | 2 - > lib/bpf/version.map | 9 +-- > lib/cmdline/cmdline.h | 1 - > lib/cmdline/cmdline_parse.h | 4 -- > lib/cmdline/cmdline_rdline.h | 4 -- > lib/cmdline/version.map | 26 +++------ > lib/dmadev/rte_dmadev.h | 85 ---------------------------- > lib/dmadev/version.map | 2 +- > lib/ethdev/rte_mtr.h | 25 +------- > lib/ethdev/rte_tm.h | 34 ----------- > lib/ethdev/version.map | 88 ++++++++++++++--------------- > lib/hash/rte_thash.h | 44 --------------- > lib/hash/rte_thash_gfni.h | 8 --- > lib/hash/rte_thash_x86_gfni.h | 8 --- > lib/hash/version.map | 16 ++---- > lib/ip_frag/rte_ip_frag.h | 2 - > lib/ip_frag/version.map | 9 +-- > lib/kvargs/rte_kvargs.h | 4 -- > lib/kvargs/version.map | 8 +-- > lib/lpm/rte_lpm.h | 4 -- > lib/lpm/version.map | 7 +-- > lib/mbuf/rte_mbuf.h | 1 - > lib/mbuf/version.map | 8 +-- > lib/member/rte_member.h | 54 ------------------ > lib/member/version.map | 12 +--- > lib/meter/rte_meter.h | 12 ---- > lib/net/rte_ip.h | 19 ------- > lib/pcapng/rte_pcapng.h | 11 ---- > lib/pcapng/version.map | 6 +- > lib/pdump/rte_pdump.h | 12 ---- > lib/pdump/version.map | 11 +--- > lib/power/rte_power.h | 4 -- > lib/power/rte_power_guest_channel.h | 4 -- > lib/power/rte_power_intel_uncore.h | 9 --- > lib/power/rte_power_pmd_mgmt.h | 40 ------------- > lib/power/version.map | 33 ++++------- > lib/rcu/rte_rcu_qsbr.h | 20 ------- > lib/rcu/version.map | 15 ++--- > lib/sched/rte_pie.h | 8 --- > lib/sched/rte_sched.h | 5 -- > lib/sched/version.map | 18 ++---- > lib/security/rte_security.h | 35 ------------ > lib/security/version.map | 17 ++---- > lib/timer/rte_timer.h | 4 -- > lib/timer/version.map | 7 +-- > 45 files changed, 97 insertions(+), 658 deletions(-) > You removed Vhost changes altogether, but I only asked for the Vhost Async API changes to be removed, i.e. the APIs in rte_vhost_async.h. Maxime
On Tue, 24 Oct 2023 09:20:05 +0200 Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > You removed Vhost changes altogether, but I only asked for the Vhost > Async API changes to be removed, i.e. the APIs in rte_vhost_async.h. > > Maxime Will get back to vhost, just moved it to the end of the TODO list.