From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id 9CA5E5592 for ; Sun, 9 Jul 2017 14:35:31 +0200 (CEST) Received: by mail-wr0-f171.google.com with SMTP id 77so103706906wrb.1 for ; Sun, 09 Jul 2017 05:35:31 -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=+qPJoGhAfRlspszCdwI9s3Ns0/DcuEnZ7BrTZRYV8eE=; b=Cc1IWcC8rTiWCBDx4brZvQctfwK8egpSKAYBoXvtdmQ0R/b3JVAKTHUFWRd4Dw1VHh l5KDisNjy9vUdz4UKOWpCOGV/GJvzKD0WvgmIeIavqGNwxj6S5/Y7kAo9gsBK+Vp6pml OZ6VSqMfbWA4653xjV3bUpPAsHT32IbrYyaNATzJhkDfa68oipFVQmYZmjUqMD1mFeBK Leed+jin3j1zQt+xL4+1YTbWlAaGLsauO4IkQE3b71Nux7TP/olbI877PTUKunq9mR47 aThomY+YKKQNxUsp65kcRyQKhf5uin7IQtpX/gytbSw5sXE/Hv3rE/0aVRHdyf3XFyWY gACw== 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=+qPJoGhAfRlspszCdwI9s3Ns0/DcuEnZ7BrTZRYV8eE=; b=q2NwdR5ObR+gC9yJbxvgl6szZMovegf8rDyjsWENd2FTvIKkEdTxYM4trYQXeKAWP/ Xr1PcJiph7TcFhXLcDJoymuCp3zzvSxe5K0gDTbYEx4+d8TsG54go3q3IKWIC4X/h40z +grTFGrwZN/5jt8/ab1+C32tnT3lH68QCOu0AFAvFPJtt/yxF153Vd9eS4KQTpZ97FbS gRELDyUGFuRRbK6MT9KrM3wcDo7oGQStfy+8bP6bePhRoONp68E91D4bbBW18wPFb4yg ob9nncvIpTUjUZhEimgfyJDP23Qiybz65IzymxBC8Rm0a7ZZ8wjNnzgXzKLEZGiC4Bb4 ze6A== X-Gm-Message-State: AIVw1126f5zlmB5ZPIik3+IGj5HjlLKQG/zo7gCcVCXnzhe9Tj2FZJG7 5zHrP8ghzaj0XFaMM/0= X-Received: by 10.28.74.14 with SMTP id x14mr4700486wma.15.1499603730899; Sun, 09 Jul 2017 05:35:30 -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 l73sm10717524wma.27.2017.07.09.05.35.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 05:35:29 -0700 (PDT) Date: Sun, 9 Jul 2017 14:35:21 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Jan Blunck Cc: dev Message-ID: <20170709123521.GV11154@bidouze.vm.6wind.com> References: <1a589e5bf8e6babbd364b3976511289f6762cafa.1499564333.git.gaetan.rivet@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v7 03/11] net/failsafe: add fail-safe PMD 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: Sun, 09 Jul 2017 12:35:31 -0000 On Sun, Jul 09, 2017 at 07:10:49AM -0400, Jan Blunck wrote: > On Sat, Jul 8, 2017 at 9:47 PM, Gaetan Rivet wrote: > > +static int > > +fs_parse_device(struct sub_device *sdev, char *args) > > +{ > > + struct rte_devargs *d; > > + int ret; > > + > > + d = &sdev->devargs; > > + DEBUG("%s", args); > > + ret = rte_eal_devargs_parse(args, d); > > + if (ret) { > > + DEBUG("devargs parsing failed with code %d", ret); > > + return ret; > > + } > > + sdev->bus = d->bus; > > + sdev->state = DEV_PARSED; > > You seem to be mostly interested in the bus name for the device. Why > don't you track this via your sub_device structure instead of using > rte_devargs? > > I don't understand. I track it in my sub_device structure by copying the info from the devargs? How would you get it otherwise? Devargs still has to be used as a common format that can be parsed by EAL helpers. I could certainly parse it myself, but then I would have to follow any evolution of the parameter format, and I prefer to delegate this to the EAL. > > + return 0; > > +} > > + [...] > > +static struct rte_eth_dev * > > +fs_find_ethdev(const struct rte_device *dev) > > +{ > > + struct rte_eth_dev *eth_dev; > > + uint8_t i; > > + > > + RTE_ETH_FOREACH_DEV(i) { > > + eth_dev = &rte_eth_devices[i]; > > + if (eth_dev->device == dev) > > + return eth_dev; > > + } > > + return NULL; > > +} > > Why don't you use rte_eth_dev_allocated() here? > > IIRC, at the time I choose to roll out my own version, there was ambiguities about device names availability, with some devices using their rte_devargs name, others writing their own. It has been stabilized it seems, and now I think rte_eth_dev_allocated could be used. [...] > > + > > +static int > > +fs_bus_init(struct rte_eth_dev *dev) > > +{ > > + struct sub_device *sdev; > > + struct rte_device *rdev; > > + struct rte_devargs *da; > > + uint8_t i; > > + int ret; > > + > > + FOREACH_SUBDEV(sdev, i, dev) { > > + if (sdev->state != DEV_PARSED) > > + continue; > > + da = &sdev->devargs; > > + rdev = rte_eal_hotplug_add(da->bus->name, > > + da->name, > > + da->args); > > Why don't you track the bus name through your sub_device structure instead? > > Do you mean + rdev = rte_eal_hotplug_add(sdev->bus->name, + da->name, + da->args); instead? I guess for this example it was mostly for the sake of consistency, but the bus handle within the sub_device could be used. Actually I dislike having a copy of an info. I have this info both within the sub_device directly and within the rte_devargs within the sub_device. It should be streamlined. -- Gaëtan Rivet 6WIND