From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id AC642A00C3;
	Tue, 25 Jan 2022 15:29:30 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 2EE32426F3;
	Tue, 25 Jan 2022 15:29:30 +0100 (CET)
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by mails.dpdk.org (Postfix) with ESMTP id B8278426E4
 for <dev@dpdk.org>; Tue, 25 Jan 2022 15:29:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
 t=1643120967; x=1674656967;
 h=message-id:date:to:cc:references:from:subject:
 in-reply-to:content-transfer-encoding:mime-version;
 bh=NzJcNzICBIskf8ILA1SaUQblHrMeTit1DttV36XJhyk=;
 b=VmVHJWlpg57EbIRkD7A2glPKsAdopI8E9vAHYLI9Aac0JVY54VLBfGw9
 cAXh/ori/E46NTHABJVsjDMVUD3fkbLoAJWR5WRCrUhsOpKAQoOB2h0Pm
 s0g+Ygalcb35MSGobYy64P3LUDARwNwJTzShoExe3zkJNUYI2Cz+OU6eb
 nbuyIjCm0K1pQa4liHfxHwnxPruTk41DhTfjXf3n5XhvmxAlhnR7yHaGo
 trzKq3T6XecIxRFIjqWqWlZ2zTZMTheJVI2XX3t9S0Wk6po9cIajpjftY
 4ZLFMy7a/aLJIEbPwMbNn6hFzHoUElYhynLstjTiiq0fyemisAakQeVzP Q==;
X-IronPort-AV: E=McAfee;i="6200,9189,10237"; a="307027098"
X-IronPort-AV: E=Sophos;i="5.88,315,1635231600"; d="scan'208";a="307027098"
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
 by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 25 Jan 2022 06:29:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.88,315,1635231600"; d="scan'208";a="597139290"
Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19])
 by fmsmga004.fm.intel.com with ESMTP; 25 Jan 2022 06:29:26 -0800
Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by
 ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2308.20; Tue, 25 Jan 2022 06:29:25 -0800
Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by
 ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2308.20; Tue, 25 Jan 2022 06:29:25 -0800
Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by
 orsmsx611.amr.corp.intel.com (10.22.229.24) 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, 25 Jan 2022 06:29:25 -0800
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.174)
 by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2308.20; Tue, 25 Jan 2022 06:29:25 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=XyPzLK8pG5oOHSEQbsYyxjl5Eky5dGY5cBcBJRsokVBt60YO1jNznfmcRCljdyw+j5uRNcFYJ1tF+zwNBmpjf2wHsKgfLV/Yvxu9fl5V8akko5YvIb182iMBIoq793PBtbqF7TmCGAiYLg/7hfSLA30pWhjVlMCq14Q20CGW1K+i8UsXyuJrl5RYn0hzHuk28WtVAIGvuii/8uy3VqQ0gcVVLwzbs9CTeZr+fY5sQqtrRE813HsurHIabGiM3VDr1BzU1SbtrAHCa5v5WyxTK6ug6G4hxbkkqTyZzijrH7dYSqu+0p7WwiabSN79Cnh6GF7A1xqDteXkUKx8CYou2w==
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=Xhn4jMeN4gawQi8h404HLdQqR4y9rL9tyyVkI46TYD0=;
 b=Yg8IJzKctku4tDvSKQ29Mr9JUa6Rki0rzj3cmCyfCgpoBCLPH4GBdbH/OT40HICRK0IIKf9swhAu2pB9Yvu0HKvfw+qiA2KS3lhi6z6+MCan3GFyngWEci5rBjLjvGYf23OSFFw9FS5vLjU9oFRtydAJ+9pFbIHZZn0RWJKjX76LljHMOHbeDeUVphfRfJYKJFzBeZT+ZC3Wv5Y1fa9cwXJ/S63szBoZTHLPdWPtW/JS9B4qoIzs0q4CjVUp2NPI6HWlSiz+DyfxNFlRNtBNTOuWBWBW4VNAU/GQ/KBWductR0k6PS3od45fCKMfz8v7Xgy/qy2MWc7QUAPEpmYXMw==
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 SJ0PR11MB5005.namprd11.prod.outlook.com (2603:10b6:a03:2d3::21)
 by SA0PR11MB4622.namprd11.prod.outlook.com (2603:10b6:806:9c::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.8; Tue, 25 Jan
 2022 14:29:23 +0000
Received: from SJ0PR11MB5005.namprd11.prod.outlook.com
 ([fe80::5097:78f8:816f:f243]) by SJ0PR11MB5005.namprd11.prod.outlook.com
 ([fe80::5097:78f8:816f:f243%6]) with mapi id 15.20.4930.015; Tue, 25 Jan 2022
 14:29:23 +0000
Message-ID: <352a7279-6644-da90-0113-d0925175881d@intel.com>
Date: Tue, 25 Jan 2022 14:29:17 +0000
Content-Language: en-US
To: Ori Kam <orika@nvidia.com>, "Sean Zhang (Networking SW)"
 <xiazhang@nvidia.com>, "NBU-Contact-Thomas Monjalon (EXTERNAL)"
 <thomas@monjalon.net>, Matan Azrad <matan@nvidia.com>
CC: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, "dev@dpdk.org"
 <dev@dpdk.org>
References: <20211230030817.15264-1-xiazhang@nvidia.com>
 <20211230030817.15264-2-xiazhang@nvidia.com>
 <002b1f85-0871-a02f-0345-1b19d722762a@intel.com> <2037437.VsPgYW4pTa@thomas>
 <MW2PR12MB4666A78C579FAD7F4E2ABAA1D6599@MW2PR12MB4666.namprd12.prod.outlook.com>
 <DM8PR12MB5398F8D0D6396F4C87C9CDCFA25F9@DM8PR12MB5398.namprd12.prod.outlook.com>
 <d154e5c9-f8f7-100b-e4bd-3577371c9cd7@intel.com>
 <MW2PR12MB46666FE83ED003045F4401D2D65F9@MW2PR12MB4666.namprd12.prod.outlook.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [RFC 1/3] ethdev: support GRE optional fields
X-User: ferruhy
In-Reply-To: <MW2PR12MB46666FE83ED003045F4401D2D65F9@MW2PR12MB4666.namprd12.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P265CA0072.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2af::21) To SJ0PR11MB5005.namprd11.prod.outlook.com
 (2603:10b6:a03:2d3::21)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b52e89ce-8384-40e1-7ddf-08d9e00f14fd
