From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id 218D1B4E8 for ; Sun, 22 Feb 2015 04:04:46 +0100 (CET) Received: by pdev10 with SMTP id v10so16994037pde.7 for ; Sat, 21 Feb 2015 19:04:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rYQyk8QxZSkD///B+IIAjHsM+GbxJvub0asWncCswD4=; b=JzCClg+eSEP11/4/PlxYDtuPYN0ite8Xm/15xtAXQ2CVIGNZVQj/jBcgl7g20+KO3P vhjB50O2pQXDIe4LBGMuBvyQj69rITbTJyh4+3AUjxFaCw4r4MjkLu6kEHc4oymOMAn+ OJfpFcClDy2jMviXziXxc6zvia6kcHC4FDGeibFhBv9863jAvXApAaMPgZX/bFcYjcc4 v3+P9gffo95gicWyvkcxw03eN7RrHQLp51VqAi5Mlo7r67g9gVAZ9sQxWURa2Na/dv6I 6LCxhdWLjdpu7ZX2o0PRTZ+sFQSDbgSlp8MXiKXPDlaY7mjpOu7OnEq/oJm6d0EFzVcV Be/Q== X-Gm-Message-State: ALoCoQkoUuq4JUebQH++DE7rl8YzOALGtvGtyBlu1deNmg6N7fIC/ybiTSV5IoogztyHJtkJEdnF X-Received: by 10.70.138.15 with SMTP id qm15mr8195781pdb.117.1424574285278; Sat, 21 Feb 2015 19:04:45 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id yl2sm31426872pbb.1.2015.02.21.19.04.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Feb 2015 19:04:44 -0800 (PST) Message-ID: <54E94748.6030405@igel.co.jp> Date: Sun, 22 Feb 2015 12:04:40 +0900 From: Tetsuya Mukawa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Maxime Leroy References: <1424060073-23484-2-git-send-email-mukawa@igel.co.jp> <1424414390-18509-1-git-send-email-mukawa@igel.co.jp> <1424414390-18509-14-git-send-email-mukawa@igel.co.jp> <54E70D38.6090209@igel.co.jp> <54E8003C.9080405@igel.co.jp> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v10 13/14] eal/pci: Add rte_eal_dev_attach/detach() functions 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: Sun, 22 Feb 2015 03:04:46 -0000 On 2015/02/21 21:49, Maxime Leroy wrote: > Hi Tetsuya, > > On Sat, Feb 21, 2015 at 4:49 AM, Tetsuya Mukawa wro= te: >> On 2015/02/21 0:20, Maxime Leroy wrote: > [...] >>> Why you want to add devargs in the devargs_list, if there are no need= s >>> to store this information ? >> In eal initialization code, virtual device names stored in devargs are= >> checked not to register a same device name twice. >> And each init function of PMD just trust a device name received by eal= =2E >> So there is no code in PMD to check whether device name is unique. >> > I disagree with you. This check is not present in the master branch. > > You have added this check in your hotplug patchset, in this patch: > [PATCH v10 10/14] eal/pci: Add a function to remove the entry of > devargs list > See: http://dpdk.org/ml/archives/dev/2015-February/013712.html > > Thus the problem should be already exist without your patches in the > master branch. > > For example according to you, this testpmd command should create 2 > devices with the same name: > testpmd -c 0xc --vdev eth_pcap0,iface=3Deth0 --vdev eth_pcap0,iface=3De= th1 > -n 2 -- -i > > But it's not the case: > PMD: Initializing pmd_pcap for eth_pcap0 > PMD: Creating pcap-backed ethdev on numa socket 0 > PMD: Initializing pmd_pcap for eth_pcap0 > PMD: Creating pcap-backed ethdev on numa socket 0 > PMD: rte_eth_dev_allocate: Ethernet Device with name eth_pcap0 already > allocated! > > In fact, it's not possible for any PMD_VDEV in the dpdk repo to create > 2 devices with the same name. > All the virtual device initialization functions use the > rte_eth_dev_allocate function. This function prevents to create two > ethernet devices with the same name: > > if (rte_eth_dev_allocated(name) !=3D NULL) { > PMD_DEBUG_TRACE("Ethernet Device with name %s already > allocated!\n", name); > return NULL; > } > Ah, You are right. >> For example, according to your suggestion, how to prevent below case? >> $ ./testpmd -c f -n 1 -- -i >> testpmd> port attach eth_pcap0,iface=3Deth0 >> testpmd> port attach eth_pcap0,iface=3Deth1 >> >> Also, type below, after doing above. >> testpmd> port detach 0 >> >> Probably port 0 will be "eth_pcap0,iface=3Deth0". >> But uninit code of PMD only receives a device name like 'eth_pcap0'. >> (We have 2 'eth_pcap0' devices in PMD.) >> >> To prevent above case, probably we have 2 options at least. >> One is changing init code of all virtual PMDs not to register same >> device name. > There are no need to change init code of all virtual PMDs to not > register the same device name 2 times. > Because it's already not possible to create 2 virtual device with the > same name. (see my point above) > >> The other is to use devargs_list in EAL, and call init code of PMD wit= h >> a unique device name. > Thus there are no needs to use the devargs_list for that. > > [..] >>> But you don't call rte_eal_devargs_add with RTE_DEVTYPE_WHILISTED_PCI= >>> in rte_eal_dev_attach_pdev ? >> Yes, I don't. >> Hotplug functions should not change BLACKLIST and WHITELIST. >> So not to touch the list is correct behavior. > Yes the correct behaviour for Hotplug functions is to not use the > devargs_list for physical and virtual devices ! I totally agree with you now. It seems I have a missunderstanding about code not to duplicate a vdev na= me. Thanks for your suggestions, I will fix it in next patches. Regards, Tetsuya > > Regards, > > Maxime