From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id C7FF423C for ; Thu, 18 Jan 2018 05:17:10 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 20:17:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,375,1511856000"; d="scan'208";a="11272153" Received: from jguo15x-mobl3.ccr.corp.intel.com (HELO [10.67.68.51]) ([10.67.68.51]) by fmsmga008.fm.intel.com with ESMTP; 17 Jan 2018 20:17:06 -0800 To: Thomas Monjalon References: <1515679534-22473-2-git-send-email-jia.guo@intel.com> <1516013331-18939-1-git-send-email-jia.guo@intel.com> <1516013331-18939-2-git-send-email-jia.guo@intel.com> <6977991.UJJFCEQyNF@xps> Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, gaetan.rivet@6wind.com, konstantin.ananyev@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com, jingjing.wu@intel.com, helin.zhang@intel.com, motih@mellanox.com From: "Guo, Jia" Message-ID: Date: Thu, 18 Jan 2018 12:17:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6977991.UJJFCEQyNF@xps> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH V11 2/3] eal: add uevent pass and process function 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, 18 Jan 2018 04:17:11 -0000 On 1/18/2018 6:00 AM, Thomas Monjalon wrote: > 15/01/2018 11:48, Jeff Guo: >> +enum rte_dev_event_subsystem { >> + RTE_DEV_EVENT_SUBSYSTEM_UIO, >> + RTE_DEV_EVENT_SUBSYSTEM_VFIO, >> + RTE_DEV_EVENT_SUBSYSTEM_PCI, >> + RTE_DEV_EVENT_SUBSYSTEM_MAX >> +}; > I still don't understand this classification, mixing PCI and VFIO > at the same level. ok, so let me explicit explain that that is because the deference kernel version would poke deference subsystem info from the net link message. so just forcus on the new kernel version would be fine and delete pci item.