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 8BC6FA050D; Thu, 14 Apr 2022 11:09:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EEBFC40041; Thu, 14 Apr 2022 11:09:03 +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 DC0174003F for ; Thu, 14 Apr 2022 11:09:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649927342; 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=uGCAKqcWDEzshxytzPkG4ZX60FF7ozliPbb10u7I9pk=; b=gfmyII+x5jJMWWVZ6IzxYodbEbjSu3sXJl+yCPOVe+3lT1ehzRi3GCy+cSvyCEVQZ5rtaa KYAPCP739TRb7Ktqdin9RXp+wjV9CvQR/BTHaROfPDQF1TSpdqxy4QPMowcp167gF1wi38 PqUqcRtQ9Zcrwxge3vXOChFsVy9huBc= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-232-dAhDbNtPMnmdxiqHW0FWSA-1; Thu, 14 Apr 2022 05:09:01 -0400 X-MC-Unique: dAhDbNtPMnmdxiqHW0FWSA-1 Received: by mail-wm1-f70.google.com with SMTP id h18-20020a05600c351200b0038e82e6321bso2138535wmq.5 for ; Thu, 14 Apr 2022 02:09:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=uGCAKqcWDEzshxytzPkG4ZX60FF7ozliPbb10u7I9pk=; b=kq4BKHWzGRkhUe47EdGUuwhFRwXrtGNh04VDOCkQFIaRqKXFLTMSq6Od+r+MbbLtmw vGdCT7cgug1Oz2J4lib9B8rZYNe5wkXO2XnQ614dMBR5DUfm3cl7eRGoMtGVl546H1P3 RSRbVye2c72sU4horZCRAl/k18CZDyVUyxJAs6mKlVEEOoHuyS3TS4qwhNx+n6qJL/jS c+W9agclSOVVj1rdT1NG4poVEUTaajXlDEYlMc2OhCuqB4hporUuuPzhS8ieS7Axa8tQ pe6J8MsE22s0/IE4D0Wcqsx6fQsXWfGKSsyPVOPzMjJnOyav5EMcwSDuX7inokm9ljYg JyfA== X-Gm-Message-State: AOAM531HMWQU+opkRLuTJIof/3NGuHIzyTb+GwHqhWCvlyR6VrLeefDx jK+GRI/cPOdjG8FBg7vTOMMftYqWUkvKl/jJA5v5nJ6MqQr+vMo99lKHeYvA6+J4TDlZGBkZ4w9 /Avg= X-Received: by 2002:a1c:4d04:0:b0:38e:bb87:89ca with SMTP id o4-20020a1c4d04000000b0038ebb8789camr2667235wmh.129.1649927339978; Thu, 14 Apr 2022 02:08:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8BF7MnGR97QyGm9jv+Zi+BwfzZU/AcTVEMM2jJTr+PqbaYXJrMS998S9scV70P3v+1KRAww== X-Received: by 2002:a1c:4d04:0:b0:38e:bb87:89ca with SMTP id o4-20020a1c4d04000000b0038ebb8789camr2667202wmh.129.1649927339730; Thu, 14 Apr 2022 02:08:59 -0700 (PDT) Received: from [192.168.0.36] ([78.19.110.230]) by smtp.gmail.com with ESMTPSA id m1-20020a1ca301000000b0038ea15d5f75sm5135407wme.38.2022.04.14.02.08.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Apr 2022 02:08:59 -0700 (PDT) Message-ID: Date: Thu, 14 Apr 2022 10:08:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: Christian Ehrhardt Cc: Thomas Monjalon , Ori Kam , stable@dpdk.org, dev@dpdk.org, Abhishek Marathe , Ali Alnubani , benjamin.walker@intel.com, David Christensen , Hemant Agrawal , Ian Stokes , Jerin Jacob , John McNamara , Ju-Hyoung Lee , Luca Boccassi , Pei Zhang , qian.q.xu@intel.com, Raslan Darawsheh , yuan.peng@intel.com, zhaoyan.chen@intel.com References: <20220401102216.642587-1-ktraynor@redhat.com> <42961b14-a277-8cfb-13c2-66b904015df2@redhat.com> From: Kevin Traynor Subject: Re: 21.11.1 patches review and test In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ktraynor@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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 14/04/2022 06:52, Christian Ehrhardt wrote: > On Wed, Apr 13, 2022 at 12:06 PM Kevin Traynor wrote: >> >> Hi Christian/Thomas/Ori, >> >> On 11/04/2022 07:58, Christian Ehrhardt wrote: >>> On Fri, Apr 1, 2022 at 12:22 PM Kevin Traynor wrote: >>>> Hi all, >>>> >>>> Here is a list of patches targeted for stable release 21.11.1. >>> Hi Kevin, >>> this breaks on me at build time due to symbol changes. >>> It is a wild mix of Base->Internal/Experimental, a few new symbols, >>> and even just removed ones (in gpu which is experimental, but still >>> would that need a minor soname bump?). >>> They might be intentional, but it felt too much to me without at least >>> discussing it. >>> Could you have a look if you think that they are all intentional, save >>> and correct for an LTS release? >>> >> >> Thanks for the report. I've looked through these. Comments below. >> >>> dpkg-gensymbols: warning: some new symbols appeared in the symbols >>> file: see diff output below >>> dpkg-gensymbols: warning: debian/librte-common-cnxk22/DEBIAN/symbols >>> doesn't match completely debian/librte-common-cnxk22.symbols >>> --- debian/librte-common-cnxk22.symbols >>> (librte-common-cnxk22_21.11.1~rc1-0ubuntu1~jammyppa2_amd64) >>> +++ dpkg-gensymbolsUuRb8d 2022-04-11 06:46:22.276766813 +0000 >>> @@ -197,6 +197,7 @@ >>> roc_nix_ptp_clock_read@INTERNAL 21.08 >>> roc_nix_ptp_info_cb_register@INTERNAL 21.08 >>> roc_nix_ptp_info_cb_unregister@INTERNAL 21.08 >>> + roc_nix_ptp_is_enable@INTERNAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> roc_nix_ptp_rx_ena_dis@INTERNAL 21.08 >>> roc_nix_ptp_sync_time_adjust@INTERNAL 21.08 >>> roc_nix_ptp_tx_ena_dis@INTERNAL 21.08 >>> >> >> This is a new internal from: >> commit 28acfe550dcb12b0908df754a4307b8b4d1fe5b0 >> Author: Harman Kalra >> Date: Thu Mar 3 12:30:42 2022 +0530 >> >> common/cnxk: fix mbuf data offset for VF >> >> [ upstream commit 8f98e3ecc55e02234f8bec7213b0b6a69c086949 ] >> >> Looks ok to me. >> >>> dpkg-gensymbols: warning: some new symbols appeared in the symbols >>> file: see diff output below >>> dpkg-gensymbols: warning: debian/librte-ethdev22/DEBIAN/symbols >>> doesn't match completely debian/librte-ethdev22.symbols >>> --- debian/librte-ethdev22.symbols >>> (librte-ethdev22_21.11.1~rc1-0ubuntu1~jammyppa2_amd64) >>> +++ dpkg-gensymbolskEnokB 2022-04-11 06:46:25.252795157 +0000 >>> @@ -37,6 +37,7 @@ >>> rte_eth_dev_flow_ctrl_get@DPDK_22 21.11 >>> rte_eth_dev_flow_ctrl_set@DPDK_22 21.11 >>> rte_eth_dev_fw_version_get@DPDK_22 21.11 >>> + rte_eth_dev_get_by_name@INTERNAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> rte_eth_dev_get_dcb_info@DPDK_22 21.11 >>> rte_eth_dev_get_eeprom@DPDK_22 21.11 >>> rte_eth_dev_get_eeprom_length@DPDK_22 21.11 >>> >> >> This is a new internal >> Added by: >> commit 721d0bbd1668d2a4b617a4a4de0b93dd60283d58 >> Author: Kumara Parameshwaran >> Date: Mon Jan 31 20:02:33 2022 +0530 >> >> ethdev: add internal function to device struct from name >> >> [ upstream commit 961fb4029b8c52c0e8230d34993c354d70e10e14 ] >> >> Used by: >> commit ac180f4d2662503ecd18a2e94689a229104d3d61 >> Author: Kumara Parameshwaran >> Date: Mon Jan 31 20:02:34 2022 +0530 >> >> net/tap: fix to populate FDs in secondary process >> >> [ upstream commit c36ce7099c2187926cd62cff7ebd479823554929 ] >> >> Looks ok to me. >> >>> dpkg-gensymbols: warning: some new symbols appeared in the symbols >>> file: see diff output below >>> dpkg-gensymbols: error: some symbols or patterns disappeared in the >>> symbols file: see diff output below >>> dpkg-gensymbols: warning: debian/librte-regexdev22/DEBIAN/symbols >>> doesn't match completely debian/librte-regexdev22.symbols >>> --- debian/librte-regexdev22.symbols >>> (librte-regexdev22_21.11.1~rc1-0ubuntu1~jammyppa2_amd64) >>> +++ dpkg-gensymbolsPD0Ygo 2022-04-11 06:46:33.368872490 +0000 >>> @@ -1,6 +1,8 @@ >>> librte_regexdev.so.22 librte-regexdev22 #MINVER# >>> EXPERIMENTAL@EXPERIMENTAL 20.11 >>> - rte_regex_devices@Base 20.11 >>> + INTERNAL@INTERNAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> + rte_regex_devices@EXPERIMENTAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> rte_regexdev_attr_get@EXPERIMENTAL 20.11 >>> rte_regexdev_attr_set@EXPERIMENTAL 20.11 >>> rte_regexdev_close@EXPERIMENTAL 20.11 >>> @@ -8,12 +10,16 @@ >>> rte_regexdev_count@EXPERIMENTAL 20.11 >>> rte_regexdev_dump@EXPERIMENTAL 20.11 >>> rte_regexdev_get_dev_id@EXPERIMENTAL 20.11 >>> - rte_regexdev_get_device_by_name@Base 20.11 >>> + rte_regexdev_get_device_by_name@INTERNAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> rte_regexdev_info_get@EXPERIMENTAL 20.11 >>> - rte_regexdev_is_valid_dev@Base 20.11 >>> - rte_regexdev_logtype@Base 20.11 >>> + rte_regexdev_is_valid_dev@EXPERIMENTAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> + rte_regexdev_logtype@EXPERIMENTAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> rte_regexdev_queue_pair_setup@EXPERIMENTAL 20.11 >>> - rte_regexdev_register@Base 20.11 >>> + rte_regexdev_register@INTERNAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> rte_regexdev_rule_db_compile_activate@EXPERIMENTAL 20.11 >>> rte_regexdev_rule_db_export@EXPERIMENTAL 20.11 >>> rte_regexdev_rule_db_import@EXPERIMENTAL 20.11 >>> @@ -21,7 +27,8 @@ >>> rte_regexdev_selftest@EXPERIMENTAL 20.11 >>> rte_regexdev_start@EXPERIMENTAL 20.11 >>> rte_regexdev_stop@EXPERIMENTAL 20.11 >>> - rte_regexdev_unregister@Base 20.11 >>> + rte_regexdev_unregister@INTERNAL 21.11.1~rc1-0ubuntu1~jammyppa2 >>> rte_regexdev_xstats_by_name_get@EXPERIMENTAL 20.11 >>> rte_regexdev_xstats_get@EXPERIMENTAL 20.11 >>> rte_regexdev_xstats_names_get@EXPERIMENTAL 20.11 >>> >> >> +cc Ori, regex maintainer. >> >> Regex library is an experimental API so everything should have been >> experimental or internal. This is fixing that issue. >> >> It is fixed with >> commit 6e7f8939f23c2c8ed80602bc0d62990eebe52013 >> Author: Thomas Monjalon >> Date: Sun Mar 6 10:20:22 2022 +0100 >> >> regexdev: fix section attribute of symbols >> >> [ upstream commit 89e290eb8ca99af9f7cfc3292d93860f8e672708 ] >> >> and >> >> commit 026470bafaa02cba0d46ed7b7e835262399a009a >> Author: Thomas Monjalon >> Date: Sun Mar 6 10:20:23 2022 +0100 >> >> build: hide local symbols in shared libraries >> >> [ upstream commit b403498e14229ee903c8fff9baefcb72894062f3 ] >> >> >> The fact that they are redesignated to correctly be >> experimental/internal seems ok to me. >> >>> dpkg-gensymbols: error: some symbols or patterns disappeared in the >>> symbols file: see diff output below >>> dpkg-gensymbols: warning: debian/librte-gpudev22/DEBIAN/symbols >>> doesn't match completely debian/librte-gpudev22.symbols >>> --- debian/librte-gpudev22.symbols >>> (librte-gpudev22_21.11.1~rc1-0ubuntu1~jammyppa2_amd64) >>> +++ dpkg-gensymbols4qkXdt 2022-04-11 06:46:34.552883776 +0000 >>> @@ -1,7 +1,7 @@ >>> librte_gpudev.so.22 librte-gpudev22 #MINVER# >>> EXPERIMENTAL@EXPERIMENTAL 21.11 >>> INTERNAL@INTERNAL 21.11 >>> - gpu_logtype@Base 21.11 >>> rte_gpu_add_child@EXPERIMENTAL 21.11 >>> rte_gpu_allocate@INTERNAL 21.11 >>> rte_gpu_attach@INTERNAL 21.11 >>> >> >> The missing wildcard meant this symbol escaped in 21.11. >> >> It is fixed by: >> commit 026470bafaa02cba0d46ed7b7e835262399a009a >> Author: Thomas Monjalon >> Date: Sun Mar 6 10:20:23 2022 +0100 >> >> build: hide local symbols in shared libraries >> >> [ upstream commit b403498e14229ee903c8fff9baefcb72894062f3 ] >> >> In this case the symbol is not redesignated but removed, but it doesn't >> look to have any use to a user, so I think it can be safe to remove. > > I'm 100% with all others, thanks for having a look. > On this one I can easily follow the argument of the fix for the newest release. > But for stable we can never really know if there are users. > In theory for anything that shipped in a Distribution someone might > have coded and linked something against it - we would not know. > The meant to be "stable" update will then break them the hard way. > > In this case gladly the function wasn't anything that one would > consider useful for use from outside, so I think it is ok. > > But still I wanted to make the point that in general a symbol: > 1. once released might be used and we can not never be sure if no one uses them The same argument can also be made for 22.03/22.07 which is ABI compatible with 22.11. I accept there will be exception cases where it makes sense to change in main because it is enabling some future work, which are not similarly valid for stable. So the bar should be a bit higher in stable. > 2. even being EXPERIMENTAL, touching them too much in stable updates > means not-stable. Should we at least try to minimize the impact to > stable releases? > APIs marked experimental are not part of the ABI version, but I agree it is a good goal to minimize changes for these in stable where possible. > For now I'm adapting my checkers and will continue testing ... > Thanks for raising Christian. (P.S. on PTO, so won't be able to continue discussion for now) >> There are updates to the libabigail.ignore for regex and gpu_dev to >> ignore ABI changes for these fixes. >> >> -- >> >> I'm ok with changes above for 21.11.1, what do others think? >> >> Kevin. >> >>> >>> Full log: >>> https://launchpadlibrarian.net/596047842/buildlog_ubuntu-jammy-amd64.dpdk_21.11.1~rc1-0ubuntu1~jammyppa2_BUILDING.txt.gz >>> >> > >