Ben,
The patch resolves my problem.
- Lee
-Original Message-
From: Benoit Ganne (bganne) [mailto:bga...@cisco.com]
Sent: Monday, April 8, 2019 6:00 AM
To: Roberts, Lee A. ; vpp-dev@lists.fd.io
Cc: Dave Wallace
Subject: RE: runtime undefined symbol ibv_cmd_query_po
Hi Ole,
Thanks again.
1) I've gone through setting it up for 19.01, but it seems to be having some
issues compiling, might be due to recent changes on how VPP is compiled. I've
done this in the past for 18.10, although my concerns were the loss of
performance from using it.
2) I've considered
I think the way to not create TX nodes for PPPoE interfaces would be to just
remove the .tx_function specified in its device class init in
src/plugin/pppoe/pppoe.c:
/* *INDENT-OFF* */
VNET_DEVICE_CLASS (pppoe_device_class,static) = {
.name = "PPPoE",
.format_device_name = format_pppoe_name,
On Mon, 8 Apr 2019 18:07:48 +0200
Damjan Marion wrote:
> > On 8 Apr 2019, at 17:35, Stephen Hemminger
> > wrote:
> >
> > On Sat, 30 Mar 2019 01:01:29 +0100
> > Damjan Marion wrote:
> >
> >>> On 30 Mar 2019, at 00:58, Sirshak Das wrote:
> >>>
> >>> Apologies, DPDK build failure is not val
> On 8 Apr 2019, at 17:35, Stephen Hemminger wrote:
>
> On Sat, 30 Mar 2019 01:01:29 +0100
> Damjan Marion wrote:
>
>>> On 30 Mar 2019, at 00:58, Sirshak Das wrote:
>>>
>>> Apologies, DPDK build failure is not valid. wipe-release fixed it for me.
>>> One help still required would be a sampl
On Sat, 30 Mar 2019 01:01:29 +0100
Damjan Marion wrote:
> > On 30 Mar 2019, at 00:58, Sirshak Das wrote:
> >
> > Apologies, DPDK build failure is not valid. wipe-release fixed it for me.
> > One help still required would be a sample config for using the rdma-core
> > instead of DPDK would like
Hi Jaeb,
> Thank you for the reply, as always.
>
> I was worried the ideal suggestion would be something along those lines.
> I'm looking at getting BGP traffic to traverse the dataplane and handle it
> via an application, such as Quagga or FRR, then pass it back down to VPP and
> out through t
Hi Ole,
Thank you for the reply, as always.
I was worried the ideal suggestion would be something along those lines.
I'm looking at getting BGP traffic to traverse the dataplane and handle it via
an application, such as Quagga or FRR, then pass it back down to VPP and out
through the appropriat
[Edited Message Follows]
hi,
I want to test 464XLAT feature of VPP19.04 . I tried to build and configure the
NAT and MAP plugin using this guide:
https://wiki.fd.io/view/VPP/NAT#464XLAT
But some CLI command changed , So I using this Configuration :
client (Linux):
sudo ifconfig enp0s8 up sudo
hi,
I want to test 464XLAT feature of VPP19.04 . I tried to build and configure the
NAT and MAP plugin using this guide:
https://wiki.fd.io/view/VPP/NAT#464XLAT
But some CLI command changed , So I using this Configuration :
client (Linux):
sudo ifconfig enp0s8 up sudo ifconfig enp0s8 192.168.5
> I'm looking for suggestions regarding how to best pass traffic through VPP,
> to the Linux host, and back out through VPP, without using different IP
> addresses.
> Ideally traffic would hit a VPP interface, it would get punted up to the
> host, processed by an application, and then sent back
I'm looking for suggestions regarding how to best pass traffic through VPP, to
the Linux host, and back out through VPP, without using different IP addresses.
Ideally traffic would hit a VPP interface, it would get punted up to the host,
processed by an application, and then sent back down VPP an
Lee,
Could you check that this patch fixes your issue:
https://gerrit.fd.io/r/c/18741/
You may have to use LD_LIBRARY_PATH so DPDK can find
librte_pmd_mlx5_glue.so.19.02.0 at runtime.
ben
> -Original Message-
> From: Benoit Ganne (bganne)
> Sent: lundi 8 avril 2019 10:02
> To: 'Lee Rob
Dave, this is probably an issue we want to fix for VPP 19.04.
Right, there is a conflict between internal VPP rdma-core and external
(typically distribution package) rdma-core when enabling MLX DPDK support.
We compile a very small subset of RDMA core statically to enable VPP RDMA
driver. This s
14 matches
Mail list logo