From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Tue, 7 Feb 2023 06:16:46 +0100 (CET) Received: by mail-vs1-f52.google.com with SMTP id h19so15061079vsv.13 for ; 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 Date: Tue, 7 Feb 2023 10:46:19 +0530 Message-ID: Subject: Re: [dpdk-dev] [PATCH v2 02/12] mldev: support PMD functions for ML device To: Stephen Hemminger Cc: jerinj@marvell.com, dev@dpdk.org, Srikanth Yalavarthi , Anatoly Burakov , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Feb 7, 2023 at 2:34 AM Stephen Hemminger wrote: > > On Tue, 7 Feb 2023 01:54:43 +0530 > 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. >