Re: [vpp-dev] project call

"Damjan Marion via lists.fd.io" writes: Today on the project call, we were discussing about doing some changes on those calls. Proposal from few of us who were attending is: - we should make it less formal, stop doing readouts and focus on specific topics to discuss, if there is no topics

#notuseful [Re: [vpp-dev] #vppcom, #vnet #vpp]

People who have to sort through lots of email (like myself) do not open every email before marking it read or deleting it. Email with subject lines that give no clue to the content are instant deletes for me (and many others I'm sure) -- except in this case I decided to respond b/c for some

Re: [vpp-dev] vpp in a non-previleged mode

directly then you need to run privileged. You can get away with not running privileged when using virtual devices, but not actual physical HW. Thanks, Chris. Thanks, Regards, Venu On Fri, 18 Jun 2021 at 13:49, Christian Hopps wrote: Venumadhav Josyula writes: > Hi Dam

Re: [vpp-dev] vpp in a non-previleged mode

06:47, Venumadhav Josyula < vjosy...@gmail.com> wrote: Hi Christian, Can you please share the exact steps please ? Thanks, Regards, Venu On Thu, 17 Jun 2021 at 21:25, Chr

Re: [vpp-dev] vpp in a non-previleged mode

"Venumadhav Josyula" writes: Hi All, Can you run vpp + dpdk in non-privileged mode ? This vpp running inside pod as a cnf I did this at one point, IIRC I had to disable something small bit of code in the dpdk_early_init that required root, but as this code was only required to do

Re: [vpp-dev] trex and vpp ipv6?

match the actual traffic your generating from trex. Thanks, Chris. > clear run > > thanks, > > Hemant > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io>> On Behalf Of Christian Hopps > Sent: Sunday, February 28, 2021 7:52 P

Re: [vpp-dev] trex and vpp ipv6?

I've got this to work. Try using MAC addresses instead of IP in your trex_cfg.yaml - port_limit: 2 version : 2 low_end : false interfaces: ["3b:00.0", "3b:00.1"] port_info : - src_mac : b8:59:9f:xx:xx:xx dest_mac :

Re: [vpp-dev] VPP crash while allocation buffer in Azure with MLX5

No I don't think it was a build issue. I think it doesn't work. :) I don't have the cycles currently to circle back and check again, perhaps in the future. Thanks, Chris. > On Jan 5, 2021, at 3:11 AM, Benoit Ganne (bganne) via lists.fd.io > wrote: > >> Isn't dpdk/connectx-5 broken in 20.09?

Re: [vpp-dev] VPP crash while allocation buffer in Azure with MLX5

Isn't dpdk/connectx-5 broken in 20.09? Thanks, Chris. > On Jan 4, 2021, at 9:02 AM, Benoit Ganne (bganne) via lists.fd.io > wrote: > > Hi, > > VPP 19.08 is no longer supported. Can you try with VPP 20.09 instead? > > Best > ben > >> -Original Message- >> From: vpp-dev@lists.fd.io

Re: [vpp-dev] Problem with native avf

> On Dec 7, 2020, at 5:16 PM, Damjan Marion wrote: > >> On 07.12.2020., at 22:55, Christian Hopps wrote: > > I just bumped it to 2.13.10 and added REMAKE_INITRD=“yes” into debian/dkms.in > so that should be fixed: > > $ lsinitramfs /boot/initrd.img | grep i40e

Re: [vpp-dev] Problem with native avf

> On Dec 7, 2020, at 3:02 PM, Damjan Marion wrote: > > > >> On 07.12.2020., at 20:41, Christian Hopps > <mailto:cho...@chopps.org>> wrote: >> >> >> >>> On Dec 7, 2020, at 1:44 PM, Damjan Marion >> <mailto:damjan.mar...@gmai

Re: [vpp-dev] Problem with native avf

> On Dec 7, 2020, at 1:44 PM, Damjan Marion wrote: > >> >> On 07.12.2020., at 17:02, Christian Hopps wrote: >> > > please send me output of: extras/scripts/lsnet script and exact “create > interface avf” commands you use…. PCI Address MAC address

