From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=eHPWfaQDdTS/gdbJKC7H188NEu17rW6hcBOmKAI71qs=; b=ylV8Vlb7TuDp7xXe1WpRSo+AZpzsuy4DbiX/HB8wTBnAelkXPqbcqi3NXUA1/f24wL +Fi4OOw1p8+hvNCK9ZuDhUYinRnTd5bgL1Lo9tZXMrj1XIparFyVEc0kC5OpO6fg/laq OpIiFqzvX54lEa1OFQOHEm6Y2XO7KtBsNgssr5a8jDLhpeH1KJ6gRhw08frxGLNfaS4F 8R49MtW69b+vXb45xaIsYAWoxPHrxQkkqhJ1XuuzsMB9aXma9RDC5e51OyjrwSLRHSk9 nIukQow1D9t0RmnzY/FeE72z88SoJno6HwiU/8lSxQGd56VLSHWthw8jxpNdQIFUpQ7J g63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eHPWfaQDdTS/gdbJKC7H188NEu17rW6hcBOmKAI71qs=; b=KpuD9Aw8jas7azRFukHklTCnrlcFMEIqjFJpIksqTAllq+w+ibwB8TJs6uPEdlIp9F jVyYjJykCAiA7HmwIC0H33Kj4d4aupLfpzXY/iUP4waZDCyj6HW3W7PrGBK9NbbzfNHd uH0aUtuluxUnfQ89jKeJ1COFvscqq1GW66ClHNaUQUDw/mBamyzmBfMTHrK8K4pCobp0 YQvY4mRKuowjaNcuEyHTPxd9rPaQEfsPYRmx/iHBdZCA7hz8/76qvpJeaYguFCqmSu0v 1g5V3Quw3vLHAn0C93+TDv0gGS4r10L7Szy+I8z861Z/iDJ4ab0pMLl4ubcRiVbOKtQJ 8jng== X-Gm-Message-State: AEkooutN3QVCGAxzRLy8tF5sHBaCyswZeyhDCFhX1kTdcdFb1H/bpjqZ1SV/fxrd9VlKkQ== X-Received: by 10.98.15.145 with SMTP id 17mr45659323pfp.40.1471890667042; Mon, 22 Aug 2016 11:31:07 -0700 (PDT) Received: from [192.168.1.5] ([72.168.144.203]) by smtp.googlemail.com with ESMTPSA id p64sm28925784pfd.11.2016.08.22.11.31.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 11:31:06 -0700 (PDT) To: Adrien Mazarguil , dev@dpdk.org References: <20160705181646.GO7621@6wind.com> From: John Fastabend Message-ID: <57BB44DF.4040204@gmail.com> Date: Mon, 22 Aug 2016 11:30:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC v2] Generic flow director/filtering/classification API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 18:31:08 -0000 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