[vpp-dev] dpdk plugin: RSS keys for ICE

Executive summary: Jira ticket VPP-2072 [4] describes how random RSS keys make some performance test results too random to be useful. This vpp-dev thread can be used for discussing ways how to make CSIT results deterministic. Longer version: As far as I can tell, dpdk plugin + ICE driver is the

Re: [vpp-dev] request-response between vlib processes

dev] request-response between vlib processes Hi Vratko, On Sep 13, 2022, at 5:03 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io<http://lists.fd.io> mailto:vrpolak=cisco@lists.fd.io>> wrote: In general, most of “communication” between VPP compone

Re: [vpp-dev] benchmark for a patch

> a specific patch which is not merged? It depends whether the unmerged patch is for VPP or CSIT (or you have two). 1. If VPP code is merged, various csit-verify-perf-* jobs can be triggered using csit-{node}-{arch}-perftest trigger word in CSIT Gerrit comment. Example: [0]. The VPP version used

Re: [vpp-dev] request-response between vlib processes

Regards, Florin On Sep 12, 2022, at 4:49 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io<http://lists.fd.io> mailto:vrpolak=cisco@lists.fd.io>> wrote: [resending to the correct vpp-dev e-mail address] Short version: Vratko would appr

[vpp-dev] request-response between vlib processes

[resending to the correct vpp-dev e-mail address] Short version: Vratko would appreciate something like vlib_current_process_wait_for_one_time_event_or_clock. Medium version: One instance of request-response interaction between vlib processes had a bug [11]. Vratko contributed a fix [9] for

[vpp-dev] Crash when creating AVF interface

VPP should not crash without a good reason, and possible issues with PAPI are not good enough a reason. So I opened a ticket [4] once I saw the backtrace. I will add more details there when I have any (e.g. what exactly is different from usual CSIT daily runs). Vratko. [4]

Re: [vpp-dev] Community meeting today

th validation only). To test the implementation we can use similar way as existing vpp/extras/strongswan/run.sh, but this time we focus on data path checking. All ideas welcome. Regards, Fan From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> On

Re: [vpp-dev] Configuring linux kernel bond interface in VPP

> VPP 22.06 documentation which is the equivalent Correctly not mentioning the DPDK configuration way, as it was removed due to https://gerrit.fd.io/r/c/vpp/+/19867 Vratko. From: vpp-dev@lists.fd.io On Behalf Of Dave Wallace Sent: Wednesday, 2022-June-22 18:21 To: vpp-dev@lists.fd.io Subject:

Re: [vpp-dev] wait CLI

calls. Additionally, marking cli_inband as thread safe somehow reduced the dataplane performance (after the wait). Vratko. From: vpp-dev@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io Sent: Monday, 2022-June-20 19:26 To: vpp-dev@lists.fd.io S

[vpp-dev] wait CLI

A CLI command "wait" was added in [0], and a related function vlib_process_suspend was there in the first open commit [1]. I guess both are intended to be used during initialization, forcing an exec script to slow down, e.g. for a DHCP response to arrive. But when I tried (in [2]) to teach

Re: [vpp-dev] Community meeting today

> a way to make VPP IPsec work better w/ StrongSwan As Damjan said, it would be a control plane adapter. I guess it is also a management plane adapter (translating higher level commands into VPP API commands). From existing management plane adapters, it reminds me of linux_nl. I read it listens

[vpp-dev] hw_if_index API

TL;DR: Is there an API way to get hw_if_index value? CLI "show hardware-interfaces" works for humans, but some parsing is needed for machines to extract the index value. For software interfaces, there is sw_interface_dump, but I do not see any API way to get hw_if_index. API users need that

[vpp-dev] Gerrit reviews

According to wiki [0], I am writing here to request Gerrit reviews on my recent contributions. 35697 [1] is the usual API endianness stuff. send_interface_tx_placement_details code contains a FIXME, but until that is done, my workaround is needed. 35838 [2] is also a common issue, a CLI command