Re: [vpp-dev] Problem with native avf

ou tried latest PF driver from intel? No; however, I am running such a new ubuntu (5.8 kernel) so I was hoping that was sufficient. Thanks, Chris. > > — > Damjan > >> On 07.12.2020., at 15:42, Christian Hopps wrote: >> >> I'm hitting a problem with the native A

[vpp-dev] Problem with native avf

I'm hitting a problem with the native AVF driver. The issue does not seem to exist when using the DPDK driver. This is on stable/2009, with the DPDK bump to 2008 reverted (b/c 2008 doesn't work with mellanox anymore apparently). I have an x710 card configured with a 4x10G breakout cable. The

Re: [vpp-dev] vpp crashing on latest master branch with mlx5 enabled

We actually had to revert the DPDK 20.08 use to continue to have this work in 20.09. Isn't it a bit unexpected to have a DPDK supported NIC not work though? I'd think we'd want this fixed, is there any idea why it's broken? Thanks, Chris. > On Nov 20, 2020, at 2:47 PM, Mohammed Hawari wrote:

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

I’ve seen > when testing the patch. > > Thanks, > Klement > > ps. in case you missed the link: https://gerrit.fd.io/r/c/vpp/+/28980 > >> On 13 Nov 2020, at 22:47, Christian Hopps wrote: >> >> FWIW, I too have hit this issue. Basically VPP is designed to pr

Re: [vpp-dev] Frequently updated gauge (scalar)?

e periodic gauge callback is purely there for sources that > don't provide the counters themselves. > E.g. used for polling mempry heaps, free buffers and so on. > > You can just use a normal counter (counter.c) for your high frequency gauge. > > Cheers, > Ole > >> On

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

FWIW, I too have hit this issue. Basically VPP is designed to process a packet from rx to tx in the same thread. When downstream nodes run slower, the upstream rx node doesn't run, so the vector size in each frame naturally increases, and then the downstream nodes can benefit from "V" (i.e.,

[vpp-dev] Frequently updated gauge (scalar)?

