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 054ACA0C4B; Fri, 15 Oct 2021 09:53:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF088410F1; Fri, 15 Oct 2021 09:53:45 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 6C6F040692 for ; Fri, 15 Oct 2021 09:53:44 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 147773200681; Fri, 15 Oct 2021 03:53:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 15 Oct 2021 03:53:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= Oli1n6GT3FWGnnwJymSakmKqgnHgX3BCAqAKGjrrFmI=; b=codZNemAhVy8tULp x9V1WoTTOh88oA4Mtj5VDEVWLkNpWsznQusTRVDpb+/U8NiIuiKYm1F2o1HHBkOy vcxTmTgqBldps2r+Pfj/Gz6xeLsj+DsDsH4f2bA0anCnqjGr+AuKkos17K1MMP+a u/GpmR1PF8+kjilBHTZbgJ0fr7pHNg/RmtDVy9Y8gTynjKCL+REpWP4vUT2GMR/j n4sOQaBuEC54vweIA5wfwUOe97ViY3yNZMd+V1GqUBZ78esAYXnSVLC/KmdbXivs aHIztFUxnT/2oaVVca9wu8mJMNurtyL4caBJxvTu2UwT+Dyh9Ya3kfOLKdxpc+6m mB7J1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Oli1n6GT3FWGnnwJymSakmKqgnHgX3BCAqAKGjrrF mI=; b=Qf5EjpssSjroF3dLBBlZ6VjV/+lVDjoqom3IdPJM+B88W60ttdjG29j8c JyP1kLZo73lT+kUwpbGH5aachp1CrmmCBIZlhOgLnRgiUeo0YJRVqqhelmLs3iD3 a2xu+VjYhTizkqFWBm+AqJw5rDy6OKfDLOD682mX2xly0B/wwbfLU4J/Af2XSGQk hoC2NKUqw5dPw1qOJn7kyUKE+c5LDleBY8Dpk5DEBq42VX1U0zvqqORRCcYEtYiH TS7VlYAe/Aa8a9het2y80gVXVcbl7Dxl1aQswZBIDcZLmyw5uagyvRDB5mf/7hE2 zHEuYahVZe/uY08tNwaNUImHwqB4w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddufedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Oct 2021 03:53:38 -0400 (EDT) From: Thomas Monjalon To: Harman Kalra , Dmitry Kozlyuk Cc: "dev@dpdk.org" , Ray Kinsella , "david.marchand@redhat.com" , bruce.richardson@intel.com, stephen@networkplumber.org Date: Fri, 15 Oct 2021 09:53:34 +0200 Message-ID: <1720722.lqNvvj56Xc@thomas> In-Reply-To: <20211014205317.5eb42ec9@sovereign> References: <20210826145726.102081-1-hkalra@marvell.com> <20211014205317.5eb42ec9@sovereign> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/6] 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" 14/10/2021 19:53, Dmitry Kozlyuk: > 2021-10-14 17:15 (UTC+0000), Harman Kalra: > > > > + rte_intr_type_set; > > > > + rte_intr_type_get; > > > > + rte_intr_instance_alloc; > > > > + rte_intr_instance_free; > > > > }; > > > > > > Do I understand correctly that these exports are needed to allow an > > > application to use DPDK callback facilities for its own interrupt sources? > > > > I exported only those APIs which are currently used by test suite or example > > applications, may be later more APIs can be moved from internal to public on > > need basis. > > > > > If so, I'd suggest that instead we export a simpler set of functions: > > > 1. Create/free a handle instance with automatic fixed type selection. > > > 2. Trigger an interrupt on the specified handle instance. > > > The flow would be that the application listens on whatever it wants, probably > > > with OS-specific mechanisms, and just notifies the interrupt thread about > > > events to trigger callbacks. > > > Because these APIs are experimental we don't need to change it now, just my > > > thoughts for the future. > > > > I am sorry but I did not followed your suggestion, can you please explain. > > These API is used as follows. The application has a file descriptor > that becomes readable on some event. The programmer doesn't want to create > another thread like EAL interrupt thread, implement thread-safe callback > registration and invocation. They want to reuse DPDK mechanism instead. > So they create an instance of type EXT and give it the descriptor. > In case of the unit test the descriptor is a pipe read end. > In case of a real application it can be a socket, like in mlx5 PMD. > This is often convenient, but not always. An event may be a signal, > or busy-wait end, or it may be Windows with its completely different IO model > (it's "issue an IO, wait for completion" instead of POSIX > "wait for IO readiness, do a blocking IO"). > In all these cases the user needs to create a fake pipe (or whatever) > to fit into how the interrupt thread waits for events. > But what the application really needs is to say "there's an event, please run > the callback on this handle". It's a function call that doesn't require any > explicit file descriptors or handles, doesn't rely on any IO model. > How it is implemented depends on the EAL, for POSIX it will probably be > an internal pipe, Windows can use APC as in eal_intr_thread_schedule(). > Again, I'm thinking out loud here, nothing of this needs to be done now. I like this way of thinking.