From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f68.google.com (mail-oi0-f68.google.com [209.85.218.68]) by dpdk.org (Postfix) with ESMTP id 9F142A495 for ; Sun, 14 Jan 2018 04:53:17 +0100 (CET) Received: by mail-oi0-f68.google.com with SMTP id d124so6338797oib.13 for ; Sat, 13 Jan 2018 19:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UHMWARk/ld0ERfWomGOcLdecu6tzzt92r3BrYwjJ84k=; b=JPCUfgp1/5+biSwClZMM837EJfQNAmijHShtfMiyQm4eQhAGghYaUHrdnJxb0GSNiR udbndo5/R1WIpkaiUzl6iHH3q/NO3EsNGL9ocwx8HHqZEk+zxTrvqMdPRoI1rDV2icHq 1zYguXlpc40/3J8f2TB2af2mCzV0KuyCXsyObTFoEUTn0TrcClP/VrkvBV0NAQ3jjzVR AgWue//vR/Z3AhsTLd2xmNjrO4XbgHONCrg5OOLgFDERUf3LxPoHP21PaXHil42MIZFL N/fQLnjY4TTM19aJNLP5/1pWK89f/yJKGndWMNb5xwhObr5LD8KN05JUcxZTpwcfbczN bxlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UHMWARk/ld0ERfWomGOcLdecu6tzzt92r3BrYwjJ84k=; b=nwoqFZaqaNwb4sjI3f8qZs4dcR7N1ypZhpJBjbOy176fCGHpxlTU5XOt/9Ki38kugp fb7IRQscE11vtthpiAwPGaw1zE5MOHQEE3qajGeAIM3s3tqSlkXZt5OQQOCEiuHYn0T9 xiJ/kONBQw3P7Ul5DrpwcQ2optyZgPNLCiQMU15W4AHfLO7zSADCTGQFOXRxrlt0lx7S 3vXGPgb32MFk7CDWDyoO6b581Whzj4m4l83QsZo7ytDEm0Lm7BjNsO1JxUEC857jLjGg d4yECUBgtuDcOP40R4wRT1ZWC/kaexp0Qs787BfvPCbAEzetVovmSOp2FBRpYD4nyRuX L5BQ== X-Gm-Message-State: AKwxyteOnDD9xc0tKkNuKfGFSZRLUEHl2YZ2Dtu6Zt8Ix+2XDcr7n/oY 4KWuzOmaxRYOAgfzVtpSlZlGkIQ/VSQjA3qhTlQvfUPs X-Google-Smtp-Source: ACJfBosr1VvwbhDIjHevP/u3FE0Xh4i1mJWMlgb1y6uwSVmp5RspV+xC/I/HMf35n/C7rFgA48r0Eh73CD36d8XZ9dI= X-Received: by 10.202.45.7 with SMTP id t7mr11576331oit.356.1515901995548; Sat, 13 Jan 2018 19:53:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.151.65 with HTTP; Sat, 13 Jan 2018 19:53:15 -0800 (PST) In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D66CF21B7C@PGSMSX112.gar.corp.intel.com> References: <1515688791-2794-1-git-send-email-xiangxia.m.yue@gmail.com> <49759EB36A64CF4892C1AFEC9231E8D66CF21B7C@PGSMSX112.gar.corp.intel.com> From: Tonghao Zhang Date: Sun, 14 Jan 2018 11:53:15 +0800 Message-ID: To: "Dai, Wei" Cc: "Xing, Beilei" , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 1/4] net/ixgbevf: unregister irq handler when other interrupts not allowed. 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: Sun, 14 Jan 2018 03:53:17 -0000 On Fri, Jan 12, 2018 at 4:39 PM, Dai, Wei wrote: > Hi, Tonghao & Beilei > > The issue reported by Tonghao is caused by shortage of igb_uio. > If you want to use Rx queue interrupt in your DPDK application, > I suggest use VFIO-PCI to bind NIC port instead of igb_uio. The performance of igb_uio is better than vfio-pic. So igb_uio is a better solution. And the PF binded with igb_uio can use the rx queue interrupt, because it unregister the irq handler in eal-intr-thread via rte_intr_callback_unregister. Then the PF will also not handler the irq (mailbox) from VF, right ? To support the feature of rx queue interrupt , the PF and VF binded with igb_uio may unregister the other irq. > Currently igb_uio only support single event fd. This fd is triggered by > both miscellaneous and RX queue interrupt in ixgbe VF. > But same event fd is added to epoll fd of eal-intr-thread > and also epoll fd of normal thread for Rx task, this cause the issue. Yes, it's right > If VFIO-PCI is used, different event fd for misc and Rx queue are created. > By the way, your patch also lead to missing of PF to VF reset interrupt. > So, I am sorry that I can't agree it now. > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of >> xiangxia.m.yue@gmail.com >> Sent: Friday, January 12, 2018 12:40 AM >> To: Xing, Beilei ; dev@dpdk.org >> Cc: Tonghao Zhang >> Subject: [dpdk-dev] [PATCH v2 1/4] net/ixgbevf: unregister irq handler when >> other interrupts not allowed. >> >> From: Tonghao Zhang >> >> When bind the ixgbe VF (e.g 82599 card) to igb_uio and enable the >> rx-interrupt, there will be more than one epoll_wait on intr_handle.fd. >> One is in "eal-intr-thread" thread, and the others are in the thread which call >> the "rte_epoll_wait". The problem is that sometimes "eal-intr-thread" thread >> will process the rx interrupt, and then rte_epoll_wait can't get the event >> anymore, and the packets may be lost. >> >> The patch unregister the status interrupt handler in "eal-intr-thread" >> thread and the ixgbe pf is in the same case. >> >> Signed-off-by: Tonghao Zhang >> Acked-by: Beilei Xing >> --- >> drivers/net/ixgbe/ixgbe_ethdev.c | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c >> b/drivers/net/ixgbe/ixgbe_ethdev.c >> index ff19a56..0e056a2 100644 >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c >> @@ -5078,6 +5078,15 @@ static int >> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, >> } >> ixgbevf_configure_msix(dev); >> >> + if (!rte_intr_allow_others(intr_handle)) { >> + rte_intr_callback_unregister(intr_handle, >> + ixgbevf_dev_interrupt_handler, >> + dev); >> + if (dev->data->dev_conf.intr_conf.lsc != 0) >> + PMD_INIT_LOG(INFO, "lsc won't enable because of" >> + " no intr multiplex"); >> + } >> + >> /* When a VF port is bound to VFIO-PCI, only miscellaneous interrupt >> * is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ). >> * If previous VFIO interrupt mapping setting in eth_ixgbevf_dev_init( ) >> @@ -5120,6 +5129,12 @@ static int >> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, >> >> ixgbe_dev_clear_queues(dev); >> >> + if (!rte_intr_allow_others(intr_handle)) >> + /* resume to the default handler */ >> + rte_intr_callback_register(intr_handle, >> + ixgbevf_dev_interrupt_handler, >> + (void *)dev); >> + >> /* Clean datapath event and queue/vec mapping */ >> rte_intr_efd_disable(intr_handle); >> if (intr_handle->intr_vec != NULL) { >> -- >> 1.8.3.1 >