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 5D4F0A052A; Mon, 25 Jan 2021 11:31:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 40211140EA9; Mon, 25 Jan 2021 11:31:07 +0100 (CET) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by mails.dpdk.org (Postfix) with ESMTP id DD692140E9E for ; Mon, 25 Jan 2021 11:31:05 +0100 (CET) Received: by mail-lf1-f49.google.com with SMTP id o10so16898440lfl.13 for ; Mon, 25 Jan 2021 02:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OZJ9CIWpGQfIiSm3lSCKFS+X1vgr0cCdnEG4daVDT+c=; b=eSpaj+QcYfWOXpcNZHIl82W7qwS7w3haPFsOCCQQUZ73Cqy4qfzqtGXCBrmLv6vyQB d7fLSIhXg21yctqjBbS0628DkPWKhnPeqSvjx6DIYvvrWaaRtRUM8fvBM9imvP9ZPRL+ FXWFFhLvGTan7n2WREYrzKQ0WdYshpjBigXS6FYVVElGJOap91Byge4qHnjyAFi0Le9L flHOCD4BGcEIscNLK6qXM3goesNtqoIZYsvhyorhqx7aU6tFsC+fjin0lNB1mM0hwb4r nntWHbG3VQCgvMyPY0LkEmyIIcOjTj+Sn7YuHXpiH88SjGe3urwQGsb7mV7P52HvPgFg ot8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OZJ9CIWpGQfIiSm3lSCKFS+X1vgr0cCdnEG4daVDT+c=; b=M6gghb42QjADPIDyhDMpIAwuqaQtofC1rToDbfl49euOBJ6uajVT2SfGmpvRvF0aNW q0b54X8QuduVTfxAg6nonGi+/gx5C0PRa6lwMn63tROT+lzyroRa+go4V0zkGEaHb9tF hqrbH43eGWfeBk0IDCluFtzetyya4DfJ/tBg38H7/4o6nBJmmzx14NqkVwGHCg24iB0V jIZvVjy7BleJxSLVBmet4lYeJp4jOmY4P+y1V0rCrM3ZQ7rkUF1EW5u10snbiVFmsrPL 8hfzP2Y/k1BAil36ym/nlkVwRqluyiDOP+OmgdSE/XUqOfKJU9qbRJB1lTDJsGg0OTQj w8gw== X-Gm-Message-State: AOAM5330CudHico0aR4IG2o5knX76zQV7VQh4V8LIKkm8f7Ba5cfqcWc oy+c9QWPZv4Vtj25Z24Sk7Q= X-Google-Smtp-Source: ABdhPJyugPj6Bg7Wy2ECsl5I1Tz91eLONKbU7qUKZwG5MDbrI8RjfOjU51hg+aYgeFdYI0Wq0ZKhKA== X-Received: by 2002:ac2:5f4d:: with SMTP id 13mr64941lfz.462.1611570665494; Mon, 25 Jan 2021 02:31:05 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id r5sm2117153ljc.81.2021.01.25.02.31.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Jan 2021 02:31:05 -0800 (PST) Date: Mon, 25 Jan 2021 13:31:03 +0300 From: Dmitry Kozlyuk To: "Kinsella, Ray" Cc: Thomas Monjalon , dev@dpdk.org, Stephen Hemminger , David Marchand , Maxime Coquelin , Aaron Conole , Bruce Richardson , ferruh.yigit@intel.com, ray.kinsella@intel.com Message-ID: <20210125133103.04b3107d@sovereign> In-Reply-To: References: <20201014183136.22239-1-dmitry.kozliuk@gmail.com> <5444857.Q0qPc8oPp2@thomas> <20210123012403.1bdb35d0@sovereign> <14261305.cmbqrkYmuW@thomas> <20210125130517.470ae277@sovereign> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen 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 Sender: "dev" On Mon, 25 Jan 2021 10:11:07 +0000, Kinsella, Ray wrote: > On 25/01/2021 10:05, Dmitry Kozlyuk wrote: > > On Mon, 25 Jan 2021 09:25:51 +0000, Kinsella, Ray wrote: > >> On 23/01/2021 11:38, Thomas Monjalon wrote: > >>> 22/01/2021 23:24, Dmitry Kozlyuk: > >>>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote: > >>>>> 22/01/2021 21:31, Dmitry Kozlyuk: > >>>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote: > >>>>>>> 20/01/2021 08:23, Dmitry Kozlyuk: > >>>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote: > >>>>>>>>> This is now the right timeframe to introduce this change > >>>>>>>>> with the new Python module dependency. > >>>>>>>>> Unfortunately, the ABI check is returning an issue: > >>>>>>>>> > >>>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed > >>>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c > >>>>>>>> > >>>>>>>> Will investigate and fix ASAP. > >>>>>> > >>>>>> Now that I think of it: strings like this change every time new PCI IDs are > >>>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage, > >>>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID") > >>>>>> added 2020-07-08, i.e. clearly outside of ABI change window. > >>>>> > >>>>> You're right. > >>>>> > >>>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical), > >>>>>> which can be worked around easily, if the above is wrong. > >>>>> > >>>>> If the new format is better, please keep it. > >>>>> What we need is an exception for the pmdinfo symbols > >>>>> in the file devtools/libabigail.abignore. > >>>>> You can probably use a regex for these symbols. > >>>> > >>>> This would allow real breakages to pass ABI check, abidiff doesn't analyze > >>>> variable content and it's not easy to compare. Maybe later a script can be > >>>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of > >>>> 5494 relevant commits between 19.11 and 20.11, though. > >>>> > >>>> To verify there are no meaningful changes I ensured empty diff between > >>>> results of the following command for "main" and the branch: > >>>> > >>>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py > >>> > >>> For now we cannot do such check as part of the ABI checker. > >>> And we cannot merge this patch if the ABI check fails. > >>> I think the only solution is to allow any change in the pmdinfo variables. > >>> > >> > >> So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI. > >> However we are going to end up carrying this rule in libabigail.ignore indefinitely. > >> > >> Would it make sense to just fix the size of _pmd_info to some reasonably large value - > >> say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release? > > > > I don't think so. This is a JSON *string to be parsed;* considering its size > > as part of application *binary* interface is wrong in the first place. > > Right - then is belongs in INTERNAL, I would say. > > > As for > > content, checking that no PCI IDs are removed is out of scope for libabigail > > anyway. > > Lets be clear PCI IDs - are _nothing_ to do with ABI. Technically, yes, but they're referred to in abi_policy.rst, because DPDK behavior depends on them. Same issue as with as return values: no formats change, yet compatibility is broken. > > Technically we could fix _pmd_info size, but this still allows > > breaking changes to pass the check with no benefit. > > ABI changes or other, please explain? Behavioral changes via PCI ID removal, see above.