From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id E091510DB9 for ; Thu, 22 Dec 2016 19:26:45 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id g23so37664886wme.1 for ; Thu, 22 Dec 2016 10:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WRKEOMNhrYRzPqehYUnV0+sodrxFBZ7c7JeQXeqsIv0=; b=A5IT443/YABF1w/Aj+gpyc1Yvf+ScQLoYAhSgo8SwcHaoAwOHay/wKv4usRL8kKLK6 qWYGWACwNBICIOAqOeWa/MJtbbCkAROGSqQfiCtXLV+S7dzFyqdGtpfXg3ASx/3Ft6JJ LoSpF+Yfe4Y5XjUEVXa6AXeS5JgMcdMblTtboKNfFquwmI5qiiOk9ZuNiBACOKvnDfQf MVOFi9e+ZR9b7A8gw148s2NTNhi5bW/7caiAeJ46e7ijYLZvOUn+BYJ4bgP3fEK8b4JO ohDaW3FPOVMhs9mrZ9ouHxG3xEK/ZuWxD0NX7i4NxEo8MR2AyH4cUWXQJhPV3CTjsx4O MI8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WRKEOMNhrYRzPqehYUnV0+sodrxFBZ7c7JeQXeqsIv0=; b=jA3W7Af9r06Ljwij/VbF0iCRoJ7mwne5yCbv8kTnqmsWioE72qdHcOH2GgXnkwaxrR 76UzbjqATiclw8zjyLLvFRrmlxPNT8G+cAbMdzNoYFxHwZPaFTDJ3HNVnByVmtdNyxZW ht5Zdbsgm9cD6hAVUnIm20aHGovLaq/4obLsX1Wn/98gt4IBUBsYn1+Cd3syU3vMuD9Z YmrJr1/GJILxSECJ+Gkl5zjlGl7w9IsE+3/MOtVuZHmb/lYovO0TYZTxa7EndZEbcGGM R4H66+3ohFuSDn23Gp4RHMPgf/jTK1qxgDwB5dZsuE/Jn44dSQpG0wK1k7fUUBloqtMi aXaw== X-Gm-Message-State: AIkVDXIhOzImgDUV/dBB+8QWBz4EvdMODfXLSR4mZHIHY7euyQi5Okqi7Uk5GpRHldsOhMEYuBGm0VgIFHBpeA== X-Received: by 10.28.105.81 with SMTP id e78mr11116298wmc.140.1482431205518; Thu, 22 Dec 2016 10:26:45 -0800 (PST) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.63.83 with HTTP; Thu, 22 Dec 2016 10:26:44 -0800 (PST) In-Reply-To: <8699988.5R756v89bM@xps13> References: <1482332986-7599-1-git-send-email-jblunck@infradead.org> <1482332986-7599-23-git-send-email-jblunck@infradead.org> <8699988.5R756v89bM@xps13> From: Jan Blunck Date: Thu, 22 Dec 2016 19:26:44 +0100 X-Google-Sender-Auth: DJthZ4gABNSJ9d_iMF3u4XRhSik Message-ID: To: Thomas Monjalon Cc: dev@dpdk.org, Shreyansh Jain , David Marchand , Stephen Hemminger Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v4 22/23] ethdev: Decouple interrupt handling from PCI device X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 18:26:46 -0000 On Thu, Dec 22, 2016 at 4:13 PM, Thomas Monjalon wrote: > 2016-12-21 16:09, Jan Blunck: >> The struct rte_intr_handle is an abstraction layer for different types of >> interrupt mechanisms. It is embedded in the low-level device (e.g. PCI). >> On allocation of a struct rte_eth_dev a reference to the intr_handle >> should be stored for devices supporting interrupts. > [...] >> --- a/lib/librte_ether/rte_ethdev.h >> +++ b/lib/librte_ether/rte_ethdev.h >> @@ -1629,6 +1629,7 @@ struct rte_eth_dev { >> const struct eth_driver *driver;/**< Driver for this device */ >> const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */ >> struct rte_pci_device *pci_dev; /**< PCI info. supplied by probing */ >> + struct rte_intr_handle *intr_handle; /**< Device interrupt handle */ >> /** User application callbacks for NIC interrupts */ >> struct rte_eth_dev_cb_list link_intr_cbs; >> /** > > Why adding interrupt in ethdev? > Shouldn't it be a property of rte_device? Good question. I don't think that rte_device should become an abstraction layer for all kind of real/virtual devices functionality. There are devices that do not support interrupts and this functionality is around enabling irqs per queue. Since this is a concept of the ethdev I believe the right place to keep a reference to the IRQ implementation is the rte_eth_dev.