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 DFC00A0C47; Thu, 14 Oct 2021 12:25:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 68B3340E50; Thu, 14 Oct 2021 12:25:35 +0200 (CEST) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by mails.dpdk.org (Postfix) with ESMTP id 34B4040041 for ; Thu, 14 Oct 2021 12:25:34 +0200 (CEST) Received: by mail-lf1-f52.google.com with SMTP id u21so21588240lff.8 for ; Thu, 14 Oct 2021 03:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZAZ3TyO1ka5o1QtxNualW2vfC0JSSwc++l0xRJJQWPs=; b=GupTUG9GkQELSp2hS6ljBLH76yf9ehYnqc67yVeOZ83ax/hwl5JxxyrDOUrxQRiziT RBgCk1laJoKVxTULjVsLV03t7mZ4dzvab+X4q59rbudPiLxVtZPilV86USOBhst/lswD fFaXDOweXK6L9Kie92qC8jJ9Q/DJDxhnm+FzsFqrJYszcS8vN2iXgBVlotmvWF/eh7ix PAeKVGxFu62VTkKq0zsPQlShRqWfwIkIDabNfmotpYqdoYKxK4igLLGb/J/bUUIjCCBp eBqeBxrY4utnpkUH1aCuU8+q8GQk9e+yZI2rvFuoJZzoFxPTI1OeIqL0a1TnkPbjOzPt qxuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZAZ3TyO1ka5o1QtxNualW2vfC0JSSwc++l0xRJJQWPs=; b=EUw4h2DbYKCFoBH1rITgUk71igpFzz/pESqCTIgIgJFsQKDzOrMiBS3ryPJUEvaLJx C595t3J9Cjs612a5ga66IH8lpOZMiejWcXy7u2qNSA9Lt1FQ/4Xa5Xsb5I+w/P982B+7 uPBgDvpMXnSNmVsHEUxDzE2bBnYzCnFpaaP0Trcjqx3SCInQkl7dbF7Jr1GBa3ukvDsG Sphq5VBvgC6L4EPLX4FUIvE+uTGD52mvJXpFVQc/ZIMkDb7Gee26s9vzOtqXL6hHM4MO Ag1Us8y8ecNLsqrEB3wOnOuwsUZMEDypzDmuKtQT9cAOSN9GfBk03WZkQSBJtecwL9QU 4gtA== X-Gm-Message-State: AOAM5320EKUclKaIIyWEVySEP+ByT18qJeBsdIGR4vpd/dZWXUcGgluR SVabDoiZiOnTOAbz1t6p0es= X-Google-Smtp-Source: ABdhPJxc0L02mlVYxNtsREsWehZRyikR9ngj5WRzMhVqoHvIENHeLL60p6GCrjSUy9eCJeJUFfm8Sg== X-Received: by 2002:a2e:4942:: with SMTP id b2mr5152266ljd.176.1634207133305; Thu, 14 Oct 2021 03:25:33 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id e12sm221772ljp.30.2021.10.14.03.25.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 03:25:33 -0700 (PDT) Date: Thu, 14 Oct 2021 13:25:32 +0300 From: Dmitry Kozlyuk To: Harman Kalra Cc: Thomas Monjalon , David Marchand , "dev@dpdk.org" , Raslan Darawsheh , Ray Kinsella , "viacheslavo@nvidia.com" , "matan@nvidia.com" Message-ID: <20211014132532.1644eaf4@sovereign> In-Reply-To: References: <20210826145726.102081-1-hkalra@marvell.com> <24392547.dnzkRMgc80@thomas> <10896897.yJauvYxkRq@thomas> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement get set APIs 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 Sender: "dev" 2021-10-14 09:31 (UTC+0000), Harman Kalra: > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Thursday, October 14, 2021 1:53 PM > > To: Harman Kalra > > Cc: dev@dpdk.org; Raslan Darawsheh ; Ray Kinsella > > ; Dmitry Kozlyuk ; David > > Marchand ; viacheslavo@nvidia.com; > > matan@nvidia.com > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement > > get set APIs > > > > 13/10/2021 20:52, Thomas Monjalon: > > > 13/10/2021 19:57, Harman Kalra: > > > > From: dev On Behalf Of Harman Kalra > > > > > From: Thomas Monjalon > > > > > > 04/10/2021 11:57, David Marchand: > > > > > > > On Mon, Oct 4, 2021 at 10:51 AM Harman Kalra > > > > > > > > > > > > > wrote: > > > > > > > > > > +struct rte_intr_handle *rte_intr_handle_instance_alloc(int > > size, > > > > > > > > > > + > > > > > > > > > > +bool > > > > > > > > > > +from_hugepage) { > > > > > > > > > > + struct rte_intr_handle *intr_handle; > > > > > > > > > > + int i; > > > > > > > > > > + > > > > > > > > > > + if (from_hugepage) > > > > > > > > > > + intr_handle = rte_zmalloc(NULL, > > > > > > > > > > + size * sizeof(struct rte_intr_handle), > > > > > > > > > > + 0); > > > > > > > > > > + else > > > > > > > > > > + intr_handle = calloc(1, size * > > > > > > > > > > + sizeof(struct rte_intr_handle)); > > > > > > > > > > > > > > > > > > We can call DPDK allocator in all cases. > > > > > > > > > That would avoid headaches on why multiprocess does not > > > > > > > > > work in some rarely tested cases. > > [...] > > > > > > I agree with David. > > > > > > I prefer a simpler API which always use rte_malloc, and make > > > > > > sure interrupts are always handled between rte_eal_init and > > rte_eal_cleanup. > > [...] > > > > > There are couple of more dependencies on glibc heap APIs: > > > > > 1. "rte_eal_alarm_init()" allocates an interrupt instance which is > > > > > used for timerfd, is called before "rte_eal_memory_init()" which > > > > > does the memseg init. > > > > > Not sure what all challenges we may face in moving alarm_init > > > > > after memory_init as it might break some subsystem inits. > > > > > Other option could be to allocate interrupt instance for timerfd > > > > > on first alarm_setup call. > > > > > > Indeed it is an issue. > > > > > > [...] > > > > > > > > There are many other drivers which statically declares the > > > > > interrupt handles inside their respective private structures and > > > > > memory for those structure was allocated from heap. For such > > > > > drivers I allocated interrupt instances also using glibc heap APIs. > > > > > > Could you use rte_malloc in these drivers? > > > > If we take the direction of 2 different allocations mode for the interrupts, I > > suggest we make it automatic without any API parameter. > > We don't have any function to check rte_malloc readiness I think. > > But we can detect whether shared memory is ready with this check: > > rte_eal_get_configuration()->mem_config->magic == RTE_MAGIC This check > > is true at the end of rte_eal_init, so it is false during probing. > > Would it be enough? Or should we implement rte_malloc_is_ready()? > > Hi Thomas, > > It's a very good suggestion. Let's implement "rte_malloc_is_ready()" which could be as > simple as " rte_eal_get_configuration()->mem_config->magic == RTE_MAGIC" check. > There may be more consumers for this API in future. I doubt it should be public. How it is supposed to be used? Any application code for DPDK necessarily calls rte_eal_init() first, after that this function would always return true. > > If we are making it automatic detection, shall we now even have argument to this alloc API? > I added a flags argument (32 bit) in latest series where each bit of this flag can be an allocation capability. > I used two bits for discriminating between glibc malloc and rte_malloc. Shall we keep it or drop it? > > David, Dmitry please share your thoughts. I'd drop it, but no strong opinion. Since allocation type is automatic and all other properties can be set later, there are no use cases for any options here. And if they appear, flags may be insufficient as well.