From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [RFC v2] Generic flow director/filtering/classification API Date: Mon, 22 Aug 2016 11:30:55 -0700 Message-ID: <57BB44DF.4040204@gmail.com> References: <20160705181646.GO7621@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Adrien Mazarguil , dev@dpdk.org Return-path: Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by dpdk.org (Postfix) with ESMTP id 1AADE37B4 for ; Mon, 22 Aug 2016 20:31:08 +0200 (CEST) Received: by mail-pf0-f175.google.com with SMTP id y134so34843350pfg.0 for ; Mon, 22 Aug 2016 11:31:08 -0700 (PDT) In-Reply-To: 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 16-08-19 12:32 PM, Adrien Mazarguil wrote: > Hi All, > > Thanks to many for the positive and constructive feedback I've received so > far. Here is the updated specification (v0.7) at last. > > I've attempted to address as many comments as possible but could not > process them all just yet. A new section "Future evolutions" has been > added for the remaining topics. > > This series adds rte_flow.h to the DPDK tree. Next time I will attempt to > convert the specification as a documentation commit part of the patchset > and actually implement API functions. > > I think including the entire document here makes it easier to annotate on > the ML, apologies in advance for the resulting traffic. > > Finally I'm off for the next two weeks, do not expect replies from me in > the meantime. > Hopefully on vacation :) [...] > .. raw:: pdf > > PageBreak > > +-------------------------------------------+ > | UDP payload matching | > +===+=======================================+ > | 0 | Ethernet | > +---+---------------------------------------+ > | 1 | IPv4 | > +---+---------------------------------------+ > | 2 | UDP | > +---+-----+----------+--------------+-------+ > | 3 | RAW | ``spec`` | ``relative`` | 1 | > | | | +--------------+-------+ > | | | | ``search`` | 1 | > | | | +--------------+-------+ > | | | | ``offset`` | 10 | > | | | +--------------+-------+ > | | | | ``limit`` | 0 | > | | | +--------------+-------+ > | | | | ``length`` | 3 | > | | | +--------------+-------+ > | | | | ``pattern`` | "foo" | > +---+-----+----------+--------------+-------+ > | 4 | RAW | ``spec`` | ``relative`` | 1 | > | | | +--------------+-------+ > | | | | ``search`` | 0 | > | | | +--------------+-------+ > | | | | ``offset`` | 20 | > | | | +--------------+-------+ > | | | | ``limit`` | 0 | > | | | +--------------+-------+ > | | | | ``length`` | 3 | > | | | +--------------+-------+ > | | | | ``pattern`` | "bar" | > +---+-----+----------+--------------+-------+ > | 5 | RAW | ``spec`` | ``relative`` | 1 | > | | | +--------------+-------+ > | | | | ``search`` | 0 | > | | | +--------------+-------+ > | | | | ``offset`` | -29 | > | | | +--------------+-------+ > | | | | ``limit`` | 0 | > | | | +--------------+-------+ > | | | | ``length`` | 3 | > | | | +--------------+-------+ > | | | | ``pattern`` | "baz" | > +---+-----+----------+--------------+-------+ > Just an observation if you made 'offset' specified as an embedded RAW field so that the offset could point at header length this would befully generic. Although I guess its not practical as far as I know no hardware would support the most general case. > This translates to: > > - Locate "foo" at least 10 bytes deep inside UDP payload. > - Locate "bar" after "foo" plus 20 bytes. > - Locate "baz" after "bar" minus 29 bytes. > > Such a packet may be represented as follows (not to scale):: > > 0 >= 10 B == 20 B > | |<--------->| |<--------->| > | | | | | > |-----|------|-----|-----|-----|-----|-----------|-----|------| > | ETH | IPv4 | UDP | ... | baz | foo | ......... | bar | .... | > |-----|------|-----|-----|-----|-----|-----------|-----|------| > | | > |<--------------------------->| > == 29 B > [...] > > Future evolutions > ================= > > - Describing dedicated testpmd commands to control and validate this API. > > - A method to optimize generic flow rules with specific pattern items and > action types generated on the fly by PMDs. DPDK will assign negative > numbers to these in order to not collide with the existing types. See > `Negative types`_. Great thanks. As long as we build the core layer to support this then it looks good to me. > > - Adding specific egress pattern items and actions as described in `Traffic > direction`_. > > - Optional software fallback when PMDs are unable to handle requested flow > rules so applications do not have to implement their own. This is an interesting block. Would you presumably build this using the existing support in DPDK or propose something else? > > - Ranges in addition to bit-masks. Ranges are more generic in many ways as > they interpret values. For instance only ranges make sense to cover > several TCP or UDP ports. These will probably be defined on a pattern item > basis. > Yep not needed at first but hardware does support this. Thanks for doing this work, I'll look it over in a bit more detail over the next few days but it looks like a reasonable base implementation to me. .John