From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id C2A98592B for ; Mon, 11 Sep 2017 15:00:46 +0200 (CEST) Received: from [37.168.58.44] (helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1drOPu-0001Xo-9G; Mon, 11 Sep 2017 15:06:23 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 11 Sep 2017 15:00:38 +0200 Date: Mon, 11 Sep 2017 15:00:38 +0200 From: Olivier MATZ To: santosh Cc: Hemant Agrawal , dev@dpdk.org, thomas@monjalon.net, jerin.jacob@caviumnetworks.com Message-ID: <20170911130037.o2toy25qpxae52p3@neon> References: <20170815080717.9413-1-santosh.shukla@caviumnetworks.com> <20170815080717.9413-3-santosh.shukla@caviumnetworks.com> <20170904121113.jdilonuhw77c4vx7@neon> <5fc11fd6-3741-ae25-d5e1-3bc8a643661c@caviumnetworks.com> <0df45c69-6e54-5e6a-354e-e5c2ba6d578e@nxp.com> <08aaa47a-b2e2-4b02-a9c3-6e3638503f1f@caviumnetworks.com> <4cfc26cb-18bf-76b3-af3c-5dacd86cd52e@caviumnetworks.com> <8e66eab5-51a5-af0c-8b0c-3879c516364c@nxp.com> <20170911093333.7tt3zdzdam3tshra@neon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: allow pmd to advertise pool handle 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: Mon, 11 Sep 2017 13:00:46 -0000 On Mon, Sep 11, 2017 at 06:10:36PM +0530, santosh wrote: > Hi Olivier, > > > On Monday 11 September 2017 03:03 PM, Olivier MATZ wrote: > > On Thu, Sep 07, 2017 at 04:38:39PM +0530, Hemant Agrawal wrote: > >> On 9/7/2017 3:41 PM, santosh wrote: > >>> Sorry for the font, resending proposed API: > >>> > >>> /** > >>> * Get list of supported pools for a port > >>> * @param port_id [in] > >>> * Pointer to port identifier of the device. > >>> * @param pools [out] > >>> * Pointer to the list of supported pools for that port. > >>> * Returns with array of pool ops name handler of size > >>> * RTE_MEMPOOL_OPS_NAMESIZE. > >>> * @return > >>> * >=0: Success; PMD has updated supported pool list. > >>> * <0: Failure; > >>> */ > >>> > >>> int rte_eth_dev_pools_ops_supported(uint8_t port_id, char **pools) > >>> > >>> Hemant, Olivier: Does above api make sense? Pl. confirm. Thanks. > >>> > >> looks ok to me. > > I think that returning a list is harder to use in an application, instead of an > > api that just returns an int (priority): > > > > int rte_eth_dev_pool_ops_supported(uint8_t port_id, const char *pool) > > > > The possible returned values are: > > ENOTSUP: mempool ops not supported > > < 0: any other error > > 0: best mempool ops choice for this pmd > > 1: this mempool ops are supported > > > > Let's take an example. Our application wants to select ops that > > will match all pmds. The pseudo code would be like this: > > > > best_score = -1 > > best_ops = NULL > > for ops in mempool_ops: > > score = 0 > > for p in ports: > > ret = rte_eth_dev_pools_ops_supported(p, ops.name) > > if ret < 0: > > score = -1 > > break > > score += ret > > if score == -1: > > continue > > if best_score == -1 || score < best_score: > > best_score = score > > best_ops = ops > > if best_score == -1: > > print "no matching mempool ops" > > else: > > print "selected ops: %s", best_ops.name > > > > > > You can do the exercise with the API you are proposing, but I think > > it would be harder. > > > > Olivier > > Proposed model looks okay and I'll implement _pool_ops_supported() api. > But I cant promise the testpmd related changes with this series, > Since rc1 is closing so let the api go in -rc1 release and testpmd changes will > follow then. is it ok with you? It's ok for me.