From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 514971023 for ; Tue, 31 Jan 2017 16:32:13 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id c85so265915575wmi.1 for ; Tue, 31 Jan 2017 07:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=L3cC4n9UaYHa6/Q4qHOkEoBfrfVrkyTmXYth5j/Yfpc=; b=upEQlMhYc+jIcg7/aC0uKsI5/c52FpC11/C1MJO/fSI5j9l+Nk5v51EQnmR6uSzs2o yNbDOuV1S5/p5bApg6ipe7lOKaT9XtCtwObwVLZzi4I6NjWAq3faEmLeAGNWATm8CJj+ dwV3kHUYkMWvfIL2GPyfivHfbcQvQ8cknqtWias3SIPuKmhUSGb6owlY9ks8oyjv3fuI nuZCxcvbJGRYChsLSlXPzXXv9Kh0CviDCF/ydmCH7nVbCPAeRRiUOCoBflef2TxmHOfG 7VcQOIEmDhK5rmapUSIDjT/ZaV1pHJHNgVKc4iU+9t+ZxP/BFl915v2B8mMM9rvZuucE xzSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=L3cC4n9UaYHa6/Q4qHOkEoBfrfVrkyTmXYth5j/Yfpc=; b=XblFAalOZHUsYoww2+n6lwEEY/ZQHy2skHCNeRoW7uw+bNQM31SxdtMSzx2yZElq5z w0/dX8dWhnqlbF/NzH/6GenU4cMHT16NRzTrAaZJrUr+DWjEYLsB2YnI+aTfiTZ4Md0I eID7qDJBn+WaXxSAuqFvDCdCory02g5+uY5nbu5fRtTlqCjdqRG5UkR86bTxUbqu8rKN FmNmBVQ8xnk0pQjdqzSXc/JOdZc9rCHup7yWI+kNcFMeZ0tns28rALF1VDS9wLOHCoBQ 4ic1SseZEi8qvSrdx9NsLaCUOsH2qLXUhVyyPCVtJ8N8IlQnIgiIX5MdN0xcfEme+xi8 DAig== X-Gm-Message-State: AIkVDXL+zJJAPSiIyKE2P8aCVP+QLYwH+djRWiPaHRirsG2YBIGNiubHH0yU0N4RcR3xEdq4 X-Received: by 10.223.128.77 with SMTP id 71mr24269582wrk.163.1485876732654; Tue, 31 Jan 2017 07:32:12 -0800 (PST) Received: from [10.16.0.184] (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 123sm24497178wml.6.2017.01.31.07.32.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 07:32:12 -0800 (PST) To: Ferruh Yigit , keith.wiles@intel.com References: <1485855778-15496-1-git-send-email-pascal.mazon@6wind.com> <39a46c11-66c4-d8ed-a2bc-d9421cb4afd0@6wind.com> Cc: dev@dpdk.org From: Pascal Mazon Message-ID: Date: Tue, 31 Jan 2017 16:30:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/6] net/tap: use correct tap name 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: Tue, 31 Jan 2017 15:32:13 -0000 On 01/31/2017 04:28 PM, Ferruh Yigit wrote: > On 1/31/2017 2:23 PM, Pascal Mazon wrote: >> On 01/31/2017 02:06 PM, Ferruh Yigit wrote:> On 1/31/2017 9:42 AM, >> Pascal Mazon wrote: >>>> dev->data->name contains "net_tap", the device driver name. >>> >>> I see what patch does, just as a note to commit log: >>> >>> AFAIK, "dev->data->name" is device name, and for this case it is >>> "net_tap#", like "net_tap0", "net_tap1" ... >>> >>> "dev->data_drv_name" is the driver name which is "net_tap" >> >> Indeed, dev->data->name is the device name, looking like "net_tap#", >> with number increasing for each vdev. >> I'll put the following commit log line if that's ok: >> >> dev->data->name contains the device name, e.g. "net_tap0". >> >>> >>>> dev->data->dev_private->name contains the actual iface name, >>>> e.g. "dtap0". >>> >>> Right, I agree this is correct comparing "dev->data->name" >>> >>> But the problem is pmd->name is per eth_dev. >>> >>> If I read code correct, for multiple queue support, each queue pair will >>> create a tap device, so each needs a different name. >>> >>> So can't just use pmd->name. Need to create a name per queue pair, it >>> can be combination of pmd->name + "_" + queue_id? Or can keep a name per >>> queue pair, instead of eth_dev. >>> >>> What do you think? >> >> Actually that's not exactly how it goes. >> Adding a queue to a netdevice requires to open("/dev/net/tun") and setting >> TUNSETIFF (through ioctl) on the resulting fd. >> That's the important part: queues for a given tap device must set TUNSETIFF >> with a common ifreq.ifr_name (in our case, pmd->name). >> >> This is best explained in the kernel doc, there: > > Thank you for the clarification. > If so, why PMD keeps a fd per queue? > > Overall, patch looks good except mentioned detail in commit log. > > I suggest waiting Keith's patch, and rebase this set on top of it. > > Thanks, > ferruh > >> >> [1] >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/tuntap.txt#n108 >> > <...> > I would say it is because dev->{r/t}x_pkt_burst() is done per queue. In these functions, we need to make our read() and write() accesses on the right fd considering the queue we're required to process. I'll wait for Keith's patch, then. Best regards, -- Pascal Mazon www.6wind.com