From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>
Subject: Re: [RFC] Add hot plug event in rte eal interrupt and
 inplement it in i40e driver.
Date: Thu, 15 Jun 2017 23:22:40 +0200
Message-ID: <20170615212240.GE29091@bidouze.vm.6wind.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=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: "Guo, Jia" <jia.guo@intel.com>, "Zhang, Helin" <helin.zhang@intel.com>,
 "Richardson, Bruce" <bruce.richardson@intel.com>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "Liu, Yuanhan" <yuanhan.liu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
To: "Wu, Jingjing" <jingjing.wu@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com
 [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id 23B762BBB
 for <dev@dpdk.org>; Thu, 15 Jun 2017 23:22:50 +0200 (CEST)
Received: by mail-wr0-f180.google.com with SMTP id r103so28865658wrb.0
 for <dev@dpdk.org>; Thu, 15 Jun 2017 14:22:50 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <9BB6961774997848B5B42BEC655768F810D9C9FA@SHSMSX103.ccr.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Jingjing,

On Wed, Jun 07, 2017 at 07:40:37AM +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?
> 

Sure.

> > 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?
> 

Ah yes, I was actually mistaken and thought more UIO parts would be
moving.

> > 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.
> Didn't get the idea. Why it will result in a simpler API? Is there any patch help
> Me to understand?
> 

How do you demux the hotplug_fd for several drivers / device?

-- 
Gaëtan Rivet
6WIND