[vpp-dev] Interesting VPP/Quic article

https://blogs.cisco.com/cloud/building-fast-quic-sockets-in-vpp -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15962): https://lists.fd.io/g/vpp-dev/message/15962 Mute This Topic: https://lists.fd.io/mt/72685199/21656 Group Owner: vpp-dev+ow...@lis

Re: [vpp-dev] how to create a session from thin air?

Hi Andreas, Unfortunately, you got it right. We’d need changes in the whole vnet_connect chain, including the code that generates syns, to support a non-custom next-node for syns. Half-open connections are allocated out of a different pool, so we can’t reuse tcp-output logic. We could add a

Re: [vpp-dev] how to create a session from thin air?

Am Mi., 25. März 2020 um 18:57 Uhr schrieb Florin Coras < fcoras.li...@gmail.com>: > Hi Andreas, > > You have in the tcp connection next_node_index and next_node_opaque which > can be used to determine the next node and some additional info you may > want to send to a custom next node from tcp_out

Re: [vpp-dev] n_vectors...

> On Mar 31, 2020, at 9:20 AM, Elias Rudberg wrote: > > Hi Chris and Dave, > > Thanks for bringing this up, and thanks for explaining! > > I agree with Chris that this is confusing, it makes it much more > difficult to understand the code. As someone who UTSL as a first, second and third set

[vpp-dev] Coverity run FAILED as of 2020-03-31 14:00:27 UTC

Coverity run failed today. Current number of outstanding issues are 5 Newly detected: 0 Eliminated: 0 More details can be found at https://scan.coverity.com/projects/fd-io-vpp/view_defects -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15958): ht

Re: [vpp-dev] n_vectors...

We should not rename variables in existing codes unless we're rewriting from scratch. It's already hard enough to cherry-pick bugfixes from master/latest to stable/2001 and stable/1908. Making wholesale variable name changes turns every subsequent cherry-pick into an adventure. In the interes

Re: [vpp-dev] n_vectors...

Hi Chris and Dave, Thanks for bringing this up, and thanks for explaining! I agree with Chris that this is confusing, it makes it much more difficult to understand the code. Perhaps this is the kind of thing that doesn't matter much to those who are already familiar with the code, while at the s

Re: [vpp-dev] What is the best practice for getting VPP statistics/counters with less performance degradation?

立見さん、 The best way too gather statistics is to use the stat segment. That’s a shared memory segment using optimistic locking. Use the client vpp_get_stats as example. Best regards, Ole > On 31 Mar 2020, at 13:57, Yusuke Tatsumi wrote: > >  > Hi all, > > I noticed that vppctl itself affec

[vpp-dev] What is the best practice for getting VPP statistics/counters with less performance degradation?

Hi all, I noticed that vppctl itself affects tail-latency performance while getting packet counter information via vppctl. Is there any less-affect way of getting some runtime-informations? What is the best practice for getting VPP statistics/counters with less performance degradation? Best Reg

Re: [**EXTERNAL**] [vpp-dev] Deterministic NAT - VPP 19.08

Hi again, > If that is the case, then why is the following configuration allowed ? > > nat44 deterministic add in 20.20.20.2/32 out 10.10.10.15/32 > nat44 deterministic add in 40.40.40.2/32 out 10.10.10.15/32 Think of VPP as an ASIC. Or as a set of Lego pieces. You are responsible yourself how y