From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id A63C71B19A for ; Fri, 6 Oct 2017 15:58:10 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id k4so8119090wmc.1 for ; Fri, 06 Oct 2017 06:58:10 -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:references:mime-version :content-disposition:in-reply-to; bh=lyXBn+4VhbvxDFhf/SVpKqPSmIy9RYCSAYEMh1VuiXc=; b=kLXvc4RHpRuKUsl368teARsc7j21WZWiwRdAupCjyP9wjZF/JM4ivp6jhLJeYrPX6w qqfy9xzVu9rwA10YQqDy8hjZxLEs9+b4o8gQVh9GP1aKZN0hoVU3dRHKTRWErZUFkIrw lHvxe1LCPuHXzOHExqWfK0jEie40d9OCe3DQC6VqWPAEMLP0wElmVIc9MrjEErgKxj8Y 6oUdsIwRunjeu3A5fcHFX9ZwRkEM9l7FYZUJGSdIP9zobSoxqbd+cc+dH1t2jUw4PZYv ZRWDSalsob/Vhyd+lgI0eNRdW6nQZ6mJfP5Qux8VuctwImHYR/RN+d+Xk5zSU+uzzxWg pPTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lyXBn+4VhbvxDFhf/SVpKqPSmIy9RYCSAYEMh1VuiXc=; b=aJoZeHTgZXb8DRa5bLl3XcJRgtucUiTKG6cfv43VOGo7V720H03m2ol6u9De+yWiNt Ox+QBUP/JJAgYSQpX+qyI86q20BJ9D7vtHMptr8WDfNBvkYh+BxbJRE3cTtjx3UkSoGW mM+EkUOUnQSydxIFiH3mHansHtL6QTNsTLjOQFg/Dbs42sC9KJcQzZj6gQtcIBykO3yv SqHoxJMhy4ZawsZfMQBIj2o/Ke3flR/X7esXVS6yyuvRehrxoES4jte2k2F3QJ7iIJSr dnuMuiN4VTNbNFQ7nIaXFWoVWih8qE1Vx3ngwbXuWt0+c1H97tHV2Nu2znJUBMHTnU/0 xrrA== X-Gm-Message-State: AMCzsaUXKa1aVcA/eNStGhr4XNmj1jzwoO762XPs1Mf74MakVkSu2C+T LjxjIosktdnkMeeQ9l3SDY/3vw== X-Google-Smtp-Source: AOwi7QAqCWvrQY4y56qoIdTYmLRgklQYLQT9YNTRVZp29G+kKUFGLsmcjmodayt7gng7RlE2NQqi1g== X-Received: by 10.80.141.19 with SMTP id s19mr663337eds.241.1507298290198; Fri, 06 Oct 2017 06:58:10 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id m7sm1742567eda.91.2017.10.06.06.58.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2017 06:58:09 -0700 (PDT) Date: Fri, 6 Oct 2017 15:57:58 +0200 From: Adrien Mazarguil To: Cristian Dumitrescu Cc: dev@dpdk.org, thomas@monjalon.net, jingjing.wu@intel.com, hemant.agrawal@nxp.com, jerin.jacob@caviumnetworks.com, jasvinder.singh@intel.com Message-ID: <20171006135758.GD3871@6wind.com> References: <1503705973-80742-2-git-send-email-cristian.dumitrescu@intel.com> <1507208974-180500-1-git-send-email-cristian.dumitrescu@intel.com> <1507208974-180500-2-git-send-email-cristian.dumitrescu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1507208974-180500-2-git-send-email-cristian.dumitrescu@intel.com> Subject: Re: [dpdk-dev] [PATCH V2 1/5] ethdev: add new flow action for metering and policing 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: Fri, 06 Oct 2017 13:58:10 -0000 On Thu, Oct 05, 2017 at 02:09:30PM +0100, Cristian Dumitrescu wrote: > Metering and policing action typically sits on top of flow classification, > which is why MTR objects are enabled through a newly introduced flow > action. > > The configuration of MTR objects is done in their own namespace (rte_mtr) > within the librte_ether library. The MTR object is hooked into ethdev RX > processing path using the "meter" flow action. > > Signed-off-by: Cristian Dumitrescu Looks good, one minor comment about the METER action semantics before acking this patch, see below. > --- > doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++++++++++++++ > lib/librte_ether/rte_flow.h | 22 ++++++++++++++++++++++ > 2 files changed, 46 insertions(+) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 662a912..6b9cdc2 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -1354,6 +1354,30 @@ rule or if packets are not addressed to a VF in the first place. > | ``vf`` | VF ID to redirect packets to | > +--------------+--------------------------------+ > > +Action: ``METER`` > +^^^^^^^^^^^^^^^^^ > + > +Applies a stage of metering and policing. > + > +The metering and policing (MTR) object has to be first created using the > +rte_mtr_create() API function. The ID of the MTR object is specified as > +action parameter. One or several meter actions can be added to the same > +flow. More than one flow can use the same MTR object through the meter > +action. The MTR object can be further updated or queried using the > +rte_mtr* API. rte_flow is currently documented [1] as ignoring several actions of the same kind in a given rule, in which case only the last one is taken into account. It's a deliberate design choice to simplify implementation, which I now think wasn't such a good idea after all. I'm therefore not opposed to remove this restriction globally, however in that case rte_flow documentation must be modified and PMDs reworked to implement the new behavior (failing by default when encountering multiple actions of the same time instead of ignoring them). It's probably a little late to do this now though. So my suggestion for the time being is to not describe what happens when several MTR actions are provided. We'll keep this for the next overhaul of rte_flow (some other changes are already planned). [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#actions -- Adrien Mazarguil 6WIND