Hi Rubina,

I am assuming you are observing this both in single core and multicore
scenario ?

Based on the outputs, this is what I think might be going on:

I am seeing the total# of sessions is 1000000, and no TCP transient
sessions - thus the packets that require a a session are dropped.

What is a bit peculiar, is that the session delete# per-worker are
non-zero, yet the the delete counters are zero. To me this indicates
there was a fair bit of transient sessions, which also then got
recycled by the TCP sessions properly established, before the idle
timeout has expired.

And at the moment of taking the show command output the connection
cleaner activity has not yet kicked in - I do not see either any
session deleted by idle timeout nor its timer restarted. Which makes
me think that the time interval in which you are testing must be
relatively short...

So, assuming the time between the start of the traffic and the time
you have 1m sessions is quite short, this is simply using up all of
the connection pool, a classic inherent resource management issue with
any stateful scenario.

You can verify that the sessions delete and start building again if
you issue "clear acl-plugin sessions".

Also, changing the session timeouts to more aggressive values (say, 10
seconds), should kick off the aggressive connection cleaning, thus
should unlock this condition. Of course, shorter idle time means
potentially useful connections removed.  (the commands are "set
acl-plugin session timeout <udp|tcp> idle <X>").

*if* neither of  the above does not adequately describe what you are
seeing, the cleaner node
may for whatever reason ceases to kick in every half a second.

To see the dynamics of conn cleaner node, you can use the debug command
"set acl-plugin session event-trace 1" before the start of the test.
This will produce the event trace, which you can view by "show
event-logger all" - this should give a reasonable idea about what the
cleaner node is up to.

Please let me know.


On 3/11/18, Rubina Bianchi <r_bian...@outlook.com> wrote:
> Hi,
> I am testing vpp_18.01.1-124~g302ef0b5 (commit:
> 696e0da1cde7e2bcda5a781f9ad286672de8dcbf) and vpp_18.04-rc0~322-g30787378
> (commit: 30787378f49714319e75437b347b7027a949700d) using Trex with sfr
> scenario in one core and multicore state.
> After a while I saw session deletion rate decreases and vpp throughput
> becomes 0 bps.
> All configuration files and outputs are attached.
> Thanks,
> Sincerely
> Sent from Outlook<http://aka.ms/weboutlook>


You receive all messages sent to this group.

View/Reply Online (#8490): https://lists.fd.io/g/vpp-dev/message/8490
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/14475974
Mute This Topic: https://lists.fd.io/mt/14475974/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub

Reply via email to