Re: [dpdk-dev] [dpdk-stable] [PATCH v1] net/vdev_netvsc: fix creating short name devices

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 4/25/2018 11:33 AM, Matan Azrad wrote:
> 
> 
> From: Ferruh Yigit, Wednesday, April 25, 2018 1:29 PM
>> On 4/25/2018 11:25 AM, Matan Azrad wrote:
>>>
>>>
>>> From: Ferruh Yigit, Tuesday, April 24, 2018 5:20 PM
>>>> On 4/10/2018 4:39 PM, Matan Azrad wrote:
>>>>> It is OK for me.
>>>>
>>>> Converting this to explicit ack:
>>>> Acked-by: Matan Azrad <matan@mellanox.com>
>>>>
>>>
>>> Ok, don't forget to remove the fixes line.
>>
>> Don't forget? Should fixes line be removed, why?
> 
> This is not a fix.

Right, will update it in next-net.

> 
>>>>> Thanks.
>>>>>
>>>>> From: Ophir Munk, Tuesday, April 10, 2018 6:36 PM
>>>>>> Hi.
>>>>>> Discussed with Thomas.
>>>>>> Please consider the following commit message:
>>>>>>
>>>>>> net/vdev_netvsc: shorten devices names
>>>>>>
>>>>>> Prior to this commit the vdev_netvsc PMD was creating tap and
>>>>>> failsafe devices with long names, such as "net_tap_net_vdev_netvsc0"
>>>>>> or "net_failsafe_net_vdev_netvsc0".
>>>>>> This commits creates tap and failsafe devices with short names such
>>>>>> as "net_tap_netvsc0" or "net_failsafe_netvsc0".
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Matan Azrad
>>>>>>> Sent: Tuesday, April 10, 2018 11:04 AM
>>>>>>> To: Ophir Munk <ophirmu@mellanox.com>; dev@dpdk.org
>>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>; Olga Shern
>>>>>>> <olgas@mellanox.com>; stable@dpdk.org
>>>>>>> Subject: RE: [PATCH v1] net/vdev_netvsc: fix creating short name
>>>>>>> devices
>>>>>>>
>>>>>>> Hi Ophir
>>>>>>>
>>>>>>> From: Ophir Munk, Tuesday, April 10, 2018 10:20 AM
>>>>>>>> Prior to this commit the vdev_netvsc PMD was creating tap and
>>>>>>>> failsafe devices with long names, such as
>> "net_tap_net_vdev_netvsc0"
>>>>>>>> or "net_failsafe_net_vdev_netvsc0".
>>>>>>>> Long names containing more than 32 characters may be rejected by
>>>>>>>> some APIs (e.g. membuf pool creation).
>>>>>>>
>>>>>>> Since EAL allows to use long names, I don't think it is a problem
>>>>>>> of the netvsc device.
>>>>>>> If a DPDK entity wants to use this name for some reason it needs
>>>>>>> to adjust it to the usage.
>>>>>>>
>>>>>>> I agree that short names are better and may help for such like cases.
>>>>>>>
>>>>>>> I suggest the next title:
>>>>>>> net/vdev_netvsc: use short device names
>>>>>>>
>>>>>>>> This commits fixes this issue by creating tap and failsafe
>>>>>>>> devices with short names such as "tap_net_vsc0" or
>> "net_failsafe_vsc0".
>>>>>>>>
>>>>>>>> Fixes: e7dc5d7becc5 ("net/vdev_netvsc: implement core
>>>>>>>> functionality")
>>>>>>>> Cc: stable@dpdk.org
>>>>>>>>
>>>>>>>> Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
>>>>>>>> ---
>>>>>>>>  drivers/net/vdev_netvsc/vdev_netvsc.c | 8 ++++----
>>>>>>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
>>>>>>>> b/drivers/net/vdev_netvsc/vdev_netvsc.c
>>>>>>>> index db0080a..bb2f78d 100644
>>>>>>>> --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
>>>>>>>> +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
>>>>>>>> @@ -614,13 +614,13 @@ vdev_netvsc_netvsc_probe(const struct
>>>>>>>> if_nameindex *iface,
>>>>>>>>  		       name, ctx->id);
>>>>>>>>  	if (ret == -1 || (size_t)ret >= sizeof(ctx->name))
>>>>>>>>  		++i;
>>>>>>>> -	ret = snprintf(ctx->devname, sizeof(ctx->devname),
>>>>>>>> "net_failsafe_%s",
>>>>>>>> -		       ctx->name);
>>>>>>>> +	ret = snprintf(ctx->devname, sizeof(ctx->devname),
>>>>>>>> "net_failsafe_vsc%u",
>>>>>>>> +		       ctx->id);
>>>>>>>>  	if (ret == -1 || (size_t)ret >= sizeof(ctx->devname))
>>>>>>>>  		++i;
>>>>>>>>  	ret = snprintf(ctx->devargs, sizeof(ctx->devargs),
>>>>>>>> -		       "fd(%d),dev(net_tap_%s,remote=%s)",
>>>>>>>> -		       ctx->pipe[0], ctx->name, ctx->if_name);
>>>>>>>> +		       "fd(%d),dev(net_tap_vsc%u,remote=%s)",
>>>>>>>> +		       ctx->pipe[0], ctx->id, ctx->if_name);
>>>>>>>>  	if (ret == -1 || (size_t)ret >= sizeof(ctx->devargs))
>>>>>>>>  		++i;
>>>>>>>>  	if (i) {
>>>>>>>> --
>>>>>>>> 2.7.4
>>>>>
>>>
>