From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 6B3D57FEE for ; Wed, 29 Oct 2014 10:40:16 +0100 (CET) Received: by mail-wg0-f43.google.com with SMTP id n12so1413147wgh.30 for ; Wed, 29 Oct 2014 02:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=M5ddkbgcTgfEYS+QlPz2l8PLfg5EikMHXdgATAbyGE0=; b=OH7ZjkymPnuaUYvM8D+Xebge4MU8NO4at0iMXptxVId2XxGo8x2tvN9D87vWRbhKBd 46atoNu0PTy7E9qbCxZTRMR9ssW1IHCatdKMgYPbxtd9+tPFofN8IZzKWH0R3LU42Ftp 46VTrbUbDgmJ27mpnUQk10/lfCLoUA5oGBHDYWnq2ioIXywhHCCjk7FuLyhAB1WmIeSX mLZaUGCdX6wFxQPczu67yH1vNUihH1Xr3p68i2MUhVWBI9UYIX9u2LR3vpZArbGH2wub vmqur+JOEeeWAUwqOyDp69IFeONDYEV8GuE4Ol/qeL9k4dav4J/t0o21qtn9RDaYcl5Z 1OEA== X-Gm-Message-State: ALoCoQnNQ1Wq67gMy1aoFfxxu782Hy7XcLRgerDUuoqNqhn1L1u4klFlpzd6/jB0H4eoyVPZhVKB X-Received: by 10.180.207.72 with SMTP id lu8mr34035676wic.2.1414576146581; Wed, 29 Oct 2014 02:49:06 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id bv17sm18133795wib.13.2014.10.29.02.49.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 02:49:05 -0700 (PDT) From: Thomas Monjalon To: "Wu, Jingjing" Date: Wed, 29 Oct 2014 10:48:47 +0100 Message-ID: <4986750.SpIouGGtZD@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.1-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: <9BB6961774997848B5B42BEC655768F8B24F58@SHSMSX104.ccr.corp.intel.com> References: <1411711418-12881-1-git-send-email-jingjing.wu@intel.com> <2263852.MKHN7tgybq@xps13> <9BB6961774997848B5B42BEC655768F8B24F58@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v4 11/21] ethdev: define structures for getting flow director information 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, 29 Oct 2014 09:40:16 -0000 2014-10-29 02:10, Wu, Jingjing: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2014-10-22 09:01, Jingjing Wu: > > > +/** > > > + * A structure used to report the status of the flow director filters in use. > > > + */ > > > +struct rte_eth_fdir { > > > + /** Number of filters with collision indication. */ > > > + uint16_t collision; > > > + /** Number of free (non programmed) filters. */ > > > + uint16_t free; > > > + /** The Lookup hash value of the added filter that updated the value > > > + of the MAXLEN field */ > > > + uint16_t maxhash; > > > + /** Longest linked list of filters in the table. */ > > > + uint8_t maxlen; > > > + /** Number of added filters. */ > > > + uint64_t add; > > > + /** Number of removed filters. */ > > > + uint64_t remove; > > > + /** Number of failed added filters (no more space in device). */ > > > + uint64_t f_add; > > > + /** Number of failed removed filters. */ > > > + uint64_t f_remove; > > > +}; > > > > rte_eth_fdir is a name which doesn't say what it really is. > > This structure looks like a collection of statistics. > > Why not rte_eth_fdir_stats? > > > This structure is used in old flow director API. I moved it from rte_ethdev.h to rte_eth_ctrl.h and reuse it. As we discussed before, I think the old and new APIs will co-exist for one version. I also thought the name is not good enough, but I didn't change it because I want to keep the compatibility with the API used for ixgbe. > I think we can rename it when we are ready to remove the old flow director APIs. > > > > +struct rte_eth_fdir_ext { > > > + uint16_t guarant_spc; /**< guaranteed spaces.*/ > > > + uint16_t guarant_cnt; /**< Number of filters in guaranteed spaces. > > */ > > > + uint16_t best_spc; /**< best effort spaces.*/ > > > + uint16_t best_cnt; /**< Number of filters in best effort spaces. */ > > > +}; > > > > I don't understand why this "extended" structure is not merged in the first > > one. > > Adding new fields don't break old API. > > > Just as you say the name of rte_eth_fdir is not suitable, but I didn't want to change > It. What I want to use for operation RTE_ETH_FILTER_INFO is structure > rte_eth_fdir_info. And then I define a new rte_eth_fdir_ext to get the info > rte_eth_fdir doesn't contain. > Of course we also can merger all the elements to the struct rte_eth_fdir_info > Like below without reusing the old struct rte_eth_fdir, what do you think? > struct rte_eth_fdir_info { > int mode; > uint16_t collision; > uint16_t free; > uint16_t maxhash; > uint8_t maxlen; > uint64_t add; > uint64_t remove; > uint64_t f_add; > uint64_t f_remove; > uint16_t guarant_spc; > uint16_t guarant_cnt; > uint16_t best_spc; > uint16_t best_cnt; > }; Yes, you are adding a new API while keeping temporarily the old one. So it's better to add new structures with good names, so we will be able to remove the whole old API without any other API change in next release. Thanks -- Thomas