Re: [dpdk-dev] [RFC][PATCH V2 2/3] examples/vhost: Add vswitch command line options

[Pankaj Chauhan <pankaj.chauhan@nxp.com>]

On 9/13/2016 5:44 PM, Yuanhan Liu wrote:
> On Mon, Sep 05, 2016 at 04:24:30PM +0530, Pankaj Chauhan wrote:
>> Add command line options for selecting switch implementation
>> and maximum ports for the vswitch.following are two new command
>> line options:
>>
>> --switch <switch_name> [char string, Selects the switch imlementation]
>> --max-ports<port_count> [int, selects maximum number of ports to support]
>>
>> For example:
>>
>> $ ./vhost-switch -c 3 -n 2 --socket-mem 1024 --huge-dir /hugetlbfs -- -p
>> 0x1 --dev-basename sock1
>
> That means you were basing on the master branch. You should base on
> next-virtio instead: http://dpdk.org/browse/next/dpdk-next-virtio/

Yes i were basing it on master, i will base the next version on 
dpdk-next-virtio. Sorry for this, i am bit new to dpdk upstream 
development .
>
>> --switch "vmdq" --max-ports 3
>
> Normally, we should keep the old behaviour first. Say, making the vmdq
> as the default switch mode.

Yes if we don't give the '--switch' option then default is vmdq.
>
> However, actually, I don't quite like to make the vhost-switch to bind
> to a hardare feature that tightly, that you may want to make a standalone
> patch as the last one in this patchset to make the "switch" mode be the
> default one.

Sure i will split the patch to take care of this.
>
>>
>> Signed-off-by: Pankaj Chauhan <pankaj.chauhan@nxp.com>
>> ---
>>  examples/vhost/main.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>
>> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
>> index c949df4..a4e51ae 100644
>> --- a/examples/vhost/main.c
>> +++ b/examples/vhost/main.c
>> @@ -142,6 +142,10 @@ static uint32_t burst_rx_retry_num = BURST_RX_RETRIES;
>>  /* Character device basename. Can be set by user. */
>>  static char dev_basename[MAX_BASENAME_SZ] = "vhost-net";
>>
>> +/* vswitch device name and maximum number of ports */
>> +static char switch_dev[MAX_BASENAME_SZ] = "vmdq";
>
> First of all, limiting it with MAX_BASENAME_SZ makes no sense here.
>

I will fix it, define a different constant for switch_dev name.

> Secondly, you don't have to represent the switch mode with string,
> you could simply use some numeric macros, or enum.
>

I used the string because the registration function (vs_register_switch) 
uses the switch name as string to register the switches and find the 
matching switch_dev given in command line. If we use macro or enum then 
we will have to add the MACRO for the switch id in common code every 
time a new switch implementation is added. Keeping a string as name, 
saves us from touching the common code for adding a new switch 
implementation.

> Besides, I just had a quick glimplse of your patches (still couldn't
> make a detailed look so far), and I'd ask you to do few more things
> for v3:
>
> - I'm hoping you could split this patchset further, say **maybe**
>   one patch to introduce vswitch_port, one to introduce vswitch_ops
>   and another one to introduce vswitch_dev. This helps review.
>

Do you want me to split the vswitch_ops, vswitch_dev and vswitch_port 
introduction (mainly vswitch_common.h) in three patches with the patch 
body explaining them in bit detail, correct ?

Their usage i.e vswitch_common.c can be kept in separate patch (4th 
one), is this fine? otherwise it fill be tricky to make vswitch_common.c 
to compilable without complete definition of vswitch_port, vswitch_dev 
and vswitch_ops

> - make sure each commit is buldable.
>
I will take care of this in v3
>
> And few more generic comments to the whole set:
>
> - use "__rte_unused" but not "__attribute__((unused))"
>   And we normally use it after but not before the key word.

I will take care of this in v3
>
> - follow the DPDK prefered way to define a function, the return type
>   and function name takes two lines.
I will take care of this in v3

>
> - run scripts/{checkpatches.sh,check-git-log.sh} and fix real warnings
>   if any before sending them out.
>
>   This would at least help you catch "line over 80 chars" issue.

Sure, will take care of this in v3 and onwards.

Thanks,
Pankaj
>
> Thanks.
> 	--yliu
>