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 10F713794 for ; Fri, 3 Jun 2016 13:08:26 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id n184so120590948wmn.1 for ; Fri, 03 Jun 2016 04:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2Doh+vIHBT7KfSfCmYeHnvn9cb32ntJJvPHwTm7K5qI=; b=RaAHrhh6l0zEz64v13KKuauE99LxkCtb6X5mcnS28VNbjvIyWfVoh5WpZvhOhfRa6f cDV5Oug7yxDK+brW3MeUhcF6Na8+cbSVf5X5tODTo7f3Sxgh4Y0087ckUvPZ9bCycmfU JsrdBWA+NMWWQNVT0JU31Pn/rBVdvYbd1hU0zkRXNWOvgBz4UAVXu74NRGAAFdxpiRcv EjF6g7g2iLD3Eu1TDJulxUPFoOD9L1JHWa7ASEPBtHH3cygKFp3hcNCBIMH3XtLxUHDZ yg54v6G5WVqd5K8uzCHAlen2yZRF/31ahB48VNXeFa/3Hb1PuCCkPyKWeImjP2ZxYDBj Aw8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2Doh+vIHBT7KfSfCmYeHnvn9cb32ntJJvPHwTm7K5qI=; b=WTeKPsOyaA47Y8Uak349OLooko8x+pZi8NIfOHeWWqAGT4IL9SQz/U5rnVEd7jQfXn zVITUL4cR4yuCLenmdjep7kttTvA5PRO1tL2Qa9KR9Vrn5MIMGIxc04fKiRNxT1N+dG2 gpkHM+F22UBJ304Ptp8zExuc9ItEcNobMqw7Ja8V8Av0YGsSi+obgZ6rkxbzBjNnhsp6 ySpBndz2HgYB0mZhpI+Ea+avRCehZgPNkjyAgsUN1m+GuhAGTMnsoaSiLBiboCcq/BWI Veia/l87gDr+FE99YgNiV6aEZFTGYxGak4VuC1lTktItWTZpGb4vjIZtIs0fDEYsup0r t2tA== X-Gm-Message-State: ALyK8tKeq30mkCoZJD0xT7c/IiDCIx2FQXxnOzL9u6qTr+342PTJV7w995qnQta+488R1AP+ X-Received: by 10.28.195.131 with SMTP id t125mr3215088wmf.25.1464952105788; Fri, 03 Jun 2016 04:08:25 -0700 (PDT) Received: from [192.168.42.175] ([37.164.0.198]) by smtp.gmail.com with ESMTPSA id d7sm45284610wmd.11.2016.06.03.04.08.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 04:08:24 -0700 (PDT) To: "Hunt, David" , Jerin Jacob References: <1464797998-76690-1-git-send-email-david.hunt@intel.com> <1464874043-67467-1-git-send-email-david.hunt@intel.com> <1464874043-67467-2-git-send-email-david.hunt@intel.com> <20160603063755.GA5277@localhost.localdomain> <57515BBE.4070205@intel.com> Cc: dev@dpdk.org, viktorin@rehivetech.com From: Olivier MATZ Message-ID: <575164FF.1080509@6wind.com> Date: Fri, 3 Jun 2016 13:07:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <57515BBE.4070205@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations 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: Fri, 03 Jun 2016 11:08:26 -0000 On 06/03/2016 12:28 PM, Hunt, David wrote: > On 6/3/2016 7:38 AM, Jerin Jacob wrote: >> On Thu, Jun 02, 2016 at 02:27:19PM +0100, David Hunt wrote: >>> +/** >>> + * @internal wrapper for external mempool manager put callback. >>> + * >>> + * @param mp >>> + * Pointer to the memory pool. >>> + * @param obj_table >>> + * Pointer to a table of void * pointers (objects). >>> + * @param n >>> + * Number of objects to put. >>> + * @return >>> + * - 0: Success; n objects supplied. >>> + * - <0: Error; code of put function. >>> + */ >>> +static inline int >>> +rte_mempool_ops_enqueue_bulk(struct rte_mempool *mp, void * const >>> *obj_table, >>> + unsigned n) >>> +{ >>> + struct rte_mempool_ops *ops; >>> + >>> + ops = rte_mempool_ops_get(mp->ops_index); >>> + return ops->put(mp->pool_data, obj_table, n); >> Pass by value of "pool_data", On 32 bit systems, casting back to >> pool_id will >> be an issue as void* on 32 bit is 4B. IMO, May be can use uint64_t to >> pass by value and typecast to void* to fix it. > > OK. I see the problem. I'll see 4 callbacks that need to change, free, > get, put and get_count. > So the callbacks will be: > typedef void *(*rte_mempool_alloc_t)(struct rte_mempool *mp); > typedef void (*rte_mempool_free_t)(uint64_t p); > typedef int (*rte_mempool_put_t)(uint64_t p, void * const *obj_table, > unsigned int n); > typedef int (*rte_mempool_get_t)(uint64_t p, void **obj_table, unsigned > int n); > typedef unsigned (*rte_mempool_get_count)(uint64_t p); I don't quite like the uint64_t argument (I exepect that most handlers will use a pointer, and they will have to do a cast). What about giving a (struct rte_mempool *) instead? The handler function would then select between void * or uint64_t without a cast. In that case, maybe the prototype of alloc should be: typedef int (*rte_mempool_alloc_t)(struct rte_mempool *mp); It would directly set mp->pool_data and return 0 or -errno. By the way, I found a strange thing: > typedef void (*rte_mempool_free_t)(void *p); [...] > void > rte_mempool_ops_free(struct rte_mempool *mp) > { > struct rte_mempool_ops *ops; > > ops = rte_mempool_ops_get(mp->ops_index); > if (ops->free == NULL) > return; > return ops->free(mp); > } > Seems that the free cb expects mp->pool_data, but mp is passed. Another alternative to the "uint64_t or ptr" question would be to use a uintptr_t instead of a uint64_t. This is won't be possible if it need to be a 64 bits value even on 32 bits architectures. We could then keep the argument as pointer, and cast it to uintptr_t if needed. Regards, Olivier