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 7D8EA43C54; Tue, 5 Mar 2024 08:45:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 618444026B; Tue, 5 Mar 2024 08:45:07 +0100 (CET) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by mails.dpdk.org (Postfix) with ESMTP id 6DC1D4026B for ; Tue, 5 Mar 2024 08:45:05 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4TpndL0gRLz1vvtM; Tue, 5 Mar 2024 15:44:22 +0800 (CST) Received: from kwepemd100004.china.huawei.com (unknown [7.221.188.31]) by mail.maildlp.com (Postfix) with ESMTPS id C814A1A016C; Tue, 5 Mar 2024 15:45:01 +0800 (CST) Received: from [10.67.121.175] (10.67.121.175) by kwepemd100004.china.huawei.com (7.221.188.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Tue, 5 Mar 2024 15:45:00 +0800 Message-ID: Date: Tue, 5 Mar 2024 15:45:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4 1/7] ethdev: support report register names and filter To: Thomas Monjalon , CC: , , , , References: <20231214015650.3738578-1-haijie1@huawei.com> <20240226030739.3775514-1-haijie1@huawei.com> <20240226030739.3775514-2-haijie1@huawei.com> <6000520.alqRGMn8q6@thomas> From: Jie Hai In-Reply-To: <6000520.alqRGMn8q6@thomas> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.175] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemd100004.china.huawei.com (7.221.188.31) 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 Hi, Thomas , Thanks for your review. On 2024/2/29 17:52, Thomas Monjalon wrote: > 26/02/2024 04:07, Jie Hai: >> This patch adds "filter" and "names" fields to "rte_dev_reg_info" >> structure. Names of registers in data fields can be reported and >> the registers can be filtered by their names. >> >> The new API rte_eth_dev_get_reg_info_ext() is added to support >> reporting names and filtering by names. And the original API >> rte_eth_dev_get_reg_info() does not use the name and filter fields. >> A local variable is used in rte_eth_dev_get_reg_info for >> compatibility. If the drivers does not report the names, set them >> to "offset_XXX". > > Isn't it possible to implement filtering in the original function? > What would it break? > If we implement filtering in the original function rte_eth_dev_get_reg_info(), ABI would be broken and old app cannot run with linked to the new library. Existing binary applications will have backwards compatibility with our current patch. Although the ABI is modified, the old app can still behave normally in the case of dynamic linking with the new library. And the new APP using rte_eth_dev_get_reg_info() works well with the old library. >> @@ -20,6 +25,12 @@ struct rte_dev_reg_info { >> uint32_t length; /**< Number of registers to fetch */ >> uint32_t width; /**< Size of device register */ >> uint32_t version; /**< Device version */ >> + /** >> + * Filter for target subset of registers. >> + * This field could affects register selection for data/length/names. >> + */ >> + const char *filter; >> + struct rte_eth_reg_name *names; /**< Registers name saver */ >> }; > > I suppose this is an ABI break? > Confirmed: http://mails.dpdk.org/archives/test-report/2024-February/587314.html > I think it is ABI change but not ABI break. please see above. > > . Best regards, Jie Hai