X-MS-TrafficTypeDiagnostic: SA0PR11MB4622:EE_
X-Microsoft-Antispam-PRVS: <SA0PR11MB4622DD6A1DE602D8470214CC955F9@SA0PR11MB4622.namprd11.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: qg3VbWPUS5DACnmHYSuBlMgIAaE88XB9MGkcVHOpV4U2l6yWl2f7awlwvIg7HPR7joOCfWik0mkZKSbH61HrGGD8cg6TU5adb9Vlhf7sdhtLPz4cYFcfo+qZ3k4oreOVIOF9DLg3/ZQ/uPfg7KCJ5q7J8IRnTRgioFBm7dbqhZDqdFcs434Eg2Hf1cucr8tNZiEWVEXMO8JHvmFoMuk0vZn+reCc+azHBzisBaAJPoY0C72eOFU8ypmtskd/XJvMP8JC73jswDyKWpHmfsiE6lSdZQ6MAHYgKw2UjbrVpzHbuE4ATFPX5KjgjHRjwCfJoGwHoAx9nZzR5M2fjdKYwJWlUjZ1RFIWWfC16kfCw5vsU22+umQYlPPf3B+QomfNBZv/5FAMV9pmfukbiydyt0qIluVnog5E8jbfHsr0azi4NIHVvTE2Y7tMPf6fkFrO5STm6ouKnJac2K3lp0M2pM9YNqTH8f9hU6XrRdR1yuqgWZaRIvjaYeKtklAIMS7a7sV181K7B9EW5gGr3P0mDpe7EfJxr/+0rVYtXr81KiM5BTDiu16mqELv07u9bAnCzleFD9xjVtiGjNgGm4LJBY4BX8HsLpStqNNJXwbwHhuCPcGrttAr7K8Fk7zsdC2eb4T45QhWGZmGv5q/TgJQEY0ziZZL5/XfJUhOaZrCeaEOqSL9mJ8SZBVbrMTi6fuoZKpb8ll8NHxMUQnB5ywWv/PTm+pbBLCTper1xZOSYmA=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SJ0PR11MB5005.namprd11.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(366004)(6506007)(82960400001)(2616005)(83380400001)(5660300002)(8676002)(6486002)(186003)(31686004)(44832011)(26005)(6666004)(6512007)(53546011)(66556008)(38100700002)(66476007)(316002)(4326008)(8936002)(508600001)(2906002)(86362001)(66946007)(54906003)(110136005)(31696002)(36756003)(21314003)(45980500001);
 DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TnAxMGlXRDduYlE0YWVlUGJGK284Vm1FMmk2S0JiMmtxU3VmQThVOWJtNlhB?=
 =?utf-8?B?QnJUMHlEZTVUSXkvRzdoRGVPWXlNUjFXL05VVi9xS2o0eWNhVkNZaE51Uk9C?=
 =?utf-8?B?cUdTaDJYNm5WR1JYYmxGc1BWK2lNRTh4T0pQUTlFRVZueXRMYjFSKzhhb29w?=
 =?utf-8?B?OFNoeExMQXVFZTJYdi9mdmN5V0x5aGdBUWljdTVIMHFxZGgyVUxOQmxXRnJ2?=
 =?utf-8?B?Y2pYcG5kTExTdC9PZU1CMSs0L3FQQzlnMXlOdWFBS1lGQ1U2L0tjOEpxZUNF?=
 =?utf-8?B?cGFyMHgvUzkrSm05T1p4aVVLRDQvOW5JL05sU3RlcGNScHpUaXVrUnd1bWtI?=
 =?utf-8?B?OVBZMllVTTJ6K1I4c1ZIcS80aGN6T0F1K0thZXhEODRya1JSZDZ5ekVHNkd6?=
 =?utf-8?B?ZGpTSHp5Q3VEMHlYZjlTT0l5bmh2cGhzanhyaHV4NVQ0YU41aHZOMS94Kyt6?=
 =?utf-8?B?RjBucHhWL2FLOEhDbGZDbDg1WGpDaDBwN0lsOUxmSnBxNS9Eck1HZFY4SDFP?=
 =?utf-8?B?U1l1V0hzUzBPaFFRSis2TzBUQzNsTHdtaThNSGFLaStvTU1vcGdCRWV4dlRH?=
 =?utf-8?B?WWM2WTVwMFF0ZWVTMEVvQkpZNHVWaW4ydjVrVDcyQXJZTTJLZXNaY0Zzbkp6?=
 =?utf-8?B?dVJ2aU9VOEpqME9qRnFpbVArTjFqblJGVUo2NE5vYUNGSVdYT1FZbGpkUXNY?=
 =?utf-8?B?aExEVHZkRm5wSGhOd053alFpdi9TZW8vMlpZOVBvOFV4Yy9oNFZwVkdlVXBu?=
 =?utf-8?B?NE5tQWY1d3IwMEJwWXU4UTJtcytaMWVRNUp2UjZ2Y25UeEFZTUJkRHFZaWZD?=
 =?utf-8?B?YjJKSXZyOGJHdVlKa0pKdjJ1REVsWjBxUUt1RVozS2k1MUx4UnlyWWhhTUU2?=
 =?utf-8?B?aFQwRzIxbUN3OWJWUWJxK1kyUVl6bkw4QjJRSmUyN2x1dW1IVjhPdHhiZjcz?=
 =?utf-8?B?T3hCM2kyWHlYK1JxazBUbUNZdEhZWERnM0MrUUh6SThhYW9nMVNjTGRoUVpH?=
 =?utf-8?B?eXFCdjQ5dE55SUJXb1krNk96b2EzVWhJT2lVaXpHM3NxeWwrY1hzVldlc3lG?=
 =?utf-8?B?MlJ5YkdoRHpUdUhrUFhBVjJuNXVkZURjSk8rWStKRkNROWVtUHE2SjFHSmJy?=
 =?utf-8?B?bEpjcm5JNGpIUTZkK2ZFSGhEZ0djOHdTdU9GL3c3aUdTS2lBYkE5R0RSeEMw?=
 =?utf-8?B?VzVzVEZLNjZNbTAxSGVvcHhQS20raVlZakI4N2hZc2VWbUlPT2k5MHZRTlE5?=
 =?utf-8?B?bHd1WHdBdDAwM0VQTW95a2dma0RPSGZTeXBWcHo1TWVvdkFObSttWVZqWHVo?=
 =?utf-8?B?eENjNzlEbUM5UENSNkNZRVhUUXA1T1lHdS9nd0ZsdmNmcWdMR3pSNHVvZ1o5?=
 =?utf-8?B?WUJkTzV4QlhIVy9FTkRDVlUvVFdjRFJIYmJJK213cDJDS0tZaWUzL3RiTzR6?=
 =?utf-8?B?aU9vQ0hTYWNPdG1zK3VnMk1NZUgvQWFzSTVnN3RiMnJRaExHa3ZqclIwWUVL?=
 =?utf-8?B?ZDFrdlk4VFN2cVdkNXlBTEl6VFJDUjZ5Q2RNWndYNDhBcm4wczRhS3ltNm1F?=
 =?utf-8?B?ZTh5RHV0RmZ5ZnQvSDREdHJtUDkvb1o3RzN2bFhvUnF1SWhtOFpaeEw3cHpK?=
 =?utf-8?B?WlhVTkRUQm5nTHY0bXFlZDBIclllWTFGTlNrNkJzalNOWVB2L1p2emRjVFFt?=
 =?utf-8?B?S2lpSTlGUythdndQSVFCRkdFRkpSc1Z5ZzFkSXZnYk9BTGhVU0hkWjZxeEY3?=
 =?utf-8?B?ZG0rSzZYZDB4Ykc0UmpzRzBZSkpVWDhoK2ZxM3YwMXd1SVhRN1o4WE1JTnRw?=
 =?utf-8?B?NXlwZE1uL0FWQkR1SVNhMzFzbGQ3SEdXaHk2ajZKU1Ezbm1QdktGKzlOVkdH?=
 =?utf-8?B?U3hsNnRYSU5VU01VbzMzWWJ2QUJNMzRaOVgrSjBFV285ZDhCYStZY01vcHV5?=
 =?utf-8?B?ZjA5R2Zyakt4Q0NheWRHSmgxQzNkcDRTKzJDUHVQZDNCQk41Z1p2WUpGQVBB?=
 =?utf-8?B?NUNkMGZhWnQ3cXpONThEOVpxejk2dW8ySnZER3BhY0FSNFhNWDY4aU9aZWRt?=
 =?utf-8?B?cml4VldDVTUzNG9FUUNRRGJ0QVU4R3RGc0JhSzBvTjZaT1BvdTMwQWE4YVVn?=
 =?utf-8?B?R004NzRzSDlLWW4rMjduSUlxUHZLWmNyaTcvYjUyRE9NbEdCbnEyMUVFUHNt?=
 =?utf-8?Q?yxkSZw7/enIpcwUGx4tFV2M=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b52e89ce-8384-40e1-7ddf-08d9e00f14fd
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5005.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2022 14:29:23.3892 (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: HwsksadOL7LpgYelzZK2wC+yHoCMjZN8AXPUAZ2M+tClHJQfkph7muVpIDSbab8W34uLqzZRWE1Ub2Wa+1v8yA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4622
X-OriginatorOrg: intel.com
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On 1/25/2022 1:06 PM, Ori Kam wrote:
> Hi Ferruh,
> 
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Subject: Re: [RFC 1/3] ethdev: support GRE optional fields
>>
>> On 1/25/2022 9:49 AM, Sean Zhang (Networking SW) wrote:
>>> Hi,
>>>
>>>> -----Original Message-----
>>>> From: Ori Kam <orika@nvidia.com>
>>>> Sent: Wednesday, January 19, 2022 6:57 PM
>>>> To: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
>>>> Sean Zhang (Networking SW) <xiazhang@nvidia.com>; Matan Azrad
>>>> <matan@nvidia.com>; Ferruh Yigit <ferruh.yigit@intel.com>
>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org
>>>> Subject: RE: [RFC 1/3] ethdev: support GRE optional fields
>>>>
>>>> Hi,
>>>>
>>>>> -----Original Message-----
>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> Subject: Re: [RFC 1/3] ethdev: support GRE optional fields
>>>>>
>>>>> 19/01/2022 10:53, Ferruh Yigit:
>>>>>> On 12/30/2021 3:08 AM, Sean Zhang wrote:
>>>>>>> --- a/lib/ethdev/rte_flow.h
>>>>>>> +++ b/lib/ethdev/rte_flow.h
>>>>>>>     /**
>>>>>>> + * RTE_FLOW_ITEM_TYPE_GRE_OPTION.
>>>>>>> + *
>>>>>>> + * Matches GRE optional fields in header.
>>>>>>> + */
>>>>>>> +struct rte_gre_hdr_option {
>>>>>>> +	rte_be16_t checksum;
>>>>>>> +	rte_be32_t key;
>>>>>>> +	rte_be32_t sequence;
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> Hi Ori, Andrew,
>>>>>>
>>>>>> The decision was to have protocol structs in the net library and
>>>>>> flow structs use from there, wasn't it?
>>>>>> (Btw, a deprecation notice is still pending to clear some existing
>>>>>> ones)
>>>>>>
>>>>>> So for the GRE optional fields, what about having a struct in the
>>>> 'rte_gre.h'?
>>>>>> (Also perhaps an GRE extended protocol header can be defined
>>>>>> combining 'rte_gre_hdr' and optional fields struct.) Later flow API
>>>>>> struct can embed that struct.
>>>>>
>>>>> +1 for using librte_net.
>>>>> This addition in rte_flow looks to be a mistake.
>>>>> Please fix the next version.
>>>>>
>>>> Nice idea,
>>>> but my main concern is that the header should have the header is defined.
>>>> Since some of the fields are optional this will look something like this:
>>>> gre_hdr_option_checksum {
>>>> rte_be_16_t checksum;
>>>> }
>>>>
>>>> gre_hdr_option_key {
>>>> rte_be_32_t key;
>>>> }
>>>>
>>>> gre_hdr_option_ sequence {
>>>> rte_be_32_t sequence;
>>>> }
>>>>
>>>> I don't want to have so many rte_flow_items, Has more and more protocols
>>>> have optional data it doesn't make sense to create the item for each.
>>>>
>>>> If I'm looking at it from an ideal place, I would like that the optional fields will
>>>> be part of the original item.
>>>> For example in test pmd I would like to write:
>>>> Eth / ipv4 / udp / gre flags is key & checksum checksum is yyy key is xxx / end
>>>> And not Eth / ipv4 / udp / gre flags is key & checksum / gre_option checksum
>>>> is yyy key is xxx / end This means that the structure will look like this:
>>>> struct rte_flow_item_gre {
>>>> 	union {
>>>> 		struct {
>>>> 			/**
>>>> 		 	* Checksum (1b), reserved 0 (12b), version (3b).
>>>> 			 * Refer to RFC 2784.
>>>> 			 */
>>>> 			rte_be16_t c_rsvd0_ver;
>>>> 			rte_be16_t protocol; /**< Protocol type. */
>>>> 		}
>>>> 		struct rte_gre_hdr hdr
>>>> 	}
>>>> 	rte_be_16_t checksum;
>>>> 	rte_be_32_t key;
>>>> 	rte_be_32_t sequence;
>>>> };
>>>> The main issue with this is that it breaks ABI, Maybe to solve this we can
>>>> create a new structure gre_ext?
>>>>
>>>> In any way I think we should think how we allow adding members to
>>>> structures without ABI breakage.
>>>>
>>>> Best,
>>>> Ori
>>>
>>> Thanks for the comments and suggestion.
>>> So the acceptable solution is to have new structs define in rte_gre.h?
>>> struct gre_hdr_opt_checksum {
>>> 	rte_be_16_t checksum;
>>> }
>>>
>>> struct gre_hdr_opt_key {
>>> 	rte_be_32_t key;
>>> }
>>>
>>> struct gre_hdr_opt_ sequence {
>>> 	rte_be_32_t sequence;
>>> }
>>>
>>> And to add new struct gre_ext defined in rte_flow.h:
>>> struct gre_ext {
>>> 	struct rte_gre_hdr hdr;
>>> 	struct gre_hdr_opt_checkum checksum;
>>> 	struct rte_hdr_opt_key key;
>>> 	struct rte_hdr_opt_seq seq;
>>> };
>>>
>>> And we use struct gre_ext for this new added flow item gre_option.
>>>
>>
>> What about having a struct for 'options' and use in in flow item for options,
>> like:
>>
>> struct gre_hdr_opt {
>>     struct gre_hdr_opt_checkum checksum;
>>     struct rte_hdr_opt_key key;
>>     struct rte_hdr_opt_seq seq;
>> }
>>
>> struct gre_hdr_ext {
>>     struct rte_gre_hdr hdr;
>>     struct gre_hdr_opt;
>> }
>>
>> struct rte_flow_item_gre_opt {
>>     struct gre_hdr_opt hdr;
>> }
> 
> Fom my understanding the header should reflect structures
> as they appear in the spec.
> 
> If we look at the spec, from my understanding each of those items is stand-alone.
> It is possible to have just key or key and seq or any other combination.
> So the struct you suggested is not valid struct in gre header.
> 

If it is not valid header representation, please forget about it.

But this means initially suggested 'struct gre_ext' is wrong, right?

So should 'rte_flow_item_gre_opt' use separate structs, like:

struct rte_flow_item_gre_opt {
   struct gre_hdr_opt_checkum checksum;
   struct rte_hdr_opt_key key;
   struct rte_hdr_opt_seq seq;
}


> If you are O.K with adding such a struct to the gre file I will also be O.K with it.
> 
> Best,
> Ori
>>
>>> Correct me if my understanding is not right.
>>>
>>> Thanks,
>>> Sean
>>>
>>>
>