From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by dpdk.org (Postfix) with ESMTP id 1A86BFA61 for ; Thu, 19 Jan 2017 21:33:54 +0100 (CET) Received: by mail-vk0-f44.google.com with SMTP id t8so38580892vke.3 for ; Thu, 19 Jan 2017 12:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q1dWt+Gb+dmm3k8add0IO/fHQhtMIVM9iALnIYVF370=; b=pJTlvTQNlQn6OgUn0jg5ecqR4/gK6HhoDIX4d3pRNEMwe7gn3CPrCS74s5gokEi7Px yqkr8H4y9d7y9q66l6kqBBauoNwna6+++089D43YtYf4JznO0ftReqQ69yBYoZtXAAR+ BqZYOR9vW23eaElbPmxig2F9b4rZUxBdhOKsvpDI4cHZ/H4BrDzEBnpdHdYBHxa/z2wV +QASo95Rc9U9O5RlJztb9mlo6vVSJVoYAHaSdS4dMSsl93YWUiM4ql8+be4xpC/zSn3j LjoZp60jziCVnAt/Q+GHMOBWZfOHXClrUkzLS7HW0hY2sPyJCpjRZfzdepqwp8GDr9Ou ZKLA== 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=q1dWt+Gb+dmm3k8add0IO/fHQhtMIVM9iALnIYVF370=; b=WNHr9Sud97qeGVt2uy5TBqynKYv0mXnxtn9XGXyibbFOLEWW5Wgn6MMVb3U7s3+nTO WKj2OpLu5Z1Tk1NdBVK+WQQ0DkrpV4ZZe7UOS04O44G6u4lmw7uvLKBKRD/8IvVmTQj/ fouhezggWdhRqXhI2ABBq8Xkq0VaHZGSlDFjS1Pt/l1W+EeQtTMiVqdrDvUR0bwvThcU k1bk2Nsnr3ZW7uGdBsjPCljmB6AgFgwtZfykK0AvaaXvSyya09QitNGnvGIfm559yyy8 phu6eEt/z78+1CDo1IzV/2Dc7TatB9l2YPaJYgGJ9fkcIbHoJ/T1FjYbemS0ad3JOunb WeLw== X-Gm-Message-State: AIkVDXImumLnH3Te8Tb3XMbHLY7leALBq68f+Cgf96ogvqIecV6diUTekqek8P1KwTy6Wgo2kz4YKq4qclMIqE4S X-Received: by 10.31.69.201 with SMTP id s192mr4723860vka.37.1484858034171; Thu, 19 Jan 2017 12:33:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.146.141 with HTTP; Thu, 19 Jan 2017 12:33:53 -0800 (PST) In-Reply-To: References: <3355891.l3I590SjcV@polaris> <608e7dfd-5226-3e30-f43b-0fbe01aee16a@intel.com> <7605618f-dc86-3060-473e-aff5545cac72@intel.com> From: Alejandro Lucero Date: Thu, 19 Jan 2017 20:33:53 +0000 Message-ID: To: Ferruh Yigit Cc: "Tan, Jianfeng" , Gregory Etelson , dev , "users@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-users] IGB_UIO: PCI Resources Management 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, 19 Jan 2017 20:33:55 -0000 On Thu, Jan 19, 2017 at 4:36 PM, Ferruh Yigit wrote: > On 1/13/2017 11:10 AM, Alejandro Lucero wrote: > > I completely misread the patch, and I wrongly thought that code was > > linked to module removal, but I see this is not about that, but about > > releasing the /dev/uio file calling release function, what is done by > > the kernel when the process exits. > > > > So yes, the patch avoids the problem I talked about. > > > > However, calling that specific ixgbe driver function will break other > > devices relying on igb_uio. What about implementing a notifier chain for > > this? The igb_uio code would be agnostic and each interested driver, > > like ixgbe or nfp_net, could execute the specific port close code when > > the notifier chain triggers. > > Can you please elaborate, how can this be done? > This is kernel code, and interested drivers are in userspace. This patch > benefit from Linux kernel driver of same device. > > The patch seems to add a function to the ixgve_vf kernel driver which will be called from igb_uio. The patch does not show the usual path to the kernel ethernet drivers because, I guess, it is a patch for a specific software build. So the interested drivers are not in user space, and a driver, igb_uio, calling a userspace function? No way. Any netdev driver interested to close ports, those left working by a crashed DPDK app, could register a notifier like this: int device_notifier(struct notifier_block *nb, unsigned long action, void *data) { ... if (action == NETDEV_GOING_DOWN) { ... } struct notifier_block device_nb = { .notifier_call =device_notifier, }; ... register_netdev_notifer(&device_nb); ... Inside igb_uio, something like this: raw_notifier_call_chain(&netdev_chain, val, dev); which would trigger the invocation of all registered notifier functions. Please, note that this is just a possibility, and the notifier chain to use could not be the best one, same for the event NETDEV_GOING_DOWN. Also, how can the drivers know if that event is for them?, This is something to work on. Because UIO is part of the kernel, maybe it could be pushed a specific chain for this purpose if we can not use any currently available. > > > > > > On Fri, Jan 13, 2017 at 5:33 AM, Tan, Jianfeng > > wrote: > > > > > > > > > -----Original Message----- > > > From: Yigit, Ferruh > > > Sent: Friday, January 13, 2017 10:05 AM > > > To: Tan, Jianfeng; Alejandro Lucero > > > Cc: Gregory Etelson; dev; users@dpdk.org > > > Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources > Management > > > > > > On 1/13/2017 1:51 AM, Tan, Jianfeng wrote: > > > > > > > > > > > >> -----Original Message----- > > > >> From: users [mailto:users-bounces@dpdk.org > > ] On Behalf Of Ferruh Yigit > > > >> Sent: Thursday, January 12, 2017 8:22 PM > > > >> To: Alejandro Lucero > > > >> Cc: Gregory Etelson; dev; users@dpdk.org > > > > >> Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources > > > Management > > > >> > > > >> On 1/12/2017 12:12 PM, Alejandro Lucero wrote: > > > >>> > > > >>> > > > >>> On Thu, Jan 12, 2017 at 11:55 AM, Ferruh Yigit > > > > > >>> > >> wrote: > > > >>> > > > >>> On 12/9/2016 8:54 AM, Gregory Etelson wrote: > > > >>> > Hello, > > > >>> > > > > >>> > IGB_UIO driver does not close port PCI activities after > > DPDK process > > > >> exits. > > > >>> > DPDK API provides rte_eth_dev_close() to manage port PCI, > > > >>> > but it can be skipped if process receives SIGKILL signal > > > >>> > > > >>> I guess I understand the problem. > > > >>> > > > >>> > > > >>> This is a known problem, but it is not just a UIO problem, and > > this > > > >>> patch does not solve it, maybe it just solves part of it. > > > >>> > > > >>> In fact, a DPDK program crashing could imply the NIC DMAing > > after that > > > >>> and after that memory was assigned to another program. > > > >> > > > >> Yes. > > > >> Can there be a way to stop NIC DMA, (or prevent it access to mem > > > >> anymore) when app crashes? > > > >> I think that is what this patch is looking for. > > > > > > > > If I understand it correctly, you are looking for this patch? > > > > http://dpdk.org/dev/patchwork/patch/17495/ > > > > > > > > > > > > That is good, thanks Jianfeng, I will check it. > > > > > > btw, patch's current state is rejected, which is by mistake, it > > seems I > > > confused it with "iomem and ioport mapping" patch, sorry about it, > I > > > will update its status immediately. > > > > No problem at all. This patch is rejected as it's based on "iomem > > and ioport mapping" patch. As "iomem and ioport mapping" patch has > > backward compatibility issue, we need to figure out a way to > > resubmit this patch without changing the original "iomem and ioport > > mapping" in igb_uio. > > > > Thanks, > > Jianfeng > > > > > >