I have need to track a frequently updated value (pps rate during congestion control), but I need this to be close to very frequently updated (basically whenever I change the value which is based on RTT). It seems the current gauge code you supply a callback which updates the counter (at a

Re: [vpp-dev] Latest master, dpdk and mlx5 failing

>> >> If I try to submit it upstream, I would probably do something nicer using a >> DPDK_ environment variable, but for the moment this got me past >> that error. I have not actually tested with an mlx5 device yet, so I don't >> know if something additional wil

Re: [vpp-dev] Latest master, dpdk and mlx5 failing

> > > — > Damjan > >> On 02.10.2020., at 19:01, Christian Hopps > <mailto:cho...@chopps.org>> wrote: >> >> FWIW, I got this building and running; however, since the bump to 20.08 >> VPP+DPDK no longer finds the mlx5 interfaces. >> >

Re: [vpp-dev] Latest master, dpdk and mlx5 failing

not actually tested with an mlx5 device yet, so I don't >> know if something additional will be required in order to forward packets >> via an mlx5 NIC, but it did fix the error you pasted and allow >> dpdk_plugin.so to be loaded. >> >> -Matt >>

[vpp-dev] Latest master, dpdk and mlx5 failing

I've rebased my local branch on the latest master and dpdk is failing to load now b/c 2020/10/01 18:31:54:514 errplugin/load /home/chopps/w/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins/dpdk_plugin.so: undefined symbol: ibv_fork_init I noticed that the dpdk build system has

[vpp-dev] dpdk 20.08

With the bump to dpdk 20.08, vpp (through DPDK) is not finding any interfaces on my systems with connectx-5 and connectx-6 NICs. Is this working for anyone else and the mellanox cards? Thanks, Chris. signature.asc Description: Message signed with OpenPGP -=-=-=-=-=-=-=-=-=-=-=- Links: You

[vpp-dev] Why drop NULL crypto alg tunnel packets?

Hi, Regarding: https://gerrit.fd.io/r/c/vpp/+/20593 I don't understand why the fix for writing the trailer in the wrong place for NULL crypto alg was to create a drop node for NULL crypto (and drop the packets) vs fixing the trailer writing bug. Was this a stop-gap fix? I certainly use a

[vpp-dev] dpdk crypto dev and socket id / numa problem

Hi, So there's a problem in the dpdk crypto code I think. In dpdk's ipsec.c in crypto_scan_devs() each crypto device is assigned a numa domain number dev->numa = rte_cryptodev_socket_id (i); Which I figured out meant I need to allocate a vdev cryptodev per numa (for numa domains I will

Re: [vpp-dev] Question on performance tests..

gt; > Best > ben > >> -Original Message- >> From: vpp-dev@lists.fd.io On Behalf Of Christian >> Hopps >> Sent: lundi 17 août 2020 15:00 >> To: vpp-dev >> Cc: Christian Hopps >> Subject: [vpp-dev] Question on performance tests.. >> >>

[vpp-dev] Question on performance tests..

[sent to csit-dev but perhaps since I'm not subscribed it didn't post] I'm looking at this performance graph: https://docs.fd.io/csit/master/trending/trending/ip4-2n-clx-cx556a.html Is this a uni-directional or a bi-directional test? There is a huge performance gain between June and July it

Re: [vpp-dev] address sanitizer and unit tests not working

> On Aug 12, 2020, at 10:12 AM, Benoit Ganne (bganne) wrote: > > Hi Christian, > > Thanks for the head's up. > >> I think maybe the right thing to do here is create a custom cmake build >> rule to stage the entire python package in build-root/build* > > Alternatively, do you know if we can

Re: [vpp-dev] address sanitizer and unit tests not working

FWIW I looked at this briefly but started rat-holing trying to better integrate the python packaging (which I am somewhat familiar with) with cmake (which I know almost nothing about). I think maybe the right thing to do here is create a custom cmake build rule to stage the entire python

Re: [vpp-dev] address sanitizer and unit tests not working

gt;> >> Best >> ben >> >> >> >> -Original Message- >> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> >> <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>> > d...@

Re: [vpp-dev] address sanitizer and unit tests not working

ple of crashes still, here are some fixes you might want to > apply first: > - https://gerrit.fd.io/r/c/vpp/+/27962 > - https://gerrit.fd.io/r/c/vpp/+/27963 > - https://gerrit.fd.io/r/c/vpp/+/27959 > > Best > ben > >> -----Original Message- >> From:

[vpp-dev] address sanitizer and unit tests not working

Hi, I'm trying to run the unit test with address sanitizer enabled but it's failing to run on the latest master for me. This is building on ubuntu 18.04 with clang-9 installed, the build used the same sanitizer make option too. Any suggestions? Thanks, Chris. [18:51:50 dak:/var/build/vpp]$

Re: [vpp-dev] debugging corrupted frame arguments

er to increase the per call packet count to see if the corruption moves away from the 4th element. Thanks, Chris. > > D. > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps > Sent: Thursday, July 23, 2020 1:10 PM > To: vpp-dev > Cc: C

[vpp-dev] debugging corrupted frame arguments

I have a very intermittent memory corruption occurring in the buffer indices passed in a nodes frame (encryption node). Basically one of the indices is clearly not a vadlid buffer index, and this is leading to a SIGSEGV when the code attempts to use the buffer. I see that vlib_frame_ts are

Re: [vpp-dev] AMD Epyc and vpp.

Thanks,ChbrisOn Jul 22, 2020, at 11:32 AM, Benoit Ganne (bganne) via lists.fd.io wrote:I tried setting that but didn't notice an issue, perhaps it's not an IObottleneck.Could you share the output of: - clear run/show run (it is important to clear 1st to capture

Re: [vpp-dev] AMD Epyc and vpp.

later (avx2 is supported by epyc but not avx512). I tried creating a znver2 variant but I think I'm missing something for that to actually work. Thanks, Chris. > > Best > Ben > >> -Original Message- >> From: vpp-dev@lists.fd.io On Behalf Of Christian >> Hop

[vpp-dev] AMD Epyc and vpp.

Hi vpp-dev, Has anyone done performance analysis with the new AMD epyc processors and VPP? Just naively running my normal build shows a 3GHz Epyc machine under-performing a 2.1GHz intel xeon. Thanks, Chris. signature.asc Description: Message signed with OpenPGP -=-=-=-=-=-=-=-=-=-=-=- Links:

Re: [vpp-dev] Why not break the check flow when the first error occurs of ip4_inout()?

Shouldn't the version check come first and the code avoid further checks if it fails? Probably unlikely to fail though given execution has reached "ip4_input" :) Thanks, Chris. > On Jul 21, 2020, at 7:12 AM, Dave Barach via lists.fd.io > wrote: > > Branches hurt performance more than

[vpp-dev] Regarding new ipsec interface patch

Hi vpp-dev, In the interest of expressing the community support that Neale asked for https://gerrit.fd.io/r/c/vpp/+/27795 Looks good to me. It may need some minor additional development to polish some rough edges, but I have been able to use it with a few IPTFS specific modifications to

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

> On Jul 14, 2020, at 1:20 PM, St Leger, Jim wrote: > > I believe the DPDK community converged on: > master/slave lcore -> initial/worker lcore VPP is ok here I think with "main" and "worker". > blacklist/whitelist -> blocklist/allowlist That one feels a bit clunky to me. I wonder why they

Re: [vpp-dev] ipsec interface revisted.

lbacks named "tfs" I added to ipsec to hook in. In this particular case though it's hard-coded for now. Thanks, Chris. > On Jul 6, 2020, at 4:57 AM, Neale Ranns via lists.fd.io > wrote: > > > > From: Christian Hopps > Date: Friday 26 June 2020 at 12:13 > To:

Re: [vpp-dev] name filter fix in 1908

2020, at 15:52, Ole Troan wrote: >> >> Hi Christian, >> >> Changing the patch is fine. >> The only use of version apart from human indications is for the is api >> experimental or not by checkstyle-api >> Cheers >> Ole >> >>> On 30 Jun 20

[vpp-dev] Strongswan VPP integration.

Hi folks, I adapted some github public changes made a couple years back for VPP 18.04 to finish them off and bring them to 19.08 (20.01, 20.05). However, in order to contribute these back to Strongswan they would like an MIT license. There was no license on the new files in github, however,

Re: [vpp-dev] name filter fix in 1908

oping in Ole for an opinion... > > Thanks... Dave > > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps > Sent: Tuesday, June 30, 2020 3:10 AM > To: vpp-dev > Cc: Christian Hopps > Subject: [vpp-dev] name filter fix in 1908 > > C

[vpp-dev] name filter fix in 1908

Could this fix: https://gerrit.fd.io/r/c/vpp/+/23140 be pulled into stable/1908? It applies clean after adapting the version number change to be compatible with 1908 branch. Thanks, Chris. signature.asc Description: Message signed with OpenPGP -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all

Re: [vpp-dev] ipsec interface revisted.

> On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns) wrote: > > Hi Chris, > > As far as I'm concerned, it's your plugin, you can add whatever functionality > you need. If you separate the new interface type out into another plugin, so > it can be used without your feature, then the

Re: [vpp-dev] ipsec interface revisted.

hris. > On Jun 23, 2020, at 8:51 AM, Neale Ranns (nranns) wrote: > > > Hi Chris, > > On 22/06/2020 13:09, "Christian Hopps" wrote: > >> >> - It operates directly with the IPsec tunnel mode and transport mode SAs >> without needing to mang

Re: [vpp-dev] ipsec interface revisted.

> On Jun 22, 2020, at 4:11 AM, Neale Ranns via lists.fd.io > wrote: > > > > From: on behalf of Christian Hopps > Date: Thursday 18 June 2020 at 18:20 > To: vpp-dev > Cc: Christian Hopps > Subject: [vpp-dev] ipsec interface revisted. > > Hi, > >

[vpp-dev] ipsec interface revisted.

Hi, So to revisit this topic from a different angle. I believe VPP needs something like the xfrm linux interface [1]. If I understand things correctly this actually provides what was useful (but more-so) with old ipsec interface functionality that has been lost. It is also a much cleaner/more

Re: [vpp-dev] IPsec tunnel interfaces?

> On May 11, 2020, at 11:03 AM, Christian Hopps wrote: > >> On May 11, 2020, at 9:56 AM, Neale Ranns (nranns) wrote: >> >> On 11/05/2020 14:28, "Christian Hopps" wrote: > >> >> Is it *really* that big a deal to have a logical interface

Re: [vpp-dev] Interesting backtrace in 1908

weekend a lot happier. >> >> I'll look into why the relevant patch didn't make it back into 19.08 - it >> will now! - unfortunately "stuff happens..." >> >> Thanks for confirming... Dave >> >> -Original Message----- >> Fro

Re: [vpp-dev] Interesting backtrace in 1908

_NODE_TYPE_PROCESS, >.name = "startup-config-process", >.process_log2_n_stack_bytes = 18, > }; > /* *INDENT-ON* */ > > It's entirely possible that compiling -O0 blows the stack, especially if you > end up 75 miles deep in fib code. > > Dave > >

Re: [vpp-dev] Interesting backtrace in 1908

0 * 16, (const u8 *) src + 0 * 16); (gdb) p dst $27 = (u8 *) 0x7fffb90bea90 "" (gdb) p src $28 = (const u8 *) 0x7fffafa01fd0 "iptfs-refill-zpool sa_index %d before %d requested %d head %d tail %d" (gdb) down #0 0x000075cbe8b1 in clib_mov16 (dst=0x6d986a57 , src=0x

