Re: [vpp-dev] Plugin Versions

SemVer says: > Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards > compatible bug fixes are introduced. > A bug fix is defined as an internal change that fixes incorrect behavior. That means API version should be bumped even if the change only affects the implementation (and n

Re: [vpp-dev] device job voting?

I forgot to add, that technical details of this kind are usually being discussed in great detail on fd.io slack, channel csit-papi. Vratko. From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) Sent: Friday, 2019-May-24 18:14 To: 'Paul Vinciguerra' ; vpp-dev@lists.fd.io Subject: RE: [vp

Re: [vpp-dev] device job voting?

Hi Paul. > "cli_inband" commands There are other ways how CSIT can be broken by an innocent looking VPP change. CSIT currenlty does use: - VAT console commands - vppctl commands - cli_inband via PAPI - in-house serialization-deserialization for using PAPI remotely [1] Other VPP interfaces which

[vpp-dev] device job voting?

Long story short, a VPP change [0] has broken CSIT and needs a fix [1]. If the devicetest job was voting, it would [2] vote -1, preventing the breakage. Vratko. [0] https://gerrit.fd.io/r/18352 [1] https://gerrit.fd.io/r/19636 [2] https://jenkins.fd.io/job/vpp-csit-verify-device-master-1n-skx/8

Re: [vpp-dev] false verified + 1 for gerrit jobs

> reduce the number of retries (or possibly completely) +1 for completely. Vratko. -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Ed Kern via Lists.Fd.Io Sent: Tuesday, 2019-May-07 00:34 To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) Cc: vpp-dev@lists.fd.

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

> I increased idle timeout from 10min to 60min. Was it around the time this [2] job failed recently? 16:14:44 ++ sleep 184s 16:16:29 FATAL: command execution failed Vratko. [2] https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-hsw/335/console -Original Message- From: csit-..

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

>> interleaved by quick periods of activity >>> 09:26:36 ++ sleep 197s > send any keepalive packages I always assumed the console outputs are enough to keep jnlp connection alive. Also, I believe this failure over weekend has hit multiple jobs at once. For example https://jenkins.fd.io/job/cs

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File exists That error is expected, it just means the testbed is currently used by another job, so this job should sleep a while and try again. > the job was waiting (sleep) from 04:45:12 til 05:26:36 I believe my browser is showi

Re: [vpp-dev] backward PAPI-compatibility

By the way, I prefer to have default values defined already in .api.json files, for example like this [6]; assuming it does not break language bindings. That way we will have just one kind of backward compatibility, so it will be easier to decide API version bumps. Vratko. [6] https://gerrit.fd

Re: [vpp-dev] backward PAPI-compatibility

o/r/#/c/19198/3/src/vnet/interface.api Oops, I forgot Drafts are not visible in VPP Gerrit. The links should be visible now. Vratko. From: vpp-dev@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Monday, 2019-April-29 16:30 To: vpp-d

[vpp-dev] backward PAPI-compatibility

Hello VPP reviewers. When adding a comment to API flag day document, I have stumbled upon an idea, that is somewhat larger than the document itself. It has to do with a weaker form of VPP backward compatibility, specific to clients using Python API (PAPI). Here is the relevant part of the commen

[vpp-dev] release commit rule

One sentence from miletone e-mails caught my attention: > Commit first to the release throttle, > then "git cherry-pick" into master I have tried searching for context. I have found this [0] wiki edit, with just > Here are a few common-sense suggestions: as an explanation. When I was working on O

Re: Re： [vpp-dev] is sw_interface_dump api bug?

> Hope this can help: https://gerrit.fd.io/r/#/c/18302/ I prefer https://gerrit.fd.io/r/18299 Vratko. -Original Message- From: Yohan Pipereau (ypiperea) Sent: Thursday, 2019-March-14 18:33 To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) ; Dave Barach (dbarach) ; "Zhou Y

Re: Re： [vpp-dev] is sw_interface_dump api bug?

>> 4) sw_interface_dump return loop10's info instead of loop1 > predictable behavior Probably it would be sufficient to just improve the current [1] documentation. Vratko. [1] https://github.com/FDio/vpp/blob/f49ba0e81e0cb9b9f8075cb4ce051b5bacde8ad3/src/vnet/interface.api#L206 From: vpp-dev@l

Re: [vpp-dev] VPP plugins development in Go

> cgo might just about work > it cost around 300 clock cycles to cross the c <---> golang boundary Aside of cgo [1], there is also gccgo [2]. But I imagine the performance would still be not good enough. Vratko. [1] https://golang.org/cmd/cgo/ [2] https://golang.org/doc/install/gccgo From: vpp-

Re: [vpp-dev] more per-patch vpp performance jobs

> and to let people know that simple "perftest" trigger > will stop working if the solution is merged as is. It has been merged, around 85 minutes ago. Vratko. From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) Sent: Monday, 2019-February-18 17:26 To: vpp-dev@lists.fd.io Cc: csit-

