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 D622545980; Thu, 19 Sep 2024 15:16:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C718243354; Thu, 19 Sep 2024 15:16:34 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 1716A402B1 for ; Thu, 19 Sep 2024 15:16:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726751793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qX5d9Jp8enmXmngICHo6eYbyz8RH7mDA92eLeH/m4ps=; b=UElQBjiyl7qBSvzpC0r+Rxy+K4eOwawDP9x8/dD6RS5IEkNhmthJC4yFcCrztVQpAqJxKx +KdDsYpXQHmu64D9Gnh9k0jnM2bsWPepaVGOw0SejeeklNs6Nx4iSvMCXtCQhYIxa/tVEu a+U2k6Ud1Vi9lqlGynm7umY4wBU5dSc= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-564-XZoqHgUAMRmmyzdN9_mb9A-1; Thu, 19 Sep 2024 09:16:32 -0400 X-MC-Unique: XZoqHgUAMRmmyzdN9_mb9A-1 Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-207332f7c17so9277505ad.2 for ; Thu, 19 Sep 2024 06:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726751791; x=1727356591; h=content-transfer-encoding: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=qX5d9Jp8enmXmngICHo6eYbyz8RH7mDA92eLeH/m4ps=; b=Sb7buNdseJYNAYA3a5y/frFsQ0dHG0IYP0PO7PfGAJbbJJI/KHqv+uKsEqqpOmvLrP vbTTNJTxeshFr18C5/f7zaAYsmKIxl0gQ5c6hNSBoAk6IC4kh44H1URVWmPrWs7F81D7 Kua/eJKlU9q13KK3WbrB1NM2+DB2YBa8askDH0wA4/af3xiK3cSmFA9ezegUO0D1Q6i2 un7wGUN2qC4Ppau1bwTc9OwZde2I0KY7L4EK/UeAwA6Hs6gECX9mghDrD+vhSIr/hDxr 1aGXicjZfE4CKkSQY5ZEWpI2xxtwTUaOTuAaMfcT5PaMlux1Z1GgeVBDp4bPB4w+go/A T5dw== X-Gm-Message-State: AOJu0YwaltMP32b4L9CB+T+FGRuKQFQ9AUnefvKy7mFGztiwEf/1jCMX KzZ1qleAxcDAYJeScKgMeSfLZ7/hIf9zEBawqo7h3QYU9ct4yyzptECca6c03Gn63gb3KQZ8B1W 1UZ3B4zsVzH22AB7iQChrtnM4oAdKgMCFN4AorHZYnChhnlOPzxkeT5EtreO+l86nK0YaViJEBV 1PILGAb59QP3S0SlE= X-Received: by 2002:a17:902:db11:b0:206:93e7:5837 with SMTP id d9443c01a7336-2076e3f8962mr427101705ad.39.1726751791490; Thu, 19 Sep 2024 06:16:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF1aae8oDVj21J6JhviFxVTqUrmyyQp8iy8OWXbKd0z8CyyQyHqGT92oCfCU58R6qhrKG8kij8Pch5Q5ONQ5E0= X-Received: by 2002:a17:902:db11:b0:206:93e7:5837 with SMTP id d9443c01a7336-2076e3f8962mr427101455ad.39.1726751791195; Thu, 19 Sep 2024 06:16:31 -0700 (PDT) MIME-Version: 1.0 References: <20240812132910.162252-1-bruce.richardson@intel.com> <20240814104933.14062-1-bruce.richardson@intel.com> <20240814104933.14062-2-bruce.richardson@intel.com> In-Reply-To: <20240814104933.14062-2-bruce.richardson@intel.com> From: David Marchand Date: Thu, 19 Sep 2024 15:16:15 +0200 Message-ID: Subject: Re: [PATCH v3 01/26] cryptodev: remove use of ethdev max queues definition To: Bruce Richardson Cc: dev@dpdk.org, ferruh.yigit@amd.com, thomas@monjalon.net, mb@smartsharesystems.com, Akhil Goyal X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Aug 14, 2024 at 12:50=E2=80=AFPM Bruce Richardson wrote: > > The number of queue pairs supported by cryptodev should not be dependent > on the number of ethdev Rx or Tx queues, so add a new define for > cryptodev specifically. > > Signed-off-by: Bruce Richardson > Acked-by: Morten Br=C3=B8rup > --- > config/rte_config.h | 1 + > lib/cryptodev/cryptodev_pmd.c | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/config/rte_config.h b/config/rte_config.h > index dd7bb0d35b..d67ff77c71 100644 > --- a/config/rte_config.h > +++ b/config/rte_config.h > @@ -71,6 +71,7 @@ > > /* cryptodev defines */ > #define RTE_CRYPTO_MAX_DEVS 64 > +#define RTE_CRYPTO_MAX_QPS_PER_DEV 256 Cc: Akhil. Before this patch, the dummy_cb array could hold 1024 entries, so I wonder if this is enough / what the reason is to go to 256. Additionnally, should we check rte_cryptodev_pmd_init_params->max_nb_queue_pairs in rte_cryptodev_pmd_create() ? > #define RTE_CRYPTODEV_NAME_LEN 64 > #define RTE_CRYPTO_CALLBACKS 1 > > diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.= c > index 87ced122b4..d3263bd907 100644 > --- a/lib/cryptodev/cryptodev_pmd.c > +++ b/lib/cryptodev/cryptodev_pmd.c > @@ -212,8 +212,8 @@ dummy_crypto_dequeue_burst(__rte_unused void *qp, > void > cryptodev_fp_ops_reset(struct rte_crypto_fp_ops *fp_ops) > { > - static struct rte_cryptodev_cb_rcu dummy_cb[RTE_MAX_QUEUES_PER_PO= RT]; > - static void *dummy_data[RTE_MAX_QUEUES_PER_PORT]; > + static struct rte_cryptodev_cb_rcu dummy_cb[RTE_CRYPTO_MAX_QPS_PE= R_DEV]; > + static void *dummy_data[RTE_CRYPTO_MAX_QPS_PER_DEV]; > static const struct rte_crypto_fp_ops dummy =3D { > .enqueue_burst =3D dummy_crypto_enqueue_burst, > .dequeue_burst =3D dummy_crypto_dequeue_burst, > -- > 2.43.0 > --=20 David Marchand