[vpp-dev] Interesting backtrace in 1908

I'm wondering if maybe this SIGSEGV/backtrace might be related to the other recently reported problem with the FIB and barrier code? The workers are at the barrier when the SIGSEGV happens, but maybe they aren't when they need to be earlier on? In this case I've compiled w/o CLIB_DEBUG set,

Re: [vpp-dev] ixge and rdma drivers

f, link-state auto, > trust on > > And the in in VPP: > > vpp# create interface avf :61:06.0 name eth0 > > > >> On 2 Jun 2020, at 09:40, Christian Hopps wrote: >> >> Hi vpp-dev, >> >> I've been contemplating trying to use native drivers

Re: [vpp-dev] ixge and rdma drivers

:61:00.1 1 > > Virtual Functions: > ID PCI Addr PCI IDDriver MAC Addr Config > 0 :61:06.0 8086:37cd vfio-pci spoof checking off, link-state auto, > trust on > > And the in in VPP: > > vpp# create interface avf :61:06.0 na

[vpp-dev] ixge and rdma drivers

Hi vpp-dev, I've been contemplating trying to use native drivers in place of DPDK with the understanding that I may be paying a ~20% penalty by using DPDK. So I went to try things out, but had some trouble. The systems in paticular I'm interested in have 10GE intel NICs in them which I believe

