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 8D092A0C4B; Thu, 14 Oct 2021 19:53:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10E4940041; Thu, 14 Oct 2021 19:53:20 +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 3C8B94003C for ; Thu, 14 Oct 2021 19:53:19 +0200 (CEST) Received: by mail-lf1-f52.google.com with SMTP id p16so30637675lfa.2 for ; Thu, 14 Oct 2021 10:53:19 -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=gSbKYq2/iJ5nJMhLtGwjeZIP3qYsv8sUqipzUxB+DPU=; b=bcvj0Jh1W7S3dG85pCiyXdsCBBYFYJixCoYF09LFfTbOTz52lPUNzG6nQII0lYfuL0 IZcFRZNU6xR+5cUelTPjc9SPP1AvIe2oLqybt7ia1hmXNoiGdMV8gYzz3p/JjP9bw3b1 eVjApft3E7YmcFhF6cVktvu6Ndc4JLhb0fat1Nke1uDF7kmtpPqLTphDPb+kLO4jzie6 WnedP+DVExwykIskW95tDKp+0znTVojNlAyyup/kry7eiaRP/lCdz23VM/DGGwvwIIK6 2M4Z4LUaFttUhWIL51lZaMk4kzA5+OIDdjbWwfZlbl+8vzBkK8jWM8JWDxRSG20xCvs2 QVKA== 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=gSbKYq2/iJ5nJMhLtGwjeZIP3qYsv8sUqipzUxB+DPU=; b=gVJImJ9UUprG5s2QXIJoOYJDh9zbUdByGPLGZNW9SdQQ605q2rT2bHMUrrE3BiIhT9 4zZiyTTcDumqyr+Ac1RtFz0zeuwUUlQn2x3NnhGSn3vAxSu6BfasvUYXduhiaFLyJUro Oy2x1GBVEAvezErNNvVbrJMznRkgfclLrXvOAdp0pl37kfHGOd9L7niZKo7+En71Abu+ F90CHUpWYZJlYfpes08ffocA4akqgc9XUPOF+rTk97Pj9WZgtL+JN79FOBVCXKzESb4e C+Jg7yotkRMDbH3nXJsNT7N3UzO3M9klk1wy3W4j/+1V0r/oE1HccB484uarV/gTzm+D Vn8Q== X-Gm-Message-State: AOAM531YjkDs/dyaqbaW3KsWTdTz5g6wMxla5JcKCOMM2sx7SYj4QtWA xBCrUHRWiS6xQqV49sNgstY= X-Google-Smtp-Source: ABdhPJycDc4kCVPpsWQ278ara6f06ajWEkYwrOJru5gppvm/DijtTXiBHH0nuCZF2XvhFmyKoWFo5w== X-Received: by 2002:a05:6512:20ce:: with SMTP id u14mr6594871lfr.548.1634233998715; Thu, 14 Oct 2021 10:53:18 -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 o13sm279858lfn.59.2021.10.14.10.53.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 10:53:18 -0700 (PDT) Date: Thu, 14 Oct 2021 20:53:17 +0300 From: Dmitry Kozlyuk To: Harman Kalra Cc: "dev@dpdk.org" , Thomas Monjalon , Ray Kinsella , "david.marchand@redhat.com" Message-ID: <20211014205317.5eb42ec9@sovereign> In-Reply-To: References: <20210826145726.102081-1-hkalra@marvell.com> <20211005121502.66964-1-hkalra@marvell.com> <20211005121502.66964-2-hkalra@marvell.com> <20211014035852.7bb70657@sovereign> 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 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" 2021-10-14 17:15 (UTC+0000), Harman Kalra: > [...] > > > +int rte_intr_fd_get(const struct rte_intr_handle *intr_handle) { > > > + if (intr_handle == NULL) { > > > + RTE_LOG(ERR, EAL, "Interrupt instance unallocated\n"); > > > + rte_errno = ENOTSUP; > > > + goto fail; > > > + } > > > + > > > + return intr_handle->fd; > > > +fail: > > > + return -1; > > > +} > > > > Please add a similar pair of experimental API for the "handle" member, it is > > needed for Windows interrupt support I'm working on top of these series > > (IIUC, API changes should be closed by RC1.) If you will be doing this and > > don't like "handle" name, it might be like "dev_handle" or > > "windows_device". > > I add new APIs to get/set handle. Let's rename it to "windows_handle" The name works for me, thanks. > > > [...] > > > +int rte_intr_max_intr_set(struct rte_intr_handle *intr_handle, > > > + int max_intr) > > > +{ > > > + if (intr_handle == NULL) { > > > + RTE_LOG(ERR, EAL, "Interrupt instance unallocated\n"); > > > + rte_errno = ENOTSUP; > > > + goto fail; > > > + } > > > + > > > + if (max_intr > intr_handle->nb_intr) { > > > + RTE_LOG(ERR, EAL, "Max_intr=%d greater than > > > +RTE_MAX_RXTX_INTR_VEC_ID=%d", > > > > The macros is not used in the comparison, neither should the log mention it. > > I will add the check. What check? I mean that the condition is `max_intr > intr_handle->nb_intr`, so `RTE_MAX_RXTX_INTR_VEC_ID` is not relevant, `intr_handle->nb_intr` is dynamic. Probably it should be like this: RTE_LOG(ERR, EAL, "Maximum interrupt vector ID (%d) exceeds " "the number of available events (%d)\n", max_intr, intr_handle->nb_intr); > [...] > > > + 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.