From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by dpdk.org (Postfix) with ESMTP id 5BBD38D8B for ; Tue, 2 Feb 2016 06:41:21 +0100 (CET) Received: by mail-oi0-f53.google.com with SMTP id p187so105274069oia.2 for ; Mon, 01 Feb 2016 21:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yG1HSxEv2ZAx0BEshEmAxvUvRfuJn0eTgYKeTylchWE=; b=J8uforjK2Lv4mqRq+V53FdzwaFiGNnZ8dYFM0U2w7F3xDxyFiiIm7QVqSe3zAqjJDh v2wqPiP2ZzqZlHmUnmorIbBwV9BEQfYvp5c88vllJjYtVFsoQSp/GLgoveolpLafNG3Q m1B1fajmxlL8c+nzyDw4fVgZ2/n+v9mpweDfNHz9eTyG2RUSGaET7luvSMTuEQe34lJe o1LPAi++1FQBnV/u3pgzX9CKM82Fv6emMynUMa/ZUhrU36PZUxxUQay/A+3pE3GkSYrG Gupc28WnQ8A89GvT0ZlJz43tHKpc+fD422DvMJPrBcZAj9XVqZK+83C3dfTwYfFZku30 5f2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=yG1HSxEv2ZAx0BEshEmAxvUvRfuJn0eTgYKeTylchWE=; b=F9bb0190DBoFqXu15J3l5gywlWAknXa19vjC+BrgI++2RMt92/A/OLFD6tORMJZsnK cHeHr+/GXIQZNgZlmFuov3pql2ZZirJgjbEO3SbGtedAYxWKPF8OrPTWaVPnsk4/QUH7 qjQHjS1FrnxLis5jbYBCkjVL/xU+Z15z8TBUURHsNHLaw8obivijPQHgGG8C9i/zZyJm jZJXXcUuJDuAIlj8NagSDSMbFh8Oqy/2sH5dz7ZgRkbP9v4w55f5xMJaZYuAcEYB8/Bi JbE4BS9eWGV9ZRxkKyq0sFPKpzmExOrov1tf4EX517ekHcnVc26eNin9GYN8lL71jcoo q2Fg== X-Gm-Message-State: AG10YOT/9b1rV4YZ0BC0az7yL+1XF9VSkTYE373DhloSwUYo45WcMWLMidTkLvAPiUTSVJjA6CLwGebadyt4OsE4 X-Received: by 10.202.175.204 with SMTP id y195mr19102118oie.22.1454391680822; Mon, 01 Feb 2016 21:41:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.180.72 with HTTP; Mon, 1 Feb 2016 21:41:01 -0800 (PST) In-Reply-To: References: From: David Marchand Date: Tue, 2 Feb 2016 06:41:01 +0100 Message-ID: To: =?UTF-8?Q?Mauricio_V=C3=A1squez?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , Jan Viktorin Subject: Re: [dpdk-dev] rings PMD detaching X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 05:41:21 -0000 Hello Mauricio, On Tue, Feb 2, 2016 at 2:37 AM, Mauricio V=C3=A1squez wrote: > I was wondering if there were a way to detach (delete) a ring pmd device > created with rte_eth_from_rings. I realized that rte_eth_dev_detach does > not work in this case because there is a comparison between the device's > name and the driver's name in rte_eal_vdev_uninit, then devices created > with arbitrary names can not be uninitialized. I would say this is the same problem than what I observed in pci code. Doing a "driver" lookup on detach is useless (and buggy in your case), eal should just reuse the driver that the device had been attached to. The problem is that, for vdev, the driver is not stored in a device object at attach time, since there is no device object. > My question is how to implement it?, I have two ideas on mind: > - make rte_pmd_ring_devuninit a public function, then the user can call > this using as argument the name of the device. Having something like this enter abi, because of a bug in eal, does not sound like a good idea. > - modify rte_eal_vdev_uninit in such a way that there is not any comparis= on > based on the dev name, probably it will require to add some extra field i= n > the rte_eth_dev structure to distinguish between the different virtual > devices. No, the problem lies in eal where resources are bound to drivers. No reason to pollute ethdev (we have enough workarounds in it ;-)). This driver lookup should just go away. If we had the rte_device I described [1], this kind of issues would disappe= ar. [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html Regards, --=20 David Marchand