Hi Srikanth,
Please use VPP 17.04 release and NSH 17.04 release, which contains majority NSH
features and new building system.
For building NSH_SFC 17.04, using below commands:
cd $Path/nsh_sfc/nsh-plugin/
rm -fr build
./build.sh
I just compiled them and it worked well.
Regards,
Hongjun
Hi Daniel,
Can you try with this patch?
https://gerrit.fd.io/r/#/c/7418/
Regards,
Damjan
On 4 Jul 2017, at 22:14, Bernier, Daniel
> wrote:
Hi,
I have ConnectX-4 50GE interfaces running on VPP and for some reason, they
appear as
Hi,
I have ConnectX-4 50GE interfaces running on VPP and for some reason, they
appear as “Unknown” even when running as 40GE.
localadmin@sm981:~$ lspci | grep Mellanox
81:00.0 Ethernet controller: Mellanox Technologies MT27700 Family [ConnectX-4]
81:00.1 Ethernet controller: Mellanox
Hi Hongjun,
I am trying to compile NSH SFC plugin (17.01) for VPP. While compiling, I am
getting the following error for 'nsh_plugin' compilation. But, I can see that a
JIRA (https://jira.fd.io/browse/NSHSFC-18?gerritIssueType=IssueOnly ) ticket is
generated on the same issue. It's resolved by
Hi,
The lookup DPO the route’s path links to needs to be created with:
lookup_dpo_add_or_lock_w_fib_index(fib_index,
DPO_PROTO_IP4,
LOOKUP_MULTICAST,
Etc…);
This is
Please do not introduce dpdk plugin dependencies into interface_api.c. We’ve
moved all dpdk dependencies to the dpdk plugin, on purpose.
What are you trying to do?
Thanks… Dave
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Samuel S
Sent: Tuesday, July 4,
Hi
I want to include header file dpdk.h from src/plugin/dpdk/device to
src/vnet/interface_api.c, but when i compile vpp with build.sh, An error
occurs in the compilation process.
/root/vpp/build-data/../src/vnet/interface_api.c:76:35: fatal error:
dpdk/dpdk.h: No such file or directory
#include
I see thanks! the api add_del_route_t_handler too, I realize, does not free
the label_stack.
Thanks,
-nagp
On Tue, Jul 4, 2017 at 1:54 PM, Neale Ranns (nranns)
wrote:
> Hi nagp,
>
>
>
> My intention there was to ‘pass ownership’ of the label stack to the
> extension. The
Hi nagp,
My intention there was to ‘pass ownership’ of the label stack to the extension.
The caller, the owner of the rpath, should not then free the label stack. This
saves the allocation of a new vector and memcpy.
Regards,
neale
From: on behalf of