[vpp-dev] more per-patch vpp performance jobs

Current "perftest" job only runs on 2n-skx testbed. People were asking for a job running on other testbeds as well. So, I have prepared a solution. CSIT part: [1], ci-management part: [2]. It will take few hours for Sandbox runs to get a testbed and finish. The downside is that I have not figure

Re: [vpp-dev] graph node placement on workers

Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Thursday, 2019-January-03 18:13 To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: [vpp-dev] graph node placement on workers Hi developers. When examining some performance test results, I started seeing patterns, so I

[vpp-dev] graph node placement on workers

Hi developers. When examining some performance test results, I started seeing patterns, so I now have multiple questions. I have noticed that (with hyper-threading on) l2-input-vtr graph node is present only on half of VPP workers. (At least for the dot1q test below.) In CSIT, the node is always

[vpp-dev] naginator on verify

Hello. I have encountered a false Verified+1 (again) caused by a naginated retry effectively removing non-naginated failure. The mechanism is basically the same as the one described in this [0] older e-mail. Consensus then was that VIRL tests are unreliable, but false +1 is caused by inconsiste

Re: [vpp-dev] [csit-dev] anomaly detection changes

hile keeping the sensitivity high. (But I am not the one examining each possible regression.) Vratko. [2] https://lists.fd.io/g/csit-dev/message/3247 [3] https://docs.fd.io/csit/master/trending/new/index.html From: csit-...@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGI

Re: [vpp-dev] question related to VPP statistics

There is "stat segment" [0] way of publishing counters. But it was added somewhat recently, so ipsec code probably does not support it (yet). Vratko. [0] https://github.com/FDio/vpp/blob/master/src/vpp/stats/stats.md From: vpp-dev@lists.fd.io On Behalf Of Kevin Yan Sent: Friday, 2018-November-0

Re: [vpp-dev] [csit-dev] new per-patch job

o/r/16120 From: vpp-dev@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Monday, 2018-November-12 13:40 To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] [csit-dev] new per-patch job Hello VPP devs. Now that CSIT testbed

Re: [csit-dev] [vpp-dev] ARM vpp-dpdk-dkms nexus artifacts - CSIT

Just letting you know I am deleting this from (the bottom of) my TODO. Everything should have been solved by everyone using packagecloud now. Vratko. From: vpp-dev@lists.fd.io On Behalf Of Tina Tsou Sent: Thursday, 2018-April-19 19:16 To: Ed Kern (ejk) Cc: Peter Mikus -X (pmikus - PANTHEON TEC

Re: [vpp-dev] ip4-load-balance

> Any clues as to what might causing the delta? >> using FD.io VPP 18.07 If you are still using that, the performance might depend on the NUMA node used. There was a placement bug, and the fix [1] has been merged just before 18.10. Vratko. [1] https://gerrit.fd.io/r/15483 -Original Message-

Re: [vpp-dev] API changes to trigger email

> email = f...@project1.io > email = f...@project2.io I think it would be easier to sent only one e-mail to a fd.io mailing list created specifically for announcing VPP api changes. Similarly to how we created csit-report [0] for announcing perform

Re: [vpp-dev] [csit-dev] new per-patch job

[0] https://gerrit.fd.io/r/15826 [1] https://gerrit.fd.io/r/15347 From: csit-...@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Friday, 2018-September-07 17:20 To: vpp-dev@lists.fd.io Cc: csit-...@lists.fd.io Subject: Re: [csit-dev] new per-patch

Re: [vpp-dev] auto-abandon

> difficult to find I decided to test that, on a change that is actually abandoned (because 9336 is not, yet). This [0] simple search link finds two changes, one [1] of them is abandoned. Vratko. [0] https://gerrit.fd.io/r/#/q/%22igmp+proxy%22 [1] https://gerrit.fd.io/r/12561 From: vpp-dev@lis

Re: [vpp-dev] auto-abandon

> https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html Pros are worth it. Contributors can still Restore (and rebase) manually if needed, when they receive an e-mail about the auto-abandon hitting their Change. > Should we enable that? +1. Vratko. From: vpp-dev@lists.

Re: [vpp-dev] Master branch l2bd test perf dop

> Is that drop visible in CSIT trending graphs? Mostly not, apparently it depends (at least) on NIC (x520 is not affected) and on number of CPU cores for workers (visible for 4). The biggest drop I see is here [0]. Vratko. [0] https://docs.fd.io/csit/master/trending/trending/l2-3n-hsw-xl710-64

Re: [vpp-dev] anomaly detection changes

Quick update, we are stuck. > the test is now executing 10 trials of 1 second > so in theory nothing should change No big changes were visible, so we have kept this change. > to take standard deviations into account > to detect smaller regressions and progressions. But we are not going ahead

[vpp-dev] anomaly detection changes

Hello people watching the trending pages [0]. We have just merged a Change [1] which affects how MRR tests work. Instead of single trial of 10 second duration, the test is now executing 10 trials of 1 second. PAL is told to aggregate the results, so in theory nothing should change, but in practi

Re: [vpp-dev] new per-patch job

tko. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Friday, 2018-September-07 15:04 To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: vpp-dev@l

Re: [vpp-dev] new per-patch job

d on directories edited. The hard part is creating a mapping from directories to test tags. Vratko. From: vpp-dev@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Friday, 2018-September-07 15:04 To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.

[vpp-dev] new per-patch job

Hello VPP devs. There is a new way of testing performance impact of a VPP Change before merging it. When you add Gerrit comment "perftest" a job will start (different from the previously available one). It will compile both the code in the Change and in its parent, run few tests against both bui

Re: [vpp-dev] Suspicious login on fd.io wiki

> suggest a workaround? Navigate to https://wiki.fd.io/view/Main_Page before logging in. Vratko. -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Marco Varlese Sent: Wednesday, 2018-September-05 15:31 To: Vanessa Valderrama via RT Cc: vpp-dev@lists.fd.io; infra-steer...@lists.fd

Re: [vpp-dev] num-mbufs

> I cannot update wiki, it tells me that I'm trying to do suspicious login :) My workaround it to attempt the login from less deep wiki page, e.g. [1]. Vratko. [1] https://wiki.fd.io/view/Main_Page From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via Lists.Fd.Io Sent: Tuesday, 2018-August

Re: [vpp-dev] IRC SPAM

Following up on discussion from TCS meeting. It seems the registration part works, assuming you follow the e-mail instruction by issuing /msg NickServ VERIFY REGISTER But the actual login instructions are not helpful, especially the /connect command is not the way for the web client. > on th

Re: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

> then this issue was fixed It was not fixed, we have just listed VPP-1361 as a known issue [2] and performed more job runs to compensate for failures. Vratko. [2] https://docs.fd.io/csit/rls1807/report/vpp_performance_tests/csit_release_notes.html -Original Message- From: vpp-dev@lis

[vpp-dev] make wipe

At the root of local VPP git repository (current master), this is what "make help" has to say about the "wipe" target: wipe- wipe all products of debug build But currently (I think) "all" does not include dpdk/. I believe "make -C dpdk clean" should be inserted somewhere, but I am

Re: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

sage- From: vpp-dev@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Wednesday, 2018-August-01 18:13 To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) ; Ray Kinsella ; vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: Re:

