From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id B93CF58D8 for ; Wed, 10 Aug 2016 13:02:43 +0200 (CEST) Received: by mail-wm0-f54.google.com with SMTP id o80so95437576wme.1 for ; Wed, 10 Aug 2016 04:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=wVOIvvlR1nogTuw5akeUFiX3CPiM8M40j9lfq5gKDmE=; b=wUp0FEiY72ktlAuo5OlDAV0/fh43uGlna/tl8sJkBmL6x9lNb1gEHsI5T7BZGyBQw9 RmMvNHvA4DlERG90R+aqWuxG492yA4ugByswERD9Zo56NGf9WCZ91B0/qWbT6l/RGQgH NNRO40NxRxm3ag5mziIkIyKwKFDmjmUTq/U6Ts/51CswW1ZbbRwJ9SLTEg0+39D18VHf APBGpJppW64vcQykJGDqorssYJZKR6LycVbpYmLtnqGR64Lt4fO2lvaVmpbhXuhXeMI8 oA4HK4EKZMGLVcbfF8uQd0fcadfGuznNNjtZVdbZktYxRt/qZOasbgVnYamxIoKbjFPI X7oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=wVOIvvlR1nogTuw5akeUFiX3CPiM8M40j9lfq5gKDmE=; b=Zc10wAFdg/On5LeeZGGfRhLUXbXhIV7pVbcT6aJEsh0IahWlUBwAJKBUJqpKbAM3Fa EmsZeSYKE8Bx3WnR3wbclCHIz3n5YENR2RAAbxJ/8rD1q8qjE4C0LZhmqoae9R6tM8iT oFu/b5DT4ULISEC9IXIRQ2ykGFP0tANy9bFhBsPqaR7te/BQfvHb4PACb8/n+EikM8hL cCo/iXwCRI0Smv+TsW6Gn5UZFldbHA/NeqZIc7D8GhfJWC1cspikLwQMS0MV2yz88XUx lUzzdCqul6eaAdoMYGy16eXIJltwCJu/yi1kFG56a3Tm9fYYSKFWnVx9rQJJSgMgDaTG IypQ== X-Gm-Message-State: AEkoouvDoEbiLTfEumYkWBwiab1GfYoG15Q4ujDLj9ndO29DZFPlHsBNlZvK8MtiWy2U1hg5 X-Received: by 10.194.47.206 with SMTP id f14mr3870777wjn.98.1470826963377; Wed, 10 Aug 2016 04:02:43 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id o4sm42439830wjd.15.2016.08.10.04.02.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Aug 2016 04:02:42 -0700 (PDT) Date: Wed, 10 Aug 2016 13:02:36 +0200 From: Adrien Mazarguil To: John Fastabend Cc: Jerin Jacob , 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 Message-ID: <20160810110236.GA3336@6wind.com> Mail-Followup-To: John Fastabend , Jerin Jacob , 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 References: <20160705181646.GO7621@6wind.com> <20160711104141.GA10172@localhost.localdomain> <20160721192023.GU7621@6wind.com> <5793DD3E.3080605@gmail.com> <57A0E423.2030804@gmail.com> <20160803143049.GF3336@6wind.com> <57A233A9.3000006@gmail.com> <20160804130528.GM3336@6wind.com> <57AA4A0A.8060809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57AA4A0A.8060809@gmail.com> Subject: Re: [dpdk-dev] [RFC] 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: Wed, 10 Aug 2016 11:02:44 -0000 On Tue, Aug 09, 2016 at 02:24:26PM -0700, John Fastabend wrote: [...] > > Just an idea, could some kind of meta pattern items specifying time > > constraints for a rule address this issue? Say, how long (cycles/ms) the PMD > > may take to query/apply/delete the rule. If it cannot be guaranteed, the > > rule cannot be created. Applications could mantain statistic counters about > > failed rules to determine if performance issues are caused by the inability > > to create them. > > It seems a bit heavy to me to have each PMD driver implementing > something like this. But it would be interesting to explore probably > after the basic support is implemented though. OK, let's keep this for later. [...] > > Such a pattern could be generated from a separate function before feeding it > > to rte_flow_create(), or translated by the PMD afterwards assuming a > > separate meta item such as RAW_END exists to signal the end of a RAW layer. > > Of course processing this would be more expensive. > > > > Or the supported parse graph could be fetched from the hardware with the > values for each protocol so that the programming interface is the same. > The well known protocols could keep the 'enum values' in the header > rte_flow_item_type enum so that users would not be required to do > the parse graph but for new or experimental protocols we could query > the parse graph and get the programming pattern matching id for them. > > The normal flow would be unchanged but we don't get stuck upgrading > everything to add our own protocol. So the flow would be, > > rte_get_parse_graph(graph); > flow_item_proto = is_my_proto_supported(graph); > > pattern = build_flow_match(flow_item_proto, value, mask); > action = build_action(); > rte_flow_create(my_port, pattern, action); > > The only change to the API proposed to support this would be to allow > unsupported RTE_FLOW_ values to be pushed to the hardware and define > a range of values that are reserved for use by the parse graph discover. > > This would not have to be any more expensive. Makes sense. Unless made entirely out of RAW items however the ensuing pattern would not be portable across DPDK ports, instances and versions if dumped in binary form for later use. Since those would have be recognized by PMDs and applications regardless of the API version, I suggest making generated item types negative (enums are signed, let's use that). DPDK would have to maintain a list of expended values to avoid collisions between PMDs. A method should be provided to release them. [...] > hmm for performance reasons building an entire graph up using RAW items > seems to be a bit heavy. Another alternative to the above parse graph > notion would be to allow users to add RAW node definitions at init time > and have the PMD give a ID back for those. Then the new node could be > used just like any other RTE_FLOW_ITEM_TYPE in a pattern. > > Something like, > > ret_flow_item_type_foo = rte_create_raw_node(foo_raw_pattern) > ret_flow_item_type_bar = rte_create_raw_node(bar_raw_pattern) > > then allow ret_flow_item_type_{foo|bar} to be used in subsequent > pattern matching items. And if the hardware can not support this return > an error from the initial rte_create_raw_node() API call. > > Do any either of those proposals sound like reasonable extensions? Both seem acceptable in my opinion as they fit in the described API. However I think it would be better for this function to spit out a pattern made of any number of items instead of a single new item type. That way, existing fixed items can be reused as well, the entire pattern may even become portable as a result, it could be considered as a method to optimize a RAW pattern. The RAW approach has the advantage of not requiring much additional code in the public API besides a couple of function declarations. A proper full blown graph would require a lot more as described in your original reply. Not sure which is better. Either way they won't be part of the initial specification but it looks like they can be added later without affecting the basics. > > [...] > >> The two open items from me are do we need to support adding new variable > >> length headers? And how do we handle multiple tables I'll take that up > >> in the other thread. > > > > I think variable length headers may be eventually supported through pattern > > tricks or eventually a separate conversion layer. > > > > A parse graph notion would support this naturally though without pattern > tricks hence my above suggestions. All right, I agree a method to let applications precisely define what they want to match can be useful now I understand what you mean by "dynamically". > Also in the current scheme how would I match an ipv6 option or specific > nsh option or mpls tag? Ideally through specific pattern items defined for this purpose, which is how I thought the API would evolve. Of course it wouldn't be fully dynamic and you'd have to wait for a DPDK release that implements them. -- Adrien Mazarguil 6WIND