Re: [vpp-dev] clang-9

> On 12 May 2020, at 10:10, Andreas Schultz > wrote: > > > > Am Di., 12. Mai 2020 um 10:00 Uhr schrieb Damjan Marion via lists.fd.io > <http://lists.fd.io/> <mailto:me@lists.fd.io>>: > > > > > On 12 May 2020, at 03:40, L

Re: [vpp-dev] clang-9

>>> binary >> install on Ubuntu-18.04 on Arm; >>> 2.2 keep the code as it is now, although it will disable >>> multi-arch >> support for these two CPUs with clang-9; >>> 2.3 when we are developing code or doing benchmarking,

Re: [vpp-dev] clang-9

.3 when we are developing code or doing benchmarking, we need > to hack the code temporarily from “set(CMAKE_C_COMPILER_NAMES clang-10 > clang-9 gcc-9 cc)” to “set(CMAKE_C_COMPILER_NAMES clang-10 gcc-9 cc)”, so > that multi-arch will be supported with gcc-9. > > Could you suggest on

Re: [vpp-dev] rx misses observed on dpdk interface

ok, this is quite common to see. What is your question / concern? — Damjan > On 7 May 2020, at 04:42, zhangt...@inspur.com wrote: > > Hi all； > I am using Intel 82599 (10G) , running with VPP v20.01-release with line > rate of 10G 128 bytes of packet size， i am observing Rx misses on the

Re: [vpp-dev] IPsec tunnel interfaces?

Is there a way to keep ipsecX naming, use of ipipX for ipsec tunnels seems to be confusing for many people... > On 7 May 2020, at 14:15, Neale Ranns via lists.fd.io > wrote: > > > Hi Chris, > > They were replaced by ipip interfaces protected by SAs: >

Re: [vpp-dev] Segmentation fault in rdma_device_input_refill when using clang compiler

i already pushed one, can you updatr it instead? Thanks -- Damjan > On 7 May 2020, at 01:56, Elias Rudberg wrote: > > Hi Dave and Damjan, > > Here is instruction and register info: > > (gdb) x/i $pc > => 0x7fffabbbdd67 :vmovdqa64 > -0x30a0(%rbp),%ymm0 > (gdb) info registers rbp ymm0 >

Re: [vpp-dev] Segmentation fault in rdma_device_input_refill when using clang compiler

Can you try this: diff --git a/src/plugins/rdma/input.c b/src/plugins/rdma/input.c index cf0b6bffe..b461ee27b 100644 --- a/src/plugins/rdma/input.c +++ b/src/plugins/rdma/input.c @@ -103,7 +103,7 @@ rdma_device_input_refill (vlib_main_t * vm, rdma_device_t * rd, if (is_mlx5dv) { -

Re: [vpp-dev] Handshake procedure

> > On 5 May 2020, at 13:45, Artem Glazychev wrote: > > Hello. > > I'm want to make plugin for Wireguard tunnel. > Wireguard has a handshake procedure. It occurs every few minutes. > I have a question: is it possible to make this procedure in a vpp plugin? Can > i see similar examples/ideas

Re: [vpp-dev] clang-9

Lock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx) > 07:56:20 File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 59, > in __init__ > 07:56:20 unlink_now) > 07:56:20 OSError: [Errno 28] No space left on device > ... > > Regards, > John > > Fr

Re: [vpp-dev] clang-9

gument] > clang: error: argument unused during compilation: > '-L/root/origin/build-root/install-vpp-native/external/lib' > [-Werror,-Wunused-command-line-argument] > > Thanks. > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io>> On Beha

Re: [vpp-dev] Prefetch Clustering

> On 29 Apr 2020, at 00:55, Christian Hopps wrote: > > I wrote this longish email with diagrams and what not and accidentally > deleted it, so this one's shorter.. sorry :) > > So I think this brings into question the value of doing more than a single > buffer worth of prefetch in a loop

[vpp-dev] VPP Multi-versioning changes on x86

As you probably know, VPP build system is compiling selected C files multiple times with different compiler flags and there is runtime infra which detect CPU type on runtime and selects optimal binary. On x86 today we have following variants: - baseline (-march=core-i7) - avx2

Re: [vpp-dev] clang-9

00018 >> (gdb) p f >> $7 = (svm_fifo_t *) 0x204024780 <- the thing being memset >> >> If my math is correct, the right hand operator is 0x1f0 + 0x204024780 + >> 0x100018 = 0x204124988. Doesn’t look to be aligned. Could this be the issue? >> >> Florin >> >

