From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com [74.125.83.46]) by dpdk.org (Postfix) with ESMTP id E452A5699 for ; Thu, 29 Jun 2017 19:27:52 +0200 (CEST) Received: by mail-pg0-f46.google.com with SMTP id t186so51343653pgb.1 for ; Thu, 29 Jun 2017 10:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=v6Ld+eM2/dWKQQL+jYtaQv/DTBWRsqpWKqFVRVs/fcI=; b=N6OEQUytL8rzH9aujKKG0kX1PnikXkFo7Eejt2laHi4Fy0swslF9oj+OLLxHMA3ZZS GNH0dX4T2pGAVyS8Ujds6x9gD0W0XPz4AH0ORd88umLS1K4s7yWY762l+eZrDa+jRBgG TZYvV6TILvEaO8XA4gVHNIcK6TFySVHel7NnAnF5ratrFo7LHNVpZntdZvY+nEzLK49r ZMfgU1pCm+/OXKskuvtG0AOXGRCjZBF3WxNEvoMZnIAEIk8ygbIOxsC4PSnngtIr4GH7 GhbrgIOnDE/jP6fml2fsk5PYrDhuOzZ1INat6rlEpeMVa++h7Gxy2ncAYmv2BTAwn0Qt pypQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=v6Ld+eM2/dWKQQL+jYtaQv/DTBWRsqpWKqFVRVs/fcI=; b=i9Lg5mSbUYju/nmzstwLXBmX8CUD8ZuPI6VOZXX0QNPv+/0RwEumumrnM4g3cc7K8B CRQ2Abc5yCs6sZbMgvcRSGmjBROM36Ej4kNC8rP+L9Glv7K/pJ6kxF/LTnLBXnv4Aa1m iyTnpR1WgKZxwIDrwmiBvB7MERmzST9VY4TR+qwoo7RhQ5zMMpmnVRZT76Ck/6OxK3Ry nCfxjKxFeUmx3X4/hJ2FgzpyC8Pr+knf6wnusQ5r++YXYzZq6cw8SPhPxlRcNLCf3VmR CaFeW044MYTwMEL270pllWDgxqpfjEi5FcJhGfZNSfjHqGAX5DUFJneeePo8EYz+xmnR 8IoQ== X-Gm-Message-State: AKS2vOy42Pa9s+E0HhWicvq0DstRa4IX2Fb5sw17Lj6ZARBtC25ldwjL qp9X7nJCTD1GnXa1 X-Received: by 10.98.25.8 with SMTP id 8mr17635399pfz.80.1498757272162; Thu, 29 Jun 2017 10:27:52 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id n19sm9169611pfa.64.2017.06.29.10.27.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Jun 2017 10:27:52 -0700 (PDT) Date: Thu, 29 Jun 2017 10:27:48 -0700 From: Stephen Hemminger To: "Wu, Jingjing" Cc: =?UTF-8?B?R2HDq3Rhbg==?= Rivet , "Guo, Jia" , "Zhang, Helin" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Liu, Yuanhan" , "dev@dpdk.org" Message-ID: <20170629102748.2b5caa72@xeon-e3> In-Reply-To: <9BB6961774997848B5B42BEC655768F810D9C9FA@SHSMSX103.ccr.corp.intel.com> References: <1495986280-26207-1-git-send-email-jia.guo@intel.com> <20170530071400.GN14914@bidouze.vm.6wind.com> <9BB6961774997848B5B42BEC655768F810D9C9FA@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and inplement it in i40e driver. 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, 29 Jun 2017 17:27:54 -0000 On Wed, 7 Jun 2017 07:40:37 +0000 "Wu, Jingjing" wrote: > > > > > >Secondly, in order to read out the uevent that monitoring, we need to add uevent API in rte > > layer. We plan add 2 , rte_uevent_connect and rte_get_uevent. All driver interrupt handler > > could use these API to enable the uevent monitoring, and read out the uevent type , then > > corresponding to handle these uevent, such as detach the device when get the remove type. > > > > > > > I find having a generic uevent API interesting. > > > > However, all specifics pertaining to UIO use (hotplug_fd, subsystem > > enum) should stay in UIO specific code (eal_pci_uio.c?). > > > Yes, but it can be also considered as interrupt mechanism, right? > > > I am currently moving the PCI bus out of the EAL. EAL subsystems should > > not rely on PCI specifics, as they won't be available afterward. > > Will the interrupt handling be kept in EAL, right? > > > It should also allow you to clean up your API. Exposing hotplug_fd and > > requiring PMDs to link it can be avoided and should result in a simpler > > API. You were right given the current model this is the correct way to do it. It would be good if the interrupt model stuff could be moved back into EAL so that if device is removed, no code in driver needs to be added. All the bus -> device -> interrupt state is visible, and EAL should be able to unwind from there. Thinking more of the Linux model where there is no need (in general) for hot plug specific code in each driver.