[dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app guide

Kavanagh, Mark B mark.b.kavanagh at intel.com
Wed Jul 20 09:41:41 CEST 2016


>
>Hi Mark,

Hi Jianfeng,

Thanks for your comments - I've responded inline.

Cheers,
Mark

>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mark Kavanagh
>> Sent: Tuesday, July 19, 2016 11:32 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app
>> guide
>>
>> - Fix vhost setup flags
>> - Add minor edits to improve readability and consistency
>>
>> Signed-off-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
>> ---
>>  doc/guides/sample_app_ug/tep_termination.rst | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>  mode change 100644 => 100755
>> doc/guides/sample_app_ug/tep_termination.rst
>>
>> diff --git a/doc/guides/sample_app_ug/tep_termination.rst
>> b/doc/guides/sample_app_ug/tep_termination.rst
>> old mode 100644
>> new mode 100755
>> index 2d86a03..c3d1e97
>> --- a/doc/guides/sample_app_ug/tep_termination.rst
>> +++ b/doc/guides/sample_app_ug/tep_termination.rst
>> @@ -59,8 +59,8 @@ This allows network isolation, QOS, etc to be provided
>> on a per client basis.
>>  In a typical setup, the network overlay tunnel is terminated at the
>> Virtual/Tunnel End Point (VEP/TEP).
>>  The TEP is normally located at the physical host level ideally in the software
>> switch.
>>  Due to processing constraints and the inevitable bottleneck that the switch
>> -becomes the ability to offload overlay support features becomes an
>> important requirement.
>> -Intel® XL710 10/40 G Ethernet network card provides hardware filtering
>> +becomes, the ability to offload overlay support features becomes an
>> important requirement.
>> +Intel® XL710 10/40 Gigabit Ethernet network card provides hardware
>> filtering
>>  and offload capabilities to support overlay networks implementations such
>> as MAC in UDP and MAC in GRE.
>>
>>  Sample Code Overview
>> @@ -131,14 +131,14 @@ Compiling the Sample Code
>>
>>      .. code-block:: console
>>
>> -        CONFIG_RTE_LIBRTE_VHOST=n
>> +        CONFIG_RTE_LIBRTE_VHOST=y
>>
>>      vhost user is turned on by default in the configure file
>> config/common_linuxapp.
>>      To enable vhost cuse, disable vhost user.
>>
>>      .. code-block:: console
>>
>> -        CONFIG_RTE_LIBRTE_VHOST_USER=y
>> +        CONFIG_RTE_LIBRTE_VHOST_USER=n
>
>Actually, this example does not necessarily disable vhost-user. It can work with vhost-user.

Okay; however, the instruction that I modified relates to the case where vhost cuse is the preferred option (or at least that's how it comes across upon reading).
With that in mind, CONFIG_RTE_LIBRTE_VHOST_USER should be set to 'n', and not 'y', as previously described.

>I also notice that there are many comments inside this example to indicate it works with
>vhost-cuse. I think we need to correct this. 

Do you mean to say that the example app does not work with vhost cuse? What should be corrected? 

>By the way, vhost-cuse could be deprecated in
>the future, please refer here, http://dpdk.org/ml/archives/dev/2016-July/044080.html

Thanks Jianfeng, I'm aware of this; however, as that will not be the case in the v16.07 release, I think that the cuse instructions should still be updated.
>
>Thanks,
>Jianfeng
>
>>
>>       After vhost is enabled and the implementation is selected, build the vhost
>> library.
>>
>> --
>> 1.9.3



More information about the dev mailing list