Re: [vpp-dev] unix-epoll-input in workers

all asleep when there > is no interfaces in polling mode. Interface queues can be dynamically > assigned to different workers so there will be lot of messing around to make > this working. > >> On 20 May 2020, at 21:51, Christian Hopps wrote: >> >> Would this work? >> &g

Re: [vpp-dev] unix-epoll-input in workers

Would this work? https://gerrit.fd.io/r/c/vpp/+/27186 Thanks, Chris. > On May 20, 2020, at 1:44 PM, Christian Hopps wrote: > > > >> On May 20, 2020, at 11:39 AM, Damjan Marion via lists.fd.io >> wrote: >> >> >> >>> On 20 May 2020, at 1

Re: [vpp-dev] unix-epoll-input in workers

> On May 20, 2020, at 11:39 AM, Damjan Marion via lists.fd.io > wrote: > > > >> On 20 May 2020, at 16:29, Christian Hopps wrote: >> >> >>> On May 20, 2020, at 9:42 AM, Damjan Marion via lists.fd.io >>> wrote: >>> >

Re: [vpp-dev] unix-epoll-input in workers

> On May 20, 2020, at 9:42 AM, Damjan Marion via lists.fd.io > wrote: > > > >> On 20 May 2020, at 14:38, Christian Hopps wrote: >> >> I'm wondering why I have unix-epoll-input in my worker threads "show >> runtime" results. Co

