From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [PATCH 1/3] librte_ether: add RTE_ETH_FDIR_OTHER for
 flow director behavior
Date: Tue, 29 Sep 2015 15:38:23 +0100
Message-ID: <20150929143823.GE6748@bricha3-MOBL3>
References: <1443536800-13269-1-git-send-email-andrey.chilikin@intel.com>
 <1443536800-13269-2-git-send-email-andrey.chilikin@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org
To: Andrey Chilikin <andrey.chilikin@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 3A20AB62
 for <dev@dpdk.org>; Tue, 29 Sep 2015 16:38:27 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <1443536800-13269-2-git-send-email-andrey.chilikin@intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Tue, Sep 29, 2015 at 03:26:38PM +0100, Andrey Chilikin wrote:
> Add new flow director behavior RTE_ETH_FDIR_OTHER to assign a queue by other filters
> 
> Signed-off-by: Andrey Chilikin <andrey.chilikin@intel.com>
> ---
>  lib/librte_ether/rte_eth_ctrl.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
> index 26b7b33..3acf501 100644
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -417,6 +417,7 @@ struct rte_eth_fdir_input {
>  enum rte_eth_fdir_behavior {
>  	RTE_ETH_FDIR_ACCEPT = 0,
>  	RTE_ETH_FDIR_REJECT,
> +	RTE_ETH_FDIR_OTHER,
>  };
>  
>  /**
> -- 
> 1.7.4.1
> 
Is "OTHER" meant to be a "NOOP" or a generic hold-all for a set of other possible
behaviours. From the description, I would assume NOOP - in which case would
RTE_ETH_FDIR_NOOP not be a better name?

/Bruce