From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 0F88F1B48B for ; Wed, 11 Jul 2018 05:10:50 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 20:10:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,336,1526367600"; d="scan'208";a="244265701" Received: from jguo15x-mobl3.ccr.corp.intel.com (HELO [10.67.68.71]) ([10.67.68.71]) by fmsmga005.fm.intel.com with ESMTP; 10 Jul 2018 20:10:46 -0700 To: Stephen Hemminger References: <1498711073-42917-1-git-send-email-jia.guo@intel.com> <1531220607-2977-1-git-send-email-jia.guo@intel.com> <1531220607-2977-8-git-send-email-jia.guo@intel.com> <20180710144813.2d08babf@xeon-e3> Cc: bruce.richardson@intel.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com, gaetan.rivet@6wind.com, jingjing.wu@intel.com, thomas@monjalon.net, motih@mellanox.com, matan@mellanox.com, harry.van.haaren@intel.com, qi.z.zhang@intel.com, shaopeng.he@intel.com, bernard.iremonger@intel.com, arybchenko@solarflare.com, wenzhuo.lu@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com, dev@dpdk.org, helin.zhang@intel.com From: Jeff Guo Message-ID: Date: Wed, 11 Jul 2018 11:10:44 +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: <20180710144813.2d08babf@xeon-e3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v8 7/7] igb_uio: fix uio release issue for hotplug 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: Wed, 11 Jul 2018 03:10:51 -0000 On 7/11/2018 5:48 AM, Stephen Hemminger wrote: > On Tue, 10 Jul 2018 19:03:27 +0800 > Jeff Guo wrote: > >> >> +/* uio pci device state */ >> +enum rte_udev_state { >> + RTE_UDEV_PROBED, >> + RTE_UDEV_OPENNED, >> + RTE_UDEV_RELEASED, >> + RTE_UDEV_REMOVED, >> +}; >> + > The states here are a little confusing. especially since pci_release > seems to take different actions based on the state. And there is nothing > preventing races between unexpected removal (PCI), and removing the > device from being used by igb_uio. The states here just manage in igb uio, and only restore the status of igb uio. And only the RTE_UDEV_REMOVED that the key status might be a highlight and process, it is means pci have been removed, then directly come to igb uio remove without go igb uio release at first, the status is for hotplug out, need to do specific process. It will no affect the normal process, and for normal igb uio remove, udev be release, no any status need to restore. > Would it be possible to only use state variable from the kernel PCI > layer where the value is consistent? The state which i only care here is hot remove state, i check that kobj->state_remove_uevent_sent could be use in igb uio, except that still can not find a specific state of kernel pci to identify it. If we can find it, it should be best. what's other comment from guys? > Also there is refcounting in PCI layer (and locking). Could that > be used instead? It might be, but if state is enough here we might not considerate to use it. If i am missing anything, let me know.