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 2AD8143266; Thu, 2 Nov 2023 00:40:10 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 007B342D7B; Thu, 2 Nov 2023 00:39:56 +0100 (CET) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2048.outbound.protection.outlook.com [40.107.93.48]) by mails.dpdk.org (Postfix) with ESMTP id B90AE427E7 for ; Thu, 2 Nov 2023 00:39:54 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VGXkQUr8q/N1PwqCgrWxWwVFmedxrRlkG1wtRiCUTBe3v2lLfQU1h/YeAdWoLQq7sxnu3BvmbZknjS7hXwLqLbwNacOvCruAAjLOjb50hSUXnIATKRLPCWRrDuAm9vNrBfDN1krwYBitDSUU5q0PiRHMQb8GXkh+5lWoEKAsK7F+O7JDK0xciJOPCNISVp8WlbrHl3orNjezPyTRbxFxb8+7jmPfIjOVC6Gio9eKris9D2zo7Qv7ff0NFY62OoBw/5EIIZlkleFz2EYgiELKz/jQjrcZWFy7qItpk11+3C1eaQD6ldOLwShbyDxT08ZBN94azLd/6U7rmAJw/qQB7g== 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=Qy/9GS04PeB1GPYjO5YYZ4Fsygll2zhJ+RjxD/6Ux4E=; b=MGt68S9R4H2yI9C39dCmxwxca/1xMVRDp0OGIk54VLPsgnyyuVNJ+3hQEE+nOJU6OUcK1K6/FHsGaZ1Ywu6738rJRFwAxtLfvv6qL2H9gcTNZaJ09KEdgwCnZ+kWnfjd537L3+71BI/WdQUW97asVfBLfbxXstgS+knt3sPWJXGVSf3P0odLoVF5AV7E9Rl4wgQzhgYnohlU3uvk0UenPC/Ds2s9AIg941R7TtNmr1ahmTK5KxpDcdyzM+UvgYeJ+BATxTB88r1iFs4TnlH7+qc4dTw7dVvPftMz2/CcFcpPqHzQ9OaaJyjPZB3/o51G4pWTDFNbaVhY6LbDgCixBg== 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=Qy/9GS04PeB1GPYjO5YYZ4Fsygll2zhJ+RjxD/6Ux4E=; b=yJIER+4F0rOfeM0jI1zaGUshb2JG5CWzQMpqSy2hNbE3P1edQSdmdqO7Wf8UFptQrOmOZkRG6+NbJgagQpfgIpAjrklKkVcWhHgC6R6KbhDNRE811hB2ObKQvS5AKFf0VVW/baNfb+h3HE41t5X/zsD1dpONvMGrWhG4n+KEy48= 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 DS0PR12MB7629.namprd12.prod.outlook.com (2603:10b6:8:13e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.29; Wed, 1 Nov 2023 23:39:52 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::2569:edb2:670f:816f]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::2569:edb2:670f:816f%6]) with mapi id 15.20.6954.019; Wed, 1 Nov 2023 23:39:52 +0000 Message-ID: <3a11b30d-346f-446f-903a-5a56cbae3853@amd.com> Date: Wed, 1 Nov 2023 23:39:47 +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, Gagandeep Singh , Hemant Agrawal , Qiming Yang , Qi Zhang , Simei Su , Junfeng Guo Cc: thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, liuyonglong@huawei.com 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> 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR0P281CA0205.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:ad::19) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|DS0PR12MB7629:EE_ X-MS-Office365-Filtering-Correlation-Id: db2efdc3-6da2-42d0-a788-08dbdb33d889 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MIrUY5O2XbaCkuAprrz0J1/Vb4tqRyxaVlFPLKZA39Qskekjnjd2Y9cdfLqvhkxO+XtYkVYtc4kDcKmL7IosYjkIibzixRn8PRcZLhiYNVEFDmzRXGf+z8feDurM2T4dIawOgSD9VOg0Aou1SB6YRMDrXayAG4xE+L3+P6JhHOdn6zp6st08GdI2ZE42FGO6BUnw3GVGfNCnEh4+j9uqwZy7xEZdsommLcKuwBHbeS+NFna35uXEloDPSeo4KJ0dCk4K2AjlvX6n81cB8nhKQnUJN1l+qptw+VTW2TGTl6hD1O0bwSjFrZBdWi/t2zXpFGkL2arN8kaMT/f5ITK21f+TK9fKKzzmlbUJQVdkDSm6+4Lj1mBC8LePTuR70+vUE0NYHotjK1LjsarLNq/ftXk4VBnADFhpD8+RL8bTnCDaOCmnykK8gipenYKgoxLLJAfSvJV7yOkn1WsYZV0myO0zmWoIwf81CQNIgc/xkS7zXEwETV0Hyh5TiMqAeWlM2hlQuLSNkPOeyc5MSp+a1MTUR9WN2hbMbwc/BLmzkbwgZz32/n453bvFYuVDRnc1ZBm0PRzI4JY4Q0FbBtBmvJX0hyN8Nvh/JF2gL+vgLf8plDchNlTr2+GM1XNlOQS960yC/wYPizi01udEO3mqEg== 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)(376002)(396003)(346002)(366004)(39860400002)(136003)(230922051799003)(64100799003)(1800799009)(186009)(451199024)(7416002)(83380400001)(8676002)(2906002)(44832011)(2616005)(316002)(53546011)(8936002)(5660300002)(41300700001)(38100700002)(26005)(4326008)(478600001)(66476007)(110136005)(31696002)(66556008)(6512007)(6486002)(6506007)(66946007)(6666004)(86362001)(36756003)(31686004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bnF3MEZ3N1o3Y2c4bERzU2F3RnlpZzhtNVpDaVJkWG40OGR1UlpHOWF1bkFO?= =?utf-8?B?U1pIdUVGUVJ4Y0NLT1RZQ3RnaFlGVTVKY0pWcVNJMk1lM0pDcHVXRVNrU0JF?= =?utf-8?B?aEpXZ1BDVjJSWksyVDQ2ZFdZQW91TjBUKzQ0azlBN2dueVB4eTdTL3A1Y3Uw?= =?utf-8?B?bjhEK3BoMGVpNXh3TWhDYlo4amxNemhiWVpPcHpJMXZUSXBaZUxia1NTdlpw?= =?utf-8?B?SUdqcktubEFwRWFldWlaQWwzM0VIZ0lBR0VQOElwSUJZeGpld3Faa0k5cThw?= =?utf-8?B?NVMzZzU1MjVmT3NWYkhGWDRyQ3BBa3lrVjVmU3FNamR5ZFdBMjFJdFgwTk1P?= =?utf-8?B?bklLN1ZnUTIxSmxJa0ZONEduSDZpUC9PNXU0TXcxYzBJYUxGSnJybUtibWFY?= =?utf-8?B?Q0piTkswWldlcXJNcHdoalhlTGhTdlBJczNuZFZMTHJ4bHZUbStjNEJsS3R6?= =?utf-8?B?bEVXSytYTmVwampGazVzUXU0c2RCam8veGFBVzNXalJhbWlCVDdRQnNPaW1u?= =?utf-8?B?dFpRZ2g1T1ZLN2pocTA5djJMM2R4MVU5b09UOEh6THlGcmtiOUdHNThocUgw?= =?utf-8?B?WXA3UVE4TG93cGx2LzNSNUJsM2doTjFMeWVFbmNVUmVkN0F5WlhuMm1DOTRv?= =?utf-8?B?eGpseW9wTkFtN01QdEdpZWFWZXhrMTd1UnNjVU83OFcwMWZkamw5NDBoYjNu?= =?utf-8?B?QzZpMEhQN2pRTGdhTmpWY1BDQnZmSGdWbFFwUHI1amtzTFl6dkZUQTZkNTBa?= =?utf-8?B?SUhNc3djUUs1ZWVJelVVZXkxSlFiWFU2cmIrNVNUYXlpT2VHR21RU0o3SS92?= =?utf-8?B?ZUd6c0Q0c29WR295T2lnVTFUWGhLcEd6bWZaZlQyWHROWGhsN3Z5bTdFUG51?= =?utf-8?B?T2VmcTV2Z1h1cGdyOGlFV1JJTFN6LzF2R01ONkJoeEtTWVd4eDB3SU1KeFRQ?= =?utf-8?B?dmpKRVJEMjIzSUptaGNNWUZETDdSWVQzVnJOQmt0N1p1em5GcUJYUk1DOTh6?= =?utf-8?B?bUpCdXBKdno0bmNHUlNrdmw2aDZXZmNGQXFnTDlWd3ZzWHhUSFFjaEd6MHRR?= =?utf-8?B?ZWJPRHR4NTIzK20xeXF3V1lqSHA5dFQyKy9FSUwxRy9Hc2MwQ2h6NlNhSnYv?= =?utf-8?B?VzFJMXBlNXBjQ2lCRDV2TFRZdEtNeWNDN3kyUzgzeU8vWGJsSHRINFZNVGpH?= =?utf-8?B?ZUp3V3JGai85a24xa0ttOXNEeCtmSm5hZjR4RElmQ1JQaERjS3ZqZGpFOGxL?= =?utf-8?B?ZGJVR2NBeEw0Z1JJTVI5MDRJZFg1eVFWUG5ENVgwYmpzS2NGc0FZMGxVNW1M?= =?utf-8?B?ZVM4b3B0NXZsRmxPS1diOU51ZVB4d2c2NUx0Kzd4Q2tsZ0ROSVUzcXl4RmNm?= =?utf-8?B?K2VybTZ3SlJxT3JyaFlWUGU2dGxOdEtaMWFiSkpHbFdIMnBnbEwrZnlYMHRT?= =?utf-8?B?NndYblZ1d05lM0lzVjdVY240M2JHYTMvQUpLNmtyQjRmaVlVREJLSVozMnd2?= =?utf-8?B?NjZJWTZiRlpIcWZHY2l1ZnBLaytvR2ZyQzRMY2lSbTNBT1Z6eXBIRHRDWkFn?= =?utf-8?B?VEtlUFhFSzg5VkNDOWdJQ1Q3ZFlnQ1k0YUYxYmJtRmNPSGJFRmpRZU9kb1hs?= =?utf-8?B?WDZwVnpTenpoYytWaEZYSGpQaXRMb1lGZnVMNzU1SlVOZmlKc2R2SXRSdnd4?= =?utf-8?B?a1BNc291akg4TjI2ZERJYmdLZFp2MzVQTzBFQkF1c1MyTyt6bmYzNXNIZHF4?= =?utf-8?B?Y2JtblRSQlV1VkJ5clloK0lpYkM3dHRwM3Rmb0w0ell6dHNEZS93cnlKWkpT?= =?utf-8?B?THdVN0h5eGRaNXYrN1RIaGhMeUdhRnR1K0RPcnB3eTFqNFJOMUp2Y3lKaW1y?= =?utf-8?B?bkpSNGJPbUZNTE9JMWhOcUFNYnJXcFJ0L0dHL3BtZlRvYTk3RU5wTnZDVzEr?= =?utf-8?B?Y0ZRTlhMQXJKTGxScWJ0S05Nb2U1NGRKNTJ4eEtJMDNuOS9SNUVIdXlRZnRY?= =?utf-8?B?Z3AzcGIxRWhUT0s0TXRWaGNIUjhmb0lSVFJVdFVGaDJUdjhLd2JyVnZ2WHM5?= =?utf-8?B?dHlNSWQxR3k4UERaVm1YWEg2V3I4cURZNkZHeVpmMnl2Z01lWUh3K1UwV21Z?= =?utf-8?Q?+m6Xld/ATiYEYABatURuoP5wA?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: db2efdc3-6da2-42d0-a788-08dbdb33d889 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2023 23:39:52.7855 (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: nlfMHr1yssdgXKUUj8LdIMyIldSzHkUfon05MjkbBZiztyyKskl0tHa5xW4GIN1J X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7629 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 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. 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? We have 'rte_eth_timesync_*()' APIs, my understanding is application parses the PTP protocol, and it may use this information to configure NIC to synchronize its clock, but it may also use PTP provided information to sync any other clock. Is this understanding correct? > If TIMESTAMP offload is not for PTP, I don't know what the point of this > offload independent existence is. > TIMESTAMP offload request device to add timestamp to mbuf in ingress, and use mbuf timestamp to schedule packet for egress. Technically this time-stamping can be done by driver, but if offload set, HW timestamp is used for it. Rx timestamp can be used for various reasons, like debugging and performance/latency analyses, etc.. >> >>>> PTP is a protocol for time sync. >>>> Rx TIMESTAMP offload is to ask HW to add timestamp to mbuf. >>> Yes. >>> But a lot of PMDs actually depand on HW to report Rx timestamp releated >>> information >>> because of reading Rx timestamp of PTP SYNC packet in read_rx_timestamp >>> API. >>> >> HW support may be required for PTP but this doesn't mean timestamp >> offload is used. > understand. >> >>>>> And then about four years later, ptpclient enable Rx timestamp offload >>>>> because some PMDs require this offload to enable. Please see >>>>> commit 7a04a4f67dca ("examples/ptpclient: enable Rx timestamp >>>>> offload"). >>>>> >>>> dpaa2 seems using TIMESTAMP offload and PTP together, hence they >>>> updated >>>> ptpclient sample to set TIMESTAMP offload. >>> There are many PMDs doing like this, such as ice, igc, cnxk, dpaa2, hns3 >>> and so on. >>> >> Can you please point the ice & igc code, cc'ing their maintainers, we >> can look together? > > *-->igc code:* > > Having following codes in igc_recv_scattered_pkts(): > >         if (rxq->offloads & RTE_ETH_RX_OFFLOAD_TIMESTAMP) { >             uint32_t *ts = rte_pktmbuf_mtod_offset(first_seg, >                     uint32_t *, -IGC_TS_HDR_LEN); >             rxq->rx_timestamp = (uint64_t)ts[3] * NSEC_PER_SEC + >                     ts[2]; >             rxm->timesync = rxq->queue_id; >         } > Note：this rxm->timesync will be used in timesync_read_rx_timestamp() > Above code requires TIMESTAMP offload to set timesync, but this shouldn't be a requirement. Usage seems mixed. > *-->ice code:* > > #ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC >         if (ice_timestamp_dynflag > 0 && >             (rxq->offloads & RTE_ETH_RX_OFFLOAD_TIMESTAMP)) { >             rxq->time_high = >                rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high); >             if (unlikely(is_tsinit)) { >                 ts_ns = ice_tstamp_convert_32b_64b(hw, ad, 1, > rxq->time_high); >                 rxq->hw_time_low = (uint32_t)ts_ns; >                 rxq->hw_time_high = (uint32_t)(ts_ns >> 32); >                 is_tsinit = false; >             } else { >                 if (rxq->time_high < rxq->hw_time_low) >                     rxq->hw_time_high += 1; >                 ts_ns = (uint64_t)rxq->hw_time_high << 32 | rxq->time_high; >                 rxq->hw_time_low = rxq->time_high; >             } >             rxq->hw_time_update = rte_get_timer_cycles() / >                          (rte_get_timer_hz() / 1000); >             *RTE_MBUF_DYNFIELD(rxm, >                        (ice_timestamp_dynfield_offset), >                        rte_mbuf_timestamp_t *) = ts_ns; >             pkt_flags |= ice_timestamp_dynflag; >         } > >         if (ad->ptp_ena && ((rxm->packet_type & RTE_PTYPE_L2_MASK) == >             RTE_PTYPE_L2_ETHER_TIMESYNC)) { >             rxq->time_high = >                rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high); >             rxm->timesync = rxq->queue_id; >             pkt_flags |= RTE_MBUF_F_RX_IEEE1588_PTP; >         } > #endif > > Note: rxm->timesync and rxq->time_high will be used in > timesync_read_rx_timestamp() > This usage looks good, if TIMESTAMP offload enabled mbuf dynamic field and flag set accordingly. And if PTP enabled, and PTP packet type detected relevant flag set in mbuf, and timesyc value set to use later for 'timesync_read_rx_timestamp()'. Although above usage looks correct, I can see in 'ice_timesync_enable()' TIMESTAMP offload is used requirement to enable timesync. TIMESTAMP offload seems used as way to enable HW timestamp, as Hemant mentioned what is done is dpaa2. >> >> >>>> We need to clarify dpaa2 usage. >>>> >>>>> By all the records, this is more like a process of perfecting PTP >>>>> feature. >>>>> Not all network adaptors support PTP feature. So adding the check for >>>>> PTP >>>>> capability in ethdev layer is necessary. >>>>> >>>> Nope, as PTP (IEEE1588/802.1AS) implemented as dev_ops, and ops already >>>> checked, so no additional check is needed. >>> But only having dev_ops about PTP doesn't satisfy the use of this >>> feature. >>> For example, >>> there are serveal network ports belonged to a driver on one OS, and only >>> one port support PTP function. >>> So driver needs one *PTP* offload. >>>> We just need to clarify TIMESTAMP offload and PTP usage and find out >>>> what is causing confusion. >>> Yes it is a little bit confusion. >>> There are two kinds of implementation: >>> A： ixgbe and txgbe (it seems that their HW is similar) don't need >>> TIMESTAMP offload，and only use dev_ops to finish PTP feature. >>> B:  saving "Rx timestamp related information" from Rx description when >>> receive PTP SYNC packet and >>>      report it in read_rx_timestamp API. >>> For case B, most of driver use TIMESTAMP offload to decide if driver >>> save "Rx timestamp related information. >>> What do you think about this, Ferruh? >>>> I would be great if you can help on clarification, and update >>>> documentation or API comments, or what ever required, for this. >>> ok >>>>> --- >>>>> v3: >>>>>    - patch [2/3] for hns3 has been applied and so remove it. >>>>>    - ops pointer check is closer to usage. >>>>> >>>>> Huisong Li (2): >>>>>     examples/ptpclient: add the check for PTP capability >>>>>     ethdev: add the check for the valitity of timestamp offload >>>>> >>>>>    examples/ptpclient/ptpclient.c |  5 +++ >>>>>    lib/ethdev/rte_ethdev.c        | 57 >>>>> +++++++++++++++++++++++++++++++++- >>>>>    2 files changed, 61 insertions(+), 1 deletion(-) >>>>> >>>> . >> .