Any more thoughts on this failure ?
Thanks
Manoj Iyer
From: vpp-dev@lists.fd.io on behalf of Manoj Iyer via
lists.fd.io
Sent: Tuesday, May 26, 2020 6:51 PM
To: Damjan Marion
Cc: bga...@cisco.com ; vpp-dev@lists.fd.io
; Rodney Schmidt ; Kshitij Sudan
Hi Govind,
1) According to Jenkins, this patch permits some of the packets that
should be denied, hence JJB voted "-1".
2) If you suspect merely the prefetches are the issue, just commenting
out the body of prefetch_session_entry() in the original code should
turn it into a no-op that doesn't
Congratulations!
Le 27/05/2020 23:28, « vpp-dev@lists.fd.io au nom de Andrew Yourtchenko »
a écrit :
Dear all,
I am happy to announce that the release 20.05 is available on
packagecloud.io in fdio/release repository.
I have verified that it is installable on Ubuntu 18.04 and
Brilliant, good job!
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Andrew Yourtchenko
Sent: Wednesday, May 27, 2020 17:28
To: vpp-dev
Subject: [EXTERNAL] [vpp-dev] VPP release 20.05 is complete!
Dear all,
I am happy to announce that the release 20.05 is available on
Dear all,
I am happy to announce that the release 20.05 is available on
packagecloud.io in fdio/release repository.
I have verified that it is installable on Ubuntu 18.04 and Centos 7
distributions.
Special thanks to Vanessa Valderrama and Dave Wallace for the help
during the release.
--a
Hi Andrew,
While profiling the ACL plugin node using perf tool in ARM Neoverse platform,
Bihash related prefetches were shown as bottleneck.
Performance improvement is seen in ARM N1, TX2 and Intel Skylake servers after
removing those prefetches. Testing is done with Ingress ACL/IPv4
Dear VPP committers,
please do not merge any new patches onto stable/2005 until my notice
it's okay to do so.
--a
/* Your friendly 20.05 release manager */
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16538):
Thanks Andreas !!
From: Andreas Schultz
Sent: Tuesday, May 26, 2020 4:14 PM
To: Govindarajan Mohandoss
Cc: vpp-dev@lists.fd.io; nd
Subject: Re: [vpp-dev] GTPu Question
Hi Govind,
I'm NOT one of the GTPu maintainers, but I do work on a UPF implementation
based on VPP.
The GTPu plugin is
Yep, so it looks like we have an issue...
https://gerrit.fd.io/r/c/vpp/+/27305 has the same failures, I am rerunning it
now to see how intermittent it is - as well as testing the latest master
locally
--a
> On 27 May 2020, at 18:56, Elias Rudberg wrote:
>
> Hi Andrew,
>
> Yes, it was
Hi Andrew,
Yes, it was Basic LISP test. It looked like this in the console.log.gz
for vpp-verify-master-ubuntu1804:
===
===
TEST RESULTS:
Scheduled tests: 1177
Executed tests: 1176
Passed tests: 1039
Basic LISP test - was it the one that was failing for you ?
That particular test intermittently failed a couple of times for me as well, on
a doc-only change, so we have an unrelated issue.
I am running it locally to see what is going on.
--a
> On 27 May 2020, at 18:25, Elias Rudberg wrote:
Hi all,
All worked just fine as I was on top of "stable/2001" branch, but today I
rebased my work on top of "stable/2005" and did a "make pkg-rpm" which breaks
right at the end at the "vpp-papi" build stage.
Specifically:
>
> ...
> running install_egg_info
> running egg_info
> creating
Hi Ole,
OK, now I have changed the patch to include a bounds check. This is
still using an intermediate u32 variable however, I tried making
collector_port a u32 but then one of the Gerrit tests failed, I wasn't
able to figure out why as I could not reproduce that problem on my end,
it happened
+1
Also, please be aware that the VPP cli is by design "The Debug CLI" and
is not intended for use as a production API.
VPP cli commands can be changed without warning and without any
guarantee of backwards compatibility.
Thanks,
-daw-
On 5/27/2020 8:53 AM, Chris Luke wrote:
That is quite
Hi,
I see the NAT plugin already supports TCP MSS clamping but it is implemented
only in in2out direction.
We have endpoints with wrong MTUs behind tunnels and not all the traffic is
NATed. Hence, it would be very nice to have generic support for MSS clamping
that could be enabled on the
That is quite odd indeed. This is the sort of issue that could take some time
to properly diagnose and I cannot dig in to it right away. For now, if you are
not using the output, perhaps as a workaround simply redirect stdout to
/dev/null?
That said, if this part of a larger application, I
Hi,
Kindly let us know if VPP supports MSTP or STP.
Do we have any plan for adding port status in structure vnet_hw_interface_t.
Do we have any data structure which is already available to set port status to
learn/forward/blocking etc..
Regards,
M. Kavitha-=-=-=-=-=-=-=-=-=-=-=-
Links: You
We reserve continuous address space…..
> On 27 May 2020, at 10:14, siddarth rai wrote:
>
> Hi Damjan,
>
> I have tried the latest master and it seems that the core size is around 1.3
> G , as you mentioned above.
> However, the VPP VSZ is still around 16G. This used to be low in earlier
>
[Edited Message Follows]
[Reason: added diagram of what i'm trying to acheive]
Hi,
I have successfully set ipfix export (to some extent) and I can see the
template set and records I have configured in the vpp is in fac being sent and
received by tap0. I'm using scapy, session NetflowSession
Attached is the sample VPP commands script, having a delay of 50 ms. Below is
the screenshot of he output we get on running the script : -
Request 88 : time 14:05:01.906
Request 89 : time 14:05:01.906
Request 90 : time 14:05:02.043
_____ _ ___
__/ __/ _ \ (_)__
Attached is the sample VPP commands script, having a delay of 50 ms. Below is
the screenshot of he output we get on running the script : -
Request 88 : time 14:05:01.906
Request 89 : time 14:05:01.906
Request 90 : time 14:05:02.043
___ _ _ _ ___
__/ __/ _ \ (_)__ | | /
Hi,
Attached is the sample VPP commands script, having a delay of 50 ms. Below is
the screenshot of he output we get on running the script : -
Request 88 : time 14:05:01.906
Request 89 : time 14:05:01.906
Request 90 : time 14:05:02.043
_____ _ ___
__/ __/ _ \ (_)__
Hi Damjan,
I have tried the latest master and it seems that the core size is around
1.3 G , as you mentioned above.
However, the VPP VSZ is still around 16G. This used to be low in earlier
released(around 2G)
Can you give any hint why the Virtual size has increased so much?
The pmap output is
Hi Elias,
Thanks for spotting that.
Just make collector_port a u32 and add a boundary check?
Best regards,
Ole
> On 27 May 2020, at 03:27, Elias Rudberg wrote:
>
> Hello VPP experts,
>
> When testing the current master branch for NAT with ipfix logging
> enabled we encountered a problem with
Hi Elias,
Thanks for fixing these.
You could just call vlib_get_main() instead of passing thread_index (for now).
Cheers,
Ole
> On 27 May 2020, at 03:49, Elias Rudberg wrote:
>
> Hello again,
>
> Here is another fix to avoid assertion failure due to vlib_time_now()
> being called with a vm
25 matches
Mail list logo
