From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 8E58569D8 for ; Mon, 13 Mar 2017 03:33:57 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 12 Mar 2017 19:33:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,156,1486454400"; d="scan'208";a="943539350" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 12 Mar 2017 19:33:56 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 12 Mar 2017 19:33:56 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0248.002; Mon, 13 Mar 2017 10:33:53 +0800 From: "Lu, Wenzhuo" To: Adrien Mazarguil CC: Le Scouarnec Nicolas , "dev@dpdk.org" Thread-Topic: FW: Issues with ixgbe and rte_flow Thread-Index: AQHSly9VSVacWJmR5EC8Uqr0D2ovhaGKMkmAgAB1ebX//+itgIAAChGAgAElwrCAAewl4P//xucAgAScZrA= Date: Mon, 13 Mar 2017 02:33:52 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09093B56EDD7@shsmsx102.ccr.corp.intel.com> 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> In-Reply-To: <20170310114602.GZ3790@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 13 Mar 2017 02:33:58 -0000 Hi Adrien, > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Friday, March 10, 2017 7:46 PM > To: Lu, Wenzhuo > Cc: Le Scouarnec Nicolas; dev@dpdk.org > Subject: Re: FW: Issues with ixgbe and rte_flow >=20 > Hi, >=20 > On Fri, Mar 10, 2017 at 07:12:24AM +0000, Lu, Wenzhuo wrote: > > Some replies in line. > > Send it again with off the users@dpdk.org. Seems I cannot send the mail > successfully with it. >=20 > I'm removing everyone from the CC list and putting back dev@dpdk.org then= , > let's not break everyone's DPDK-related spam filters anymore. >=20 > This is separate from the VLAN item issue mentioned in the same thread, I= think > this one is related to the ixgbe implementation (sorry Wenzhuo :) More be= low. No need to sorry :) It's my bad. Forgot to mention that this rte_flow_error= problem is related to the PMD implementation.=20 More or less it caused by the HW. Although we have this generic filter, but= in HW there're still several different filters, PMD has to check them one = by one. >=20 > [...] > > Hi Le Scouarnec, > > > > > -----Original Message----- > > > From: Le Scouarnec Nicolas > [...] > > > I also have a side comment which might be more related to the > > > general rte_flow API than to the specific implementation in ixgbe. I > > > don't know if it is specific to ixgbe's implementation but, as a > > > user, the rte_flow_error returned was not very useful for it does > > > return the error of the last tried filter-type (L2 tunnel in ixgbe), > > > and not the error of the filter-type that my setup should use (flow d= irector). >=20 > The helpfulness of error messages is entirely a PMD's responsibility sinc= e they > are not hard-coded into the API. rte_flow is deliberately not aware of th= e > various underlying APIs used by PMDs to implement flow rules. >=20 > In this case, assuming your rule could only work through flow director, t= he PMD > should have saved and reported the error encountered with that filter typ= e > (either by saving it before attempting others, or recognizing that this r= ule > wouldn't work with others and not attempt them). >=20 > > > I had to change the order in which filters are tried in ixgbe code > > > to get a more useful error message. As NICs can have several > > > filter-types, It would be be useful to the user if > > > rte_flow_validate/create could return the errors for all filter > > > types tried although that would require to change the rte_flow API > > > and returning an array of rte_flow_error and not a single struct. >=20 > rte_flow_error is a compromise to provide a detailed explanation about th= e > errno value returned by a function, which describes exactly one error (id= eally the > first error encountered). >=20 > While returning an array could provide additional details about subsequen= t > errors, I think it would needlessly complicate the API and make it slower= without > much benefit, given that most (if not all) PMD functions return as soon a= s one > error is detected and also for performance reasons. >=20 > > It's a good suggestion. I remember we have some discussion about how > > to feedback the error to the APP. I think the reason why we don't make > > it too complex because it's the first step of generic API. Now we see > > some feedback from the users, we can keep optimizing it :) >=20 > Right. Note ixgbe could append several messages to rte_flow_error.message= if > necessary as in such cases. Storage for the message is provided by the PM= D and > can be const, static or dynamic. >=20 > However I really think the best approach would be to report the most rele= vant > (first) error only. It's good if we can find which one is the most relevant. It sounds like int= roducing an AI to judge which kind of the filter is the best choice. And considering some filters may have overlap, like n-tuple and flow direct= or. So maybe the first one is the only option here :) >=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 followin= g the IEEE > spec to define the structures so we will not miss anything. But why not d= o some > optimization. For VLAN the tpid must be 0x8100, for IPv4, the ethertype m= ust be > 0x0800. So why bothering let APP provide them and driver check them? Seem= s > we can just remove these fields from the structures, it can make things s= impler. > > > > Adrien, as you're the maintainer of rte_flow, any thought about these i= deas? > Thanks. >=20 > Basically I think we must give users the flexibility to provide nonstanda= rd 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 point is= when using the filter, users don't care about the value of TPID, they only= care about the vlan packets should be filtered. The type already tells the= driver that. No matter we use the well-known or self-defined TPID, it's du= plicate of vlan type. >=20 > It's really about whether we want to make the inner type part of the VLAN= item > with TPID outside or keep it as-is. Anyway please reply to my previous me= ssage > if you want to talk about that and let's fork this one to discuss the > rte_flow_error issue. >=20 > -- > Adrien Mazarguil > 6WIND