From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id D568241C26;
Mon, 6 Feb 2023 22:04:36 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id B42DD40A7D;
Mon, 6 Feb 2023 22:04:36 +0100 (CET)
Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com
[209.85.210.169])
by mails.dpdk.org (Postfix) with ESMTP id 234C240156
for <dev@dpdk.org>; Mon, 6 Feb 2023 22:04:35 +0100 (CET)
Received: by mail-pf1-f169.google.com with SMTP id a5so6322324pfv.10
for <dev@dpdk.org>; Mon, 06 Feb 2023 13:04:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc:subject:date
:message-id:reply-to;
bh=KY/wjwUd+X/nzHsRm6yzfFT3xhP0c9SzHirlBnu5NB4=;
b=pAEFSpOdbe8sGGDSHdw1/mZDRqM/HYQpqWVGSt2OA0/TmYYOluZ8RHHC4TCedl/sPR
sS6RYMK1LOQ+62WdsK8KF3X4syTKvmPLqVepvTuufxxw+xBUjMMqusfYeU/7zal4jwo3
+oxexTBt6G2uoV1nKM6SgmrPBLufAN+tBW9JDhwrsLLKNcJ27tX2xmMrqBoc9hGXfVAA
wBxUDeBHBOt4DnBomOWYmc3d/e6tS6G2PYkQ1uxiYgDVNQDf+Bl7apm9+SjT8xu4L2Zt
dwYHTCYqYxdaCJHqxna+zb+ziWRFhqEkCLx0hkBdisM7PKuDpryN/L1SUNBlvUQK83ly
o6Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=KY/wjwUd+X/nzHsRm6yzfFT3xhP0c9SzHirlBnu5NB4=;
b=lTUY60rFSEQBKofY2UhfuRaDLVOAKLqW9x8IhED6+wJ0uOlY0VNfvC2ytT2TOk0Z0Q
IsF3JXiohGMtN0HHS4kJxPF0xWfdhA/xpcpFDBhmWye+EeTRAC+tzAAW5+pn1Y6/4HRM
v//PtiuSH4PW8GxFlgpLFXsNYMFoIaYkNj+Z762FwKtUiT4iH4L8JAkhU2aFfOOxER4M
Z62RusVmq0/AiFJpLMsoIgNHq7+ypo2O2eFTPS21Ke6gRyz67D/x+Tu9Xy66DUiD6SfC
pMvB4rsL4Taf/tiNohtMS3nApCgDswVUTlNMzWq1daLjGxA1BaVImkCL5VkyIEgqDo2m
rDEg==
X-Gm-Message-State: AO0yUKXCY36Jj9+bg3k91mWjyf1vGpWw2EXxb44Slb/c5ePUOw6H2Xyz
RAbMMSwjP40MDgcvf21qu18+0g==
X-Google-Smtp-Source: AK7set/ZLP3s11tJw5A61bf5p3N0BwtF1GVpIjLA3xVNAv1B3iOSTBC0il9YDlt6RCOkg4AuptUsnQ==
X-Received: by 2002:a62:158f:0:b0:593:a800:2abc with SMTP id
137-20020a62158f000000b00593a8002abcmr758040pfv.8.1675717474292;
Mon, 06 Feb 2023 13:04:34 -0800 (PST)
Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218])
by smtp.gmail.com with ESMTPSA id
n11-20020a056a000d4b00b00576259507c0sm7603357pfv.100.2023.02.06.13.04.33
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 06 Feb 2023 13:04:33 -0800 (PST)
Date: Mon, 6 Feb 2023 13:04:32 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: <jerinj@marvell.com>
Cc: <dev@dpdk.org>, Srikanth Yalavarthi <syalavarthi@marvell.com>, "Anatoly
Burakov" <anatoly.burakov@intel.com>, <thomas@monjalon.net>,
<ferruh.yigit@xilinx.com>, <dchickles@marvell.com>,
<sshankarnara@marvell.com>, <pkapoor@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v2 02/12] mldev: support PMD functions for ML
device
Message-ID: <20230206130432.654d1467@hermes.local>
In-Reply-To: <20230206202453.336280-3-jerinj@marvell.com>
References: <20221114120238.2143832-1-jerinj@marvell.com>
<20230206202453.336280-1-jerinj@marvell.com>
<20230206202453.336280-3-jerinj@marvell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Tue, 7 Feb 2023 01:54:43 +0530
<jerinj@marvell.com> wrote:
> +static struct rte_ml_dev ml_devices[RTE_MLDEV_MAX_DEVS];
>
This will reserve space for 64 devices, but almost all users
will only have one. Maybe a level of indirection and allocate as needed?
You could even use a single allocation for the pmd and device private
data portion.
> + */
> +struct rte_ml_dev_data {
> + /** Unique identifier name. */
> + char name[RTE_ML_STR_MAX];
Why is name first, it is the least used field. Might want it to be last
for cache locality.
> + /** Reserved for future fields */
> + uint64_t reserved[3];
Reserved fields have been a problem in the past.
Why do this? Are thy just available pad elements to be cache line size?
And why bother being cache aligned for an info struct?