[vpp-dev] unix-epoll-input in workers

I'm wondering why I have unix-epoll-input in my worker threads "show runtime" results. Couldn't it selectively disable/enable itself based on whether it actually had any work to do (things to poll)? I'm aware it modifies its behavior when there are other polling nodes running, but it still is

Re: (Q about fixing endianness bugs in handlers) Re: [vpp-dev] Proposal for VPP binary API stability

I would be more than willing to sign up for this. Thanks, Chris. > > --a > > >> >> FWIW... Dave >> >> From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion >> via lists.fd.io >> Sent: Saturday, May 16, 2020 7:23 AM >> To: Andrew Yourtchenko &g

Re: (Q about fixing endianness bugs in handlers) Re: [vpp-dev] Proposal for VPP binary API stability

the actual API users to chime in. Please tell me which is >>> the least worst option from your point of view :-) >>> >>> 2) What is the best course of action in the future. Note, this is also >>> the simpler case in that there is a way to trigger a CRC-affecting >&g

Re: (Q about fixing endianness bugs in handlers) Re: [vpp-dev] Proposal for VPP binary API stability

able to get away with (1) or (3) from > above ? > > And a tweak to the process (and potentially tooling) with regards to > going to "production API status": > > An API that is not touched during a "make test" can not be moved > beyond the "in-progress" s

Re: [vpp-dev] Performance on the Macchiatobin

We've also seen good numbers from these boxes; however, we have had issues with connecting them back-to-back (they don't work that way the interfaces flap), they seem to work when connected through a *non-marvel* based switch. IOW there's something weird going on with the marvel chip talking to

Re: [vpp-dev] blinkenlights .. vpptop?

-infra, etc..) appear to be insurmountable in a reasonable amount of time (a few hours) Too bad, looked interesting. I'm going to try and back out my API changes and see if that works as a stop-gap, but otherwise will have to punt. Thanks, Chris. > On May 14, 2020, at 7:24 AM, Christian Ho

Re: [vpp-dev] Proposal for VPP binary API stability

API stability is borderline critical for a project like VPP I think. Yes, it can be used stand-alone, but real value is added by building products on top of it. Also important is having an API framework that allows for backward-compatible changes to the API for making improvements. I'm not

Re: [vpp-dev] blinkenlights .. vpptop?

some info on generating a vpp go api, but how to do that with the downloaded go module dependencies (or how to update those to include my development version) is not obvious. Thanks, Chris. > On May 14, 2020, at 5:27 AM, Christian Hopps wrote: > > Yes, looking at that now. Should hav

Re: [vpp-dev] blinkenlights .. vpptop?

Yes, looking at that now. Should have googled first :) I think the only thing missing here is the usage bar to present "idleness" per-worker/core. But this is a great start. Thanks, Chris. > On May 14, 2020, at 5:25 AM, Benoit Ganne (bganne) via lists.fd.io > wrote: > > Hi Chris, > >> Has

[vpp-dev] blinkenlights .. vpptop?

Has anyone contemplated the possibility of a "vpptop" like utility for VPP? The thought crossed my mind while I was using htop to help debug some performance problems I've been having that aren't directly related to vpp processing. I'm thinking that vpptop could present a dashboard like top

Re: [vpp-dev] IPsec tunnel interfaces?

> On May 11, 2020, at 9:56 AM, Neale Ranns (nranns) wrote: > > > > On 11/05/2020 14:28, "Christian Hopps" wrote: > > > >> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns) wrote: >> >> >> >> From: on behalf of Chr

Re: [vpp-dev] IPsec tunnel interfaces?

> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns) wrote: > > > > From: on behalf of Christian Hopps > Date: Sunday 10 May 2020 at 14:33 > To: "Neale Ranns (nranns)" > Cc: Christian Hopps , vpp-dev > Subject: Re: [vpp-dev] IPsec tunnel interfaces? &g

Re: [vpp-dev] IPsec tunnel interfaces?

