From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0125.outbound.protection.outlook.com [104.47.40.125]) by dpdk.org (Postfix) with ESMTP id 8954028F3 for ; Wed, 15 Mar 2017 15:29:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technicolor.onmicrosoft.com; s=selector1-technicolor-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RbEM0dHBgW6YhdgJyFJ3oobyrNx7yfkmaUVwK1h4okc=; b=jVc5e+9McPKhQOJyaeRpNU2jUU2i/znN9KB8PMScqpye6eL8Lk80S8+89qtnmgXT81HF/tCOLJ7Nlgs6eogFFanos9mmV0QpZsQihIyRSVzfDoxsMmz6gzM8mULjgiDCiLqfRsQb07RgjMHlNt6lhd2+f300hGrmiDKzcKV4xgU= Received: from CY4PR02MB2552.namprd02.prod.outlook.com (10.173.41.11) by CY4PR02MB2550.namprd02.prod.outlook.com (10.173.41.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 15 Mar 2017 14:29:44 +0000 Received: from CY4PR02MB2552.namprd02.prod.outlook.com ([10.173.41.11]) by CY4PR02MB2552.namprd02.prod.outlook.com ([10.173.41.11]) with mapi id 15.01.0947.020; Wed, 15 Mar 2017 14:29:44 +0000 From: Le Scouarnec Nicolas To: Adrien Mazarguil , "Lu, Wenzhuo" CC: "dev@dpdk.org" Thread-Topic: FW: Issues with ixgbe and rte_flow Thread-Index: AQHSly9VSVacWJmR5EC8Uqr0D2ovhaGKMkmAgAB1ebWAAG7JgIAAB/ekgACkyACAAemsAIAATHQAgAQcuACAA7BTAIAANlJW Date: Wed, 15 Mar 2017 14:29:44 +0000 Message-ID: References: <6A0DE07E22DDAD4C9103DF62FEBC09093B56D514@shsmsx102.ccr.corp.intel.com> <20170308154131.GQ3790@6wind.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B56DC90@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B56E40A@shsmsx102.ccr.corp.intel.com> <20170310114602.GZ3790@6wind.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B56EDD7@shsmsx102.ccr.corp.intel.com>, <20170315105344.GJ3790@6wind.com> In-Reply-To: <20170315105344.GJ3790@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=technicolor.com; x-originating-ip: [165.225.76.81] x-ms-office365-filtering-correlation-id: 00dcd7e1-a28a-49f3-6953-08d46bafb9f9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR02MB2550; x-microsoft-exchange-diagnostics: 1; CY4PR02MB2550; 7:0QMkWD9XzMF0u4QxKlG+7UCkZqkDKnYapQ8/DFi0cOHq9PmTkhxr0VR5CRtW2tLdQkPswZjkYCQ1TQo3hlU85iGnIakxW96GAPI/t+op739bqDqu5uSSOxPl4R8iu8mlh8j1HVH0kdi/siBUhExbnu+glN9jnUAtwcYkDg27+MWW+9Q8uyMJ3rm8G9//cSmym4AbobgwRz+RFMmghvhSMvYQIGkPk3WSWcI893qVi1WnPmEj0MXY5qN4KppJQ/owu6rGbnCuCaV3X4Iv9+BjwDY5a83dcvDfqpTba/LeDpz3G29GF+NYe/EpdnwB2zBuW/HnOs08jdksWC5at81aVg==; 20:4oaafrNWXUEY8yGIYOcTDxBAsd1N4PBXI5o6warK23vgczPsCKXwnPohi4+j1f2q4NGxQljFfD8z8XA77hLwtKk6g6rTPq3BsoT+VsZFM2u8b0fxn2+kEucnF7tAeaJkdALGizRd1c1s88gBakRpIJDfgfZ1bOP56xp1V9AsFn4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR02MB2550; BCL:0; PCL:0; RULEID:; SRVR:CY4PR02MB2550; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39860400002)(39410400002)(39450400003)(81166006)(2906002)(3660700001)(6116002)(53936002)(2900100001)(8936002)(229853002)(7736002)(77096006)(5660300001)(86362001)(7696004)(55016002)(3280700002)(305945005)(74316002)(99286003)(9686003)(2950100002)(6506006)(6246003)(102836003)(4326008)(38730400002)(25786008)(3846002)(6436002)(8676002)(189998001)(66066001)(122556002)(54356999)(76176999)(50986999)(93886004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR02MB2550; H:CY4PR02MB2552.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: technicolor.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 14:29:44.8099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 036da35c-ba43-4e4a-9bff-72ec0f508621 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2550 Subject: Re: [dpdk-dev] FW: Issues with ixgbe and rte_flow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:29:47 -0000 Hi Adrien,=20 > > > > And about the tpid, ethertype. I have a thought that why we need it= as it's > > > duplicate with the item type. I think the initial design is just foll= owing the IEEE > > > spec to define the structures so we will not miss anything. But why n= ot do some > > > optimization. For VLAN the tpid must be 0x8100, for IPv4, the etherty= pe must be > > > 0x0800. So why bothering let APP provide them and driver check them? = Seems > > > we can just remove these fields from the structures, it can make thin= gs simpler. > > > > > > > > Adrien, as you're the maintainer of rte_flow, any thought about the= se ideas? > > > Thanks. > > > > > Basically I think we must give users the flexibility to provide nonst= andard TPIDs > > > as well (there's apparently already a few), so we can't just leave it= out entirely. > > Agree that TPID or something else like that can be changed. But my poin= t is when > > using the filter, users don't care about the value of TPID, they only c= are about the > > vlan packets should be filtered. The type already tells the driver that= .=20 > > No matter we use the well-known or self-defined TPID, it's duplicate o= f vlan type. > You're right about the usefulness of specifying TPID in most cases, howev= er > because the pattern is not arranged in the same order as the packet, user= s > do not know what EtherType they should specify inside struct > rte_flow_item_eth if they want to provide one, which I think will haunt u= s > for a long time (Nicolas' feedback gave me this impression.) > I 'm now convinced modifying rte_flow_eth_vlan could make this much clear= er > and intend to update the API accordingly. So far affected PMDs would be > i40e, ixgbe, mlx4, mlx5, sfc and tap. Overall, as a user, I feel one difficulty/complexity in using the API comes= from the need to specify both the stack of protocol (in type) and at each level the "next pr= otocol type" of the header (in spec). Then, the PMD has to check that what I specified as the "next protocol type= " is coherent with the protocol stack before setting up the filters. Basically, for a valid filter, I shoul= d always have rte_flow_item[1].type =3D=3D rte_flow_item[0].spec.type, and rte_flow_item= [2].type =3D=3D rte_flow_item[1].spec.{type,next_protocol} (except for L2.5 protocol as I experienced, which makes thinks confusing).= Couldn't the API leverage this fact so that I don't need to specify the ether_type, TPID, next_protocol_id, ... which are redun= dant with rte_flow_item.type ? Changing this wouldn't reduce the expressiveness of the filter, as long as = there is a rte_flow_item type CustomL3OverEthernet where you can specify the ether_type expected at L2, a= nd a CustomL4OverIP where you can specifiy the next protocol id at L3 (IP), and if needed to su= pport custom TPID, CustomVLANOverEthernet. These would be used by a small minority of users, thus keeping the API simp= ler for users of most common protocols.=20 Best regards, --=20 Nicolas Le Scouarnec=