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 106B4A0C4C; Tue, 5 Oct 2021 18:07:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CCCEF413E2; Tue, 5 Oct 2021 18:07:55 +0200 (CEST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mails.dpdk.org (Postfix) with ESMTP id 15EDF413DF for ; Tue, 5 Oct 2021 18:07:54 +0200 (CEST) Received: by mail-pj1-f54.google.com with SMTP id ls18so4391159pjb.3 for ; Tue, 05 Oct 2021 09:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BmZOXgVeaq7DJs2PCfOY2i1KPlxm1L7IcnS+sXUUw8c=; b=rvv0znr1xq/q9RbYuXgyOmHM1deRFjVLfJBXaZTx+cbtj+HQuCNv9k3WNeHyR9caTJ N7hEaRmxJ2kjBvzk0DpMzUbilGrfwlPVlxbhQm/+Ib5R/lr7aavckQvwRzzEbTeO8C3h 4JBd83+ajxcGv0p72WISw+XEEZXTGej7R7Zdd99UapdFT6QIX1+cBrmJ3pxB8M+6uVvS PvlyURg+29Nst6dj9BJxjt5sksOdV/ulS7oQPuWroIGprTpgSkyaKnW2rUbdqrzMavuw 7bRcc0rh4YoomhSK427yPyIlJjGMb/Fj8sytQMWOkORdhmY9u/WlYAsR5olgN7QhhqyV C6Og== 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=BmZOXgVeaq7DJs2PCfOY2i1KPlxm1L7IcnS+sXUUw8c=; b=rN5Sy5R3rZnPgTc98ZMawyVBTVUvYbvVYizlyFLOSiUpiH8ZRZ2Xj79j3u5jg+jxxy KpXY9Czx8qiM8bFBiQx5PqZW4Cc1ZEBFxGx6X5CI6CB2oH9wYb/yah0aJMqUyCtM1HmX OoAMskq+4WsDfL6DGhXaPiRwwGZ4CkWDXZlG/HhRA+CR/cdHTFxhCNGTINzCyAeL+397 FtRZrW01he6nwODCbYLYXlfiqs+c2DmbC7UVR+xCAHPiT9FjNybz6/NPrButm3uX09Ei TFsSlKdi6OsK+EfaeZEec+LYXdCTxjV4RwSHO0ZHZT2Vn5ET9IIiaKK5xBaMk/o6iFhO p28g== X-Gm-Message-State: AOAM531fQqIWhb/Pz9SePR3tMeXjS8UH1hqRib1ZQs/MK9daVfXxiXfr XotZsFOWNEkaQpwzjaKk6egg4Ym4i0aEwA== X-Google-Smtp-Source: ABdhPJxPWsvofZ6aruAEKwlQ1Jjbt7EjuZrcAk2t4I2XDDYMN7JNBGFUCsIyXs5Kv4DXZdeH7TdpAw== X-Received: by 2002:a17:90a:30b:: with SMTP id 11mr4792026pje.136.1633450073121; Tue, 05 Oct 2021 09:07:53 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id m186sm18557949pfb.165.2021.10.05.09.07.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 09:07:52 -0700 (PDT) Date: Tue, 5 Oct 2021 09:07:50 -0700 From: Stephen Hemminger To: Harman Kalra Cc: Message-ID: <20211005090750.4d7329f1@hermes.local> In-Reply-To: <20210826145726.102081-1-hkalra@marvell.com> References: <20210826145726.102081-1-hkalra@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/7] make rte_intr_handle internal 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" On Thu, 26 Aug 2021 20:27:19 +0530 Harman Kalra wrote: > Moving struct rte_intr_handle as an internal structure to > avoid any ABI breakages in future. Since this structure defines > some static arrays and changing respective macros breaks the ABI. > Eg: > Currently RTE_MAX_RXTX_INTR_VEC_ID imposes a limit of maximum 512 > MSI-X interrupts that can be defined for a PCI device, while PCI > specification allows maximum 2048 MSI-X interrupts that can be used. > If some PCI device requires more than 512 vectors, either change the > RTE_MAX_RXTX_INTR_VEC_ID limit or dynamically allocate based on > PCI device MSI-X size on probe time. Either way its an ABI breakage. > > Change already included in 21.11 ABI improvement spreadsheet (item 42): > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_s > preadsheets_d_1betlC000ua5SsSiJIcC54mCCCJnW6voH5Dqv9UxeyfE_edit-23gid- > 3D0&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=5ESHPj7V-7JdkxT_Z_SU6RrS37ys4U > XudBQ_rrS5LRo&m=7dl3OmXU7QHMmWYB6V1hYJtq1cUkjfhXUwze2Si_48c&s=lh6DEGhR > Bg1shODpAy3RQk-H-0uQx5icRfUBf9dtCp4&e= > > > This series makes struct rte_intr_handle totally opaque to the outside > world by wrapping it inside a .c file and providing get set wrapper APIs > to read or manipulate its fields.. Any changes to be made to any of the > fields should be done via these get set APIs. > Introduced a new eal_common_interrupts.c where all these APIs are defined > and also hides struct rte_intr_handle definition. I agree rte_intr_handle and eth_devices structure needs to be hidden. But there does not appear to be an API to check if device supports receive interrupt mode. There is: RTE_ETH_DEV_INTR_LSC - link state RTE_ETH_DEV_INTR_RMV - interrupt on removal but no RTE_ETH_DEV_INTR_RXQ - device supports rxq interrupt There should be a new flag reported by devices, and the intr_conf should be checked in rte_eth_dev_configure Doing this would require fixes many drivers and there is risk of exposing existing sematic bugs in applications. code