standards work and probably put various limitations etc on the types of user IP that can be input (so that we can cache and replicate that information at will) -- but that does not represent an equivalence. Thanks, Chris. > On May 10, 2020, at 8:33 AM, Christian Hopps wrote: > >> On

Re: [vpp-dev] IPsec tunnel interfaces?

d to make similar changes to both the ipsec and > > > ipsec_gre create APIs. The other motivation was removing 2 interface > > > types that did exactly the same as the existing ipip and gre tunnels (and > > > the same goes for their APIs too, like how do I configure what

Re: [vpp-dev] IPsec tunnel interfaces?

On May 8, 2020, at 3:57 AM, Neale Ranns via lists.fd.io wrote: > > > > From: on behalf of Christian Hopps > Date: Thursday 7 May 2020 at 23:27 > To: "Neale Ranns (nranns)" > Cc: Christian Hopps , vpp-dev > Subject: Re: [vpp-dev] IPsec tunnel interfaces? &

Re: [vpp-dev] IPsec tunnel interfaces?

> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) wrote: > > > Hi Chris, > > On 07/05/2020 16:55, "Christian Hopps" wrote: > > > >> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote: >> >> >> Hi Chris, >> &

Re: [vpp-dev] IPsec tunnel interfaces?

Psec functionality. Could we bring back the functionality using more "acceptable to the project" APIs or something? Thanks, Chris. > > /neale > > > From: on behalf of Christian Hopps > Date: Wednesday 6 May 2020 at 14:32 > To: vpp-dev > Cc: Christian Hopp

[vpp-dev] IPsec tunnel interfaces?

Hi, vpp-dev, Post 19.08 seems to have removed IPsec logical interfaces. One cannot always use transport mode IPsec. How can I get the efficiency of route based (FIB) IPsec w/o transport mode? Adding superfluous encapsulations (wasting bandwidth) to replace this (seemingly lost, hope not)

Re: [vpp-dev] worker barrier state

e pool. > > On a somewhat related topic, you probably saw: > https://gerrit.fd.io/r/c/vpp/+/26811 > as an example of getting MP safe APIs wrong. I made a similar change locally back when we started talking about this. :) Thanks, Chris. > /neale > > On 24/04/2020 16:34, &quo

Re: [vpp-dev] 11th hour changes and code reviews

> On May 4, 2020, at 3:46 PM, Andrew Yourtchenko wrote: > More inline: >> On 4 May 2020, at 19:20, Paul Vinciguerra wrote: >> >> I agree that the change I submitted is a monster. Honestly, there are 2-5 >> git-friendly changes that could be refactored out of it. Its written and >> used by

Re: [vpp-dev] route lookup api

After multiple amended commits to fix python style errors, a new version with v4/v6 API tests has been uploaded. https://gerrit.fd.io/r/c/vpp/+/26829 Thanks, Chris. > On May 2, 2020, at 5:25 PM, Christian Hopps wrote: > > I was able to do a minimal test on it so I submitted, b

Re: [vpp-dev] route lookup api

P release manager hat) > > On 4/27/2020 5:02 PM, Christian Hopps wrote: >>> On Apr 27, 2020, at 11:44 AM, Jon Loeliger via lists.fd.io >>> >>> wrote: >>> >>> >>> >>> On Wed, Feb 19, 2020 at 4:47 AM Christian Hopps >>&g

bug in api generation [Re: [vpp-dev] packed enums]

re in the union. Anything that has a union in the API will suffer this same bug; the recent enum size changes to very common types (address family, ip proto, etc) merely cause this bug to be hit more ofetn. Thanks, Chris. > On May 2, 2020, at 8:20 AM, Christian Hopps wrote: > > Som

[vpp-dev] packed enums

Some recent changes related to packed enums in the API have broken already written code for low level API use. I think the main commit that did this was the one that added __packed__ to the generated enum declaration, but there are the related changes that add the enum size declarations I

Re: [vpp-dev] route lookup api

