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 3BF14A00C3; Wed, 21 Sep 2022 15:58:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2ED794067C; Wed, 21 Sep 2022 15:58:11 +0200 (CEST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2043.outbound.protection.outlook.com [40.107.22.43]) by mails.dpdk.org (Postfix) with ESMTP id B29034014F for ; Wed, 21 Sep 2022 14:59:23 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=linh7s1VRstNoQI8o9haWIQPdUgsvg5GwTMeFyEWiFKpeufwLW2LOMUbo1TUpSvJLJIZScbpHIWo/pcZbRXlMBspZTH7feuy9XyKPoqB/TTB2058Rj2lxQfELp/PtXn7ZiN17Z9GnMeHt2RO4ay/9Vc4ig7uLjuVv81ZXd7NsQI4wtx++aW6CKnRJrCGJx5CVxC3wGQ7sfOrPow/+GdkkAR76ZJYDDDJzmS1BAxWUDRKCOpYvku1RLuj6LDFAdsWB79gLFKlpwzAIZU6ND0Z1yaJXtP5k/KisL3uCyXH9fu8IlqDPdsE0iCueXgVRy48LfrzCNECj6SLfVhVYeVSug== 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=vvFNtHPtqKbhKGrsi3XgsPSDP2FQs96e6vyi6SUg0jQ=; b=ZtW2bkk8KtnAMtGCHuwEbCAMTcJH9+S9Q4TvboebI8G+HGyi/hfPjMg1o6r/ov8zqKyFUlBs1l5UEo+yPTr3CQpWPFxOoT9N1Zcv6yDcEHkG1dYVt0nuGsOPq3A5a6IACp8gJs1V6kjB+W6pg9+K2uOGNDaFQQRdvDFgEm95+dNgErtj3ClmrROSSU7CWBf8SrOfV4xw6DL+/I9qgEqM62cj+vkFPt/gwO7WFgcYFeGE3DnY2ZGtq8WlIcNdwwEt26ZuFjYOv9twAHUAGcG6hSKtz3lnbwqh1rpTlCoXLMXtiqKLGuDTE7nLv7Y9EOclxuYjFxEjlXS2ZVVqWDHgNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vvFNtHPtqKbhKGrsi3XgsPSDP2FQs96e6vyi6SUg0jQ=; b=0AIFfXPIUwrh9QN47m7/ZKO/BrKgmVHP/m5+9yYex3AcBGRJF5O94yq8oiAKo1jHajCgt7j4eH+pVqESq2tUe4oyzgFZ7z88goiQCW6XVh7xyvlE2YLCNFhtpuzAgVYwhL44Xxpfh0ozJRj7Y/8kQ3SkNtLPlrLFatJVmB/a8GiM2sOHqKMFpmjSzhzpA+B52WiWTgQq9dD9YwBk1On/s5CQrM55SATf6Ploh8dCUmfJkmsfA+NhhQc/BagXtResinnfOOUrOaKu8XSjAg9Rdkkgv248j6jcfiRzqy/DJFicPKN9wWCkCH9Vxt7cArZqAormrEbf2JEIy4zwn9utNA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; Received: from PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:269::8) by PAWPR10MB7101.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:2e1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14; Wed, 21 Sep 2022 12:59:21 +0000 Received: from PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM ([fe80::e4a0:49e4:2152:11b1]) by PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM ([fe80::e4a0:49e4:2152:11b1%5]) with mapi id 15.20.5632.021; Wed, 21 Sep 2022 12:59:21 +0000 Date: Wed, 21 Sep 2022 14:59:12 +0200 From: Henning Schild To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Felix Moessbauer" , , , , "Maxime Coquelin" , "Marcelo Tosatti" Subject: Re: [PATCH v6 0/2] Add l2reflect measurement application Message-ID: <20220921145912.1c18b660@md1za8fc.ad001.siemens.net> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8733F@smartserver.smartshare.dk> References: <20220902084533.675698-1-felix.moessbauer@siemens.com> <98CBD80474FA8B44BF855DF32C47DC35D87339@smartserver.smartshare.dk> <20220921132713.516616cf@md1za8fc.ad001.siemens.net> <98CBD80474FA8B44BF855DF32C47DC35D8733F@smartserver.smartshare.dk> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: CH0PR03CA0080.namprd03.prod.outlook.com (2603:10b6:610:cc::25) To PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:269::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA4PR10MB5780:EE_|PAWPR10MB7101:EE_ X-MS-Office365-Filtering-Correlation-Id: 5e60b10b-4cbf-405d-85a2-08da9bd11a05 X-LD-Processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +8D610arYRY+j9So7YK0Hxs7lfT0tquIKa18/HqBNK5vZgfc2FRf15z1zuJNexVqHzsE6Cp+deGtZxIi3ZK5P0m5GaTWOGat4gVgusBxHIsjC1qNd2EODsCWXCFov040F4ynGRhoQR9NOVnCWZn28Tha/zztiPfTDioLvWn7EoVjL5P1mY38Vk7OWreZc2JEswB838JThncDdatS9W9mVvFx895k77GZImc6cDNsTnMU3UcKqltnAYTLFb4HvBQ7VGltDQ8BP0HEeLD3y6Y8SGXuCS02l7VT1VTW+ky98khFbOvYiWwIrQyRlNBjcU1meYDizTKcK3P5rq5ApCDhxpAC126sNNciA+/JqcJwV86z6Iuev33uaG1B3QB0wWZgkueOgJTio2XlxLRGoE0cGSqDYWW7/4+hDjAVH88A1TXcafBA4nnVoJibXhW8KnU3HMrV7ruWGXqBOOq7H+Xu22TZ1G9wib2wCQhN+Cc2kH2LmYty2Z9xsHF+XwMoIdB7zgd0xbCPMAHtutICgD+0Sz6HTjsDs8nkAMuiJzrlJ3tLGhOoo7gmktaKQB/gZxa7klf7U/PAxI5rw1GkeM8i1PYlcoA94ARcnUb8x3D7tXn5C3CL7Y5mU1VSYBOkBvMsyr4bekBoeIflwNo01lVMuttUPEgIqsl18sySV0M239NTqUZRIF5k1QeBFUsH342Hvbyjx3yntYu4QyAwKiPDxjENNZfkRGg7mBpacRzYNjA3DKvUEVmZEWX/VKMb4wAy X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(4636009)(396003)(376002)(366004)(39860400002)(136003)(346002)(451199015)(186003)(6506007)(83380400001)(66574015)(6512007)(9686003)(66946007)(66476007)(66556008)(5660300002)(4326008)(8676002)(6666004)(478600001)(966005)(41300700001)(6486002)(86362001)(316002)(1076003)(44832011)(54906003)(6916009)(82960400001)(8936002)(2906002)(38100700002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M1FleGdGcTZORWtXK0N4RFRvbXJKWm9JN3hkOFlPSUloTDNRcU9qVElTeC9F?= =?utf-8?B?bG1RWlV1MTJWZ1pLMW54Y0pOOWNJbzJ2eWY0akdDeWZwbWlqNUdVMlNCSVlF?= =?utf-8?B?b0NWOE1YY2JzWk1IMHR0RHV3ZFIrYVFvMDJiWHh2RDZNMWVxa09VaDV6a0ZE?= =?utf-8?B?T1QzOGlrelFCRjZXaG9YTFc4SGY4MFdIN0JTajAvSUNIUjE2SDJiTlROMlpP?= =?utf-8?B?a1gwaGNZRnZ1VVlscVlzSkczZkdteWFhNTBSeVlHajdtR2xMYjBZeUlFdFhk?= =?utf-8?B?TXVoR3VWTUhJRGdLM3hrRkkweEVFUUNEVUhFL0QxQ3VLRjZVRnp0N3lwYjd5?= =?utf-8?B?aWN5c1hpeXNWWDNkS1pWeU1aNXIrZERBdE1pa3g1MDlYd2cyVGhQUTR3WVFj?= =?utf-8?B?ak5qVnFBbTFvOFlqVU9KRGlZeWR4SlRGOEhqU0VhUC9ZMlMrdzBZV2hVanFZ?= =?utf-8?B?WkJPNjNaeExReFVxeUF5Z29tQlZxaEt5WlBKRlVxRk1kMS9FRU9pWXhXVUVW?= =?utf-8?B?Y0JwaVN6WVYrYlBRODJEUE1SQVlTTlU4ZkIyblpNRHNLVURRaytPZ3FtdTN2?= =?utf-8?B?UFZPYlBxZVF4MFpQK2daQ081Yk15Mjd1anBlMm03aEdMOTlBdVNnT042dXdB?= =?utf-8?B?ZC9yS0FQd2d1S1Y5ZHMwb1pFakx4ZHRNTVhUeFpEUUNXTTBXV0QyWjlUdVpT?= =?utf-8?B?WGluRGQrdy8wci84QnppR0VjMG9xVGNwTUk3TkNvU3Q1eWttYzZNYXdra0RT?= =?utf-8?B?WlpOTFA4ZTlLQytucnEzNzBnWEFsaVYzOVBJdGNuQmYrMTJCTDF5ZW41MnVM?= =?utf-8?B?UEVacTZIUlBsK1o1Umo3TFJ5Z28yNzgyekNPVXk3ZzFzUThVeHE4aUllWCt6?= =?utf-8?B?RTJoSFNQdHI5Vmxid3lpTGNUdWJ6SDUrN0RGVlBieG9rZWRWYlpSbEh5QlZK?= =?utf-8?B?UThUdEVIakY4Tlc3M2tpTFpBNnZTMWhkbUVUcU82WXpiTldzcjlHWUlDcmcv?= =?utf-8?B?Rlc5VWVLbEdMTGxPSFBpT1V2OTI5OE1VMTBnaEZRTngzVUZsWE1saEdKcUNP?= =?utf-8?B?VVd0ZU40RTVVdUFrMit0dHQ1RlNRZEFNeHFpR2hMUjZHMGdSMHA4Y3lCNk51?= =?utf-8?B?a1FMTXN4T1dHc3JXc3B4U1ZtWDlhRkVWU2JRUUs1MkdqdGJQSHdjMTRkdFhS?= =?utf-8?B?ak9ETkNyN1hFYVFlVzQ2RVB5TzBWY1ViRG83TDFjalFQQkxUdGYwT2F0YXQ3?= =?utf-8?B?dG1QOHJBZTJpTjhGckVOOUR3V25DbzJHaERjQXJGQ2YrMVRUZGx2Q2FuWmlR?= =?utf-8?B?amI4SmpmQjl3bm1HWVh6U2owdTZodk9xdnF3R3FKRFFJWk54MHNQWlJKbWlp?= =?utf-8?B?YnVrRGNrUTJnTGh1cjJlSlZqeFlZUHJSRk13WWJCeWpuQndYd3MwZVgxdUJX?= =?utf-8?B?VlEwT2g2d0t0NjI0MVoyMjA5MEwvWG5uT0pWWmZraUdIWW5YVEVDR0lhTS9P?= =?utf-8?B?ZUdOOHd6ekZSS3RBb1A0RGVSK0JXNjd4dFB5RG5EMFJuRXNrbStnSmJ1UDQv?= =?utf-8?B?YlZCWUJGRkpkWWpwaE5tRDNUc2xBazVwVDNVU1FFQ3U4Wk9kR1J0dkc0SE00?= =?utf-8?B?OVkrUHFzMlByRDlIQnlRRlM3dnlUSHQ5MjZJTTZ0cUdTYTNIK293cG1zemI3?= =?utf-8?B?OU5LNWY1bGo5KzFaaFBPTUQzNm50SjFrdDFkQ2M5eXBXcFRVT2VhNWNoSlFG?= =?utf-8?B?YmRkSE5qMmVPZ2JLZnJzbmNMZFZJdWtWRWY3MlJrZmpjNmx4a2N5bjBaTDl5?= =?utf-8?B?VERNWXlqRnJQUkVRNkEyaVdlMEFLRzEzT3QxNnFkcXkwdGhSVkdMaDEzc0k1?= =?utf-8?B?VlNrSDdLcTZQMVQrL2tDYnEvQmtRamZEbnpVaHl1QytyQkZIV2dZQUhUbHMx?= =?utf-8?B?RWdPQ05kTnFBY3ZLNlJ0b2pjOGtmbk1vazVGRVhOd1J0YVM4SCttOW5FTzFl?= =?utf-8?B?YVo1M3BWM1RTR2wyTG9pSHYwNjdPUnRvOE1OeExoc2RBWjNuZHRvbHV6YlJF?= =?utf-8?B?TlVqbFlrbVJZZTNOMUpkN2RPb1JIU3VmUUhoVzRkR2J6NGhVcGpxZDVtWjh5?= =?utf-8?B?L1ZOcHlIRGNjaUV0ZlZoU3FZakNGc05FclpZMnpqRW4rcmpXRUZydFVXR0J5?= =?utf-8?B?aU04Y1R1WDN6OEREN2xOcnpld251RVFvUEgrWndyaUlaOHU5ZzQwdkVzSlZQ?= =?utf-8?B?Mm56QW5ON0JGVUt5Ti9ETVFMVStnPT0=?= X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e60b10b-4cbf-405d-85a2-08da9bd11a05 X-MS-Exchange-CrossTenant-AuthSource: PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2022 12:59:21.6354 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Yfl6OB7+eUj7Mnfo2qAIt4pTye4VfOsQvR/XVye69YxmjzIplxHDELNgin/VdgIZqr6lYaIT76vy8eWWZFRCkzePhUDB5tMCoAeSeqTmB1w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR10MB7101 X-Mailman-Approved-At: Wed, 21 Sep 2022 15:58:10 +0200 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 Am Wed, 21 Sep 2022 14:22:07 +0200 schrieb Morten Br=C3=B8rup : > > From: Henning Schild [mailto:henning.schild@siemens.com] > > Sent: Wednesday, 21 September 2022 13.27 > >=20 > > Am Wed, 21 Sep 2022 11:43:13 +0200 > > schrieb Morten Br=C3=B8rup : > > =20 > > > > From: Felix Moessbauer [mailto:felix.moessbauer@siemens.com] > > > > Sent: Friday, 2 September 2022 10.46 > > > > > > > > Dear DPDK community, > > > > > > > > this patch provides the l2reflect measurement tool > > > > which will be discussed in our 2022 DPDK Userspace Summit talk: > > > > "Using DPDK OVS for deterministic low latency communication" > > > > > > > > While the code still might need some polish, we believe it is > > > > a good starting point for discussions about low latency > > > > networking in DPDK. > > > > > > > > The tool can also be used in a CI environment to contineously > > > > measure latencies across the evolution of DPDK and Linux. > > > > > > > > Best regards, > > > > Felix Moessbauer > > > > Siemens AG =20 > > > > > > Dear Felix and Henning, > > > > > > Great to meet you at the 2022 DPDK Userspace conference. > > > > > > Have you considered using the Configuration Testing Protocol > > > (CTP), described in chapter 8 of the Ethernet specification from > > > 1984 [1], instead of your own packet format and the Local > > > Experimental Ethertype? =20 > >=20 > > No we have not, first time i hear about that. First type we used > > must have been 0xaffe or 0xdead, would have to dig through version > > control. =20 >=20 > You seem to be using the correct EtherType for an experimental > protocol like this. I was not opposing to that. >=20 > > =20 > > > [1]: http://decnet.ipv7.net/docs/dundas/aa-k759b-tk.pdf > > > > > > The CTP an obsolete protocol, and not part of the IEEE standards > > > for Ethernet, but I think Wireshark is able to parse such > > > packets. =20 > >=20 > > Yes ... does not seem to be a train one wants to hop on. > >=20 > > Maybe you can explain how one would use CTP to measure roundtrip > > times, and go into detail on how that would add value. =20 >=20 > I would only change the packet format, not the way of measuring. >=20 > >=20 > > I had a quick look at the spec and did not clearly see whether the > > protocol could be used at all ... maybe "abused". And being a CTP > > server one would need to implement more than just "reply". And i do > > not see any value, except maybe "wireshark support" ... but i am > > not sure how that would add value. The packets we send are trivial, > > headers are ethernet and the content does not matter ... so > > wireshark support is there for all relevant fields. =20 >=20 > The primary - and probably only - advantage would be that the > EtherType 0x9000 is officially allocated for CTP, so you don't need > to use one of the EtherTypes allocated for experimental purposes, > which might also be used for other purposes. Yes that is something i thought about as well. In case there would be some sort of conflict with 88B5 i would rather include some sort of "magic start" or sub-protocol id if you want. But until we see such a conflict i would simply stick with 88B5 which seems to be a good fit, but not "clearly standardized". I would not envision people running l2reflect on a very busy/big network, as the results would become increasingly fuzzy and meaningless and other latency benchmarks would probably be a better fit. Any confusion with another 88B5 application is "highly unlikely". And when jumping on 9000 we switch from one "unlikely number" to another one ... or in fact we are now on one that is "more likely"? From what i read cisco equipment might start acting on those 9000 packets. I think a "highly unlikely" conflict does not justify a rewrite. For a not well defined protocol it would not be a "conflict" really. While 9000 would be "more likely" and dictate a corset to try and fit in. Even if we can make it fit today, future extensions might not work out. So i think i would stay away from CTP. Henning > The CTP packet format is also trivial: >=20 > The "Request" packet basically contains a SkipCount=3D0 field followed > a sequence of 1) a "FORWARD" structure with the MAC address of the > Request sender, and 2) a "REPLY" structure containing only a receipt > number (which I guess is like the ID or Sequence Number of an ICMP > Echo packet). >=20 > The "Reply" packet is the same, but the SkipCount is increased by the > size of the "FORWARD" structure (i.e. 8 bytes), so the SkipCount > field now points to the "REPLY" structure. >=20 >=20 > Furthermore, the protocol also allows forwarding the packet through > multiple hops, like MPLS. In that case, the initial packet's sequence > will contain two or more "FORWARD" structures, and the CTP server on > each hop will pop the topmost "FORWARD" structure (by updating the > SkipCount field) and forward the packet to the next hop. However, > nothing prevents you from also expanding your protocol to also > multi-hop, if the need for it should arise. >=20 > >=20 > > regards, > > Henning > > =20 > > > There might also be long term perspectives in building on top of a > > > published (although obsolete) standard - e.g. the protocol could > > > be revived and become part of the DPDK protocol library, along > > > with =20 > > LACP. =20 > > > > > > On the other hand, it might limit your ability to expand the =20 > > protocol. =20 >=20 > Just wanted to let you know about the existing protocol, so you can > give it a few thoughts. There are pros and cons. >=20 > I have no personal preferences for CTP vs. your protocol. >=20 > -Morten >=20