From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC] Generic flow director/filtering/classification API Date: Mon, 11 Jul 2016 16:11:43 +0530 Message-ID: <20160711104141.GA10172@localhost.localdomain> References: <20160705181646.GO7621@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: , 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 Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0083.outbound.protection.outlook.com [104.47.40.83]) by dpdk.org (Postfix) with ESMTP id 7B271370 for ; Mon, 11 Jul 2016 12:42:15 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20160705181646.GO7621@6wind.com> 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" 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. > 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 > 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. > | 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) > > 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. > > +---------------------+ > | 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. > > - 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? Jerin