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 46FE343010; Tue, 8 Aug 2023 23:33:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D3C9D42B71; Tue, 8 Aug 2023 23:33:56 +0200 (CEST) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mails.dpdk.org (Postfix) with ESMTP id 92DE041148 for ; Tue, 8 Aug 2023 23:33:55 +0200 (CEST) Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1bbff6b2679so40749095ad.1 for ; Tue, 08 Aug 2023 14:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1691530434; x=1692135234; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=BzNzaOds0qkwQGl9aLoTHh9tk4lss1O+h9sDXzi72XY=; b=ZK8LynFD6vOsb55DS9eElBgMCWXnXjOpQumMyGPY/vVOVEBmJhn5Nw/D4bXdaKN/uU yy3e+MjZ3Ighjn3g95Kv+jVwajYBAyQj2o9e3R88XK1AxuvDWfdKSEPHPNn5XpkIkSKk z2aoQPoFFi8/jXqCkdysoB4SpCBWgWB3Y2YQzSs9CI2gd954CBJySaG2ZXgKGhAdrEWc L+zrhwNRlUnIQjUAbBtDDrOdvy6AB6vl4P3YUoMKycjl5E6rSM0SN2sVBkYfSlny2FeA 2JNeHpPV4S6eoOXsxHCNzq9x6kyWWt9+RaYMdoPJuP/vCLUXH62POSGJEx1nEtycNSMk Cg7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691530434; x=1692135234; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BzNzaOds0qkwQGl9aLoTHh9tk4lss1O+h9sDXzi72XY=; b=k1erZhiYGnp/uq4fvVhDTz1q24TMpn1wO6kjY58k4mTPo3hXH6GcRnA4Y4lluAw373 lI8JBeWDuu0wCdNPPvQpCFA4MEVGg/yBCaB1qdPAZZ4gY0Lji8FPTJ9+jtehdjC5bUCu oOPIBr5buhVMDWpHgu7LtF2NnP6H8bhXsKegIrTwlD8Wus2Vh7EV0UFh8MRHi5QhHKrg gL3Qxg+jNwqWh+q44vI11/5icQvvehVYk/ymA/qy/AruoR10ixazB0GDPaAYZ0Wni7ED 8Q2ufpy18REO8PLVVWZJivrdlrJkNZVtWSKMLApWNBi2utwQtKh6WFRWtWGl8+mrPttz iuLg== X-Gm-Message-State: AOJu0YxlQ9VYkoqnE9HXK1fhqSmTDA5MJzu0mY80A1zHeSupMwwkqYsC XIBs9ejyw+xW8wwX+BfMaN9pHQ== X-Google-Smtp-Source: AGHT+IEDnDnvbK/Sm22ViAtGcjIBaQachwFSo5eBup5VfvroZFmRbhsnpK4vorc9o1OyImA4L5mOug== X-Received: by 2002:a17:902:eb45:b0:1bc:82b1:9f90 with SMTP id i5-20020a170902eb4500b001bc82b19f90mr726664pli.68.1691530434570; Tue, 08 Aug 2023 14:33:54 -0700 (PDT) Received: from hermes.local (204-195-127-207.wavecable.com. [204.195.127.207]) by smtp.gmail.com with ESMTPSA id e16-20020a17090301d000b001bc18e579aesm9518099plh.101.2023.08.08.14.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Aug 2023 14:33:54 -0700 (PDT) Date: Tue, 8 Aug 2023 14:33:52 -0700 From: Stephen Hemminger To: Tyler Retzlaff Cc: dev@dpdk.org Subject: Re: [PATCH 00/20] remove experimental flag from some API's Message-ID: <20230808143352.79e8370e@hermes.local> In-Reply-To: <20230808181912.GA16722@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230808173527.186042-1-stephen@networkplumber.org> <20230808181912.GA16722@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 8 Aug 2023 11:19:12 -0700 Tyler Retzlaff 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.