From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=pZtYAvTea9NMksTmX2N5NjlDbm/xUtuzDNTyNY/tenU=; b=O5cC1L8DNj638RJgRThxyj+YiCGuYXv21lzjKyzubTtK/EETIdSYYemUhKE63aF8TY 5+cwil4fPA9Yw8mCVVm5soUx80CdicvJTL11wcaSqIBIch1kJ7zcwdqH3Mkt8vcADnmW CnQ/qZ53xGoaEhJCmexayHlg6LLH1X526J9Iwr9Q1sX2QEyaH4COhsOSXRNMEDNuLYib +8JMcFSZE153C7HZmTfrWib+2JHKamdwgcdE9A2bGCgHQ9fXJ96QhmsNG9LRovid5crK houA/w2wgq7ErNmCUYdkZ2ptC5lj2i0qK0bIql4MQ10x8imxKUyLz9uvbDyGjdP8Av8J aQ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pZtYAvTea9NMksTmX2N5NjlDbm/xUtuzDNTyNY/tenU=; b=kU6n/JNl2D0v/45L42SGXOURGzzLAltnn0qvB41qlVRqSZjhH01jpUdURnGoPJqeJB I2MGlTB5QQlJQK3Islato5Bgj/UQmjP2LiCz9tBQte791scZrHBQldWWaMs6wR6yrJ7V uQ5tM9hehMkO3diwo5OoMu9zTtyFn0QAGC814/y10LgDK/PnCd3c/OPDaIzYu/R+sgJV 9qDOSU5iGbn+2la3MCNstyn1Lfcn70IFJUcbGLtxm2iUMP00YPbCuo/2x9P1basf/mcS lLEY3Vjbv6rtj+OKSDj97uWEBwAAJhO7QXh/sMBUymFzSTxP7QiQD41dTl9ppsph3u4G /zTg== X-Gm-Message-State: AIkVDXL3gVlS73obKnsUrnZ7rXLn2FV5NHJaUdWL7DMGbfmlw9YU5lR4mTjjcSUb4x2mVQ== X-Received: by 10.84.209.172 with SMTP id y41mr139636630plh.96.1483558452707; Wed, 04 Jan 2017 11:34:12 -0800 (PST) Received: from [192.168.1.6] ([72.168.145.205]) by smtp.googlemail.com with ESMTPSA id y15sm150045321pgc.43.2017.01.04.11.34.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 11:34:12 -0800 (PST) To: Adrien Mazarguil , Simon Horman References: <20161221161914.GA14515@penelope.horms.nl> <20161222124804.GD10340@6wind.com> <20170104095347.GA24762@penelope.horms.nl> <20170104181219.GH12822@6wind.com> Cc: dev@dpdk.org From: John Fastabend Message-ID: <586D4E2B.7040903@gmail.com> Date: Wed, 4 Jan 2017 11:34:03 -0800 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: <20170104181219.GH12822@6wind.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 00/25] Generic flow API (rte_flow) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:34:13 -0000 [...] >>> 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 >