From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by dpdk.org (Postfix) with ESMTP id 931E9B71B for ; Sat, 21 Feb 2015 04:49:21 +0100 (CET) Received: by padet14 with SMTP id et14so12732614pad.11 for ; Fri, 20 Feb 2015 19:49:20 -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=iX2zSal0EFN3ZdGWFIGZfbamnUn+mjy93GijRc4+fCc=; b=AnCgk0p7nUoigOrTuYERFQobTRVoXnfAJbKFyo/XPCaByFXh0AqCsQlLkSqpGDAEHC Klq/pQOS8S7136MQPxz4zb9xVjY9zQJVeVt1i0nqptsjRuXpAJm1Atrrcn1NALR3IYSx URk3nObbWrqJUPhF8jzCA4M1taQhJ7swWdUuSW9pcal0gQOm9wtrUJMroCkILcrJ/DN1 ntL3RB0xlBwQeI2B9UPRjWANWmhzeQfe4jR3jRKTTcbNtN24K5lfgtLsO7Ij4QYDHq9p CIB6fTYQ35JDITx/vC5qo1zfFba4QTtKSIq+HpuJ9XHNrtZoEnl2Bhvm3tyggth0VxG6 vWjQ== X-Gm-Message-State: ALoCoQmIjZjMmIz0LbakjOtc+ziM8uho3GOSBLGMxZ3lyhTi9dANFohZka1Nq5odlgv0hSuzJPGe X-Received: by 10.68.69.102 with SMTP id d6mr1441074pbu.110.1424490560819; Fri, 20 Feb 2015 19:49:20 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id kg2sm28297618pbc.72.2015.02.20.19.49.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 19:49:20 -0800 (PST) Message-ID: <54E8003C.9080405@igel.co.jp> Date: Sat, 21 Feb 2015 12:49:16 +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> 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: Sat, 21 Feb 2015 03:49:21 -0000 On 2015/02/21 0:20, Maxime Leroy wrote: > Hi Tetsuya, > > Thanks for your comment. > > On Fri, Feb 20, 2015 at 11:32 AM, Tetsuya Mukawa wr= ote: >> On 2015/02/20 19:14, Maxime Leroy wrote: >>> Hi Tetsuya, > [...] >> Hi Maxime, >> >> I appreciate for your comment. >> >> When rte_eal_init() is called, if we have "--vdev" options, these will= >> be stored in vdevargs as you describe above. >> I agree this is the current behavior of DPDK. >> >> When we call hotplug functions, I guess doing same thing will be more >> consistent design. > The rte_eal_devargs_add is here to store a white list parameters for > later creating the devices. > It means that the devargs_list is only needed at the init to store the > devargs parsed . > I think we should not use the devargs_list after eal initialization. > > Why you want to add devargs in the devargs_list, if there are no needs > 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. So there is no code in PMD to check whether device name is unique. 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. The other is to use devargs_list in EAL, and call init code of PMD with a unique device name. But first case, eal initialization code can calls init of PMD with unique name, but hotplug cannot. It's not so consistent behavior. Also, we need to have almost same code that assure unique name in each PM= D. > At the end, it adds extra codes for nothing. > >> For example, we can do like below. >> 1. $ ./testpmd --vdev 'eth_pcap' -- -i >> 2. testpmd>port detach > It's exactly the same for physical device: > 1. $./testpmd -w 0000:08:00:1 -- -i > 2. testpmd> port detach > > 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. I guess you feel something strange about usage of devargs_list. If so, I agree with it. Probably the issue is that devargs_list is used for not only storing command parameters, but also not to register same virtual device name twi= ce. > Thus it makes the hotplug implementation not coherent for me. > > What do you think ? Anyway, here is my guess. Current DPDK uses devargs not to register same virtual device name. If we follow this, probably using devargs is straight forward. But if we should change the design itself, could you check below. http://dpdk.org/dev/patchwork/patch/3374/ Thomas and I agreed that I will try to change design in post-rc1. In a future patch, probably it might be nice to have virtualdev_list, then we can use devargs_list only for storing command arguments. Regards, Tetsuya > Regards, > > Maxime