Re: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

> VPP is not crashing so no core dump are available. I tried to use "gcore" command to create a core dump from running VPP. So far I got this [0] archive, compressed to around 25 MB, but the core file inside is around 160 GB big. Not sure how to make it smaller, even with small numbers in startup

Re: [vpp-dev] [csit-dev] The environment variable PATH is changed after "Setup Framework"

> I wonder why the PATH is changed in CSIT. I do not think CSIT is changing the PATH. I think you see diferent values, because you are logging in in an different way. See the technical summary [0] from bash documentation, or somewhat older and more colourful page [1]. [0] https://www.gnu.org/sof

Re: [vpp-dev] Revert of gerrit 13408 / "vppinfra: AVX2 blend" in progress..

> Not sure what exactly happened It went like this: 0. Patch set 2 is uploaded. 1. Both clang and virl jobs (among others) are triggered. 2. Both jobs fail (virl on the usual NFS mount symptom). 3. Virl job has naginator, so its result is reported as NOT_BUILT. 4. Clang is reported as FAILURE, so

Re: [WARNING : MESSAGE ENCRYPTED] [vpp-dev] [VPP]Questions about VPP behavior of over performance limit

> VPP rx/tx counter is 0 Last time I have seen this behavior, it was caused by insufficient value of mem-mbufs [1] parameter. The symptom is large amount of mbuf allocation errors in statistics. See this [0] thread for more context. Vratko. [0] https://lists.fd.io/g/csit-dev/topic/csit_ip4_tes

Re: [vpp-dev] new anomaly detection

> we are planning to replace the old graphs by new graphs > (and delete [1]) some time next week, > depending on the feedback we get. The feedback was non-negative, so we are going ahead. Expect the new content to appear on the old URL [0] around one hour from now. Vratko. From: Vratko Polak -X

Re: [vpp-dev] new anomaly detection

The standalone logic (not related to PAL internals) is now available on PyPI [2], meaning you can do "pip install jumpavg". Currently there is zero documentation on how to actually use the library (unless you are willing to read comments in the code itself). I will add something when I make PAL u

[vpp-dev] new anomaly detection

By now, you should be familiar with Continuous Performance Trending page [0] leading to various graphs and tables tracking performance changes of VPP code. We are planning to replace the old ways of how do Trendline Graphs look. There are still few things missing, but the basic functionality is t

<    1   2