Re: [vpp-dev] clang-9

emset > > If my math is correct, the right hand operator is 0x1f0 + 0x204024780 + > 0x100018 = 0x204124988. Doesn’t look to be aligned. Could this be the issue? > > Florin > >> On Apr 28, 2020, at 7:13 AM, Damjan Marion via lists.fd.io >> wrote: >> >> >>

[vpp-dev] clang-9

Folks, As there is bug in gnu assembler which is shipping with ubuntu 18.04 we are not able to produce working binaries with avx512 instruction set. Because of that, I had to change default to avx2. reported bug[1], but it is ignored for a year. As alternative[2], I wanted to consider using

[vpp-dev] Prefetch Clustering

Folks, At many places in the code we have cluster of prefetch instructions which seems to be bad idea to do. I already noticed that perfermance is better when prefetch instructions are interleaved with other code, And there is nice section explaining right that in the Intel Optimization

Re: [vpp-dev] dpdk-20.02 compile error for Intel atom

looks like your compiler version is so old that it doesn’t know about silvermont. You need newer one suggest gcc-8 at least. Also if i read it right, you use kernel 3.10, suggest using something newer. VPP uses syscalls which are not available in kernel 3.10 -- Damjan > On 25 Apr 2020,

Re: [vpp-dev] Observed Txpacket drops (dpdk tx failure)

For a start try with newer version of vpp. 18.07 is not supported for a long time -- Damjan > On 25 Apr 2020, at 18:17, Aswin Surendran wrote: > >  > Hi, > > I am seeing "Tx packet drops" on a VPP controlled DPDK device (VPP 18.07). > Initially, traffic was working fine between the

Re: [vpp-dev] vpp project committer nomination: Benoit Ganne

+1 > On 21 Apr 2020, at 13:39, Dave Barach via lists.fd.io > wrote: > > Vpp project committers: please vote +1, 0, -1 on the > mailto:vpp-dev@lists.fd.io mailer as to whether we should add Benoit Ganne as > a vpp project committer. > > Ben has about 150 merged patches, see >

Re: [vpp-dev] Checkstyle script not work in ubuntu

/tools/clang-format/clang-format-diff.py <https://github.com/llvm-mirror/clang/blob/master/tools/clang-format/clang-format-diff.py> — Damjan > On 18 Apr 2020, at 11:00, Damjan Marion via lists.fd.io > wrote: > > > If we decided to stick with old indent, which i still d

Re: [vpp-dev] Checkstyle script not work in ubuntu

If we decided to stick with old indent, which i still disagree that is right thing to do, can you just compile indent all the time and modify path so /opt/vpp/…/bin/ comes first. I really don’t like one more option in the top level Makefile. — Damjan > On 18 Apr 2020, at 10:29, Andrew

Re: [vpp-dev] VPP and Core allocation

Running on 2 sibling threads on haswell/bradwell usually gives around 10% more performance, and on skylake/cascadelake number is 20% or more. Caveat is that you need to rely on RSS or some other mechanism do equally distribute traffic between 2 cores…. — Damjan > On 17 Apr 2020, at 09:12,

Re: [vpp-dev] Macswapplugin compilation failure

that code seems to be seriously outdated, take sample plugin from the src/examples/sample-plugin https://git.fd.io/vpp/tree/src/examples/sample-plugin — Damjan > On 14 Apr 2020, at 15:14, tupai via lists.fd.io > wrote: > > Hi All, >

Re: [vpp-dev] dpdk-20.02 compile error for Intel atom

+1, -march=atom is bad, you likely have newer ATOM CPU, so consider using -march={silvermont,goldmont,goldmont-plus}. What exact CPU are you targeting? — Damjan > On 14 Apr 2020, at 12:13, Benoit Ganne (bganne) via lists.fd.io > wrote: > > Hi, > > This is a dpdk issue, not a VPP issue.

Re: [vpp-dev] naive questions on VPP memory usage ( does it ever come down )

Can you capture "show memory main-heapsh” before and after? Will show you exact number of pages mapped. I.e. vpp# show memory main-heap Thread 0 vpp_main virtual memory start 0x7f13c03ae000, size 1048640k, 262160 pages, page size 4k numa 1: 45220 pages, 180880k not mapped: 216940

Re: [vpp-dev] Spike in core VPP VSZ

