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