From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) by dpdk.org (Postfix) with ESMTP id 8A65D1075 for ; Thu, 16 Mar 2017 18:01:49 +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=PyiRV14xmWe8O+/0XUuk4vzNz3Z7YbAcc4d3Os8Zejg=; b=jkdGJ0/HcSanopg7gir3kvsxKccdDjEe4dckmOoIl6bRwS639BHIRN8aqcD57isCW4q9cquLXJ7swmHeDoj4WJmAQYLT9STI9thj+cken6sq3Uhi6i1YtD2pOPQpvSeL/C3tIJo1uDKJDu1uQPBPFv2Fl7BIhaJoMHv2PrtoqeM= Received: from CY4PR02MB2552.namprd02.prod.outlook.com (10.173.41.11) by CY4PR02MB2549.namprd02.prod.outlook.com (10.173.41.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 16 Mar 2017 17:01:43 +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; Thu, 16 Mar 2017 17:01:43 +0000 From: Le Scouarnec Nicolas To: Adrien Mazarguil CC: "Lu, Wenzhuo" , "dev@dpdk.org" Thread-Topic: FW: Issues with ixgbe and rte_flow Thread-Index: AQHSly9VSVacWJmR5EC8Uqr0D2ovhaGKMkmAgAB1ebWAAG7JgIAAB/ekgACkyACAAemsAIAATHQAgAQcuACAA7BTAIAANlJWgAAfx4CAABxvSA== Date: Thu, 16 Mar 2017 17:01:43 +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> , <20170315160153.GL3790@6wind.com> In-Reply-To: <20170315160153.GL3790@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=technicolor.com; x-originating-ip: [165.225.76.70] x-ms-office365-filtering-correlation-id: 95cb831a-444b-4c95-55a4-08d46c8e1f56 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR02MB2549; x-microsoft-exchange-diagnostics: 1; CY4PR02MB2549; 7:je+dhIuIfQ4HGBxNMMAwl252dDBM5x8SwCNpXjU4To8YcDozG+yaMNWXTsmkbMGy8lsncI5jOtr8/Vj/ZCKgUCdMec04lC8MF+Nu3Ex/u4vPZR/lWvoVizmA2ySe0RlBs/JWr8opJZPZEIV7DfalzqnFqpRVbU8CIekyBgyCzX4vtLkGclmAkKs9qsgoUlQQwyXNsrBd9ls6zEhvtEcQSEob2uJyCV+N31yq8PX5RpZo234l+cSdSrzkoIaeRL03FeDbgOruwCgxioJ07WFF/NlXesvlVPvoOIHcRn+meh6JGuXQ6BWFSNg7Wq6AZfxKfzJFKRB6aHlxjcXV7EePwA==; 20:DIHFsOuyg/FQJ98Xd4JERwJD5hOba8IwhNztYEllUPvfUiptX4IT3GJx+6aCqTWTowxwPjTnHK7Ox3UiIrPdQFKIAb+0s/o3kokpAVrESX1cCc+Ma4xpmZOiuviGY28K6fRZsN/BGLI4xallIGKVBrV2EFRKzguJ0Y+Nyo1Covs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(6072148); SRVR:CY4PR02MB2549; BCL:0; PCL:0; RULEID:; SRVR:CY4PR02MB2549; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(43544003)(24454002)(2900100001)(25786008)(55016002)(74316002)(7696004)(54906002)(99286003)(4326008)(93886004)(8936002)(110136004)(3846002)(6116002)(3660700001)(102836003)(2906002)(6246003)(8676002)(33656002)(38730400002)(50986999)(6606003)(122556002)(9686003)(189998001)(6916009)(53936002)(6506006)(229853002)(3280700002)(66066001)(6436002)(77096006)(19627405001)(81166006)(5660300001)(54356999)(86362001)(2950100002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR02MB2549; H:CY4PR02MB2552.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: technicolor.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 17:01:43.2052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 036da35c-ba43-4e4a-9bff-72ec0f508621 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2549 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Thu, 16 Mar 2017 17:01:50 -0000 Hi Adrien, >On Wed, Mar 15, 2017 at 02:29:44PM +0000, Le Scouarnec Nicolas wrote: >> Overall, as a user, I feel one difficulty/complexity in using the API co= mes from the need to >> specify both the stack of protocol (in type) and at each level the "next= protocol type" of the header (in spec). >> >> Then, the PMD has to check that what I specified as the "next protocol t= ype" is coherent with the protocol >> stack before setting up the filters. Basically, for a valid filter, I sh= ould always have >> rte_flow_item[1].type =3D=3D rte_flow_item[0].spec.type, and rte_flow_i= tem[2].type =3D=3D rte_flow_item[1].spec.{type,next_protocol} >> (except for L2.5 protocol as I experienced, which makes thinks confusin= g). Couldn't the API leverage this fact so that I don't >> need to specify the ether_type, TPID, next_protocol_id, ... which are re= dundant with rte_flow_item.type ? >Just to be clear, as a user you don't *need* to provide them, however the >API certainly does not prevent you to do so. Only masked fields are >relevant, and the default item masks (rte_flow_item_*_mask) do not include >protocol types because as you're pointing out, that would indeed be a pain= . >Is the documentation not clear enough regarding this? >(see "8.2.3 Pattern item") To me it wasn't clear that the PMD/DPDK would take care of "type" fields in= network headers for me, hence, I tried to set them correctly (and got it wrong for ether_type/tpid)= -- I feared that filtering on VLAN tci without restricting to VLAN packets (setting ether_type) would be undefined= behavior. I just check ixgbe_flow and as you said it just ignores the types and relies on the stack so my previou= s comment and suggestion was wrong. The documentation is very clear on struct and how to use them, but a few co= mmon examples (in C) would have been useful to me; for example I could have noticed that the example never set the ether_type = & cie. testpmd is hard to read as an example. > I think adding custom types would be more complicated than the current > approach of leaving the payload type field unspecified or set it to some > custom value that PMDs may or may not accept depending on their > capabilities. You're right. My comment was based on the misconception that it was mandato= ry to correctly specify ether_types / next_protocol_id / ... Best regards.