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 2AAFD41C2A;
Tue, 7 Feb 2023 06:16:47 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 072E440F18;
Tue, 7 Feb 2023 06:16:47 +0100 (CET)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com
[209.85.217.52]) by mails.dpdk.org (Postfix) with ESMTP id 3017540E6E
for <dev@dpdk.org>; Tue, 7 Feb 2023 06:16:46 +0100 (CET)
Received: by mail-vs1-f52.google.com with SMTP id h19so15061079vsv.13
for <dev@dpdk.org>; Mon, 06 Feb 2023 21:16:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=PfkovstMnM1Jvo9lU9r7SD7LDVRRy6yXGd/7uqEaFcA=;
b=a1+rFhXSMBPU5X1/tbsKrbhQiuwKpu69xsZv42/yedB8qQB6cLUXZIwKcb3Q33aybl
jThEPo0iTaoKv0sLJHjBcU/RA07Asaa6LZYjiWAFoFxBZVpqRRnjrVBsRBiYo0U9VNaA
pwZE3zJTe83y+wchBvCwYvEuE7v10F4uzrhKjUzeBTWycGifdcnYr1xNDNATjyKyp+0K
ybbOgNNfrK/PFd86i4bV02bSrGo9OnhkeZXqlVIHY/fNFSUixsyVFWoPgq/FcBRE+paY
PLRNC3V0fd7ZpD0yV1/2Fiy0iNLwIdHVZy/ZR2xAs8NZFi0grtHxD2bzurm7oKHIoBIw
maVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=PfkovstMnM1Jvo9lU9r7SD7LDVRRy6yXGd/7uqEaFcA=;
b=S2OhWHNn9ckQs4XBPAa+cttjUgIMjAgr4V/T1GS/V6IX7nEb6YNsRXXCEMOPgpHqVI
/ljBcm3JNWvUoynS3/M5E0feOIgQwmabtAeN2/RTSBzgxdATzJeMA2MHDXUCl/RkJRzE
WOpRVPUzPptPc2SMUY940kavzhFjF32YVF6znkTYxWBxROiXhZoYfSNpi02iMZV7K+90
v+F02+ZC0XdnkZ9GordUzCx93gKQLFNgLzG+P1g4iGunuy4T9WEIrulf5yEOp9EeDDje
oW07il9npOZacSS15OCGlGCOgaQ6qDJ0P9fZaEAuV81cNZYBuKAZhxsGzQw5x8esfdlX
a5EQ==
X-Gm-Message-State: AO0yUKUu+I8fK/IcpH2qLmDD1dGXFYbSA3FlzepBehNecd6zFfcPiLvE
5FpEVH8j87SlSQwNujEZy6O+d2Ok4aXZ1Jfzvwo=
X-Google-Smtp-Source: AK7set/gJaofbKUYkkjBmLyx5WTnSWna/x1hSGV0Gy9KTqWvvhm1F3D7ZOTOYFGhb8dNAa/YfMAArwBI9DZc2/FBp4w=
X-Received: by 2002:a67:de9a:0:b0:40f:b3a4:ccbc with SMTP id
r26-20020a67de9a000000b0040fb3a4ccbcmr439755vsk.45.1675747005438; Mon, 06 Feb
2023 21:16:45 -0800 (PST)
MIME-Version: 1.0
References: <20221114120238.2143832-1-jerinj@marvell.com>
<20230206202453.336280-1-jerinj@marvell.com>
<20230206202453.336280-3-jerinj@marvell.com>
<20230206130432.654d1467@hermes.local>
In-Reply-To: <20230206130432.654d1467@hermes.local>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Tue, 7 Feb 2023 10:46:19 +0530
Message-ID: <CALBAE1MQAjws_aK1+uDxFUytmjctD5adVF7S=xnV0277Ht-8gQ@mail.gmail.com>
Subject: Re: [dpdk-dev] [PATCH v2 02/12] mldev: support PMD functions for ML
device
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: jerinj@marvell.com, 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
Content-Type: text/plain; charset="UTF-8"
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, Feb 7, 2023 at 2:34 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> 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?
As Thomas suggested, I will add something similar to rte_gpu_init()
>
> 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.
It is slowpath, does not matter. But there is no harm in moving end of
it. I will move to end of the structure.
>
> > + /** Reserved for future fields */
> > + uint64_t reserved[3];
>
> Reserved fields have been a problem in the past.
Will remove it.
> Why do this? Are thy just available pad elements to be cache line size?
Yes.
>
> And why bother being cache aligned for an info struct?
We can remove it. Will removing reserved and cache aligned.
>