> >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