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 65B3943A0F; Tue, 30 Jan 2024 17:44:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 890D041141; Tue, 30 Jan 2024 17:43:56 +0100 (CET) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by mails.dpdk.org (Postfix) with ESMTP id 10CFC41141 for ; Tue, 30 Jan 2024 17:43:55 +0100 (CET) Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-6de287449f1so1385842b3a.2 for ; Tue, 30 Jan 2024 08:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1706633034; x=1707237834; darn=dpdk.org; 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=AppmVXUXiNKLM9KFfI7y9I0ErkTdffv1TEgRhycRSRA=; b=UzJExW3dDpC5i4qCpBxuwHVI2CwDTICHaussiNA/p73ZEdxSInrC3GaKgqgSzxXubE o1RatJsKBZPd0Sfm1rFj7gHRoEaYlYx/Q8ttCOReUSSqtJO94op5SSqCcY5CESTdxVSZ L1QEihWwq+FolJfFQQWsTOFC1+pUQ2BzeD4g6WRXCotOihmHGqiYrxwMileuNSEjRZyx FhO4eucg3A8bBhXHY1WDCayEugLGdNbzTFQY390fjIfvqnoL5i6MCKfdXm6MbIFhW+L5 qZPmP8dd5mE7EuMyRfWc7I/wepasah1ZfMc8fYkZT+TsdQ9CVd3XBWvBfGFQsyx5qEGg mBww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706633034; x=1707237834; 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=AppmVXUXiNKLM9KFfI7y9I0ErkTdffv1TEgRhycRSRA=; b=OF3z9B/EosLpnSrqDeEw2jf7+a4N0ulHgbPRKQLQeIIaNU9ALNq1qiHDHeh7AMs+Aw En/726t9fL2U2qv5HPTPtG0QZJV8xWDtvGvGAd2TlE9zLNPQmu6IvZ743z1gRDpS8d4Q rDprOzT3wJXJErdMJeQSLnfsXHITAxRfu5/KBf/a72PCotcrCmyk2Ji4bNIFei8l8yUS Rp2QIA7luUu5A/ShMeIKfMWT0MKL0ORS4KogvT3tHa5hPu1OPy2cEhBPAp2xAedGHY4C y9Bi5lGoqP6eCfQBunCqRTVHkFYDbPp+lgSP5/FrOAhd2mwlSfDwZSRy1uTruwxq5qLI KIJg== X-Gm-Message-State: AOJu0YzBxmbWEqFPBVgDrAFIJdOoctxqtjxSklZtPpddFTsFUNl3o4c3 GlaIntd6YA0xJthT4e0J6l+378OnUkkRo2jer7NJQ2arXSeODSYemxPLlXWtaE5Mj3ZHv7QX1k4 i20c= X-Google-Smtp-Source: AGHT+IG87KsWKn5epp3LN05uZjVrlkWPbGNLz+y7SzAHcRuD6OussMPPl+lbHReo/Y94nFTDQhzhvg== X-Received: by 2002:a05:6a00:2da0:b0:6dd:7b4f:ed8b with SMTP id fb32-20020a056a002da000b006dd7b4fed8bmr5079237pfb.27.1706633034198; Tue, 30 Jan 2024 08:43:54 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id lo18-20020a056a003d1200b006dde0b7d633sm8073368pfb.77.2024.01.30.08.43.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 08:43:53 -0800 (PST) Date: Tue, 30 Jan 2024 08:43:52 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: longli@microsoft.com, Andrew Rybchenko , dev@dpdk.org Subject: Re: [Patch v2] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX WQEs Message-ID: <20240130084352.56971000@hermes.local> In-Reply-To: References: <1706150562-23248-1-git-send-email-longli@linuxonhyperv.com> <1706577181-27842-1-git-send-email-longli@linuxonhyperv.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 30 Jan 2024 10:19:32 +0000 Ferruh Yigit wrote: > > -mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq) > > +mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq, uint32_t count) > > { > > int ret; > > uint32_t i; > > + struct rte_mbuf **mbufs; > > + > > + mbufs = rte_calloc_socket("mana_rx_mbufs", count, sizeof(struct rte_mbuf *), > > + 0, rxq->mp->socket_id); > > + if (!mbufs) > > + return -ENOMEM; > > > > 'mbufs' is temporarily storage for allocated mbuf pointers, why not > allocate if from stack instead, can be faster and easier to manage: > "struct rte_mbuf *mbufs[count]" That would introduce a variable length array. VLA's should be removed, they are not supported on Windows and many security tools flag them. The problem is that it makes the code brittle if count gets huge. But certainly regular calloc() or alloca() would work here.