From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by dpdk.org (Postfix) with ESMTP id 352752082 for ; Wed, 7 Nov 2018 00:34:13 +0100 (CET) Received: by mail-wr1-f53.google.com with SMTP id d10-v6so15463370wrs.5 for ; Tue, 06 Nov 2018 15:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=y0D7oXDB+cQbNR6Ov8/uNgE6L5ii9ORVXFAjrIWAHjU=; b=HWykiR2Si9scZPdyta/e4dvZqUXRs/iqk+nloUn48xxQ7o6k/Dse55AM/FAZgQylup HnTrqpvmu+fBSOZzHy5XjhO1uehgBpPewDA1ZS58BihfnNFCnkox51LC5cKZ4/M/qn/E 7wJ64TPuceC+I1LQWCZmuyv8WCO2GbsjGLnkzALeSEDX3yzWH++8cWNXqzak5pGmXeoX jqaap5fKHTyXQcqxNveJjbzXLr9nWt5qnygaBVN94BDq/NirkA/7a+zroKMc+eSwQpvY XZdfX3hodrAd0F8Su1cHUWDJd//saXYGtcM9AzPn6mFYNq+u1VMORnzBnJweUZGiOJBm qBwA== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=y0D7oXDB+cQbNR6Ov8/uNgE6L5ii9ORVXFAjrIWAHjU=; b=jsvI00SVige8+H+Gos3IgxGlqug7PcwqLgUo+kuoKiqBPdwl9EfLzwDNSW6z5uiIfr DcP0HhOmX2ON02lG8XVtiS8Wxo6zA2ZCTrWbCRtkr7XjrPwUA5jOqiH8TZjshnRtha+q YiWag9EiKJ1i/jgzJHtr9E1imtP357upGlNw7hhWrHTo5A8SAD/Ow1crq36aGPzxvsy5 /LxH8lwrWSKS0VtJC7kWHpYgOZ7o1Qi2ahxsT98INR4S2T6e59OrkeZ+JRsrOxwxH3mk FO/OZPg8Oz5ij1BsqT8WYg209BzK82shAj8H2V/t8v8MPmKkW+a4NYiiicrWzUbOUMx5 KhNQ== X-Gm-Message-State: AGRZ1gKOvbVQODOgE+tDuSF9yvldgaLvkm8b4WGp0Cx9WJWD41mjCSzX wU2WPN1sKAC7YqWOt6AGrHdHWg== X-Google-Smtp-Source: AJdET5ekP2tlAQ6Vz0UnIvhasThp9UTFkBMSJBV3r+afpZieWkRRg1fzjsLhzruY+vbEOYMjxr8Daw== X-Received: by 2002:adf:f68e:: with SMTP id v14-v6mr23469235wrp.261.1541547252355; Tue, 06 Nov 2018 15:34:12 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id f18-v6sm29648001wre.86.2018.11.06.15.34.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 06 Nov 2018 15:34:11 -0800 (PST) Date: Wed, 7 Nov 2018 00:33:52 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: "Zhang, Qi Z" , "dev@dpdk.org" , "Yigit, Ferruh" Message-ID: <20181106233352.qhe7kuhgiexpvpih@bidouze.vm.6wind.com> References: <20181106003150.10560-1-qi.z.zhang@intel.com> <11443385.dze8hbQCXQ@xps> <039ED4275CED7440929022BC67E70611532E0279@SHSMSX103.ccr.corp.intel.com> <2180900.HKzicAuZ6Y@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2180900.HKzicAuZ6Y@xps> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] bus/vdev: fix probe same device twice 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: Tue, 06 Nov 2018 23:34:13 -0000 On Tue, Nov 06, 2018 at 09:36:22PM +0100, Thomas Monjalon wrote: > 06/11/2018 16:46, Zhang, Qi Z: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > Hi, > > > > > > 06/11/2018 01:31, Qi Zhang: > > > > When probe the same device at second time > > > > > > Sorry I stop on this first sentence. > > > How and why do you probe a vdev twice? > > > > if we do rte_dev_hotplug_add or rte_dev_proble on a probed device. (yes, this is not usually what an application want, but it can happen by miss-operation, and this is covered by our test case, it make sense to me that hotplug API should be robust enough to handle that situation.) > > Yes I agree we must handle this situation. > > > we will failed at the second time as expected, > > but will not able to detach the device any more, since during the second scan, original vdev->device.devargs is corrupted. > > The root cause is we remove a devargs which was referenced. > Could we overwrite the first devargs instead of removing it? > > It's also possible to add a back-reference to an rte_device in [1], but that can only work if only one rte_device references a devargs. It seems to be the case now, but it might be good to enforce explicitly that when a bus scans its devices, it should do a 1-to-1 map to devargs. If mapping rte_device to rte_devargs needs to respect rules, it could help bus developpers to have a function that will do the job: verify that the devargs is not currently used, add the back-reference to the rte_device. With the proper back-reference, it is possible to clean-up the device when removing the devargs (and also to add the rte_devargs_extract() function that would allow keeping the original devargs and insert it back if the hotplug fails, then the mapping must be restored). [1]: https://mails.dpdk.org/archives/dev/2018-November/118274.html -- Gaëtan Rivet 6WIND