Hi Florin,
I've rebase my changes to your TCP split patch and it kind of works. The
problem that I've encountered now is that TCP always hands the buffers to
ip[46]_lookup.
Would it be acceptable to modify the application, session and tcp logic to
be able to inject a function per application
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
I'm not clear on what you mean by table add/del, but I can give you the
scenario I'm concerned with.
I have a packet P input and it has some state S associated with it.
The API wants to delete state S. When is it safe?
Say P's arc from input to output contains E edges. Each node on the arc
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_output. You can initialize those as you may
see fit in your custom listen node.
For
Hello ACL Maintainer,
We want to measure and optimize the ACL performance for ARM servers. As per
the foll. link, there are 4 different implementation of ACLs in VPP.
https://fd.io/docs/vpp/master/usecases/acls.html
We would like to start with most commonly used ACL implementation in
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 handing off
packets from thread to thread seems like a bad implementation strategy. The
Hi Andreas,
Understood. Let me know if the next_node_index works for you.
Regards,
Florin
> On Mar 25, 2020, at 12:39 PM, Andreas Schultz
> wrote:
>
> Am Mi., 25. März 2020 um 18:57 Uhr schrieb Florin Coras
> mailto:fcoras.li...@gmail.com>>:
> Hi Andreas,
>
> You have in the tcp
OK, no need to see the script... Classifier table out of memory... If you’re
using the “classify table” debug CLI to set up the tables, change (or add)
“memory-size xxxM” or “memory-size xxxG” to give the classifier enough memory.
Depending on how many concurrent entries you expect, set the
It works! Thank you very much, Dave. Much appreciated.
Le mer. 25 mars 2020 à 09:39, Dave Barach (dbarach) a
écrit :
> OK, no need to see the script... Classifier table out of memory... If
> you’re using the “classify table” debug CLI to set up the tables, change
> (or add) “memory-size xxxM”
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
vpp show log only showed a bunch of dhcp/client timeouts, I believe. I don't
know if there was a VM migration, but how could I know for sure? The VM has
been powered on the entire time, but perhaps there was a hot-swap of NICs?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this
Hi Chris,
I'd expect only 2 dtap too. Do you know if there was a VM migration?
Is there anything in vpp 'show log'?
ben
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Chris King
> Sent: mercredi 25 mars 2020 15:00
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] VPP
> On 25 Mar 2020, at 16:01, Christian Hopps wrote:
>
> 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
+1.
View any metadata subject to table add/del accidents with suspicion. There is a
safe delete paradigm: each vlib_main_t has a “lap counter”. When deleting
table entries: atomically update table entries. Record the lap counter and wait
until all worker threads have completed a lap. Then,
2nd attempt - replying all. Dave - Apologies for the duplicate response.
Thanks for your response. You're right -- I should have provided more
details. My script is trying to set up a large numbers of IPs to block
using classifiers. I now have a backtrace as well which indicates that it
seems to
I am running vpp v20.01-release on Ubuntu 18.04 on an Azure VM. I had been
forwarding traffic with VPP for about 5 days and today I noticed that my 2 main
interfaces FailsafeEthernet2 and FailsafeEthernet4) had gone down and I could
not find a reason. I looked at the journalctl logs (which only
Coverity run failed today.
Current number of outstanding issues are 4
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 (#15865):
Hi all,
Any ideas I can try? I am not familiar with dhcp plugin.
Thanks.
On Mon, Mar 23, 2020 at 12:55 AM Carlito Nueno
wrote:
> Hi all,
>
> I am using vpp v20.01 and govpp - v0.3.1
>
> lease.DomainServer is showing [0 0 0 0], empty Address and the conversion
> to IP address is 0.0.0.0.
>
>
Hi all,
I have a large script (2000 lines, 146,459 bytes) that I'm trying to
execute using 'exec' in vppctl. When I copy+paste commands from the script,
it works fine. However, if I try to execute the script with 'exec
/path/to/myscript.txt', VPP crashes.
I'm running VPP v20.01 on Ubuntu 18.04
How about: send a backtrace (preferably from a debug image), and put the script
somewhere so that we can work the problem?
From: vpp-dev@lists.fd.io On Behalf Of Luc Pelletier
Sent: Wednesday, March 25, 2020 7:53 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP Crashes When Executing Large
20 matches
Mail list logo
