From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by dpdk.org (Postfix) with ESMTP id 77BEE1396 for ; Wed, 15 Mar 2017 11:53:53 +0100 (CET) Received: by mail-wr0-f172.google.com with SMTP id l37so8281223wrc.1 for ; Wed, 15 Mar 2017 03:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CYsVcDS1zc8DJlLhAQaIwyMoW6yoU9wvYcHAILN79bc=; b=KxD6CW4zVXsdH9UOvlxsnAqNM1xBNbOdoBMZYwPHY0OgYdrsRnBFYtwWqQL5QcDGHy ERM7iV3nPK/kGcCAk1tfOmve5NKmbMQgPJJiB+src6ZOrUdcrBDQ3TnTM0fIXWJ3INHW 9JoaspFjxCo5lae+vpwcZSJI43Jr3DIXhJK4acPt5sweuEOibTuhiEwcJMYHPsbzB6Sr bQvakVtw5hVQGEpIb4JJzSo2Pe/buq4DqM687G23xMs+MJIKfpFQIrFYKLWOhn9EALTO S4hdFf5bAtzbIQ3BngSPhQeeP0M4CMrQZ69JybcAVHrEu4fRlq764BihOPImRLgcmFEJ UYlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CYsVcDS1zc8DJlLhAQaIwyMoW6yoU9wvYcHAILN79bc=; b=hP+2v6yfq9D2KNUkR0XeFoSCS4OQ6gAbQasNfsIgQdFLDnuVImWWEndrTQzajFOv/D DuhuNR4PZMrTCfooSR71Gzz6dKfLZIEqn33JBnPbrH4VQ2eGJSmMqrz3fB/mGjTqv5pp HdXWH06kDwbPtdjZRRGWh/QU9fyQU9fepcr98gAuR6CZKpUffGyVFdqRDdHaMCQIynnx KQRgYEhbwJKMYjXl1Res6iShNfnnKh06Lq8IvHwaV9xW7ZGF8Irm3Nglzjhdt7wzRzmw 4W+KvR2IPay3V6zNKBIMGnoRjyITZShkBTr+jYRXkKdwhU0co1ebItiLgOy7T61kAOva yr0w== X-Gm-Message-State: AFeK/H3NzRj7fREZ+X98Z1pmVI49xeD+5xXGPUC0Ls+Hi+rioIP0+WpTDTCxFc+3DGa9QjmO X-Received: by 10.223.170.3 with SMTP id p3mr2672492wrd.100.1489575233216; Wed, 15 Mar 2017 03:53:53 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id o63sm3267483wmo.30.2017.03.15.03.53.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 03:53:52 -0700 (PDT) Date: Wed, 15 Mar 2017 11:53:44 +0100 From: Adrien Mazarguil To: "Lu, Wenzhuo" Cc: Le Scouarnec Nicolas , "dev@dpdk.org" Message-ID: <20170315105344.GJ3790@6wind.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> <6A0DE07E22DDAD4C9103DF62FEBC09093B56EDD7@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B56EDD7@shsmsx102.ccr.corp.intel.com> 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 10:53:53 -0000 Hi Wenzhuo, On Mon, Mar 13, 2017 at 02:33:52AM +0000, Lu, Wenzhuo wrote: [...] > > > 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 :) > > > > 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 PMD and > > can be const, static or dynamic. > > > > However I really think the best approach would be to report the most relevant > > (first) error only. > It's good if we can find which one is the most relevant. It sounds like introducing 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 director. So maybe the first one is the only option here :) OK, I also think it's better that way. > > > 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 following the IEEE > > spec to define the structures so we will not miss anything. But why not do some > > optimization. For VLAN the tpid must be 0x8100, for IPv4, the ethertype 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 things simpler. > > > > > > Adrien, as you're the maintainer of rte_flow, any thought about these ideas? > > Thanks. > > > > Basically I think we must give users the flexibility to provide nonstandard 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 duplicate of vlan type. You're right about the usefulness of specifying TPID in most cases, however because the pattern is not arranged in the same order as the packet, users 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 us for a long time (Nicolas' feedback gave me this impression.) I'm now convinced modifying rte_flow_eth_vlan could make this much clearer and intend to update the API accordingly. So far affected PMDs would be i40e, ixgbe, mlx4, mlx5, sfc and tap. I'll reply to the other thread about that. -- Adrien Mazarguil 6WIND