From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [PATCH v2 00/25] Generic flow API (rte_flow) Date: Wed, 4 Jan 2017 11:34:03 -0800 Message-ID: <586D4E2B.7040903@gmail.com> References: <20161221161914.GA14515@penelope.horms.nl> <20161222124804.GD10340@6wind.com> <20170104095347.GA24762@penelope.horms.nl> <20170104181219.GH12822@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Adrien Mazarguil , Simon Horman Return-path: Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) by dpdk.org (Postfix) with ESMTP id 6A1522C71 for ; Wed, 4 Jan 2017 20:34:13 +0100 (CET) Received: by mail-pf0-f176.google.com with SMTP id i88so83302137pfk.2 for ; Wed, 04 Jan 2017 11:34:13 -0800 (PST) In-Reply-To: <20170104181219.GH12822@6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" [...] >>> Well, it should be easier to answer if you have a specific use-case in mind >>> you would like to support but that cannot be expressed with the API as >>> defined in [1], in which case please share it with the community. >> >> A use-case would be implementing OvS DPIF flow offload using this API. > > OK, OVS has been mentioned several times in this thread and my understanding > is that rte_flow seems to accommodate most of its needs according to people > familiar with it. Perhaps ML archives can answer the remaining questions you > may have about combining rte_flow with OVS. For what its worth. I reviewed this and believe it should be sufficient to support the OVS SR-IOV offload use case with action/classifier extensions but without any fundamental changes to the design. We built a prototype OVS offload on top of another API we dubbed Flow-API a year+ ago and there seems to be a 1:1 mapping between that older API and the one now in DPDK so I'm happy. And the missing things seem to fit nicely into extensions. Also I believe the partial pre-classify use cases should be easily handled as well although I'm not as familiar with the bit-level details of that implementation. At some point capability discovery will be useful but we certainly don't need those in first iteration and rte_flow doesn't preclude these type of extensions so that is good. By the way thanks for doing this work Adrien, glad to see it being accepted and drivers picking it up. Thanks, John > >>> [1] http://dpdk.org/ml/archives/dev/2016-December/052954.html >>> [2] http://dpdk.org/ml/archives/dev/2016-December/052975.html > > [3] http://dpdk.org/doc/guides/prog_guide/rte_flow.html >