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 5525543FC6; Tue, 7 May 2024 09:04:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3737642E22; Tue, 7 May 2024 09:04:05 +0200 (CEST) Received: from wfout7-smtp.messagingengine.com (wfout7-smtp.messagingengine.com [64.147.123.150]) by mails.dpdk.org (Postfix) with ESMTP id A423F40270 for ; Mon, 6 May 2024 17:34:29 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.west.internal (Postfix) with ESMTP id 8587F1C00168; Mon, 6 May 2024 11:34:25 -0400 (EDT) Received: from imap47 ([10.202.2.97]) by compute3.internal (MEProxy); Mon, 06 May 2024 11:34:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1715009665; x=1715096065; bh=1wxHLLLHxgu169ldnKzuhZwCNLTk 0hMopu4xDAoMjX8=; b=cbXsWIDxJRvpWwb4M2u47YisF9zRcZcGhA5/l1211iQT OXlU/8E6A3aHszEI0UmX3oxm5k5LzI8VwfqTggto1F2Va2PHph1aaWlK/+pO7FuV Qy5u7ig73BsAAehkFLLee7FB1u5aLQ/zUXaM9YYY4af2P8p3keDDIqKHRCLcezGo 5g72aa6xfII/gDFPW70q0T+KF2i3Mqzb3K9SoskZyGyMQw6fdTkA3dDDhcdBnMe/ wsuE1dkQSlqvz52LBZeywh43s+uhc3KHQvBRz6QTOrAJ5Q2pivIK3/0JohS9l+Q2 iKE0dc63Zyb+hWN0coirB/4EdxrAbgxw1jDM7hMQcw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddviedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfvfho mhculfhonhgvshdfuceothhhjhesfhhrvggvsghsugdrohhrgheqnecuggftrfgrthhtvg hrnhepteetfeefgeetfeelteefieeuteeghfdtffetudeihfejuddvveefvedutdfhtdff necuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehthhhjsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id C6834A60078; Mon, 6 May 2024 11:34:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-437-gcad818a2a-fm-20240502.001-gcad818a2 MIME-Version: 1.0 Message-Id: In-Reply-To: References: <20240502135541.47142-1-thj@freebsd.org> <20240503094615.1427-1-thj@freebsd.org> Date: Mon, 06 May 2024 16:34:04 +0100 From: "Tom Jones" To: "Bruce Richardson" Cc: dev@dpdk.org Subject: Re: [PATCH] freebsd: Add support for multiple dpdk instances on FreeBSD Content-Type: text/plain X-Mailman-Approved-At: Tue, 07 May 2024 09:04:04 +0200 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 testing this out the biggest gap I see is that we need a documentation >> update for it. In V3 can you please update the FreeBSD GSG doc with some >> details about how to use this feature. >> >> Also, on first run using testpmd, the application failed to start, as I was >> missing a file-prefix option. At minimum I think the code needs to default >> the file-prefix on BSD to "contigmem0", so that when running a standalone >> app as before, it "just works". An idea for backward compatibility here >> that may help us, is to omit the "0" for contigmem0 device. That would mean >> that an older DPDK app will work with a newer kernel driver, and vice >> versa. >> >> Beyond that, I'm not sure how to get multiple processes working right now >> (hence the doc update request!). When I run a second instance of DPDK on my >> system with "--file-prefix=contigmem1", I get errors about the shared >> config file in "/var/run/dpdk/rte/config". >> > Inspiration struck me just after I hit send on this email. Removing the > #ifdefs in eal_common_options.c allows me to run two processes in > parallel just fine. > > I think we need to consider how to rework this to avoid using the > file-prefix argument for the contigmem files. Not sure what a better scheme > is, though. Do you have any ideas or suggestions on this from your > experience doing up this patch? Thanks for testing I'll fix these pieces up. I'll add a default to /dev/contigmem0, it'll fail to get the lock in normal use so it shouldn't be a problem. I have done basically all of my testing through vpp, I can't say I've ever had much luck getting testpmd to do more than just start up. I resused the exist file-prefix interface as it allowed the smallest change to vpp[1]. I'm not normally a fan of such overloading, but it isn't so bad in this case. I tried adding a compatible patch with the old /dev/contigmem and sysctl API, but it added a lot to the driver to handle a case I'm not sure we need. I think my next steps should be: - add a default for the file prefix - documentation for the new option with those I'll try to post a v3 patch this week. - Tom [1]: https://github.com/adventureloop/vpp/commit/d49be6e1958016c2d680c2e06e23c42988911aa7