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 C3DBB43B45; Mon, 19 Feb 2024 05:03:22 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8FE0E4029B; Mon, 19 Feb 2024 05:03:22 +0100 (CET) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2080.outbound.protection.outlook.com [40.107.223.80]) by mails.dpdk.org (Postfix) with ESMTP id A0C5140278 for ; Mon, 19 Feb 2024 05:03:20 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ux09jfKz6HX8c0Oix9EZxzrdmNl4YgpLkNGafY97ujvOgx3ISGiDFzhLeEBRXJ10i8JhkdC8tkunLScPawyJgW7q+hYhxnTI5KZM3Ev7+w1vMpJlLEQ85yN6qZ0tKKfvOB/sBBQocg0+b69gTmVsJoZ46QRw5YiqNmbcKrN+cDpw/k3VtNwwHWIy/HZS/Nd4Xh/g6IbqaXid/LZ8xU5ca3VYVfH0P2SIe5fTjHTHJHagPD+h+EIR5bULzCm/P1zdVriJIHYXIeW4hH06NXycCNI+1tZ3SPuU5cQKC7if25GBijognpeyyTwYMyS/ZTh2QcgboYKWm2ZKhXOv6Co6pQ== 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=lD/y1/AspoE5r0kktvK8u1My6tKisKg6cm9+QiTu8kw=; b=RRhKlR+2inHD4Q4/I5COP8o1iwIMqa/hRMt3qdK4Yz6FmDtNc7WdgccznnDbvxFPcKwax778vnCcKcx6w78+B7n6tAHUCXephFb3BaTge3dxknJJZZcakyqQD9+qhJ8yv9qyzHFBCWrSg+UHTJdMZJttqX8jYLPDU4S9zIzbfVT7io3v9JhpA+G4ArWbk9qEcOCcSz6mq9tlWeidz4zSvYL3+rhgSy17lTiJXzSz6BI0IgGGzArbYjCJpcptGCARIy8hlwQzVZHIPm9Ojd/boM1jdbQRYmgKOeAitzyH+Y30l/onTije9MJ70fyIsIVOnLacAWM9X9T83oXlfo1CzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lD/y1/AspoE5r0kktvK8u1My6tKisKg6cm9+QiTu8kw=; b=MS0rHJZrtfo/JJQv86LB8fNgKzBFjOdXB1KZTeEC77fyIOU6unStU1ihKj0ZpXaAuIIx4aoKKw0GzOJ/GszY/7xs8SPpK/MEdvsMdZXsdgppiUZ3bj1iUbDfAW58hMbJXEnLI+uMHEp6i63OfmKzgRbhfWYGr4AaenLXTsKfQo3DBiRTEBD/eOO7tnvonGotZF2ihG7s3tNYQFVgUcw0iNTVbEOzKFtGeU+eRyT0SdvVtx+yvQUPnJNoQ1/2iO1C4R9LVDO8adowMhI6rF71j7P7QSpZ49yHNJazWyWBVHFiMY2AdnOuhVk5RSy2qjn8Fqw7A8q2fzNPAcJUjB/ZhQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from IA1PR12MB6019.namprd12.prod.outlook.com (2603:10b6:208:3d5::16) by CYYPR12MB8989.namprd12.prod.outlook.com (2603:10b6:930:c2::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.17; Mon, 19 Feb 2024 04:03:18 +0000 Received: from IA1PR12MB6019.namprd12.prod.outlook.com ([fe80::8c2e:f7e8:e736:4370]) by IA1PR12MB6019.namprd12.prod.outlook.com ([fe80::8c2e:f7e8:e736:4370%2]) with mapi id 15.20.7292.022; Mon, 19 Feb 2024 04:03:18 +0000 Message-ID: <8acace68-a65c-4097-a600-47e629d4a111@nvidia.com> Date: Mon, 19 Feb 2024 12:03:08 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC V1 1/1] net: extend VXLAN header to support more extensions Content-Language: en-US From: Gavin Li To: Thomas Monjalon , orika@nvidia.com, andrew.rybchenko@oktetlabs.ru, Ferruh Yigit Cc: dev@dpdk.org, jiaweiw@nvidia.com References: <20240130112520.1971315-1-gavinl@nvidia.com> <4126957.6PsWsQAL7t@thomas> <27994279.gRfpFWEtPU@thomas> <6f109cc9-87a1-43a0-8b13-190ee263be1c@nvidia.com> In-Reply-To: <6f109cc9-87a1-43a0-8b13-190ee263be1c@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR01CA0119.apcprd01.prod.exchangelabs.com (2603:1096:4:40::23) To IA1PR12MB6019.namprd12.prod.outlook.com (2603:10b6:208:3d5::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR12MB6019:EE_|CYYPR12MB8989:EE_ X-MS-Office365-Filtering-Correlation-Id: d80b30e7-9a9b-4967-85aa-08dc30ffb43c X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NDq3JE34OGQfTVLU//gVlYOJvzlIZtQz6yChDu2v0VG2Xa1iuP55k7Zy+rdgt1QDfP9YRqTbTu82Izo2ijU/3XH0a5Lozm2PaUyd+20AgVi1qaL7j9YZLcKcvMj0os27YhBTk5EX90rXQWhotKV1JLlPtpB4UDPUSRUHyz6lClANw+lZaOIruyMwUeQ6bCNuIZwkTyGcXt02qq3On3uinR0nRYPnyukwDbfHEE9r+vNjlEVdtiz/VJagbLLjZT2kRvbM0kKzQBnc+9Ch5SoOZkF8H8pwu0IrERdSh2exI+KfDN/kvzrfSrSbyyRqi6dLe0i5OKGL/dru6QxW5Tuy30uT9fEqgy8v6jffZve40vVmW9Px7C73YT8JF6C+cEJ9FTkjMawe0+RtP9rAFx/pFB01n59AM8mtGbUSIhtbNvBLdg6qGnJzJzvD6F8MOUkxXhI4ZL/DNCkB7DBGxkZJ3bdacW5fuHyMdWJ6Xv6qSoxQ4In9R3lSKCLRdMzKDuc0DyvIbt4iA/DGbPVAzV3VDKQ03e1MOuhXo6pELQa0XQfyJzrGuuN+icBUST8INPeIlg8u4tEhYUjIm2xnMIHnVQiJXlbieEe6POY465YhauM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR12MB6019.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(376002)(396003)(346002)(136003)(366004)(230922051799003)(1800799012)(64100799003)(451199024)(186009)(66556008)(2906002)(8936002)(4326008)(8676002)(5660300002)(83380400001)(2616005)(107886003)(38100700002)(86362001)(31696002)(36756003)(26005)(110136005)(66476007)(66946007)(316002)(6506007)(53546011)(6512007)(6666004)(478600001)(6486002)(966005)(41300700001)(31686004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aStYYWVMUkZpK0k2Z3o3UUwrcVVFMTBpRVlodlVvUjU0UFcyMnFURDFJMUwz?= =?utf-8?B?Q3ZqWHZ0NVJWMDVLQUxFUHUvd05FUDNPS3dMSHE2UVpFMXR4UXdGa1FRT0hj?= =?utf-8?B?N3duSTFuWGNGVGlMSHZiZ05kQ2hNa1Z0SVdlVlBIaE9xRmh3bUgwV0dsQmZw?= =?utf-8?B?Q2dkMjFPdWdqd2paNmYwODd1ZmtlcmVKVVp1cDdzSkRWVEhuME1wSHJadkNF?= =?utf-8?B?NkN1UTg4dERoZUk2VXRWQ2p6S0pWaUx1eVMrcStuV3dQMExTYlBlWHFRVnZn?= =?utf-8?B?SXlDRURySmpPVG53WXdQdnJYemlDUzYveTZHTkI1cTFWRllhUTZ1Nnk4V3FI?= =?utf-8?B?T0NCMzR0M2R4dVprWHJETC8rTXh2bFdOWVJIUDFXMU1zcm4wWFo4eDVoVlJr?= =?utf-8?B?VU0xOWtVUXVsaWxEZVAybkxzcnRTUGpjc0lUUUt5dkhOVUhpc1FZeTNsRTVV?= =?utf-8?B?bWVxM21jZE9uODlZb0RwZTBmK2xZMHhqZC9BM1NvTmZBd0w5aStTdFNCTERN?= =?utf-8?B?bHE1WE1mUEVDcE1jUzNJa0hHV3BBdnAvRllqOVkrdVhvZ0ZqSUNVVmxPb1pL?= =?utf-8?B?OWliMWZyc3doQW5wOWdzWWhsUk1WTFlBRGsxQThSQ1FMa0RCZG5vbFRDNU1s?= =?utf-8?B?L1FWbjU0MHArUk8zMDczeEw2eWJyWjhQUFZVRTJ4MlFPdkdPRTN1dm52RVZu?= =?utf-8?B?L3VxVEtqcW45Tjh4OGIrVlRVYWtsUm05RGVEaGMwSDNNdmt4VmRhRlNGV1Fn?= =?utf-8?B?dGdzTElZckJzRk5CYkQxM2dKMk1jNCtYREUyVTBuTlZGUnVvRUdkWFZzUWZn?= =?utf-8?B?MEprV0JzeWp6N092WCs5ai9RMnlVcG0wNWswcHZjdERVcEVveU8vOFhZeTRG?= =?utf-8?B?Y0Yyc1UzcGg5T2tQaTY5aUhmSE5weWdMM0JJQ3VWSkROci9wSVZwY1FJRTRD?= =?utf-8?B?Rk5Na1pnRk55dDNSSjFOYVNNQ3ZhOTNCY3B5cVRkSW9DUGw1OG9DN1ZrMzZL?= =?utf-8?B?cGZ4TXIvQ2tObWJCYnBFckNhUXJYNitGbWpLenl5clJKSHVaaFNyVDF3R3dm?= =?utf-8?B?cEttWkNPbDhnNXhSMHZPWkpvNG1XckovQ0ZPNGRHRU9Bdk54NDNOQ3lpTjlE?= =?utf-8?B?QnN5R3AvTUs3YzNvNnhnK3JCcmZIanZSZGIwUHh1aHovRVhibWJOcVBlSEhq?= =?utf-8?B?cjhyOXljaDJNc0wzeFE1N25mbW5WV1BLR1hucXlIWmZVamJoM1JTUjdIWW8z?= =?utf-8?B?WnVMMmtKOXpZVHlCN0ovNVAwNjlWNGZJeW1WUTViNHBtTEFPNTFCaFlKZHBL?= =?utf-8?B?dERTSWVsc3JrQnlZaVFNK09tcTNjM2tCeStYN2lhQkVJK0JPenJ6T0ZPRi9H?= =?utf-8?B?d2ZFSnJlcnlTbGdNUG9yaDg2dDlEZ09KTTVoeFY1M2RmSTBxaFg5QzFZeDFY?= =?utf-8?B?TGtyc090VFdnZnVvd2hDcW5OTUc1U2g3NXAzOENVZS9iMmRuNmMxWlhxN2F2?= =?utf-8?B?eGpKS3Nja2srL1pZSVVuZTF3Ymo4WUhrN2pjVEhDYTZNcjRLU21rMjNYSkNt?= =?utf-8?B?UDJBenZKTXBEZEJWT1R3YVNweUdEaTRNZlE4RHZSVEI5TmdxZWJ0NlNMZkhm?= =?utf-8?B?OWg0NVVjMTBpb3N3N1NWZXlyZ2V5b3JpWTUrT3pZL3ZhYXMxRW01Rll6YjRG?= =?utf-8?B?OVhHemJNRzcyanlpQmFFQ0RYMVgreUFpazExWDRGUk5CT3pKVk1DL001dytz?= =?utf-8?B?eDl5ODduQWpOVis2VCsyampKclVGQWpVdlZUMlJJOThmS3RXWEZPY3ZPVnN3?= =?utf-8?B?TE0xb20xSlpGTnZRVDhLMU1SalZobHFORlVHK0xOZlBqZk5hR3RQMXpHTEpx?= =?utf-8?B?bUpuMS9EM0Q1WU5uRzZYa1NyelVtNCtOcGRIQ0R0SUg2dnVpNEJodWttSldz?= =?utf-8?B?NCtLVVFHeHRQbHZzREQvd2FiMlFWQU9pMHlPbWxPekcxQ08wdG1XSWZVenhQ?= =?utf-8?B?aUlrK2VOKy9kMG1sOFp1Q0VGbE9QVkxMK2UrdzlyVWdkdDM3VFBraU12c0lr?= =?utf-8?B?KzgyYlEwNmVGK1lrRU5YTVJHbWxwYURNYlhXUmhSbFVGTWo1bGQ2cS9mMEpE?= =?utf-8?Q?GZ/da5Eu8NVQyj2Q7MkPfOVtz?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d80b30e7-9a9b-4967-85aa-08dc30ffb43c X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6019.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2024 04:03:18.1393 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: wuILDTGZhqW0DG8UrQJZ01Ocmr7IfmdfSMRdrs4gI7w2hiCXpgnMkRF4/AFlXVoE/afmy5Q8Fnp4I3+HRxW7mA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8989 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/19/2024 11:44 AM, Gavin Li wrote: > > > On 2/9/2024 11:32 PM, Thomas Monjalon wrote: >> 09/02/2024 15:58, Ferruh Yigit: >>> On 2/9/2024 1:44 PM, Thomas Monjalon wrote: >>>> 09/02/2024 13:11, Ferruh Yigit: >>>>> On 2/9/2024 10:12 AM, Thomas Monjalon wrote: >>>>>> 09/02/2024 00:54, Ferruh Yigit: >>>>>>> On 1/30/2024 11:25 AM, Gavin Li wrote: >>>>>>>> Currently, DPDK supports VXLAN and VXLAN-GPE with similar header >>>>>>>> structures and we are working on adding support for VXLAN-GBP >>>>>>>> which is >>>>>>>> another extension to VXLAN. More extension of VXLAN may be added >>>>>>>> in the >>>>>>>> future. >>>>>>>> >>>>>>>> VXLAN and VXLAN-GBP use the same UDP port(4789) while VXLAN-GPE >>>>>>>> uses a >>>>>>>> different one, 4790. The three protocols have the same header >>>>>>>> length and >>>>>>>> overall similar header structure as below. >>>>>>>>      0                   1                   2                   3 >>>>>>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>>>>>> 0 1 >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>     |R|R|R|R|I|R|R|R| >>>>>>>> Reserved                           | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>     |                VXLAN Network Identifier (VNI) | >>>>>>>> Reserved    | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>>                             Figure 1: VXLAN Header >>>>>>>> >>>>>>>>      0                   1                   2                   3 >>>>>>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>>>>>> 0 1 >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>     |R|R|Ver|I|P|B|O|       Reserved                |Next >>>>>>>> Protocol  | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>     |                VXLAN Network Identifier (VNI) | >>>>>>>> Reserved    | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>>                           Figure 2: VXLAN-GPE Header >>>>>>>> >>>>>>>>      0                   1                   2                   3 >>>>>>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>>>>>> 0 1 >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>     |G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R|        Group Policy >>>>>>>> ID        | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>     |          VXLAN Network Identifier (VNI)       | >>>>>>>> Reserved    | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>>                            Figure 3: VXLAN-GBP Extension >>>>>>>> >>>>>>>> Both VXLAN-GPE and VXLAN-GBP extended VXLAN by redefining its >>>>>>>> reserved >>>>>>>> bits, which means the packets can be processed with same pattern >>>>>>>> and most >>>>>>>> of the code can be reused. Instead of adding more new items by >>>>>>>> copying/pasting code for the VXLAN extensions in the future, >>>>>>>> it’s better >>>>>>>> to use existing VXLAN infrastructure and add support code in it. >>>>>>>> >>>>>>> >>>>>>> Hi Gavin, >>>>>>> >>>>>>> The motivation is to prevent code duplication, and the code >>>>>>> mentioned is >>>>>>>   the driver code, right? >>>>>> >>>>>> The motivation is mainly to provide a unified and more explicit API. >>>>>> >>>>> >>>>>  From user perspective, I think existing approach is more explicit, >>>>> because it sets VXLAN or VXLAN_GPE flow types. >>>>> >>>>> I am trying to understand the benefit, how unifying flow type in >>>>> the API >>>>> helps to the user? >>>>> >>>>>>> Overall OK to unify "struct rte_vxlan_hdr" although it makes the >>>>>>> struct >>>>>>> a little complex, perhaps we can consider extraction some nested >>>>>>> structs >>>>>>> as named struct, no strong opinion. >>>>>>> >>>>>>> >>>>>>> But not sure about removing the flow item types for VXLAN-GPE, or >>>>>>> not >>>>>>> adding for VXLAN-GBP. >>>>>>> >>>>>>> Think about a case user adding a rule, which has a item type as >>>>>>> VXLAN >>>>>>> and in the protocol header some bits are set, lets say first >>>>>>> word, last >>>>>>> byte is set, how driver will know if to take it as GPE "next >>>>>>> protocol" >>>>>>> or "group policy id". >>>>>> >>>>>> The driver may decide depending on the UDP port and some >>>>>> distinguishing flags. >>>>>> If you want to match on GBP, you should includes the GBP flag in >>>>>> your pattern, >>>>>> no need to use a separate item. >>>>>> >>>>> >>>>> Why not be more explicit? >>>>> It helps to driver to know more about the pattern to be able to create >>>>> proper flow rule, if there is an obvious way for driver to >>>>> differentiate >>>>> these protocol extensions, and flow item type is redundant, I can >>>>> understand the proposal, but otherwise I think better to keep flow >>>>> items >>>>> for extensions. >>>> >>>> In any case we need the simple VXLAN item. >>>> If we have GPE and GBP specialized items, >>>> what means a match on the simple VXLAN? >>>> Does it include packets with other extensions or exclude them? >>>> Matching the bits in the protocol make such decision explicit. >>>> >>>>> When a rule is set in HW, HW may not care about the protocol, as >>>>> long as >>>>> bits in the rule match with the packet, HW can apply the action. >>>>> But for driver to be able to set the rule properly, it needs more >>>>> explicit information. >>>> >>>> Yes information is in the pattern to match. >>>> >>>>> Lets assume driver API get a pattern with 'RTE_FLOW_ITEM_TYPE_VXLAN' >>>>> type and "struct rte_flow_item_vxlan", at this point driver doesn't >>>>> know >>>>> if it is VXLAN or any of the extensions. >>>> >>>> Yes it knows because of the matched bits in the pattern. >>>> If the rule specify a match on GBP flag = 1, it is GBP only. >>>> If the rule specify a match on GBP flag = 0, it excludes GBP. >>>> If the rule does not mask GBP flag, it includes GBP. >>>> >>> >>> >>> OK, VXLAN-GBP protocol has a GBP flag that gives a way to differentiate >>> the extension, so flow item for it becomes redundant and we can get rid >>> of it. >> >> Yes I think so. >> >>> Is it same for the other extensions? >>> If we use VXLAN flow item and by setting specific field in pattern can >>> we differentiate VXLAN and any other extension? >>> Or in some cases other information, like UDP port, needs to be taken >>> into account to differentiate protocol/extension? >> >> For VXLAN-GPE, differentiation is on UDP port. >> Remember we have an API to fill some UDP ports: >> rte_eth_dev_udp_tunnel_port_add with RTE_ETH_TUNNEL_TYPE_VXLAN_GPE >> >> The UDP port value/mask may be part of the flow rule pattern. >> >> >>> I found a spec for VXLAN-GBP, but it shows as sub-header for VXLAN-GPE, >>> different than what this RFC describes: >>> https://datatracker.ietf.org/doc/html/draft-lemon-vxlan-gpe-gbp >>> >>> Can you please share link for VXLAN-GBP Extension spec? >> >> I will let Gavin explain here, I'm not an expert. > > Sorry for the wrong format of my last mail. Let me try again. > > The RFC mentioned, aka draft-lemon-vxlan-gpe-gbp was to define VXLAN-GBP > as a sub header of VXLAN-GPE by assigning a next protocol num of > VXLAN-GPE for VXLAN-GBP, which has been obsoleted since > draft-ietf-nvo3-vxlan-gpe-09, the latest is > draft-ietf-nvo3-vxlan-gpe-13. It was temporarily valid from > draft-ietf-nvo3-vxlan-gpe-05 to draft-ietf-nvo3-vxlan-gpe-08. > > The VXLAN-GBP we are discussing in this thread is an VXLAN extension > parallel to VXLAN-GPE. > > The RFC introduced VXLAN-GBP sub header to VXLAN-GPE is > https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-05. > > The RFC obsoleted the sub header is > https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-09. > > The latest RFC of VXLAN-GPE is > https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-13. And the latest RFC of VXLAN-GPB is https://datatracker.ietf.org/doc/html/draft-smith-vxlan-group-policy-05. > > >> >>