From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 30A9F1BE8B for ; Wed, 4 Jul 2018 08:44:29 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id z13-v6so4452387wma.5 for ; Tue, 03 Jul 2018 23:44:29 -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:content-transfer-encoding:in-reply-to:openpgp :user-agent; bh=/BILdLo14zQcnBjfsyxQ/nLdAdM4Z4CUgDfkkosZY+8=; b=JcaW7LIf+QYXRCK4C0PWnfJuESBzuGb6V8KKoCmG+kOB5IvqcJMxLzDS8Dq5tCjvo/ zM+xo5sjs9WBbRzjxzNZPs+cVGYDF2bm8B8g4cgarfnqAS93ZaXjEBRsIrEqtw7hVscq Qhk2QJkhtdS0JybKkooO+HNv2cUpH/1fOV5wjHDiISIk7kUFihKrsY0CHAXnct/wbel1 iYkPswZQLslDLE+fwaBAKCM7sRGxkUBtbaFbDcNas6FxMaFnidmbvlh4YDHHmR9xG9kd 34PloicBJ04Xvpei9MsOxSgTO391RP1BwruM37kvvzdkmWFmxP/M/Y82ugZEFKijsF9H LBIA== 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:content-transfer-encoding :in-reply-to:openpgp:user-agent; bh=/BILdLo14zQcnBjfsyxQ/nLdAdM4Z4CUgDfkkosZY+8=; b=uFNeOVNFuItH1rdwXnA1OkExe7786bDfko6KYid2bhMgbExzXkUFvFBBPLwndLFidU cJ3pO8rLy1S/6dMV0cDlPdSE3lhC27n6qVuFQSpdMGTn4H65fh+IUrVQCFzPmhZ8T2nF DZ/SiDv2Cey5oPvUOa1Hyrzjk3Q9XJb8vG8hon9HwpRev1ZAgsJwbGJJWsqS/KmHsvGJ +Dz49xUSNnWp6Bi5wamPpaOaafF/HLPBE7iVezA/W7HxrlK/lMvHMLWU/RJWqQt8wM1P 5KtG83ALUIZjCzj116EFX3SHOxMbm1WiksNbmSBtMXI5ZqBJz9NhJOcaP9ZzheRXd5Cm GR/Q== X-Gm-Message-State: APt69E1/RPcKr8oFnnNEvLaWlCiWIcRneZiXn8jghMRz+do/Wlofmxo9 eXPbkL19GMd6VykdSk5BlVPD X-Google-Smtp-Source: AAOMgpfK9BvQ771VjrZvFIvleMa1m+R7gFQTIiyrD9zZ9ICUp/CdAyRfj0sgN3mT3oPshuW+jswMpg== X-Received: by 2002:a1c:2807:: with SMTP id o7-v6mr638804wmo.11.1530686668829; Tue, 03 Jul 2018 23:44:28 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v19-v6sm2438908wmc.9.2018.07.03.23.44.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Jul 2018 23:44:28 -0700 (PDT) Date: Wed, 4 Jul 2018 08:44:24 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Yongseok Koh Cc: dev@dpdk.org, Adrien Mazarguil Message-ID: <20180704064424.qmplbxgaxlqicbvl@laranjeiro-vm.dev.6wind.com> References: <1368a8720f3ec3c40e47a6b1d9ef1edf0f38a646.1530111623.git.nelio.laranjeiro@6wind.com> <20180703010703.GB38831@yongseok-MBP.local> <20180703071756.5fqggm5o77ytaptg@laranjeiro-vm.dev.6wind.com> <20180703170504.GA41721@yongseok-MBP.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180703170504.GA41721@yongseok-MBP.local> OpenPGP: id=A0075DA8F66A5949 preference=signencrypt User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 02/20] net/mlx5: handle drop queues are regular queues 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 Jul 2018 06:44:29 -0000 On Tue, Jul 03, 2018 at 10:05:05AM -0700, Yongseok Koh wrote: > On Tue, Jul 03, 2018 at 09:17:56AM +0200, Nélio Laranjeiro wrote: > > On Mon, Jul 02, 2018 at 06:07:03PM -0700, Yongseok Koh wrote: > > > On Wed, Jun 27, 2018 at 05:07:34PM +0200, Nelio Laranjeiro wrote: > [...] > > flow_drop_queue is also confusing as it is a drop hash rx queue, it can > > be used without a flow as a regular queue. > > Renaming it to drop_hrxq. > > Not so much critical to me but the entry has a field having repeating name. > priv->drop_hrxq.hrxq and priv->drop_hrxq.rxq > Sounds still confusing... > > > > > +/** > > > > + * Release a drop Rx queue Verbs object. > > > > + * > > > > + * @param dev > > > > + * Pointer to Ethernet device. > > > > + * @param rxq > > > > + * Pointer to the drop Verbs Rx queue. > > > > + * > > > > + * @return > > > > + * The Verbs object initialised, NULL otherwise and rte_errno is set. > > > > + */ > > > > +void > > > > +mlx5_rxq_ibv_drop_release(struct rte_eth_dev *dev, struct mlx5_rxq_ibv *rxq) > > > > > > If rxq for drop is saved in priv->drop.rxq, then why does it have to get rxq > > > pointer as an argument? Looks redundant. > > >[...] > > > > Like for all hrxqs, indirection tables, rxqs, which are stored in priv > > inside a list or an array. > > However, the assumption is there's only one drop queue while the regular ones > have multiple instances. > > > Priv is used as a storage place which is only access through > > *_{new,get,release} functions. > > Yes, that's what I'm telling you. *_{new,get,release}() accesses priv, then why > the pointer (which is saved in priv) is needed as an argument? > > > This is also to keep a consistency between regular hrxqs, and drop hrxq also. > Not sure why that consistency has to be kept. > > int mlx5_rxq_release(struct rte_eth_dev *dev, uint16_t idx); > int mlx5_hrxq_release(struct rte_eth_dev *dev, struct mlx5_hrxq *hxrq); > > mlx5_rxq_release() takes index as the instances are stored in an array and > mlx5_hrxq_release() takes pointer as the instances are stored in a list. > > Then, what if there's only one instance and no need to search? > Not taking such an argument sounds more consistent... >[...] Even if I prefer to keep consistency about identical functionality (in this case creating an hash Rx queue), I'll make the changes to please you. Regards, -- Nélio Laranjeiro 6WIND