From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [RFC] Generic flow director/filtering/classification API Date: Thu, 21 Jul 2016 21:20:23 +0200 Message-ID: <20160721192023.GU7621@6wind.com> References: <20160705181646.GO7621@6wind.com> <20160711104141.GA10172@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, Thomas Monjalon , Helin Zhang , Jingjing Wu , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , Wenzhuo Lu , Jan Medala , John Daley , Jing Chen , Konstantin Ananyev , Matej Vido , Alejandro Lucero , Sony Chacko , Pablo de Lara , Olga Shern To: Jerin Jacob Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id BD5C9593A for ; Thu, 21 Jul 2016 21:20:29 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id f65so32393419wmi.0 for ; Thu, 21 Jul 2016 12:20:29 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20160711104141.GA10172@localhost.localdomain> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Jerin, Sorry, looks like I missed your reply. Please see below. On Mon, Jul 11, 2016 at 04:11:43PM +0530, Jerin Jacob wrote: > On Tue, Jul 05, 2016 at 08:16:46PM +0200, Adrien Mazarguil wrote: > > Hi Adrien, > > Overall this proposal looks very good. I could easily map to the > classification hardware engines I am familiar with. Great, thanks. > > Priorities > > ~~~~~~~~~~ > > > > A priority can be assigned to a matching pattern. > > > > The default priority level is 0 and is also the highest. Support for more > > than a single priority level in hardware is not guaranteed. > > > > If a packet is matched by several filters at a given priority level, the > > outcome is undefined. It can take any path and can even be duplicated. > > In some cases fatal unrecoverable error too Right, do you think I need to elaborate regarding unrecoverable errors? How much unrecoverable by the way? Like not being able to receive any more packets? > > Matching pattern items for packet data must be naturally stacked (ordered > > from lowest to highest protocol layer), as in the following examples: > > > > +--------------+ > > | TCPv4 as L4 | > > +===+==========+ > > | 0 | Ethernet | > > +---+----------+ > > | 1 | IPv4 | > > +---+----------+ > > | 2 | TCP | > > +---+----------+ > > > > +----------------+ > > | TCPv6 in VXLAN | > > +===+============+ > > | 0 | Ethernet | > > +---+------------+ > > | 1 | IPv4 | > > +---+------------+ > > | 2 | UDP | > > +---+------------+ > > | 3 | VXLAN | > > +---+------------+ > > | 4 | Ethernet | > > +---+------------+ > > | 5 | IPv6 | > > +---+------------+ > > How about enumerating as "Inner-IPV6" flow type to avoid any confusion. Though spec > can be same for both IPv6 and Inner-IPV6. I'm not sure, if we have a more than two encapsulated IPv6 headers, knowing that one of them is "inner" is not really useful. This is why I choose to enforce the stack ordering instead, I think it makes more sense. > > | 6 | TCP | > > +---+------------+ > > > > +-----------------------------+ > > | TCPv4 as L4 with meta items | > > +===+=========================+ > > | 0 | VOID | > > +---+-------------------------+ > > | 1 | Ethernet | > > +---+-------------------------+ > > | 2 | VOID | > > +---+-------------------------+ > > | 3 | IPv4 | > > +---+-------------------------+ > > | 4 | TCP | > > +---+-------------------------+ > > | 5 | VOID | > > +---+-------------------------+ > > | 6 | VOID | > > +---+-------------------------+ > > > > The above example shows how meta items do not affect packet data matching > > items, as long as those remain stacked properly. The resulting matching > > pattern is identical to "TCPv4 as L4". > > > > +----------------+ > > | UDPv6 anywhere | > > +===+============+ > > | 0 | IPv6 | > > +---+------------+ > > | 1 | UDP | > > +---+------------+ > > > > If supported by the PMD, omitting one or several protocol layers at the > > bottom of the stack as in the above example (missing an Ethernet > > specification) enables hardware to look anywhere in packets. > > It would be good if the common code can give it as Ethernet, IPV6, UDP > to PMD(to avoid common code duplication across PMDs) I left this mostly at PMD's discretion for now. Applications must provide explicit rules if they need a consistent behavior. PMDs may not support this at all, I've just documented what applications should expect when attempting this kind of pattern. > > It is unspecified whether the payload of supported encapsulations > > (e.g. VXLAN inner packet) is matched by such a pattern, which may apply to > > inner, outer or both packets. > > a separate flow type enumeration may fix that problem. like "Inner-IPV6" > mentioned above. Not sure about that, for the same reason as above. Which "inner" level would be matched by such a pattern? Note that it could have started with VXLAN followed by ETH and then IPv6 if the application cared. This is basically the ability to remain vague about a rule. I didn't want to forbid it outright because I'm sure there are possible use cases: - PMD validation and debugging. - Rough filtering according to protocols a packet might contain somewhere (think of the network admins who cannot stand anything other than packets addressed to TCP port 80). > > +---------------------+ > > | Invalid, missing L3 | > > +===+=================+ > > | 0 | Ethernet | > > +---+-----------------+ > > | 1 | UDP | > > +---+-----------------+ > > > > The above pattern is invalid due to a missing L3 specification between L2 > > and L4. It is only allowed at the bottom and at the top of the stack. > > > > > ``SIGNATURE`` > > ^^^^^^^^^^^^^ > > > > Requests hash-based signature dispatching for this rule. > > > > Considering this is a global setting on devices that support it, all > > subsequent filter rules may have to be created with it as well. > > Can you describe the use case for this and how its different from > existing rte_eth devel RSS settings. Erm, well, this is my attempt at reimplementing RTE_FDIR_MODE_SIGNATURE without being too sure of what it actually /does/. So far this definition hasn't raised any eyebrows. By default this API works like RTE_FDIR_MODE_PERFECT, where protocol headers are matched with specific patterns. I understand this signature mode as not giving the same results (a packet that would have matched a pattern in perfect mode may not match in signature mode and vice versa) as there is some signature involved at some point for some reason. OK, I really have no idea. I'm confident it is not related to RSS though. Perhaps people more familiar with this mode (ixgbe maintainers) should comment. Maybe this mode is not all that useful anymore. > > - Only ``spec`` needs to be defined, ``mask`` is ignored. > > > > +--------------------+ > > | SIGNATURE | > > +==========+=========+ > > | ``spec`` | TBD | > > +----------+---------+ > > | ``mask`` | ignored | > > +----------+---------+ > > > > > > > ``ETH`` > > ^^^^^^^ > > > > Matches an Ethernet header. > > > > - ``dst``: destination MAC. > > - ``src``: source MAC. > > - ``type``: EtherType. > > - ``tags``: number of 802.1Q/ad tags defined. > > - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one: > > > > - ``tpid``: Tag protocol identifier. > > - ``tci``: Tag control information. > > Find below the other L2 layer attributes are useful in HW classification, > > - HiGig headers > - DSA Headers > - MPLS > > May be we need to intrdouce a separate flow type with spec to add the support. Right? Yeah, while I'm only familiar with MPLS, I think it's better to let these so-called "2.5" protocol layers have their own specifications. I think missing protocols will appear at the same time as PMD support. -- Adrien Mazarguil 6WIND