From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 693C269D4 for ; Thu, 25 Oct 2018 17:27:02 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id n5-v6so5996660wrw.12 for ; Thu, 25 Oct 2018 08:27:02 -0700 (PDT) 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=V0gabvggHhkj+OysUBbstB4ps8Tg9OqPkfc7JvZHiH8=; b=RN6kz17be5ftcUuSk1Wcgs5awdl8WkyFeKAo7SF/ufsH+hXQ/f/7nB/SgPH7qguXxi nuZuU6N5OOI1Rc+lV/fjoTXc00LVAeoMtTQ1lPYrAc92Jvjp3ZIYNFOT4XCJBGGc5Uxx pU10SpH1JclSO6X9pQjvRk1nMfmXLZmjPWTB9FwhdWf6KDoZUaXI3S4KvRlOzP4jM1JY ooMZuUgmm2YUHobU4s6RRzh1DLAAbRBQO5HSY4/dmbknLxFKXnFxqfG0WqmWhkBhU3o8 shr8TamxNqss6blEIVb5Sgha8zmyOHqm3cb3MjOcvprXbNacv/zxzsBHnADHdzaOEdMI ywtg== 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=V0gabvggHhkj+OysUBbstB4ps8Tg9OqPkfc7JvZHiH8=; b=ftmMO7FYNCAnapLWwp1H9LAX3gzhUTrtxWxcYVi9vV4+8bCVJb+VerZcxKBddgqF1I nlrVBfAWIQNwmizyid6+j7dvr6wsMOZrNJeHP0DshBKR8gfNNjhIEyzA5QtCKOU7YXMk QYkTgu5UmtQGvsQx5Ut8fmhSmFBw5htpqpgyf6BL3UNKx0peffQ48D5eKaj6mUfDQ58k fH9XWsGzqtiAoATMsvKwSGDq0+mEoOj2+dtxg5E+g1UIrjlw0UL/mItzwZZIBR0r1zDN erxIsnDV+ARNC88miMX3NhMsX87nJ5AnJhRAak2y4ZnbjmhPmXN4q3tMKus6TvgKl/pv 1+Pw== X-Gm-Message-State: AGRZ1gKx+lX1YvgK1as6B1L7qhtg8Kr71cOxfOvex4V4pVn418b/0aGA gqIXlkFGsGJ3WAb8UQPzusuV7Q== X-Google-Smtp-Source: AJdET5eax2KKe6ZAE5hqiBoFqniLli0zbpJ2BdOeuJnnVraCenHI4GFq5pMlrCdgVCAbOpFLpYtOgA== X-Received: by 2002:a5d:628c:: with SMTP id k12-v6mr2284184wru.83.1540481221737; Thu, 25 Oct 2018 08:27:01 -0700 (PDT) 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 82-v6sm2739650wms.17.2018.10.25.08.27.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Oct 2018 08:27:00 -0700 (PDT) Date: Thu, 25 Oct 2018 17:26:42 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Zhang, Qi Z" Cc: "thomas@monjalon.net" , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20181025152642.jcq56s37wbjgfs3z@bidouze.vm.6wind.com> References: <20181025033036.23680-1-qi.z.zhang@intel.com> <20181025095118.gnc75zvkuvfajtha@bidouze.vm.6wind.com> <039ED4275CED7440929022BC67E70611532DB6EF@SHSMSX103.ccr.corp.intel.com> <20181025150313.g6d7tfhmsiz7wwim@bidouze.vm.6wind.com> <039ED4275CED7440929022BC67E70611532DB741@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <039ED4275CED7440929022BC67E70611532DB741@SHSMSX103.ccr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] bus/vdev: fix device argument corrupt after bus scan 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, 25 Oct 2018 15:27:02 -0000 On Thu, Oct 25, 2018 at 03:18:20PM +0000, Zhang, Qi Z wrote: > > > > -----Original Message----- > > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com] > > Sent: Thursday, October 25, 2018 10:03 AM > > To: Zhang, Qi Z > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > Subject: Re: [PATCH] bus/vdev: fix device argument corrupt after bus scan > > > > On Thu, Oct 25, 2018 at 02:56:55PM +0000, Zhang, Qi Z wrote: > > > > > > > > > > -----Original Message----- > > > > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com] > > > > Sent: Thursday, October 25, 2018 4:51 AM > > > > To: Zhang, Qi Z > > > > Cc: thomas@monjalon.net; dev@dpdk.org; stable@dpdk.org > > > > Subject: Re: [PATCH] bus/vdev: fix device argument corrupt after bus > > > > scan > > > > > > > > On Thu, Oct 25, 2018 at 11:30:36AM +0800, Qi Zhang wrote: > > > > > It's not necessary to insert device argment to devargs_list during > > > > > bus scan, but this happens when we try to attach a device on > > > > > secondary process. The patch fix the issue. > > > > > > > > > > Fixes: cdb068f031c6 ("bus/vdev: scan by multi-process channel") > > > > > Cc: stable@dpdk.org > > > > > > > > > > Signed-off-by: Qi Zhang > > > > > --- > > > > > drivers/bus/vdev/vdev.c | 11 +++++++---- > > > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c > > > > > index > > > > > 688e31c21..818a2bfc2 100644 > > > > > --- a/drivers/bus/vdev/vdev.c > > > > > +++ b/drivers/bus/vdev/vdev.c > > > > > @@ -202,7 +202,9 @@ alloc_devargs(const char *name, const char > > > > > *args) } > > > > > > > > > > static int > > > > > -insert_vdev(const char *name, const char *args, struct > > > > > rte_vdev_device **p_dev) > > > > > +insert_vdev(const char *name, const char *args, > > > > > + struct rte_vdev_device **p_dev, > > > > > + bool init) > > > > > > > > Why is vdev the only bus not using hotplug API itself and > > > > reimplementing it on its own? > > > > > > I don't know the history, > > > but replace insert_vdev with hotplug API will not solve all the > > > problem (see my below comments) > > > > > > > > > > > It should not have to insert devargs at all, not even in the primary > > > > process. If it called rte_dev_probe(), this would normally already > > > > be properly handled I think. > > > > > > Currently insert_vdev is shared by two scenarios 1. rte_vdev_init, > > > which is called by application to attach a new device, I agree it's better to > > have rte_dev_probe here so, no need to have insert_vdev here. > > > 2. during secondary's vdev->scan when it receive a SCAN_ONE event from > > > primary, it should not call rte_devargs_insert, The patch is going to > > > fix the issue on secondary scenario and we can do the cleanup for > > > first issue in a separate patch > > > > In 2., won't dev_probe() check for secondary process context and in this case, > > send the request to primary, which will see that the device is already probed, > > which would thus fix your issue? > > No, It's not the case that we issue a device attaching from secondary, but the case that we try to sync with primary for a device already be attached > So we are in the context of dev->scan, we should not do dev_probe in dev->scan, since dev_probe will call dev->scan again, then it go dead loop. > > > > My take on it is that it seems to be fixing both your issue and cleaning up > > history. > > Ok! As long as you are confident this is the simplest way to write this, while taking into consideration the future rework of vdev_init(), all good :) -- Gaëtan Rivet 6WIND