Comment 15 for bug 1462093

Reviewed: https://review.opencontrail.org/14391
Committed: http://github.org/Juniper/contrail-controller/commit/187cf8830648bcf061e471edd586d2b6186bdf9b
Submitter: Zuul
Branch: master

commit 187cf8830648bcf061e471edd586d2b6186bdf9b
Author: Praveen K V <email address hidden>
Date: Wed Jul 29 16:08:06 2015 +0530

Flow optimizations - Run flow management in a work-queue

As part of flow processing we need to maintain data structures to keep
the flow action in-sync with config changes. Building these changes and
also revaluating flows when config change is notified can result in
significant latencies.

With this change we move the flow management part to a work-queue. The
flow management module is resposible to keep the flow in-sync with
config changed.

Few other slow operations operations such as logging/UVE also will be
moved to this module in subsequent commits.

Partial-Bug: #1479295

Removing the config listener

After IFmap dependency manager is introduced for all the objects in Agent,
the config listener does not play any role other than invoking node observers
and link observers, which is taken care in dependency manager itself.

As part of the same, Uuid change of node is also detected and handled.

Couple of test cases are moved out of flaky tests.

closes-bug: #1480124

Split flow_table.cc to create new file flow_entry.cc

Move FlowEntry methods to new file flow_entry.cc and flow_entry.h
No changes in functionality

Partial-Bug: #1479295

Move Flow logging to Flow Management module

Define a message to enqueue Flow Export requests in Flow Management module. Move FlowExport functionality from FlowTable to
Flow Management module. Replace FlowExport API calls in Flow Stats collector and Flow Table with a message to Flow Management
module.

Partial-Bug: #1479295

Run FlowTable processing from work-queue

This change is a step towards running Flow setup in multiple threads. Flow
creation is a two step process,

FlowHandler :
FlowEntry are created and flow action are determined in this context.
This stage can potentially run in multiple threads (future commits)
FlowHandler runs from a workqueue in "Agent::FlowHandler" task context

FlowTable :
1. Manage flow_entry_map_ which contains all flows
2. Enforce the per-VM flow limits
3. Generate events to KSync and FlowMgmt modueles
FlowTable runs from a workqueue in "Agent::FlowTable" task context

Partial-Bug: #1479295

Optimize packet processing ASIO context

Method PktHandler::HandleRcvPkt is called from ASIO context. Following
processing was done in HandleRcvPkt within this context,

- Decode of the packet including decoding on tunnel headers
- In case of bare-metas identification of interface based on MAC address

This commit minimizes processing in ASIO context. Packet are enqueued to
module work-queue baesd on the agent-header. The packet decode is
subsequently done when work-queue is scheduled.

Partial-Bug: #1479295

* Track static and floating ip preference based on instance ip

1> Floating ip, static route and allowed address pair in ecmp
mode would have preference published based on instance-ip
preference
2> If allowed-address pair address is configured in active-stdby
mode, run path preference algorithm
Test case for same
Closes-bug:#1462093,#1461787

(cherry picked from commit 590e031df3598e8dfb54d96018082aaf84401fa1)

Define a new property to configure flow export rate in schema.

This is a per vrouter config and part of virtual-vrouter stanza.
Partial-Bug: #1486850

* Agent changes for TCP connection state awareness for faster flow aging

1> Flow eviction by vrouter
If a closed or reset TCP session flow is present in a flow bucket
then vrouter could evict the flow and use the slot for
a new flow, agent would then delete the evicted flow internally
and send a message to delete reverse flow
2> Closes or reset flow would be deleted by agent during aging
cycle.
3> If a flow is stuck in SYN state for more than 180 seconds
delete the flow.

TBD:
Update stats for deleted flow
Make SYN flow timeout configurable
Partial-BUG: #1362701

Run packet-parse routins in ASIO context

In an earlier commit f148293fb1f803a7b60faae2159bbde0b7968404, the
packet-parse routines were moved out of ASIO context assuming it will
improve performance.

Further measurements show that, performing packet-parse in ASIO context
itself does not affect performance. Hence reverting the change.

Partial-Bug: #1479295

Move flow-export-rate config to global-vrouter-config stanza

flow-export-rate config is being moved from virtual-router to global-vrouter-config stanza to avoid configuring this parameter on each vrouter.
Partial-Bug: #1486850

Export only subset of flows instead of exporting all flows.

The subset of flows to be exported are selected from a algorithm. The parameters for the algorithm are
(1) configured flow export rate (2) actual flow export rate and (3) sampling threshold.
As of today based on timer event, we export certain number of flows. As part of this same timer event we
update the actual flow-export rate and sampling threshold parameters. Each flow which needs to be exported
is subjected to the following algorithm to decide whether it needs to exported or dropped.

(1) Flow samples greater than or equal to sampling threshold will always be
exported, with the byte/packet counts reported as-is.
(2) Flow samples smaller than the sampling threshold will be exported
probabilistically, with the byte/packets counts adjusted upwards according to
the probability.
(3) Probability = diff_bytes/sampling_threshold
(4) We generate a random number less than sampling threshold.
(5) If the diff_bytes is greater than random number then the flow is dropped
(6) Otherwise the flow is exported after normalizing the diff bytes and
packets. The normalization is done by dividing diff_bytes and diff_pkts with
probability. This normalization is used as heuristictic to account for stats
of dropped flows

The actual flow-export-rate will be close to the configured configured export rate and whenever there
is huge deviations we adjust sampling threshold to bring the actual flow export rate close to configured
flow export rate. It is not guaranteed that the actual flow export rate will always be close to configured flow export rate.

Partial-Bug:1486850

Conflicts:
 src/ksync/ksync_sock_user.cc
 src/vnsw/agent/oper/global_vrouter.cc
 src/vnsw/agent/oper/global_vrouter.h
 src/vnsw/agent/oper/loadbalancer.cc
 src/vnsw/agent/oper/logical_interface.cc
 src/vnsw/agent/oper/operdb_init.cc
 src/vnsw/agent/oper/service_instance.cc
 src/vnsw/agent/oper/test/instance_manager_test.cc
 src/vnsw/agent/oper/vm_interface.cc
 src/vnsw/agent/oper/vrf.h
 src/vnsw/agent/pkt/SConscript
 src/vnsw/agent/pkt/agent_stats.cc
 src/vnsw/agent/pkt/flow_table.cc
 src/vnsw/agent/pkt/flow_table.h
 src/vnsw/agent/pkt/pkt.sandesh
 src/vnsw/agent/pkt/pkt_flow_info.cc
 src/vnsw/agent/pkt/test/test_pkt_parse.cc
 src/vnsw/agent/test/service_instance_test.cc
 src/vnsw/agent/test/test_util.cc
 src/vnsw/agent/uve/test/test_stats_mock.cc
 src/vnsw/agent/vrouter/flow_stats/flow_stats_collector.cc
 src/vnsw/agent/vrouter/flow_stats/flow_stats_collector.h
 src/vnsw/agent/vrouter/ksync/flowtable_ksync.cc
 src/vnsw/agent/vrouter/ksync/sandesh_ksync.cc

Change-Id: Ieb07b7cd3890c191dc5c1cd0547a4e74caa956be