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 61A5E439FF; Mon, 29 Jan 2024 16:00:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0973A402B1; Mon, 29 Jan 2024 16:00:33 +0100 (CET) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2059.outbound.protection.outlook.com [40.107.92.59]) by mails.dpdk.org (Postfix) with ESMTP id 55DAB4029A for ; Mon, 29 Jan 2024 16:00:31 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AdKpy8pa/emw283kvFSkT6+hy5vU6BNzE4jNZR0m6KTwMB/ZtrA7fc1XrJrsvAxZvO0PMGIF+U8lo5p7xc3WF3kc5PvLQ/gVFwHvkamOl7jxRdVTbBN3+StjsmosUie25NQmBKiSBO6LsY9MAH0CPCd5pBlkV6W9ISwi0T+aZpIVrcsOo6OniwP1fwu3tMIHUW09Z+dFRgvkILU9Q5qa8ZwtDQigmLQw/PTz653gwaaPgTHMkzreKypo4NSz0V1nkRcvWWhPGQoMd61Kv7YtwWZ5IcM+XI78s5xw+rlayfzD5X5Ye9DY2XhWDiQ9zmYv1KIVAEOmVXJswJJUGbpwTA== 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=hg5jdWfGT/vCBvlQPgaMaDilmaCtxID2OaookkI3lWc=; b=W5tTQARedavcMVjGLnGHnVAdXOZyxvt10bZdsP0Gz/mMpZfBnB62SwA3Y+pIVx+XGw2lXOWtHmP9HaAz4JrtA1JcwKfrGtonwKIITiXDfue0yR7yRf+GlBptZxlsNaCyUVJC0m+KBkWor9wflafyHJ4Cvrl4ruchBv5yhiPsJevALOWjYv5MNeGH293GZJHJRgjq1V4E2ZWEJ3TupuQcE/ag7QeUkewyFSQM08WapvsmIBTX0aPPl2W5n4VUfUnmtnlyNdNvlr7Bt774SNGsm6e9cCME2JVsMmBeBMP87YFKK8HqzKoVUCRIxs75BOw4iLJtyYR1DcRlRTBLtcqPTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hg5jdWfGT/vCBvlQPgaMaDilmaCtxID2OaookkI3lWc=; b=DBXVoB6nyQ/GeunwhC5NvioENjgJhICRafry1mYKdJlBJbtaFO8KER9NvoI76+heFPuBWpjKkLuv5iXlccJ0pMM9mw4R8fD3NkUMy9wJBa1iKoAetxo4jHUbaLebmGT2F1m6/DDG6VSy8H3Of9JY/TtVkmHDaASF2muf0AqPZBs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by BY5PR12MB4920.namprd12.prod.outlook.com (2603:10b6:a03:1d3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.34; Mon, 29 Jan 2024 15:00:26 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::815a:45e6:cf5e:479f]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::815a:45e6:cf5e:479f%4]) with mapi id 15.20.7228.029; Mon, 29 Jan 2024 15:00:26 +0000 Message-ID: Date: Mon, 29 Jan 2024 15:00:20 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/2] ethdev: add the check for PTP capability Content-Language: en-US To: "lihuisong (C)" , dev@dpdk.org Cc: thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, liuyonglong@huawei.com, Gagandeep Singh , Hemant Agrawal , Simei Su , Qi Zhang , Qiming Yang , Junfeng Guo References: <20220628133959.21381-1-liudongdong3@huawei.com> <20230817084226.55327-1-lihuisong@huawei.com> <1834a6a9-ef92-4a67-a987-490151cf5380@amd.com> <242e8583-969e-d8ca-2dd4-80e8cf73a662@huawei.com> <0d7f429c-8862-4f16-b7e5-46d69581f54f@amd.com> <3a11b30d-346f-446f-903a-5a56cbae3853@amd.com> <665b0b6e-1ad9-a692-39cb-9e45e6b78b08@huawei.com> <7ecc6f3b-78f8-6421-307d-2c6c484c6109@huawei.com> <5afa7ecf-254f-424b-9a58-1548e8ef270d@amd.com> <50f72945-4f45-4f0f-9c52-a62522e27c26@amd.com> <993a921d-3191-1b9a-847e-83acde073a9d@huawei.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@amd.com; keydata= xsFNBGJDD3EBEAC/M7Tk/DfQSmP1K96vyzdhfSBzlCaGtcxNXorq4fALruqVsD3oi0yfyEz9 4YN8x7py0o9EL8ZdpOX0skc0AMCDAaw033uWhCn0GLMeGRKUbfOAPvL6ecSDvGD7CJIO9j0J eZUvasBgPdM/435PEr9DmC6Ggzdzt8IuG4PoLi5jpFSfcqxZFCCxLUDEo/w0nuguk2FTuYJg B2zEZ4JTBZrw7hIHiFh8D8hr6YA6a5uTofq1tr+l048lbtdFUl8TR0aIExVzE4Z8qKZlcE+9 RQaewjK5Al1jLE4sHdmd3GN+IvgDF3D/fLsi25SKJDeGSdeHkOmaX0qGeM4WKIfU6iARRCiQ N3AmBIxZ/A7UXBKLaOyZ+/i3sE6Wb53nrO4i8+0K2Qwyh6LjTeiJAIjYKN43ppxz3DaI+QwQ vI+uyHr4Gg0Da9EPPz/YyKauSeOZCfCB5gIfICO0j6x0SCl8uQ2nLpjxcZkf0gjcwUzP3h+S 3x6NfDji9YEij0zczW/dcSpGgZ6vsFpPrtnP9ZXy6J53yp0kJtOJoOlkEFFdU2yCZnCDseum CoudmGLZVvS0/DzHDJejq+3kK3FDGktZBOxZIIpal+nFqS7lVgOZc4+huVv3jyhzoAUOEyXA XK5j6o7g8STUY+z33QNnHpdLvecMwuzmvqy0jR54yAbZ64mB9QARAQABzSNGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBhbWQuY29tPsLBlwQTAQgAQQIbAwULCQgHAgYVCgkICwIEFgID AQIeAQIXgAIZARYhBEm7aYjps5XGsPHCElRTPtCKKm/6BQJkdyEEBQkE3meNAAoJEFRTPtCK Km/6UdcP/0/kEp49aIUhkRnQfmKmNVpcBEs4NqceNCWTQlaXdEwL1lxf1L49dsF5Jz1yvWi3 tMtq0Mk1o68mQ7q8iZAzIeLxGQAlievMNE0BzLWPFmuX+ac98ITBqKdnUAn6ig5ezR+jxrAU 58utUszDl16eMabtCu76sINL5izB8zCWcDEUB4UqM8iBSQZ7/a7TSBVS0jVBldAORg1qfFIs cGMPQn/skhy3QqbK3u3Rhc44zRxvzrQJmhY6T1rpeniHSyGOeIYqjpbpnMU5n1VWzQ4NXvAD VDkZ4NDw6CpvF4S2h2Ds7w7GKvT6RRTddrl672IaLcaWRiqBNCPm+eKh4q5/XkOXTgUqYBVg Ors8uS9EbQC/SAcp9VHF9fB+3nadxZm4CLPe5ZDJnSmgu/ea7xjWQYR8ouo2THxqNZtkercc GOxGFxIaLcJIR/XChh9d0LKgc1FfVARTMW8UrPgINVEmVSFmAVSgVfsWIV+NSpG9/e90E4SV gMLPABn1YpJ8ca/IwqovctqDDXfxZOvCPOVWTzQe/ut767W+ctGR1kRkxWcz470SycOcY+PW VRPJd91Af0GdLFkwzZgNzkd6Gyc9XXcv4lwwqBLhWrBhqPYB0aZXIG1E/cVTiRp4dWpFHAFD DcuLldjIw93lCDsIeEDM9rBizGVMWEoeFmqSe7pzGTPXzsFNBGJDD3EBEAC8fBFQHej8qgIG CBzoIEd1cZgPIARlIhRudODXoNDbwA+zJMKtOVwol3Hh1qJ2/yZP11nZsqrP4fyUvMxrwhDe WBWFVDbWHLnqXMnKuUU1vQMujbzgq/4Rb9wSMW5vBL6YxhZng+h71JgS/9nVtzyaTtsOTrJi 6nzFSDx6Wbza2jYvL9rlK0yxJcMEiKwZQ/if4KcOesD0rtxomU/iSEv6DATcJbGXP6T93nPl 90XksijRKAmOwvdu3A8IIlxiSSVRP0lxiHOeR35y6PjHY2usfEDZZOVOfDfhlCVAIBZUZALv VmFOVSTYXeKgYa6Ooaf72+cHM3SgJIbYnevJfFv8YQW0MEAJ/IXE7B1Lk+pHNxwU3VBCrKnA fd/PTvviesuYRkrRD6qqZnINeu3b2DouVGGt2fVcGA38BujCd3p8i7azoGc7A6cgF7z9ETnr ANrbg1/dJyDmkDxOxVrVquTBbxJbDy2HaIe9wyJTEK2Sznpy62DaHVY+gfDQzexBXM10geHC IIUhEnOUYVaq65X3ZDjyAQnNDBQ4uMqSHZk8DpJ22X+T+IMzWzWl+VyU4UZXjkLKPvlqPjJk 1RbKScek5L2GhxHQbPaD76Hx4Jiel0vm2G+4wei8Ay1+0YRFkhySxogU/uQVXHTv63KzQMak oIfnN/V2R0ucarsvMBW+gwARAQABwsF8BBgBCAAmAhsMFiEESbtpiOmzlcaw8cISVFM+0Ioq b/oFAmR3IPsFCQTeZ44ACgkQVFM+0Ioqb/qINhAAtcor9bevHy22HvJvXX17IOpPSklZJAeQ Az43ZEo5kRlJ8mElc2g3RzYCvL/V3fSiIATxIsLq/MDtYhO8AAvklxND/u2zeBd7BkRZTZZX W1V1cM3oTvfx3LOhDu4f2ExQzCGdkzbXTRswSJIe1W0qwsDp+YPekbrsKp1maZArGeu+6FuW honeosIrWS98QJmscEhP8ooyJkLDCCOgEk+mJ/JBjzcJGuYn6+Iy/ApMw/vqiLGL1UWekcTA g18mREHqIR+A3ZvypIufSFB52oIs1zD/uh/MgmL62bY/Cw6M2SxiVxLRsav9TNkF6ZaNQCgn GqifliCEMvEuLZRBOZSYH2A/PfwjYW0Ss0Gyfywmb2IA990gcQsXxuCLG7pAbWaeYazoYYEQ NYmWatZNMAs68ERI2zvrVxdJ/fBWAllIEd0uQ4P05GtAHPdTIDQYp545+TPV7oyF0LfXcsQs SFVZE6igdvkjfYmh+QOrHGZvpWXLTmffVf/AQ81wspzbfxJ7sYM4P8Mg5kKOsaoUdyA/2qVe cMh1CLUHXF1GlofpGbe1lj4KUJVse5g3qwV7i9VrseA8c4VIZewdIjkzAhmmbxl+8rM/LKBH dZUMTzME5PFCXJIZ83qkZQ795MTe2YScp9dIV7fsS5tpDwIs7BZNVM1l3NAdK+DLHqNxKuyO 8Zk= In-Reply-To: <993a921d-3191-1b9a-847e-83acde073a9d@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR0P281CA0045.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:48::14) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|BY5PR12MB4920:EE_ X-MS-Office365-Filtering-Correlation-Id: dd85ff3f-0797-44f3-1dcf-08dc20db06d3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: grqq9bzgq44Bf+mN+9cAXF3ty5LEQRhq3FAQvoSU3vK3YIj043cqArwVDaaN7u5QWCC3k7HaZiUMjCed2GCs1lx9lr9Exu3rJ6KrI4Pj0HvOUPHHyx+lsOUl+ZSttmNIajQpd9J2eVDHLgfjk+w97/q75Quhm4rCvt016yh8grY+3psJ5RAGE7IBpXW1yL+DMJfKRZWT+Z1N0VywvCO4BPIfBBU02jHoFv5XNvR6+13/Fh6I3z3EO1RdW/6nDxB0PS2GC/QDd4Ub6iSM4l0/x9CRvzQhkXRxru59HUGLVTDhSykzs3f7v0nhVI7ijLhU87RQlOoGDasqcP2kajTESZOeisOgWXNTHiIPwMq4hfaEP5XAYIhwxFkRwWXiNgF8/xCi+QVn2XanfWsdg45I8w3siH+FT7d3oe31ngMJmrXZdw7RHinRixnqP6ungHv4eAilZNTwwyuzRy1NagLpJRggpmKEJhiM936zxFyvNt6pC4D9WSaoHxDxu/PzCXgnjr8BLN9W2LvfxtBQpzuaK2uqoj+R/suhb0lMg/KV07NpcHIWW4aAW37TAIxJ6pc+u9TrbLK7bU4/NzmD5LewsncSJT8hjvUm0Yblz0VeOToTEs+3FmpUQF9nAT6sM4uG X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(396003)(136003)(376002)(366004)(346002)(39850400004)(230922051799003)(1800799012)(186009)(64100799003)(451199024)(316002)(31696002)(54906003)(83380400001)(66556008)(66946007)(66476007)(86362001)(6486002)(478600001)(53546011)(6506007)(6666004)(38100700002)(31686004)(26005)(2616005)(6512007)(8676002)(8936002)(4326008)(44832011)(7416002)(2906002)(5660300002)(66899024)(41300700001)(36756003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V043R3FaMTk0SGY4ajNJaE50a2xPYWlkRHo2T0sxM29wVkpHVkNCVTRRTEJE?= =?utf-8?B?T1NlZ3VqV2E0RmY0dU0vb2srYjVmcUZCbEZBVmJFNEZrclBCbnNya095eFhV?= =?utf-8?B?QjBRd25uNzU1ZlE3T1NydzNnWnpiVXM5MWxBTEVIU0J4TUt3SGk0UitTTkV3?= =?utf-8?B?bG05eGN3QnFvMFRkMUlwVlJrNDhCSTMxbHZ0d1ZjMnY4eHA3NThFTWR4VUhP?= =?utf-8?B?N09PNVpwQlpBNkFZTk50ZndzZndCM1RpTUwwVjZ4ck5WdHJBSTFSeVJYb09a?= =?utf-8?B?dlhRdk5SOW5rejZNWFk3NFFaMjYxTU9TcW5TT0tFLzkvWGdxazdFWWkzQndY?= =?utf-8?B?UUdUWC9aRlBpbURJcWpQQWhoZlBDR3BoaXg4blYxSFY1ODAyTDdqVUhISDdB?= =?utf-8?B?dDVpYmhRSjRCYU9ZWWd6M1FOTnJ1SnE5NnJVZmZlYWV6c2ljaGF0bFB4aG12?= =?utf-8?B?alNFTE9QN0ZVT0drb0VtYjY4N2R3aWpWUjIvUmE4QVhvZGlNdDdRelpjc2VC?= =?utf-8?B?T1JoeVdoRUxleGd3UHJhbjh3QVNsYXdaK3NoZUJOTmwvMGxUMWpQbm1PdXo3?= =?utf-8?B?bDVITjhRUTUwSzMvdkxyQ1BibXFBaDFKb0ZrOC9GVVd1TVlyT09MMmtOZUpS?= =?utf-8?B?clI2aFlZNU9TZ0YvRXN6ZkRIK2RMUEh3aTdUclZmVzlLOHVXQWJJT0lRMUdT?= =?utf-8?B?cmhzUGxSY3c1aHljSnRpcEVJaGQ0Z2lyZEw4UXZHb3pEZmtmZW4zOGtlYVhq?= =?utf-8?B?TDJiRmN0QTZvNmZsTEN0NXRQQm9yaFZ5TGFLdE9vdGtnZzEybUJkM2E2UUdr?= =?utf-8?B?bGlLQytsVlZLNkExdFlPSzRxZFlyejNqejNsNWFTcU85RExpZHZiaU1uUTF5?= =?utf-8?B?K2Y2SEd0K3lMVWkwTzZDc3FTaTVEK1djTEV2L1pJSFdLeWJCUERnRjdUU3lB?= =?utf-8?B?R0dXRUVObHBSTThGVGdrZSt4cWpLTVdCdE8yVGZhRGFqbitwNW1md3YvbEdX?= =?utf-8?B?L0VkZFNPek0ydXp0dElCVitqZVlmZS9iRzFTK0h3bU1CTkZLUEFsMksxQUVS?= =?utf-8?B?MjZ0WTlKd3hWR1BqbGpmc3R3MGNXbzdpN2ZHL1dBMkJVZmcyWWQ5OWJtS2ZB?= =?utf-8?B?MnFRZEt6Wmxwc2l0L3JFZHNkekFWeDk3L3Fmd0grWkJFY0tKWkpNNzVzMnJp?= =?utf-8?B?djJxMGtPQ1BSaFVwM3ZzYU1jdmVXT1luNFJLdW5aSWVrY2xTeGlhTFpjdVhv?= =?utf-8?B?bkl0Uy9rd1U1M0lqNUlzVnVHZkl3SVFwZE1PWEFoSGZ5ckhFc3N2U0lNRnlH?= =?utf-8?B?Wm5meWRkRFUveXdsMFRKRzRiay8zN1ozZEpYU0ZNeWdSUHpIaXhWQW5ra24x?= =?utf-8?B?b09pR3RjQmRibWxhYUJCOVc3VFhJNkdZckVWTGFuVlYzR3BwS3hEdVdRSUFx?= =?utf-8?B?R0xWakhLVFU5Q0NFSGpZMzZJSzViaWphak92QXpQSWxDRjJzR3hGdi9SK3o1?= =?utf-8?B?TkJYL0lKN25BRDQrU2RNcXcvRHRhckhFYXYySVY5UmJ1TmdaL1dSakdOc2Rt?= =?utf-8?B?MytIK0JtclNydUljQnRJUjc2UzdkT09oMko4ZHBybHgzUU9BN1d4Y3cvRnFU?= =?utf-8?B?d1lyQU0vWktMaGp4bXZNTENQeWYrZllmR1d5dkZlTWNNUXdobUEwdGZNS0Rr?= =?utf-8?B?T1JDSklXMzU1VytOZUw3MVVDZndJVHVDSko2cXdQVXJTMS9QdWRNV0hsaFNQ?= =?utf-8?B?aVFGYzBGWXgyVGRpZGZyMThpVjdwYnlraVF1cmdIQ1R3MXNEYzZvOVcwaXhB?= =?utf-8?B?b05YMWFTRTdSUGZIVHNXWDNzSDZjME1yNDBaOFBMR251THR2ZU1SRUNnYThk?= =?utf-8?B?K1BOWnhuMlhMR2Z1U2s1Rm1QOUxuREhZQk5EVWhobDdidWNCYzJ1emh4L0di?= =?utf-8?B?OGcvUFJ3L2ttcEJlUXowMGhtSWRKL3dIWjlaTGt1OVNlWkozVFNlWHpVNFFV?= =?utf-8?B?SDJLRmNlOGFpeDJDaHF4WVNsRW1aMHpVQWFPMWsrU1VUZUVUd3VzU05vamw4?= =?utf-8?B?YkFxRHhHM0diNTAvVEJwblMrRVU3bm1OSnJUdEFtMmFiQmhzbTMwZUJEU0hD?= =?utf-8?Q?rABQ=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd85ff3f-0797-44f3-1dcf-08dc20db06d3 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2024 15:00:26.6544 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5JOCDtC5O2TaVRd0A+N7kR5DNoJ/g2DVDm5P1Kg6APWmknlAN2b6BpkwRKjuF3nn X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4920 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 1/29/2024 1:58 PM, lihuisong (C) wrote: > > 在 2024/1/29 19:16, Ferruh Yigit 写道: >> On 1/27/2024 1:52 AM, lihuisong (C) wrote: >>> 在 2024/1/27 0:54, Ferruh Yigit 写道: >>>> On 1/11/2024 6:25 AM, lihuisong (C) wrote: >>>>> Hi Ferruh, >>>>> >>>>> 在 2023/11/23 19:56, lihuisong (C) 写道: >>>>>> 在 2023/11/2 7:39, Ferruh Yigit 写道: >>>>>>> timesync_read_rx_timestamp >>>>>>> On 9/21/2023 12:59 PM, lihuisong (C) wrote: >>>>>>>> add ice & igc maintainers >>>>>>>> >>>>>>>> 在 2023/9/21 19:06, Ferruh Yigit 写道: >>>>>>>>> On 9/21/2023 11:02 AM, lihuisong (C) wrote: >>>>>>>>>> Hi Ferruh, >>>>>>>>>> >>>>>>>>>> Sorry for my delay reply because of taking a look at all PMDs >>>>>>>>>> implementation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 在 2023/9/16 1:46, Ferruh Yigit 写道: >>>>>>>>>>> On 8/17/2023 9:42 AM, Huisong Li wrote: >>>>>>>>>>>>      From the first version of ptpclient, it seems that this >>>>>>>>>>>> example >>>>>>>>>>>> assume that >>>>>>>>>>>> the PMDs support the PTP feature and enable PTP by default. >>>>>>>>>>>> Please see >>>>>>>>>>>> commit ab129e9065a5 ("examples/ptpclient: add minimal PTP >>>>>>>>>>>> client") >>>>>>>>>>>> which are introduced in 2015. >>>>>>>>>>>> >>>>>>>>>>>> And two years later, Rx HW timestamp offload was introduced to >>>>>>>>>>>> enable or >>>>>>>>>>>> disable PTP feature in HW via rte_eth_rxmode. Please see >>>>>>>>>>>> commit 42ffc45aa340 ("ethdev: add Rx HW timestamp capability"). >>>>>>>>>>>> >>>>>>>>>>> Hi Huisong, >>>>>>>>>>> >>>>>>>>>>> As far as I know this offload is not for PTP. >>>>>>>>>>> PTP and TIMESTAMP are different. >>>>>>>>>> If TIMESTAMP offload cannot stand for PTP, we may need to add >>>>>>>>>> one new >>>>>>>>>> offlaod for PTP. >>>>>>>>>> >>>>>>>>> Can you please detail what is "PTP offload"? >>>>>>>>> >>>>>>>> It indicates whether the device supports PTP or enable  PTP >>>>>>>> feature. >>>>>>>> >>>>>>> We have 'rte_eth_timesync_enable()' and 'rte_eth_timesync_disable()' >>>>>>> APIs to control PTP support. >>>>>> No, this is just to control it. >>>>>> we still need to like a device capablity to report application if the >>>>>> port support to call this API, right? >>>>>>> But when mention from "offload", it is something device itself does. >>>>>>> >>>>>>> PTP is a protocol (IEEE 1588), and used to synchronize clocks. >>>>>>> What I get is protocol can be parsed by networking stack and it >>>>>>> can be >>>>>>> used by application to synchronize clock. >>>>>>> >>>>>>> When you are refer to "PTP offload", does it mean device (NIC) >>>>>>> understands the protocol and parse it to synchronize device clock >>>>>>> with >>>>>>> other devices? >>>>>> Good point. PTP offload is unreasonable. >>>>>> But the capablity is required indeed. >>>>>> What do you think of introducing a RTE_ETH_DEV_PTP in >>>>>> dev->data->dev_flags for PTP feature? >>>>> Can you take a look at this discussion line again? >>>>> >>>>> Let's introduce a  RTE_ETH_DEV_PTP in dev->data->dev_flags to >>>>> reveal if >>>>> the device support PTP feature. >>>>> >>> Hi Ferruh, >>> >>> Thanks for taking your time to reply. >>> >>>> Hi Huisong, >>>> >>>> First let me try to summarize the discussion since it has been some >>>> time. >>>> >>>> HW timer block can be used for Rx timestamp offload >>>> (RTE_ETH_RX_OFFLOAD_TIMESTAMP) and/or PTP support, but they are two >>>> different things. >>>> >>>> This patch uses 'RTE_ETH_RX_OFFLOAD_TIMESTAMP' capability for PTP >>>> support, which is wrong. >>>> >>> correct. >>>> After we agreed on above, your next question is to use 'dev_flag' to >>>> report PTP capability. >>>> >>>> First, can you please describe what is the motivation to learn if HW >>>> supports PTP or now, what is the benefit of knowing this. >>> There are a couple of device which have the same driver on a platform or >>> OS. >>> But just allow one device to support or be responsible for PTP feature. >>> The firmware will report a capability to tell the device if it is >>> support PTP. >>> But, currently, driver doesn't know how to report user which device >>> support PTP feature. >>> >> Driver can hold a private data that records if PTP supported by the >> device or not, and according this value PTP dev_ops can return error or >> success. >> >> This may not be ideal but it lets user to know about the support status, >> can this work? > I don't think it is user friendly. > Users know which port supports the PTP feature only when the API fails > to be invoked, right? > In addition, this is a common issue for all supported PTP device. So It > is better to do this check in PMD. >> >> >>> In addition, many drivers use RTE_LIBRTE_IEEE1588 to control PTP code >>> flow. >>> Whether the device supports PTP is irrelevant to this macro. >>> >> Yes, I guess because both features use same HW, there is confusion there. >> >>>> If we agree that there is a need to know the PTP capability, >>>> question is >>>> where to report this capability. >>>> >>>> Suggested 'dev_flags' is used for various things, some are internal >>>> flags and some are status, I don't think overloading this variable is >>>> not good idea. >>> Yes, we need to consider  carefully. >>>> Other option is an update 'rte_eth_dev_info_get()' for it but it has >>>> the >>>> same problem, this function is already overloaded with many different >>>> things. >>>> >>>> We can have an API just to get PTP capability, but this will require a >>>> new dev_ops, this can be an option but my concern is having a >>>> capability >>>> dev_ops for each feature create a mess in dev_ops. >>>> >>>> Perhaps we can have single get_capability() API, and it gets >>>> features as >>>> flags to return if that feature is supported or not, but this >>>> requires a >>>> wider discussion. >>>> >>>> Instead can we deduce the capability from PTP relevant dev_ops, if they >>>> are implemented we can say it is supported? This doesn't require new >>>> support. >>> Thank you mentioning so many ways. >>> For the end of advice, I don't think it is appropriate. >>> Because we have to modify dynamically the pointer address of all PTP >>> APIs in dev_ops on the above case. >>> >> I was thinking for the case application distinguish if PTP related >> dev_ops set or not, but after your explanation I can see this won't help >> for your case. >> Because in your case PTP dev_ops implemented but some devices support it >> and some don't, and you are looking for a way to distinguish it. > Yes >> >>> How about we use rte_eth_dev_info.dev_capa to report PTP offload? >>> This is specifically used to report "Non-offload capabilities" according >>> to its document. >>> >> As mentioned above 'rte_eth_dev_info' is overloaded, I am for being more >> cautious to expand it more. >> Also I think it is a wider discussion if we want a capability reporting >> in ethdev and where it should be. > How about we send a RFC patch which use rte_eth_dev_info.dev_capa to > report PTP offload and start to disscuss this issue? > Ack. Lets start discussion on top of a patch. Thanks. > And add Thomas's patch [1] and this patch. > > [1]https://patchwork.dpdk.org/project/dpdk/patch/20230203132810.14187-1-thomas@monjalon.net/ > >> >> .