[vpp-dev] memory layout effects on VPP performance?

When I was running tests for this [0] revert, I saw different performance consequences than expected (not reversal of the original [1] regression). After rebasing, I am seeing yet another set of unexpected performance differences. This has reminded me of Stabilizer [2] utility, I learned about

[vpp-dev] issues found in RC2 testing

Sorry for late notice, discoveries were coming faster than I was able to investigate. Not listing: - Regressions and failures with cause in CSIT code or drivers or firmware or hardware. - Regressions and failures identified but also already fixed on stable/2202. New in 22.02 (not present in

[vpp-dev] older issues still affecting CSIT

Hello, this is part two of what I had prepared for VPP monthly meeting. Older VPP Jira tickets: - https://jira.fd.io/browse/VPP-1972 (Regression in NAT44ed performance) There might be multiple additional regressions, either in performance or in memory usage, affecting NAT tests. Example

Re: [vpp-dev] vpp got stucked after bridge and loop interfaces is created and snat is configured #nat44

Sounds like the issue fixed in [0] (so after 21.06). Vratko. [0] https://gerrit.fd.io/r/c/vpp/+/33018 From: vpp-dev@lists.fd.io On Behalf Of g.good...@gmail.com Sent: Thursday, 2021-August-19 14:58 To: vpp-dev@lists.fd.io Subject: [vpp-dev] vpp got stucked after bridge and loop interfaces is

Re: [vpp-dev] sw_interface_dump currently cann't dump interface which sw_if_index == 0 #vapi

l - and giving the folks a few weeks (namely, until after RC1), to adapt. This way the spirit of why the process there in the first place will be fulfilled, without incurring the unnecessary effort for everyone. Does this make sense ? --a On 5/3/21, Vratko Polak -X (vrpolak - PANTHEON TECH

Re: [vpp-dev] sw_interface_dump currently cann't dump interface which sw_if_index == 0 #vapi

> Is there any plan for support selecting only index==0 ? Good news first. I added the TODO here [0], but since then CSIT stopped using the VAT command in [1], and other uses based on PAPI should be ready since [2]. The bad news is VPP now has more strict process [3] regarding changes to API.

[vpp-dev] VPP behavior stability document

Hello. I am working on a document, discussing improvements to the current API process that go beyond just API. It is currently a draft (of limited readability), but several people are giving me feedback already, so maybe some of you want to read and comment too. Here [0] is the Gerrit link.

Re: [vpp-dev] [csit-dev] Faster PAPI

tps://gerrit.fd.io/r/c/csit/+/26019/140#message-314d168d8951b539e588e644a875624f5ca3fb77 > [5] > https://github.com/FDio/csit/blob/b5073afc4a941ea33ce874e016fe86384ae7a60d/resources/templates/vat/vpp_route_add.vat > [6] > https://github.com/FDio/csit/blob/b5073afc4a941ea33ce874e016

Re: [vpp-dev] Faster PAPI

5ca3fb77 [5] https://github.com/FDio/csit/blob/b5073afc4a941ea33ce874e016fe86384ae7a60d/resources/templates/vat/vpp_route_add.vat [6] https://github.com/FDio/csit/blob/b5073afc4a941ea33ce874e016fe86384ae7a60d/resources/libraries/python/TestConfig.py#L121-L150 From: vpp-dev@lists.fd.io<mailto:vpp-dev@l

Re: [vpp-dev] Cisco VIC 1495 performance with DPDK and VPP 21.01

> For VPP release 20.01, I have found few [0] results [1] I meant VPP 21.01; links are pointing there, it is just a typo. Vratko. -Original Message- From: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) Sent: Tuesday, 2021-April-06 20:59 To: Manoj Kumar (manojku5) Cc:

Re: [vpp-dev] Cisco VIC 1495 performance with DPDK and VPP 21.01

In CSIT, we have one testbed type (3-node Haswell) with older cards (Cisco VIC 1385 and even Cisco VIC 1227), but we are running tests on those very rarely (those NICs are not very popular, and we prefer to run larger test selection on fewer NICs). For VPP release 20.01, I have found few [0]

Re: [vpp-dev] Bug in vl_socket_read_ready() function

> I see that this change is done as part of following commit. I only edited variable names and such. The previous code contained the same logic [1], and it seems to come from the initial code [2]. > we are deleting the socket_main.input_buffer No, we are deleting just some (perhaps all)

Re: [vpp-dev] Scapy license in VPP

ce-Software.ashx?la=en=895293E77B462CF85E4D3E80AF8DC83143D0C165 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<http://lists.fd.io> Sent: Friday, 2021-January-29 18:10 To: Paul Vinciguerra m

Re: [vpp-dev] Scapy license in VPP

m: vpp-dev@lists.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io Sent: Friday, 2021-January-29 18:10 To: Paul Vinciguerra Cc: t...@lists.fd.io; Kinsella, Ray ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Scapy license in VPP > Why do you say that

Re: [vpp-dev] Jenkins/Gerrit Failure Cause Notifications

> The rules are managed via [1]. Does that mean the rules are guaranteed to survive any sudden Jenkins upgrade (needed for security reasons)? I will feel safer if we had a copy of the database in ci-management. That way, if I contribute a new rule, you can manually apply it when merging the

Re: [vpp-dev] Faster PAPI

ies/python/TestConfig.py#L121-L150 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: Thursday, 2020-May-07 18:35 To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.i

Re: [vpp-dev] Jenkins/Gerrit Failure Cause Notifications

Nice. > new rules to the VPP Failure Cause Management database [0] How do we manage the rules? I think the database is different from usual plugin configuration, so "Jenkins configuration as code" plugin will not help directly [5]. But I think we can manage the exported database manually in

Re: [vpp-dev] Scapy license in VPP

tko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) Cc: t...@lists.fd.io; Kinsella, Ray ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Scapy license in VPP Why do you say that vpp_papi need to be dual licensed? On Thu, Jan 28, 2021 at 12:43 PM Vratko Polak -X (vrpolak - PANTHEON TECHNOLOG

[vpp-dev] Scapy license in VPP

First draft created [0] for the change that will switch licenses for Python files used together with Scapy. For some files, I was not sure whether they are used together with Scapy. One big detail is that vpp_papi needs to have dual license, as test framework integrates with it (and with scapy).

[vpp-dev] devicetest verify failures

When new CSIT oper branch got created today, VPP verify jobs started to failing, even though each test passed. That should be fixed [0] now [1]. We are working on verify job improvements on CSIT side to prevent similar issues in the future. Vratko. [0] https://gerrit.fd.io/r/c/csit/+/30329 [1]

Re: [vpp-dev] [csit-dev] event-logger debug CLI cleanup patch failing validation: [vpp gerrit 30124]

tch continues to fail validation. I’m going to try again (“recheck”) and see what happens. D. 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: Thursday, November 26

Re: [vpp-dev] [csit-dev] event-logger debug CLI cleanup patch failing validation: [vpp gerrit 30124]

Compatibility enhancement on CSIT side: [0]. > easy enough to support both “elog trace” and “event-logger trace” on the vpp > side. When [0] is merged (also to oper branch), the support on VPP side can be dropped. > add a binary API and use it in the csit robot framework +1 to that,

Re: [vpp-dev] Python API modules

> something has gone wrong here. Yeah, sorry for the confusion. I consult the maintainers file when double-checking who to add as reviewers. But when I think the maintainers file is outdated, I do not hesitate to add [0] or remove [1] anybody based on my (limited) perception. Usually I am too

Re: [vpp-dev] Increasing NAT worker handoff frame queue size NAT_FQ_NELTS to avoid congestion drops?

>> Would you consider changing to a larger value in the official VPP code? Maybe make it configurable? I mean, after 28980 is merged and you still find tweaking the value helpful. Vratko. -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Klement Sekera via lists.fd.io Sent:

Re: [vpp-dev] Issue faced while deleting segment list in sr policy

> the value we get in *sl_index_iterate at line 870 is 0 rather than the 4. The pointer sl_index_iterate points to what would be the next index in the list. > why this is happening? That is the normal thing for-loops [0] in C do, if break does not happen. See [1]. A fix could be something

Re: [csit-dev] [vpp-dev] Vectors/node and packet size

>> on all the logic hidden behind rte_eth_rx_burst call, > won’t rte_eth_rx_burst just end up using the pmd registered functions. Yes. But I personally do not have visibility to DPDK software, not to mention NIC firmware and hardware. From the fact that small-ish traffic does not lead to 1

Re: [vpp-dev] Vectors/node and packet size

> I was wondering if anyone had noticed some similar behavior. Not until you mentioned it, but the pattern is visible in CSIT results. See for example here [0] (the page is very long, and you have to scroll over multicore results to compare packet sizes). > dpdk-input In your result, calls

Re: [vpp-dev] ikev2 API & new API change process

I think there are two issues. One issue is with APIs that were not intended to be Production yet. For ikev2 that basically means the version has been set [5] above 0.x.y only by mistake. As downgrading versions is always risky, marking messages as "In-Progress" instead is better. The other issue

[vpp-dev] VPP-1876

Just a notification for people not monitoring VPP Jira. I have just opened https://jira.fd.io/browse/VPP-1876 "Worse performance with DPDK driver when MTU is set to 2022 or less" I may update the value to 2023 depending on result of a scheduled run. As explained in the Description, this is an old

[vpp-dev] Faster PAPI

Hello people interested in PAPI (VPP's Python API client library). In CSIT, our tests are using PAPI to interact with VPP. We are using socket transport (instead of shared memory transport), as VPP is running on machines separate from machines running the tests. We use SSH to forward the socket

Re: [vpp-dev] [csit-report] Regressions as of 2020-04-03 14:00:14 UTC #email

> 3n-hsw Around 2nd of April there happened a regression in eth-l2bdscale1mmaclrn test, visible here [0]. Trending needed multiple runs to identify it is there, and alerting is configured not to report "old" regressions (so it did not report this one). Anyway, the closer look shows previously

Re: [vpp-dev] [csit-report] Regressions as of 2020-04-18 14:00:15 UTC #email

> -rnd-mrr This is a consequence of [0], fixing an old bug in CSIT code. Previously, the traffic was not random enough. Vratko. [0] https://gerrit.fd.io/r/c/csit/+/26456 -Original Message- From: csit-rep...@lists.fd.io On Behalf Of nore...@jenkins.fd.io Sent: Saturday, 2020-April-18

Re: [vpp-dev] [csit-report] Progressions as of 2020-04-19 02:00:13 UTC #email

> 3n-hsw Progressions showing the fixes described in [4] do restore the previous performance. Vratko. [4] https://lists.fd.io/g/csit-report/message/2488 -Original Message- From: csit-rep...@lists.fd.io On Behalf Of nore...@jenkins.fd.io Sent: Sunday, 2020-April-19 06:07 To:

Re: [vpp-dev] [csit-report] Regressions as of 2020-04-15 02:00:17 UTC #email

> 3n-hsw This turned out to be a bug on CSIT side, breaking numa detection, affecting every NIC on numa 1. The bug was introduced in [0] and fixed in [1] and [2]. Vratko. [0] https://gerrit.fd.io/r/c/csit/+/25363 [1] https://gerrit.fd.io/r/c/csit/+/26569 [2]

[vpp-dev] faster processing slower rate

Hello VPP experts. I have encountered an unexpected pattern in performance results. So I wonder, is there a bug somewhere (VPP or CSIT), or is there a subtle reason why the performance pattern should be expected? Usually, the more processing VPP in a particular test has to do, the smaller

Re: [vpp-dev] [csit-report] Regressions as of 2020-04-03 14:00:14 UTC #email

> 100ge2p1cx556a-rdma No VPP code change. Up to now, RDMA tests were suffering from "duration stretching". That is a phenomenon where TRex takes longer to send the required number of packets, so device under tests experiences smaller offered load and MRR value is inflated. We have suppressed the

[vpp-dev] Regression in SRv6

Trending has detected a performance regression in our SRv6 tests. I summarized my current findings here [5]. Vratko [5] https://gerrit.fd.io/r/c/vpp/+/25647#message-7d415999_6a0ba69f -Original Message- From: csit-rep...@lists.fd.io On Behalf Of nore...@jenkins.fd.io Sent: Wednesday,

Re: [vpp-dev] Increase MTU from ethernet packets

> 65535 bytes with ETHERNET_MAX_PACKET_BYTES I take it as a query on how easy it is for VPP to support super jumbo frames [0]. > most networks use approximately 9000 In theory, VPP could allow higher values to be set on demand, while making sure the default MTU values remain small enough. Even

Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches?

.fd.io On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io Sent: Thursday, 2020-February-27 14:56 To: Andrew Yourtchenko Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? > Adding a new API into an exis

Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches?

> Adding a new API into an existing file will still change the CRC on the > plugin/module Looking into a .api.json file, I see "crc" only for messages, but the whole file also ends with a "vl_api_version" value. > if we are aiming for binary compatibility Crc values guard against

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

: Dave Barach (dbarach) ; Maciek Konstantynowicz (mkonstan) ; vpp-dev ; Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco) Subject: Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason... > On 26 Feb 2020, at 16:36, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at

Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches?

> as soon as the CRC of any existing messages does not change, a patch is okay > to include into 19.08 Does that mean we want an api-crc job also for 1908 stream? We currently have api-crc job only for master, because other branches were not expected to edit .api files. Vratko. From:

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

This [0] change got merged. It got wrong Verified+1 due to naginator retrying one job (and Gerrit forgetting about other ones). Basically the same as these [1] two [2] older failures. Not sure whether is better to revert the change or wait for CSIT to catch up. Vratko. [0]

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via Lists.Fd.Io Sent: Wednesday, February 26, 2020 4:10 PM To: Maciek Konstantynowicz (mkonstan) Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason... Thanks... Dave From: Maciek

Re: [vpp-dev] Arm verify job broken

> accidentally separated two scripts that had to stay together. My fault, I had no idea this kind of coupling existed. Adding comments [1] to prevent similar errors in future. Vratko. [1] https://gerrit.fd.io/r/c/ci-management/+/24348 From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps

Re: [vpp-dev] python api over tcp?

> This should be done as an intermediate agent. I have a hypothetical question. (I am not trying to be cheeky. I feel there may be a difference, I just do not see it.) Imagine a world where VPP supports (CLI via vppctl and) binary API only over shared memory. No support for binary API over Unix

Re: [vpp-dev] python api over tcp?

CSIT uses VPP API via socket (tunneled over SSH) for most interactions. We also read stats for just one (I think) purpose, reading runtime stats (/sys/node). The way we do that is historical and convoluted, for the result see INFO line at [1]. Looking at the result, the appropriate API way would

Re: [vpp-dev] merge jobs failing..

> No its not clear to me why it verified… Because the verification run happened before [2] was merged (in other words, 23913 should have been rebased after that). I think this kind of merge error still happens infrequently enough, and any "remove +1 from affected open changes" ideas would be

Re: [csit-dev] [vpp-dev] Spurious API CRC failures

> automating_vpp_api_flag_day.rst Reading that, I see various improvements I wanted to add, but never found time to do it. So, here [5] is a quick edit, with more details on the CSIT side of the process, and with links to existing changes as examples. Vratko. [5]

Re: [csit-dev] [vpp-dev] Spurious API CRC failures

> Unfortunately when I pushed the patch [2], it failed to pass the crc check Added explanations to gerrit: [3], [4]. Vratko. [3] https://gerrit.fd.io/r/c/csit/+/23926/1/resources/api/vpp/supported_crcs.yaml#34 [4]

Re: [vpp-dev] CSIT - performance tests failing on Taishan

>> the attached patch Converted to Gerrit: [1]. Vratko. [1] https://gerrit.fd.io/r/c/vpp/+/23849 -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Juraj Linkeš Sent: Thursday, December 5, 2019 11:11 AM To: Lijian Zhang (Arm Technology China) ; Peter Mikus -X (pmikus -

Re: [vpp-dev] vpp19.08 ipsec vpp_papi

> This situation does not happen when I use CLI like this I think the difference is that CLI is restricted, it can only accept printable characters on input. Therefore it assumes it gets "hexlified" value, and applies "unhexlify" on its input. Contrary to that, PAPI (hopefully) can handle

Re: [vpp-dev] Change to Gerrit

> implementing something like [0] +1, but... > skip the jobs and set verify label after the codestyle checks if no files > were changed ... how do you imagine this being implemented in ci-management? Currently, the other jobs are triggered by checkstyle_success Gerrit comment, but how would

Re: [vpp-dev] Requirements for DPDK pmd/feature testing in CSIT vpp-device-test jobs

> a +2 triggers a pre-commit gate where VOM and the dist builds and the > extended tests are run. > If everything passes, the change is merged, if not, the +2 is removed. +1 to that, but I highly doubt Gerrit supports such a workflow. Additional features we would like to have: + Manual trigger

Re: [vpp-dev] Multiple patch validation failures: yamllint AWOL

> Makefile by testing for JENKINS_URL? Inputs to the program make should be understandable by human. When I want to predict locally what would the checkstyle job vote, I prefer something like: make checkstyle-all rather than: JENKINS_URL=jenkins.fd.io make checkstyle Or did you mean a

Re: [vpp-dev] API and plugins

fig that experiences problems look like ? --a On 8 Nov 2019, at 14:47, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io mailto:vrpolak=cisco@lists.fd.io>> wrote:  Questions: If an API message handler is moved into a different plugin, does it constitute a

[vpp-dev] API and plugins

Questions: If an API message handler is moved into a different plugin, does it constitute a (backward incompatible) API change? If yes, should we use similar checks and processes as for CRC changes? Example (not merged yet): sw_interface_ip6nd_ra_config is being moved from vnet [0] to

[vpp-dev] surprising performance on denverton

Hello everyone. I am working on automating "git bisect" process for locating mainly performance regressions and progressions, (also usable for locating breakages and fixes). Of course, the process works correctly only if the performance results are stable enough. And we know from the per-patch

Re: [vpp-dev] VAT can support define a macro? #vapi

Macros are currently not supported in .api files. > define MAX_NUM (12) The "define" keyword defines API messages, not macros. The C preprocessor is one possibility to add support for macros, but not sure whether it would play well with .api syntax. You can try to add that (or a similar

Re: [vpp-dev] [csit-dev] API check failure

Fixed. Short report: https://lists.fd.io/g/vpp-api-dev/message/34 Longer discussion on how to prevent similar things from happening in future: #csit-dev channel on FD.io slack. We will update the flag day document when we conclude the discussion. Vratko. -Original Message- From: Dave

[vpp-dev] CRC job reliable again

Yesterday, we did a risky thing of merging two [0] VPP [1] changes affecting APIs. Without verifying CSIT really is ready for the end result. Fixed [2] only now. From the process point of view, we have some possible improvements planned, but until we are able to implement them, we will be

Re: [vpp-dev] VAT to PAPI issue with policer

VAT classify_add_del_session contains "skip_n 1", but PAPI classify_add_del_session does not contain "skip_n_vectors" argument, (so the default 0 is used). Not sure whether that is causing the different behavior, but there may be other differences. Vratko. From: csit-...@lists.fd.io On Behalf

[vpp-dev] Temporary CRC failures

[0] has been merged, [1] has been postponed. The VPP API CRC jobs should be reliable from now on again. Vratko. [0] https://gerrit.fd.io/r/c/vpp/+/21508 [1] https://gerrit.fd.io/r/c/vpp/+/21706 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online

Re: [vpp-dev] VPP API sometimes hangs on ip_route_details response #vppcapi #vpp_stability #vpp #binapi

Looks like VPP-1753 to me. I do not have much to add, heisenbugs are hard to figure out. Vratko. From: vpp-dev@lists.fd.io on behalf of sylvain.cadil...@jaguar-network.com Sent: Wednesday, September 4, 2019 01:36 To:

Re: [vpp-dev] how VAT work with Socket IP Address

>> See ssh -R / -L for example. > Is this way not feasible? It is feasible. In CSIT we use this (ssh -L) way, although it took me some time to tune the ssh command (so the tunnel is closed either on-demand or by timeout). Here [0] is a part of the code composing the command, in case you

[vpp-dev] API change on master

VPP API change [0] has been merged. For open VPP changes that means the next rechecks or uploads (without rebasing) will fail the CRC check job. Vratko. [0] https://gerrit.fd.io/r/c/vpp/+/18361 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online

Re: [tsc] [vpp-dev] Project Proposal for uDPI

> UDPI will be easily misunderstood as UDP+I. > uniDPI is ok? +1 to uniDPI. Vratko. From: 李幸福(Xingfu Li) Sent: Tuesday, August 13, 2019 12:45 To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco); Ni, Hongjun; Alexey; t...@lists.fd.io Cc:

Re: [tsc] [vpp-dev] Project Proposal for uDPI

>> uDPI > microDPI Universal Deep Packet Inspection is the new project here. Would it make sense to use UDPI as its abbreviation (e.g. capital U, to distinguish from "micro")? Vratko. From: t...@lists.fd.io on behalf of Ni, Hongjun Sent: Tuesday, August

Re: [vpp-dev] Reminder: 19.08 RC1 is TODAY starting 18:00 UTC

The job [1] is non-voting, so if needed the queued runs can be cancelled, which unblocks gerrit without affecting the overall vote. Several people (including me) have Jenkins rights to do that. It looks like the required executor stopped being available. I hear the appropriate people have been

Re: [vpp-dev] flag day to enable API flag day process

Yesterday I forgot to notify that the job [8] is fixed [9] now. It will be kept non-voting for a week or so to make sure no CRC surprises are about to get merged just before the voting is enabled again. Vratko. [8] https://jenkins.fd.io/job/vpp-csit-verify-api-crc-master/ [9]

Re: [vpp-dev] 19.08 RC1 Milestone (stable branch pull) is next Wed 7 Aug 2019!

> Commit first to the release throttle, then "git cherry-pick" into master Next release, next reminder why [1] I think the order should be reversed. Vratko. [1] https://lists.fd.io/g/vpp-dev/message/12786 -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Andrew Yourtchenko

Re: [vpp-dev] flag day to enable API flag day process

> job is created … but it quickly turned to non-voting, because a recent merge [4] changed CRCs. It has been reverted [5] since then, but verifying everything is fixed [6] on CSIT side is delayed [7]. Vratko. [4] https://gerrit.fd.io/r/c/vpp/+/20946 [5] https://gerrit.fd.io/r/c/vpp/+/20997 [6]

[vpp-dev] troubles with centos7 packages

Continuing from #vpp-dev slack channel: How can I figure out the correct package names for centos? The previous way does not work for recent builds. > 13:01:27 No package vpp-19.08-rc0~794_g7520e17~b7546 available.

Re: [vpp-dev] flag day to enable API flag day process

[1] is now merged, job is created, and I see [3] it passing. Vratko. [3] https://jenkins.fd.io/job/vpp-csit-verify-api-crc-master/2/console From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) Sent: Wednesday, July 31, 2019 10:41 AM To: 'vpp-api-...@lists.fd.io' ;

Re: [vpp-dev] FD.io - Gerrit 2.16 Changes

Hi Klement. Using %private avoids triggering verify jobs, and you can use UI to set the desired state after that. Based on my testing [0], "Unmark private" action triggers verify jobs if and only if "fd.io JJB" is in reviewers list (same as with "recheck" comment). From what I can see, Jenkins

Re: [vpp-dev] flag day to enable API flag day process

[0] is merged, but [1] is stuck due to [2]. Vratko. [2] https://lists.fd.io/g/vpp-dev/message/13627 From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) Sent: Monday, July 22, 2019 7:14 PM To: vpp-api-...@lists.fd.io; vpp-dev@lists.fd.io; csit-dev Cc: Dave Wallace

Re: [vpp-dev] [discuss] FD.io Maintenance: 2019-07-30 @ 1700 UTC (10:00am PDT) - 2100 UTC (2:00pm PDT)

> If you experience any issues please open a ticket at > support.linuxfoundation.org. Executors for ci-management jjb jobs are not available, opened [3]. [3] https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-17012 From: disc...@lists.fd.io On Behalf Of Vanessa Valderrama Sent:

[vpp-dev] flag day to enable API flag day process

The main API flag document: [0]. I have most of implementation ready, see [1] and comments there. The missing parts is e-mail alerting and postponing main vpp verify jobs until API check passes (older stable/ VPP branches are tricky to support in that way). Please review, I would like to merge

[vpp-dev] Ubuntu1604 merge job is broken

Paul has already commented [0] on this, hopefully my subject draws more attention. Basically, packagecould does not like the look of ubuntu1604 VOM package, leading not only to missing VOM package, but also other packages unlucky enough to come after VOM in upload order. This includes packages

Re: [vpp-dev] VPP api python scripts in packages for out-of-tree VPP plugins.

Adding vpp-dev, as I am not sure who reads vpp-api-dev. Here [0] is my attempt at a simple solution. Vratko. [0] https://gerrit.fd.io/r/20595 From: vpp-api-...@lists.fd.io On Behalf Of Luca Muscariello via Lists.Fd.Io Sent: Tuesday, 2019-July-09 15:56 To: vpp-api-...@lists.fd.io;

[vpp-dev] new make target

I have opened a Jira task [0] for a new improvement request. Its description also hints at current plans for implementation API CRC job, documented in [1]. Vratko. [0] https://jira.fd.io/browse/VPP-1715 [1] https://gerrit.fd.io/r/18356 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages

[vpp-dev] FW: [tsc] RESPONSE NEEDED: LFN Staff Survey of the Community

I associate communities with mailing lists, so forwarding (from TSC list) to the two lists I engage with the most. Vratko. From: t...@lists.fd.io On Behalf Of Brandon Wick Sent: Wednesday, 2019-June-26 04:37 Subject: [tsc] RESPONSE NEEDED: LFN Staff Survey of the Community LFN Community, In

Re: [vpp-dev] what is alternative for l2fib_add_fwd_entry in vpp stable/1810?

Seems to be removed here [0], l2fib_add_entry being the replacement. And of course, use stable/1904 or later. Vratko. [0] https://gerrit.fd.io/r/c/14699/4/src/vnet/l2/l2_fib.h From: vpp-dev@lists.fd.io On Behalf Of Mostafa Salari Sent: Sunday, 2019-June-16 10:00 To: vpp-dev@lists.fd.io

Re: [vpp-dev] Plugin Versions

dev] Plugin Versions On 27 May 2019, at 13:54, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io mailto:vrpolak=cisco@lists.fd.io>> wrote: SemVer says: > Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards > compatible bug fi

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

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:

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

  1   2   >