[dpdk-dev] [PATCH 1/6] net/tap: use correct tap name

[Pascal Mazon]

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