Not sure about 19.08 but i just tried on latest master. Without dpdk core size is is 1.29G uncompressed and 1.31G with dpdk plugin loaded. — Damjan > On 1 Apr 2020, at 14:09, siddarth rai wrote: > > Hi, > I am using VPP version v19.08.1 > I have noticed that the virtual memory size for core

Re: [vpp-dev] worker barrier state

> On 25 Mar 2020, at 16:01, Christian Hopps wrote: > > Is it supposed to be the case that no packets are inflight (*) in the graph > when the worker barrier is held? > > I think perhaps MP unsafe API code is assuming this. > > I also think that the frame queues used by handoff code violate

Re: [vpp-dev] VPP memif ping taking ~20ms

That’s weird…. Can you capture packet trace on both sides? > On 12 Mar 2020, at 11:16, vyshakh krishnan wrote: > > Hi Damjan, > > We don't have any worker threads and memif is in polling mode: > > DBGvpp# sh int rx-placement > Thread 0 (vpp_main): > node memif-input: > memif11/11

Re: [vpp-dev] Ignore SIGPROF signal in VPP

> On 12 Mar 2020, at 10:49, Lijian Zhang wrote: > > Hi Maintainers, > We are profiling VPP with MAP (a software profile suite on Arm CPUs, see > details > inhttps://www.arm.com/products/development-tools/server-and-hpc/forge/map) on > Arm CPUs. > > The MAP sampler runs inside target

Re: [vpp-dev] Failure of creating avf interface on SMP system

> On 12 Mar 2020, at 10:30, Lijian Zhang wrote: > > Hi Damjan, > We observed a failure when creating avf interfaces on two types of Arm CPUs, > both are SMP system, only one numa-id. > > Function vlib_pci_get_device_info() reads ‘/sys/bus/pci/devices/ id>/numa_node’ to check which numa_node

Re: [vpp-dev] VPP memif ping taking ~20ms

Are you running VPP with worker threads and using interrupt mode in memif? can you capture “sh int rx-placement” on both sides? — Damjan > On 11 Mar 2020, at 15:44, vyshakh krishnan wrote: > > Hi All, > > When we try to ping back to back connected memif interface, its taking around > 20

Re: [vpp-dev] Need advice on sw_interface_set_rx_placement() API #vpp

> On 10 Mar 2020, at 17:39, visaev via Lists.Fd.Io > wrote: > > Hi there, > > There is a VPP APIs function sw_interface_set_rx_placement(). This function > allows us to set specific worker for the specified queue. > And this function takes worker_id as an argument. worker_id is then >

Re: [vpp-dev] vpp project committers: formal vote to add Matt Smith as a vpp committer

+1 > On 2 Mar 2020, at 15:15, d...@barachs.net wrote: > > VPP committers, please vote +1, 0, -1 on adding Matt Smith > (mgsm...@netgate.com ) as a vpp project > committer. > Matt has contributed O(100) merged patches, and he recently contributed the > entire vrrp

Re: [EXT] [vpp-dev] Regarding buffers-per-numa parameter

;> > Everything looks fine with Buffers 537600. >> In which branch, Commit: df0191ead2cf39611714b6603cdc5bdddc445b57 is >> previous commit of b6e8b1a7c8bf9f9fbd05cdc3c90111d9e7a6897? >> >> Thanks, >> Nitin >> > -Original Message- >> >

Re: [EXT] [vpp-dev] Regarding buffers-per-numa parameter

will see that this one is already > > excluded… > > > > Also, it will not be easy to explain how this patch blows tx function in > > dpdk > > mlx5 pmd… > > > > — > > Damjan > > > > > On 17 Feb 2020, at 11:12, Nit

Re: [vpp-dev] Supported kernel versions

> On 21 Feb 2020, at 01:45, Kevin Meyer wrote: > > Hi, > The compatibility table here says VPP 20.02 should work with Ubuntu 18.04: > https://wiki.fd.io/view/VPP_-_Working_Environments. > > We are attempting to compile VPP 20.02 using Ubuntu 18.04.4 with Linux kernel > 5.3.0-40. When we

Re: [vpp-dev] Debug image build error on Arm CPUs

This should help…. https://gerrit.fd.io/r/c/vpp/+/25243 — Damjan > On 18 Feb 2020, at 09:38, Lijian Zhang wrote: > > Hi Damjan, > There’s a compiling error with the debug image with the code segment below. > The error message is pasted as follow. > >

Re: [EXT] [vpp-dev] Regarding buffers-per-numa parameter

t; Type: refactor > > Change-Id: I72221b97d7e0bf5c93e20bbda4473ca67bfcdeb4 > Signed-off-by: Damjan Marion damar...@cisco.com > > You can also try copying src/plugins/dpdk/buffer.c from stable/2001 branch to > stable/1908 > > Thanks, > Nitin > > From: vpp-dev@lists.fd.io On Behalf Of Da

Re: [vpp-dev] Regarding buffers-per-numa parameter

> On 17 Feb 2020, at 07:37, chetan bhasin wrote: > > Bottom line is stable/vpp 908 does not work with higher number of buffers but > stable/vpp2001 does. Could you please advise which area we can look at ,as it > would be difficult for us to move to vpp2001 at this time. I really don’t have

Re: [vpp-dev] VPP crashes on CSIT Taishan server

Makes sense to me, please submit patch to gerrit… — Damjan > On 14 Feb 2020, at 04:18, Lijian Zhang wrote: > > Hi, > VPP crashes on CSIT Taishan server due to function vlib_get_thread_core_numa > (unsigned cpu_id) not getting NUMA node correctly via cpu_id on Taishan > server. >

Re: [vpp-dev] VLIB headroom buffer size modfification

you need to set it on both sides: For VPP: $ ccmake build-root/build-vpp-native/vpp and change PRE_DATA_SIZE to 256 or modify following line: src/vlib/CMakeLists.txt: set(PRE_DATA_SIZE 128 CACHE STRING "Buffer headroom size.”) For DPDK you should be able to build custom ext deps package: $

Re: [vpp-dev] Regarding buffers-per-numa parameter

Shouldn’t be too hard to checkout commit prior to that one and test if problem is still there… — Damjan > On 12 Feb 2020, at 14:50, chetan bhasin wrote: > > Hi, > > Looking into the changes in vpp 20.1 , the below change looks good important > related to buffer indices . > > vlib: don't

Re: [EXT] [vpp-dev] Regarding unix_epoll_input on worker cores

rstand. I realized that AVF supports MSIX interrupts hence > native plugin can easily leverage this feature (provided hardware supports > MSIX per RQ) > > Thanks, > Nitin > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io>&g

Re: [vpp-dev] Regarding unix_epoll_input on worker cores

There are 2 use cases: - delivering RX queue interrupts directpy to the worker which handles specific queue - waking up worker thread over eventfd None of them is used today, but it should be at some point... -- DAmjan > On 5 Feb 2020, at 08:39, Nitin Saxena wrote: > > Hi, > > I understand

Re: [vpp-dev] [csit-dev] crypto_ia32 -> crypto_native

Engineer – Software > Cisco Systems Limited > > From: csit-...@lists.fd.io <mailto:csit-...@lists.fd.io> > mailto:csit-...@lists.fd.io>> On Behalf Of Damjan > Marion via Lists.Fd.Io > Sent: Monday, January 27, 2020 9:54 PM > To: vpp-dev mailto:vpp-dev@lists.fd.io&g

[vpp-dev] crypto_ia32 -> crypto_native

Folks, To avoid code duplication i would like to rename crypto_ia32 plugin into crypto_native. Reason is adding ARMv8 support which seems to be very similar to IA32 in terms of implementing CBC and GCM. Any objections or caveats? -- Damjan-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all

Re: [vpp-dev] VPP VSZ shoots to 200GB because of DPDK plugin

Can you capture "cat /proc/$(pgrep vpp)/maps” and put it into pastebin? — Damjan > On 24 Jan 2020, at 09:07, siddarth rai wrote: > > Hi, > > Thanks a lot for the tip. > > I would still like to know what is causing DPDK plugin to take up so much > VSZ. > If any one can give me any

Re: [vpp-dev] interface activation problem using VPP in Azure with DPDK failsafe interfaces #vpp #dpdk #azure

I’m far away from being dpdk-expert, I’m much closer to being expert in avoiding use of dpdk :) No idea what’s wrong here, never used this failsafe beast, maybe using native rdma driver can help -- Damjan On 23 Jan 2020, at 18:13, Balaji Venkatraman via Lists.Fd.Io wrote:  cc-Damjan

Re: [vpp-dev] Who is the maintainer of src/vnet/l2tp?

i don't think anybody maintains it actively. It was done long time ago, before VPP was open-sourced for one project which was only using IPv6. -- Damjan > On 9 Jan 2020, at 15:25, Sun, Chenmin wrote: > >  > Hi, > Does anybody know who is the maintainer of src/vnet/l2tp? I didn't find who

Re: [vpp-dev] Linking external libraries to VPP executable

> On 3 Jan 2020, at 08:13, siddarth rai wrote: > > Hi, > > My plugin is linked to an external lib. > When my plugin calls the init function of that external lib, it runs into > some problems with symbols (presumably the external lib init function calls a > dlopen to load some other files)

Re: [vpp-dev] Linking external libraries to VPP executable

99% of vpp code is not in vpp executable so i wander why do you want to do that? both some of vpp standard libraries (vnet, vlib, ..) and some of vpp plugins are linked against libs, so to be able to help you i need more details... -- Damjan > On 2 Jan 2020, at 14:20, siddarth rai wrote: >

Re: [vpp-dev] Linking external libraries to VPP executable

what do you mean by “vpp executable lib”? can you provide more details what exactly do you want to do? -- Damjan > On 2 Jan 2020, at 12:27, siddarth rai wrote: > >  > Hello, > > I am working on VPP 1908. > I want to link some external non-vpp libraries to my vpp executable lib. > > Would

Re: [vpp-dev] Discrepancies between CI jobs and s5ci

+1, simple is key here I think that we simply should remove that tap test as it falls under device driver tests which we don't test in make test framework. PS I really don't like direction where test framework is going, originally it was very simple to write tests even without having python

Re: [vpp-dev] Some investigation on bihash MAC table

> On 27 Dec 2019, at 07:09, Lijian Zhang wrote: > > Hi All, > > We have tried to improve L2 performance on Arm servers by investigating > bihash data structure. Could you please review and suggest on the findings? > > 1. Apply prefetches in Bihash MAC-table > > > Per software profiling

Re: [vpp-dev] #vpp How can I make SR-IOV VF work in VPP in host ?

The while idea is that vpp or any other vf driver should not be able to enable this -- Damjan > On 25 Dec 2019, at 13:48, Christian Hopps wrote: > > Is this something that VPP should be enabling instead though? > > Thanks, > Chris. > >> On Dec 20, 2019, at 2:26 AM,

Re: [vpp-dev] arm hardware recommendation

that board seems to be dead end, after Marvell bought Cavium looks like they stopped opensource activities around Armada, so for example musdk is not updated for more than a tear. NXP seems to be better choice with lx2160, 16 cores. I have ClearFog CX LX2K which is more expensive version of the

Re: [vpp-dev] arm hardware recommendation

> On 22 Dec 2019, at 01:02, Paul Vinciguerra wrote: > > I'm looking for something that I can run tests on an arm platform in a > reasonable timeframe. > > Any suggestions? What is your budget? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online

Re: [vpp-dev] VPP VSZ shoots to 200GB because of DPDK plugin

What is exact problem here? vsz is just virual memory size, it doesn’t mean that memory is allocated... Can you share your startup.conf? — Damjan > On 16 Dec 2019, at 13:59, siddarth rai wrote: > > Hi Benoit, > > Unfortunately, that is not an option for me. I am using dpdk plugin. > >

Re: [vpp-dev] Regarding high speed I/O with kernel

> On 7 Dec 2019, at 04:46, Prashant Upadhyaya wrote: > > On Fri, Dec 6, 2019 at 9:32 PM Damjan Marion wrote: >> >> >> On 6 Dec 2019, at 07:16, Prashant Upadhyaya wrote: >>> >>> Hi, >>> >>> I use VPP with DPDK driver for I/O with NIC. >>> For high speed switching of packets to and

Re: [vpp-dev] Regarding high speed I/O with kernel

> On 6 Dec 2019, at 07:16, Prashant Upadhyaya wrote: > > Hi, > > I use VPP with DPDK driver for I/O with NIC. > For high speed switching of packets to and from kernel, I use DPDK KNI > (kernel module and user space API's provided by DPDK) > This works well because the vlib buffer is backed by

Re: [vpp-dev] Did anything ever make vpp's native ipsec stack (ia32) work with dpdk/phy nic?

Hi Chuan, You need to specify salt for GCM to work in static config. i.e. ipsec sa add 1 spi 255129 esp crypto-key 0123456789012345678901234567890101234567890123456789012345678901 crypto-alg aes-gcm-256 salt 0x12345678 LMK if this helps... -- Damjan > On 27 Nov 2019, at 15:16, Chuan Han

Re: [vpp-dev] efficient use of DPDK

> On 3 Dec 2019, at 17:06, Thomas Monjalon wrote: > > 03/12/2019 13:12, Damjan Marion: >>> On 3 Dec 2019, at 09:28, Thomas Monjalon wrote: >>> 03/12/2019 00:26, Damjan Marion: Hi THomas! Inline... >> On 2 Dec 2019, at 23:35, Thomas Monjalon wrote: >

Re: [vpp-dev] efficient use of DPDK

> On 3 Dec 2019, at 17:06, Thomas Monjalon wrote: > > 03/12/2019 13:12, Damjan Marion: >>> On 3 Dec 2019, at 09:28, Thomas Monjalon wrote: >>> 03/12/2019 00:26, Damjan Marion: Hi THomas! Inline... >> On 2 Dec 2019, at 23:35, Thomas Monjalon wrote: >

Re: [vpp-dev] efficient use of DPDK

> > On 3 Dec 2019, at 09:28, Thomas Monjalon wrote: > > 03/12/2019 00:26, Damjan Marion: >> >> Hi THomas! >> >> Inline... >> On 2 Dec 2019, at 23:35, Thomas Monjalon wrote: >>> >>> Hi all, >>> >>> VPP has a buffer called vlib_buffer_t, while DPDK has rte_mbuf. >>> Are there some

Re: [vpp-dev] efficient use of DPDK

Hi THomas! Inline... > On 2 Dec 2019, at 23:35, Thomas Monjalon wrote: > > Hi all, > > VPP has a buffer called vlib_buffer_t, while DPDK has rte_mbuf. > Are there some benchmarks about the cost of converting, from one format > to the other one, during Rx/Tx operations? We are benchmarking

Re: [vpp-dev] #vpp How does VPP link DPDK lib？

DPDK is statically linked into dpdk plugin (dpdk_plugin.so). -- Damjan > On 29 Nov 2019, at 06:50, wei_sky2...@163.com wrote: > >  > We think VPP uses DPDK for data receive from nic, but it seems no dpdk lib > exist in vpp project. > we also try to use readelf to check the libs used by vpp,

Re: [vpp-dev] VPP New plugin intergation

> On 19 Nov 2019, at 08:36, Muthukumar Sivaperumal > wrote: > > Hi Team, > > We are trying to implement a plugin to process all packets on virtual > interface. > We are doing span from physical interface to virtual interface on vpp,by > running plugin arc node with

Re: [vpp-dev] VPP, QAT and multi threading

Dear Gopa, > On 20 Nov 2019, at 04:35, Gopakumar Choorakkot Edakkunni > wrote: > > Hi, > > I understand from your architecture that threads have a complete copy of the > entire graph, to avoid locking etc.. Not sure what do you exactly mean by copy of the entire graph. We run independent

Re: [vpp-dev] Change to Gerrit

+1 > On 20 Nov 2019, at 19:32, Paul Vinciguerra wrote: > > How would the group feel about implementing something like [0], so that > changes to the commit message don't trigger rebuilds? > > To enforce the commit message structure, we could skip the jobs and set > verify label after the

Re: [vpp-dev] address sanitizer

Instead of creating build targets, what about adding custom arguments to the cmake project: i.e. cmake -DCMAKE_BUILD_TYPE=release -DVPP_ENABLE_SANITIZERS=address,memory,thread So consumer can pick which ones to use. BTW Have you looked at others, looks like at least clang have plenty of

Re: [vpp-dev] Did anything ever make vpp's native ipsec stack (ia32) work with dpdk/phy nic?

Hi Chuan, Please note that we have daily run of IPSec performance tests in CSIT with VPP running on the physical NIC with DPDK drivers. Also please note that every VPP patch is passing unit tests with IETF and NIST test encryption vectors. Other comments inline…. > On 18 Nov 2019, at 23:48,

Re: [vpp-dev] TAP interface rx strange behavior #vpp

Good finding, this may help you: https://gerrit.fd.io/r/c/vpp/+/23396 — Damjan > On 12 Nov 2019, at 17:02, Dimitar Ivanov wrote: > > All this happen in case where tap interface is set to some bridge-domain ! If > i create tap interface and set mactime on it, >

Re: [vpp-dev] TAP interface rx strange behavior #vpp

> On 12 Nov 2019, at 10:19, Dimitar Ivanov wrote: > > Sorry for missing post to vpp-dev. > So i'm using correct TAP interface. yes, Looks like a bug. Somebidy will need to debug it. If you have time and gdb skills, try to find out if vnet_feature_start_device_input_x1 in

Re: [vpp-dev] TAP interface rx strange behavior #vpp

> On 12 Nov 2019, at 08:57, Dimitar Ivanov wrote: > > Hi All, > I need a help in investigation of one problem with TAP interface. I try to > develop plugin that inspects packets send from Host Linux via TAP interface > and take some actions on them. Scenario is like this: > Linux Host Tap

Re: [EXT] [vpp-dev] cross-compilation support

> On 6 Nov 2019, at 13:15, Stanislav Chlebec > wrote: > > Hello Damjan and all > > We had a meeting in ARM team to clarify our standpoint and goals on > cross-compilation for aarch64. > We welcome your initiative to make this process more generic and effective > and we are thankful that

Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

alf Of Dave Barach via Lists.Fd.Io > Sent: Wednesday, October 30, 2019 10:49 AM > To: Christian Hopps mailto:cho...@chopps.org>>; Damjan > Marion mailto:dmar...@me.com>> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] Change in vpp[master]: ebuild: C

Re: [vpp-dev] Deprecation of src/plugins/dpdk/ipsec, say it aint so.

> On 5 Nov 2019, at 15:17, Christian Hopps wrote: > > A recent code review comment mentioned that src/plugins/dpdk/ipsec would be > deprecated soon. > > IMO this should not happen until at least equal functionality has been put in > place to replace it (and maybe not even then -- see my

Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?

i remember doing corelist-workers with > 50 cores….. If you paste traceback we may have better clue what is wrong… — Damjan > On 4 Nov 2019, at 18:51, Chuan Han via Lists.Fd.Io > wrote: > > All even number cores are on numa 0, which also hosts all nics. > > It seems corelist-workers

Re: [vpp-dev] forge committer

> On 3 Nov 2019, at 03:20, Satoru wrote: > > Hello vpp-dev community, > > We are planning to contribute some plugin and PR to be reviewed in the vpp > gerrit. The PR includes commits from several people and would like to keep > the commit log. It seems that we need forge committer for the

Re: [EXT] [vpp-dev] cross-compilation support

s, i.e. creating Centos ARM rpms on Ubuntu x86 >>>> machine. That is the reason why i tried to see if we can use docker >>>> instead to be able to build cross-arch, cross-distro or cross- >>>> distro-version >> (or all 3 together) packag

Re: [EXT] [vpp-dev] cross-compilation support

My patch does native compilation only if TARGET_QUAD is equal to >> HOST_QUAD, where QUAD is: >> - distro name (ubuntu, centos) >> - distro version (18.04, 7.3) >> - arch (x86_64, aarch64, ...) >> - platform (generic, thunderx, ….) >> >> it also support mult

Re: [EXT] [vpp-dev] cross-compilation support

> On 31 Oct 2019, at 21:41, Christian Hopps wrote: > >> >> On Oct 31, 2019, at 4:03 PM, Damjan Marion via Lists.Fd.Io >> wrote: >> >> >> Let me clarify a bit more, as i can see that this still may be confusing: >> >> 1) VPP is using c

Re: [EXT] [vpp-dev] cross-compilation support

early draft, but it shows some basic mechanics used to produce both native and cross packages. > On 31 Oct 2019, at 20:32, Damjan Marion via Lists.Fd.Io > wrote: > > I have similar scheme on my mind, where you can have platform specific mk > files loaded…. > >> On 31 O

Re: [EXT] [vpp-dev] cross-compilation support

ing, unfortunately. >>> >>> Thanks, >>> Chris. >>> >>>> On Oct 31, 2019, at 2:23 PM, Damjan Marion wrote: >>>> >>>> >>>> That is just copy paste from Ben’s command line. >>>> >>>> As. i w

Re: [vpp-dev] cross-compilation support

I slightly modified my patch, so it builds both native packages and cross packages out of same makefile. Native: $ make pkg $ ls -la build/native-release total 99352 drwxrwxr-x 3 damarion damarion 4096 Oct 31 20:00 . drwxrwxr-x 10 damarion damarion 4096 Oct 31 19:55 .. drwxrwxr-x 22

Re: [vpp-dev] cross-compilation support

ian Hopps wrote: >>> >>> Requiring root privileges for building software is pretty atypical and >>> limiting, even for x-compiling. >>> >>> Thanks, >>> Chris. >>> >>>> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists

Re: [vpp-dev] cross-compilation support

t; Thanks, > Chris. > >> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io >> wrote: >> >> >> So what people think about following approach for cross-compilation: >> >> Patch: https://gerrit.fd.io/r/c/vpp/+/23153 >> >

Re: [vpp-dev] per-node tracing

$ git grep -h -B20 VLIB_NODE_FLAG_TRACE_SUPPORTED | grep VLIB_REGISTER_NODE VLIB_REGISTER_NODE (avf_input_node) = { VLIB_REGISTER_NODE (dpdk_input_node) = { VLIB_REGISTER_NODE (dpdk_crypto_input_node) = VLIB_REGISTER_NODE (ixge_input_node, static) = { VLIB_REGISTER_NODE (mrvl_pp2_input_node) = {

[vpp-dev] cross-compilation support

So what people think about following approach for cross-compilation: Patch: https://gerrit.fd.io/r/c/vpp/+/23153 At the moment this is just to show idea, so it works only for x86-to-x86 and between ubuntu versions only but it can be easily extended to

Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

> On 31 Oct 2019, at 13:18, Benoit Ganne (bganne) wrote: > >> I was going to remain silent, but since there's now multiple people saying >> this sounds good -- I think this sounds horrible. :) >> To wit, it seems too complex and too much setup/overhead. I'll try and >> look closer at this soon

Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

n mailto:dmar...@me.com>> >> Cc: Christian Hopps mailto:cho...@chopps.org>>; >> Stanislav Chlebec >> mailto:stanislav.chle...@pantheon.tech>>; >> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> >> Subject: Re: [vpp-dev] Change in vpp[master]: ebuild:

Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

Current cross-compilation support, even with this patch is far away from being right. It is basically hack from one to another use case. - it doesn’t work if target distro and/or version != build distro and version - packaging doesn’t have a clue about target arch and dependencies - DPDK have

Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

(resending with bogus email addresses removed, added vpp-dev) Honestly, I don't see lot of value in this kind of cross-compilation support. VPP today is linked against lot of shared libraries provided by the current distro, so effectively you can cross-compile only for same distro, same

Re: [vpp-dev] GNU indent pain

> On 22 Oct 2019, at 20:06, Andrew Yourtchenko wrote: > > On 22 Oct 2019, at 19:42, Damjan Marion > wrote: > >> >> >>> On 22 Oct 2019, at 19:26, Andrew  Yourtchenko >> > wrote: >>> >>>  >>> Damjan, >>> >>> What impact will this have on

Re: [vpp-dev] GNU indent pain

gt; be exercising the failure cases as much (e.g., long field name combinations > appearing in the far right columns seems to give indent hiccups). > > Thanks, > Chris. > >> On Oct 22, 2019, at 1:09 PM, Damjan Marion via Lists.Fd.Io >> wrote: >> >>

Re: [vpp-dev] GNU indent pain

ould not go there, if this change hurts automatic cherry-pick, lets forget it > > --a > >> On 22 Oct 2019, at 19:09, Damjan Marion via Lists.Fd.Io >> wrote: >> >> >> Folks, >> >> Now we have 2nd release of ubuntu out which comes with new GNU i

[vpp-dev] GNU indent pain

Folks, Now we have 2nd release of ubuntu out which comes with new GNU indent which introduces lot of bug fixes. Unfortunately our repo is full of products of bugs which are fixed, so it results in big mess when new indent is used. Most of the time, it is about space after __attribute__ where

Re: [vpp-dev] Coverity run FAILED as of 2019-10-22 14:00:19 UTC

you can try to wrap that assert with #ifndef __COVERITY__ ... -- Damjan > On 22 Oct 2019, at 16:22, Benoit Ganne (bganne) via Lists.Fd.Io > wrote: > > Hmm. Almost if not all of those are due to the newly introduced (by me...) > vec_set_len() macro https://gerrit.fd.io/r/c/vpp/+/21935 >

Re: [vpp-dev] Basic l2 bridging does not work

t;>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> &

Re: [vpp-dev] Basic l2 bridging does not work

L2 flood packets >>> 1 ethernet-input l3 mac mismatch >>> 3 eth1-output interface is down >>> 30922 eth0-output interface is down >>> vpp# >>> >>> &

<    1   2   3   4   5   6   7   >