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 7DFBFA04AE; Tue, 8 Feb 2022 13:59:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 364ED410FD; Tue, 8 Feb 2022 13:59:20 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id AF1FF410FC for ; Tue, 8 Feb 2022 13:59:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644325158; x=1675861158; h=message-id:date:to:cc:references:from:subject: in-reply-to:content-transfer-encoding:mime-version; bh=xOUXRNYcY09dRyi6/awX4dMpc7ySQI1w+jsVsRIoaxk=; b=IcXnQeLWth53a6AqtxGBP5/WW84JMBnfBBX/5130QDdHKsS4BA6WGZCd HfqRwJoPh9C3FbSvw6xCdF/uribel9ag+UrQIKQ2kd/Sd1235aZCUbake kNYDrI4MY9+J78eSDMccLImDDyo1DpCoGcOIStSo4aSvYCyXyjwd6HdQH E6k/WV6x7S8v3JYEsoSAMT5LKbYW4kunV2IInLl7qjw2a2uKGc0dktiE2 I9QtpCyn1k2fuzyp3HVZ6dv85F1CGX/K7KO3yQxsO13iUb7JszRNcX7+V jPO8Vk69LAAOdJ/ZXtniXZpA6c3veN9rKUU3JPfRTc2/mrqT64L1I77Ss g==; X-IronPort-AV: E=McAfee;i="6200,9189,10251"; a="248889265" X-IronPort-AV: E=Sophos;i="5.88,352,1635231600"; d="scan'208";a="248889265" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2022 04:59:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,352,1635231600"; d="scan'208";a="525536810" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga007.jf.intel.com with ESMTP; 08 Feb 2022 04:59:17 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 8 Feb 2022 04:59:16 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 8 Feb 2022 04:59:16 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Tue, 8 Feb 2022 04:59:16 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.174) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Tue, 8 Feb 2022 04:59:16 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lrAlwGwhz6Qz7UpenxCmdvf32a0X7hyGJhi2hM6blkcfB26GOsmxo6FDTLzcG0EuyaQG3aqdSPuC0ACBgfYUX39g2DzaoH1JzChzY+yYHfgQ7fbiU7XpnxcQeTUBXJhbelUQXA7oGFvYP+6Xqmfj5JJXtlRUQN/J0wMIKqjvimcCGhSiJ5DTMhy07j8eOvUO4sZpUvVuxnHGVmsTUtx199JoaWilsGr0LwihT89ZlBMvPx1g4H/q9IQpqYlCODUKar0/cj6T6p5MGmGeuTIl1/KRlwtQ1Y5TUOxuQD98nbjHmNTTFnq2DFWgwl2STGqM5uJKm6hfIERskKRwVObLQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NSKd3uD/A5k2r1AB5tcS8ew6Vc3nzaXJRVmvJYTNjOc=; b=LWZGhU+RdxK58Y7GbSv+SBpoI+qd56xEtqsDUvi1OZ/XaAQk8tmlSh7qlGvzIcORw1ucCT3MGQkkN3V+e4nUtjX6aDcq1/SuQTbMxoJ6a3T/PnFNeZDQg+e9R6eWJ0ztd1mq5r3L1kcP14qOq6OO32xSn2eMicAFhEUm9BQub5WQe94oEFm9NzMl4wp9pL8DDMkC3PW2NIPPHUlwdSUH+JEw7M7FBd09KMk8YYJONfUKokI9nTJTVASQ2P8VbaTguRk7dmOaA73oo6wXdmne6mkDIFBtxv7LrW4InJj6zIjvCJK20onPY2fNlcvvRUvTO3I9HUolrlEINQS4FVLbrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by BN0PR11MB5728.namprd11.prod.outlook.com (2603:10b6:408:165::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Tue, 8 Feb 2022 12:59:14 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::5046:8550:928d:850e]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::5046:8550:928d:850e%7]) with mapi id 15.20.4951.019; Tue, 8 Feb 2022 12:59:14 +0000 Message-ID: <9900011f-89a2-dc69-523f-2259cb4a7085@intel.com> Date: Tue, 8 Feb 2022 12:59:08 +0000 Content-Language: en-US To: "Min Hu (Connor)" , =?UTF-8?Q?Morten_Br=c3=b8rup?= , CC: Ray Kinsella , Ajit Khaparde , Thomas Monjalon , Andrew Rybchenko References: <20220111115437.32855-1-humin29@huawei.com> <20220207014719.16611-1-humin29@huawei.com> <8b129213-8d64-0b9e-8bb3-5faa8bfdd2d4@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D86E79@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D86E7A@smartserver.smartshare.dk> <8a8fbfae-7547-67e0-08ff-4faa7e9d8a50@huawei.com> <0c63906d-3979-f8ce-4c32-2ddfcceaf3b6@intel.com> <8ca8568e-b88c-e758-fc0b-d11b7cb997af@huawei.com> From: Ferruh Yigit Subject: Re: [PATCH] ethdev: introduce ethdev dump API X-User: ferruhy In-Reply-To: <8ca8568e-b88c-e758-fc0b-d11b7cb997af@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0087.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::27) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f335dec8-925a-4d3b-e29b-08d9eb02cef0 X-MS-TrafficTypeDiagnostic: BN0PR11MB5728:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OdkzkQ7WORawEOu6pVPfhMICXUb+4zgg68FM75XRODrwjLFiM7yY563MrD4/XHMOEN4YbnITUv+uluXIKqBeWidGGBR7Fw0WGhtbt4ef8YSzRDBdmazIRn0p4EYj9zit0kgM8KKBZT3wx5evqXIIdqPiFN0igHkhwHoeKF3wrVK8efUfWrhJCnVuKfE+xLDRUWF0d4L/+Cg1dYXWNXK5GTzte9HV5+sDWE6QDVnaZpSTy8K555h5NRO42mtPjYEVJTFqnhmt7x6042eimvN7OP/ntBoMJMr+4v35tHVFm+OCEPwfG/XGY9WtqRjBm5RWYdo5K23lFncIF5cILeMiN2wy08EIzpeBVpI4m6xI3YcgMsFeDpLdD4xzlRSMr5gT4XVjArRWR5OYkfPAFuwwGtc4eh3cTzTa0Pv80tKK6qYFIC4nnHMMuMyAiNyN7JEhKA6ZYYwsOR7evaDkDF70JIGPRF0OizgzAU4PY7LRm+Jud3BLKjTzzQ6aE0N15gbPJfIjFE3UtLxFLKsERXJlabfhOGYXGIr56El9ccPk5fg7WzerZJY8YrCqJ+wY9raP/+U0MvGWPPyZIaFRoumUMds/Uy/wzYfWlp58sd+hixEXpAQ6JeWMG2vR5gkvO5IugJoC7BURuInvZHmTkf2zY2f8B6Uhh/Fz0BBWZJxxA5P9aojRh7Iz2TsW4I7S8IKiqLvcrnRiDioMqdMrCQalMw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(83380400001)(44832011)(110136005)(36756003)(316002)(54906003)(6666004)(86362001)(6506007)(6512007)(53546011)(66574015)(55236004)(4326008)(66946007)(6486002)(31686004)(82960400001)(8936002)(66476007)(66556008)(8676002)(5660300002)(31696002)(186003)(38100700002)(26005)(508600001)(2906002)(2616005)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MkE2cFVxenhzeGk2VnBUcitJNlpqSzhQRldKb3Q0T2xhZExoeWtNeHpFaFFV?= =?utf-8?B?NnN4N2JNQURQc1ZWbmRGd1dueGZtdXBvOEVWSld0aUh4ZlNib005cmpMTEZk?= =?utf-8?B?akUxL0tpYS9Ud1ZRK0ZBVllhdVVIVTM4VE1GcHljd0pNbCtzWENtcjJKZWY4?= =?utf-8?B?Q0lnbzRsTzFPb2x4YUpQM2hwVzNwZ29JamJBOXZObEZyOXNEUmdPQkVPS0xa?= =?utf-8?B?UUI5VFhKdHZ3S3VSUWhaUFhuL1ZvdXJCZ2VtUC8xYmN6Ui90dnltdU1GQWpO?= =?utf-8?B?b3hJdElCL0JZdnl3d3h3NytuVytKY1RKRGIzeklhb01lRWN0U3hla0MxcDV1?= =?utf-8?B?dk16bE9YeDVBeVlLTW9Sb2RCeWVoRk0wN3RWRVpoaHBVZUxOamJ6aDN6UUdP?= =?utf-8?B?Nmp2ZXpldWhyVWhrY2owWk5MYmRJTUN0Z3MrUll3VFF6VDllTVFMSkRWTlky?= =?utf-8?B?K1U5dWRsUGtCRVE3cndsMDFGU3VDQ1J6dFNPOEhpeVJ1QVRqNWs4eHQ3MEVs?= =?utf-8?B?NEhucytmK0dlSFA0Ni8yM0xBOU9qS0dOWUpjcjRoZEZZYlAvZkZ3TGFvZU9G?= =?utf-8?B?OE50K281TDROeWJLSi83U1E3NnhMdlkwUURrejdSaDVBajFiUGpncC9ET1VQ?= =?utf-8?B?eGppU0xTZnJNRGhQYUw1YytjbnpON0pMWkdzcEZTaGlDOThjTUd0bTNUVGxU?= =?utf-8?B?NlZOb1lSb2svSkhHTXBINmd1SG5GMEJVekxRZ3BLZjZpSks2aXZjNVQvN1ha?= =?utf-8?B?LzcvN0RjMlc2Z0lFY3d0emw5eEVna1g2cmd2RVdYM3FibDNKeXFzeC95Zlht?= =?utf-8?B?R2txNkJteENFSFc1Wno0bFc3bXkrdFRnRy9yWGp3d0s1c1JITUZOL0VML0xa?= =?utf-8?B?RjdWcHRhL2RaR3pUYWZwSUluOHBraUI2MUl6ekhOWmhRL1lLcmZFK2w1R21V?= =?utf-8?B?T1hzbGx3UHoxQWhCeW5qQWozNEkxcjlxeGRpN1gwOUw5Q1pzdTBjd3FwT3Fw?= =?utf-8?B?Z1EvdDYvaXlkZ0lHYnh0dnVVU08xVlA4aUF2ZkFBbFBvRnU4VGdFNzJqSU1R?= =?utf-8?B?OTBWQm0vcXhoU0grMERiM1hvVkNOMW42VmhZQm1ERi9IczkxWFphbll2QThF?= =?utf-8?B?WmhjeUdzeHF3dzZmK2tUOEVocC9IZjhXOVAwT0dYZVc0bWJBSitpaVllRTFt?= =?utf-8?B?NVh3bTJkbFRVSkFtdkx1c3Q5MXI3eDMzVGwxOHc2VXhUVjBtZnBWNWJTSWs0?= =?utf-8?B?RTJmU29Lb0tVT3dHNVh3NE1RbFdvelZBNXh1U3daZjFodVBEZHIreDJwUlhQ?= =?utf-8?B?OXh0V2tOTllTbEJtVzlVNFFBV2tMelFmQTY4SGFRMGtlZzNJNkVaRUNhVVdM?= =?utf-8?B?enRnU1dHdmZTQ1hYUERFN2h6SkhUVVV4b09vWVhrVVRmWlZ5cXk5MnA0RUNJ?= =?utf-8?B?WlFrbkZLS0ZpU0YyL0NLL3o1c1dMZVk2L2tpQVBBQVB6TUJpVzU2Vnp1cEN1?= =?utf-8?B?OUh3TjBMV1JFNnJqbEtNbGNzMGpQV1pHMlphcC9wUmdmcTFURXRESFk5NVE2?= =?utf-8?B?T3dxYWpqVzhOVmFxcFRjWWhiZjVtMzhtM0ZzaHRvcXZNSUxxZjNZd0pkY2du?= =?utf-8?B?L2tydjRIdjlyOUczYjFwSXQrZVB2ZWY5NkVHcVdmdm1lZDl0bXdLTHRwTk9R?= =?utf-8?B?M1FmQStLVytMdXY1RzgwTHJEWldWQkF3Z1JhYmsrKy82RGY4WVMyVFQ2M1NI?= =?utf-8?B?WW9UL1luRHdXcEExMlNkZ1ZCRHJWdys0ek1xbVNVUXcxdHFCNjRoN0VPWVlW?= =?utf-8?B?OTQ2TVpySjFsMmc2aFR3T05Ga3VzV3ZhTmVHU1F6YlFyek5ZOTZUNlB3NFNK?= =?utf-8?B?Rm92M2FVR1drSUFZOFAvRHRScUlOaWF6Qk54bU16VGJaYVlNYUxjTmRpVk1F?= =?utf-8?B?Z0dMdmF2S2dWWW45dXpzYUovRE1rUEpXL0JqRUl4MGp5MGNjUXh0TThMd0o0?= =?utf-8?B?ZGRmWWxwRVRsSlBCUFhBRGEvRHZBMG5IWVlERTRXSU1nU0FYK1BkSjc2RVZH?= =?utf-8?B?TlFybERXQlIveUxOUSsxcXZkWkoyYm5YL1dRRDhHNmFOY1V2L1hUL1BsSU5C?= =?utf-8?B?Zno3cXVNS0FjczNiWFp2THJONTErTmhJQVRPYnhVcW9Wc2JVTVAyL2N4NDlH?= =?utf-8?Q?1oisRQzy4hR0T5KIEhSnHw0=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: f335dec8-925a-4d3b-e29b-08d9eb02cef0 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2022 12:59:14.6802 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8YHrVsNhhsMbC8Dctsy+FfbtlTQ5UhmT8XzF/7fINFQj4GfNHyoCV6cYjbqhfPoWg7RhitJ/0ISQihUEHyMOhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR11MB5728 X-OriginatorOrg: intel.com 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 2/8/2022 11:14 AM, Min Hu (Connor) wrote: > Hi, Ferruh, > > 在 2022/2/8 18:21, Ferruh Yigit 写道: >> On 2/8/2022 12:39 AM, Min Hu (Connor) wrote: >>> Hi, Ferruh, >>> >>> 在 2022/2/7 23:35, Ferruh Yigit 写道: >>>> On 2/7/2022 12:56 PM, Morten Brørup wrote: >>>>>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] >>>>>> Sent: Monday, 7 February 2022 13.36 >>>>>> >>>>>> On 2/7/2022 12:18 PM, Morten Brørup wrote: >>>>>>>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] >>>>>>>> Sent: Monday, 7 February 2022 12.46 >>>>>>>> >>>>>>>> On 2/7/2022 1:47 AM, Min Hu (Connor) wrote: >>>>>>>>> Added the ethdev dump API which provides functions for query >>>>>> private >>>>>>>> info >>>>>>>> >>>>>>>> Isn't API and function are same thing in this contexts? >>>>>>>> >>>>>>>>> from device. There exists many private properties in different PMD >>>>>>>> drivers, >>>>>>>>> such as adapter state, Rx/Tx func algorithm in hns3 PMD. The >>>>>>>> information of >>>>>>>>> these properties is important for debug. As the information is >>>>>>>> private, >>>>>>>>> the new API is introduced.> >>>>>>>> >>>>>>>> In the patch title 'ethdev' is duplicated, can you fix it? >>>>>>>> >>>>>>>> >>>>>>>>> Signed-off-by: Min Hu (Connor) >>>>>>>>> Acked-by: Morten Brørup >>>>>>>>> Acked-by: Ray Kinsella >>>>>>>>> Acked-by: Ajit Khaparde >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>>>> @@ -990,6 +990,20 @@ typedef int >>>>>> (*eth_representor_info_get_t)(struct >>>>>>>> rte_eth_dev *dev, >>>>>>>>>     typedef int (*eth_rx_metadata_negotiate_t)(struct rte_eth_dev >>>>>> *dev, >>>>>>>>>                            uint64_t *features); >>>>>>>>> >>>>>>>>> +/** >>>>>>>>> + * @internal >>>>>>>>> + * Dump ethdev private info to a file. >>>>>>>>> + * >>>>>>>> >>>>>>>> It doesn't dump the 'ethdev' private info, it dumps the private info >>>>>>>> from device. >>>>>>> >>>>>>> It seems perfectly clear to me. How would you prefer it phrased >>>>>> instead? >>>>>>> >>>>>> >>>>>> What described in the document is more accurate, >>>>>> "query private info from device". >>>>>> >>>>>> What we are dumping here is not ethdev private info, it is device >>>>>> private info, >>> >>> what is the difference between ethdev and device? >> >> It is not very clear, but for me 'ethdev' is refers to device abstract >> layer (ethdev library) specific private data > Could you give an example for 'ethdev'specific private data ? > I think 'struct rte_eth_dev' content can be a sample. But I hear you, diff is not clear, it is subtle as Morten said, when doc and commit log refers it as "private info from device", I think we can use the same in the API documentation as well. > and device refers to ethdev >> device (PMD) private data. ethdev is common for all drivers. > OK, we could treat it as convention in future. >> >>>>>> and we really don't know what that data may be in the ethdev layer. >>>>>> >>>>>> Also there is a chance that 'ethdev private info' can be confused with >>>>>> 'ethdev->data->dev_private' >>> what I want to dump is exactly the 'ethdev->data->dev_private'. >>> 'ethdev private info' means 'ethdev->data->dev_private'. >>> why confused? >> >> What I understand was this API can return any device private information, >> it is not limited to 'ethdev->data->dev_private', (although most of the > I think this API is limited to 'ethdev->data->dev_private'. >> data >> is represented in this struct), like if you want to dump queue state, >> this is out of 'ethdev->data->dev_private'. > Queue state can be dumped using API 'rte_eth_tx_queue_info_get'. > Yes it can be. But as far as I can see there is nothing prevents the dump() API to provide the same, it is up to PMD. If the intention is to limit what can be dump to 'ethdev->data->dev_private', it is not clear from API documentation/implementation. >> >>>>> >>>>> OK. Now I got your point! The difference is very subtle. >>>>> >>>>>> >>>>>>> [...] >>>>>>> >>>>>>>> >>>>>>>>> + */ >>>>>>>>> +__rte_experimental >>>>>>>>> +int rte_eth_dev_priv_dump(FILE *file, uint16_t port_id); >>>>>>>>> + >>>>>>>> >>>>>>>> What do you think to have the 'port_id' as first argument to be >>>>>>>> consistent >>>>>>>> with the other APIs? >>>>>>> >>>>>>> The _dump APIs in other libraries have the file pointer as the first >>>>>> parameter, so let's follow that convention here too. No need to move >>>>>> the port_id parameter here. >>>>>>> >>>>>> >>>>>> Yes, for most of the _dump() APIs, file pointer seems is the first >>>>>> argument, >>>>>> bu they are from various libraries. >>>>>> >>>>>> Within the ethdev APIs, I think it makes sense that all APIs start with >>>>>> 'port_id' parameter for consistency, like done in: >>>>>> rte_flow_dev_dump(uint16_t port_id, ...) >>>>>> >>>>>>> Only rte_dma_dump() has the file pointer last, and I didn't catch it >>>>>> when the function was defined. >>>>>>> >>>>> >>>>> OK. Then I agree with you about following the convention like rte_flow_dev_dump() with the port_id first. >>>>> >>>>> I even think Connor got it right the first time, and I proposed following the other convention. >>>>> >>>> >>>> Ahh, may bad I missed that, sorry for not commenting on time. >>>> >>>> >>>>> It's not easy when there are two opposite conventions. :-) >>>>> >>>> >>>> Yep, that is the main issue. >>>> >>>> . >> >> .