> On Apr 27, 2020, at 11:44 AM, Jon Loeliger via lists.fd.io > wrote: > > > > On Wed, Feb 19, 2020 at 4:47 AM Christian Hopps wrote: > > > On Feb 19, 2020, at 2:02 AM, Neale Ranns via Lists.Fd.Io > > wrote: > > > > > > Hi Chris,

Re: [vpp-dev] worker barrier state

Hi Neale, Comments also inline... Neale Ranns (nranns) writes: Hi Chris, Comments inline... On 15/04/2020 15:14, "Christian Hopps" wrote: Hi Neale, I agree that something like 4, is probably the correct approach. I had a side-meeting with some of the ARM fol

[vpp-dev] Packet processing time.

The recent discussion on reference counting and barrier timing has got me interested in packet processing time. I realize there's a way to use "show runtime" along with knowledge of the arc a packet follows, but I'm curious if something more straight-forward has been attempted where packets are

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

+1 for clang format. Regarding the in tree .clang-format, I had to use my own .clang_format settings though as the VPP/C++ version has different tab defaults from the indent default currently used in VPP (never use and 4 space vs always use and 8 space). Thanks, Chris. > On Apr 18, 2020, at

Re: [vpp-dev] worker barrier state

2 the send capability of your slowest node. Stated another way, 1/2 a VLIB_FRAME_SIZE (128 normally) worth of packet time on your slowest node must be reserved for the barrier or you are dropping packets. Thanks, Chris. > On Apr 15, 2020, at 9:13 AM, Christian Hopps wrote: > > Hi

Re: [vpp-dev] worker barrier state

> terms). > > Thoughts? > > /neale > > * I note that a SA delete is already (optimistically) marked MP safe, which > assumes the system flushes inbetween these API calls. > > > > > On 26/03/2020 16:09, "Christian Hopps" wrote: > >

Re: [vpp-dev] n_vectors...

any other kind of >> vector processing. There’s no law which says that frames need to have >> 32-bit elements. Each node decides. >> >> FWIW... Dave >> >> From: vpp-dev@lists.fd.io On Behalf Of >> Christian Hopps >> Sent: Monday, March 30, 2020 8:07 PM

[vpp-dev] n_vectors...

Something has always bothered me about my understanding of VPPs use of the term "vector" and "vectors". When I think of Vector Packet Processing I think of processing a vector (array) of packets in a single call to a node. The code, though, then seems to refer to the individual packets as

Re: [vpp-dev] vpp_papi not updated

$(PYTHON_INTERP) -m pip install -e $(PAPI_PYTHON_SRC_DIR)" > > On Fri, Mar 27, 2020 at 6:42 PM Christian Hopps wrote: > Hmm, at least on 19.08 doing the papi-wipe/wipe-papi is only removing things > under test. I'm running an external python app (not under test) and it's > loo

Re: [vpp-dev] vpp_papi not updated

p/+/26177 > > On Fri, Mar 27, 2020 at 6:26 PM Christian Hopps wrote: > [on 19.08] > > I'm seeing something odd building. When I "make build" after changing > something in "src/vpp-api/python/vpp_papi/*.py" it does not get reinstalled > in the build-ro

[vpp-dev] vpp_papi not updated

[on 19.08] I'm seeing something odd building. When I "make build" after changing something in "src/vpp-api/python/vpp_papi/*.py" it does not get reinstalled in the build-root. In fact if I delete build-root/install-vpp_debug-native/lib64/python3.6/site-packages/vpp_papi* it also does not get

Re: [vpp-dev] worker barrier state

> On Mar 25, 2020, at 1:39 PM, Dave Barach via Lists.Fd.Io > wrote: > > Vlib_main_t *vm->main_loop_count. > > One trip around the main loop accounts for all per-worker local graph edges / > acyclic graph behaviors. > > As to the magic number E (not to be confused with e): repeatedly

Re: [vpp-dev] worker barrier state

e. > > Dave > > > From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion > via Lists.Fd.Io > Sent: Wednesday, March 25, 2020 12:10 PM > To: Christian Hopps > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] worker barrier state > > > > > O

[vpp-dev] worker barrier state

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 this assumption. Can someone with deep VPP knowledge clarify this

  1   2   >