Change-Id: I7a24151be54ccc2c3c9505ea7afb8437752ef25f

Vrouter to generate EEXIST error when flow add request
failed due to race between agent and datapath, where
flow entry was already created due to packet trap

Closes-Bug: 1547501
Change-Id: I0d2073622b06998dd5778fb94749958afc09bac0
(cherry picked from commit c17b4d4)

We can not hash L4 ports as fragments other than the first have
no L4 headers. In result fragments of the same packets may have
been distributed onto different lcores and potentially be routed
out of order.

The fix was originally committed by Michal Dubiel (commit d59ca66)
For a reason the fix was dropped in the commit 1056396

Change-Id: Iac607e6e14a139a0c015eeb5c9ff8c3de04854c6
Closes-Bug: #1474432

If a flow operation is requested for an index which
is not active, vrouter should return an ENOENT error
for such operation

Closes-Bug: 1548678
Change-Id: I42bbd58f41a868b1ce630046ae40e911df0d9491
(cherry picked from commit 1cf3761)

Change-Id: Ia9ae864af98a645b60c5880db29ba8ff1b3c494f
Closes-Bug: #1517665

The root cause is mbuf starvation due to lots of fragments.
The mbufs get stuck in the fragment assembler.

To fix the issue we disable fragment assembler allocations if the
number of allocated fragment elements is greater than 1024.
This basically temporarily drop of out of order fragments.

+ Fix memory allocation statistics.

Change-Id: Ife775ac3073a9c5981672bd64952661c28380a7c
Closes-bug: #1545798

Add a new option "--match" to match flows based on certain criteria.
With the match option, one will be able to match based on source ip
or destination ip (with or without ports) or vrf or protocol or any
of them together with any other of them.

e.g.:
--match 1.1.1.1:20
--match "1.1.1.1:20,2.2.2.2:22"
--match "[fe80::225:90ff:fec3:afa]:22
--match "10.204.217.10:56910 & vrf 0 & proto tcp"
--match "10.204.217.10:56910,169.254.0.3:22 & vrf 0 & proto tcp"

Change-Id: Id70e6d60950babe44612e6aded036c5d1bec6f92
Partial-BUG: #1513001

…into R3.0

Insufficient space in external memory buffer is not actually
an error for the vRouter/DPDK, so we supress those messages
by using -DSANDESH_QUIET.

Change-Id: I5bc0a51f7c4659f2733a72e9b45322d117265a87
Closes-bug: #1546291

…kets

If port mirroring is enabled, cloned packet is subjected to mirroring
using the original packet's forwarding metadata. If mirroring code
changes the metadata content, original packet will be forwarded as per
the changed fmd and results in wrong forwarding.

In the current case, mirroring is to a VM in different VN (hence new VRF)
and mirroring code is modifying the fmd's dvrf to new VRF.
The original ARP packet's L2 and L3 looksups are happening on the
modified VRF resulting in ARP getting dropped.

Also the type of packet is identified using vr_pkt_type() after packet
is mirrored. This is resulting in wrong pkt_type being used for mirrored
packet hence the source IP packet the mirrored packet is not correctly
computed.

As a fix, new FMD is used for mirrored packet and packet type is
identified before mirroring itself.

Change-Id: I1fbe7d7e83c7e66c3287b8082444483578117d14
closes-bug: #1549727

The number of TX/RX descriptors are also decreased to account
for this.

Change-Id: Ib29da97e229fbf6a77644e449d2a81281f438058
Closes-Bug: 1550073

… number of TX/RX descriptors are also decreased to account for this." into R3.0

If mirroring is enabled on analyzing VM's port itself, one copy of the
original packet gets mirrored to that port. But this mirrored packet
should not be mirroed again. Right now without verifying whether the
packet is mirrored or not, it is attempted for mirroring again.

When a packet is mirrored it is marked with flag VP_FLAG_FROM_DP. If
this flag is set it is not mirrored again.

Change-Id: Ie4cca916945878b77bc4db7666992f3933db3e13
closes-bug: #1549761

…red packets" into R3.0

Currently the L2 header used for both L2 and L3 GRO processing is only
next hop id. Post GRO, the nexthop is retrieved from this id and packet
is subjected to this nexthop for further processing. The ingress
interface filled in the packet is nh_dev of this nexthop. This is
resulting in ingress interface as Tap interface though packet acttually ingressed
on Fabric interface. This can potentially lead to issues in the packet's
further processing as Tap interface is not the real ingress
interface.

As a fix, the ingress interface id is also pushed as L2 header.

Change-Id: I6fbe055fff7da4c957fde29d132b56ea19bd2f3f
closes-bug: #1550632

When Transmit port mirroring is enabled, packet received on Fabric
interface is right now mirrored using the source IP of the inner packet.
This results in RPF failure on Analyzer VM's compute node because the
compute node which is doing the port mirroring is using other compute
node's VM IP.

As a fix, if mirroring is Tax mirroring, rather using inner packets
source ip, dest ip is used, so that Analyzer VM's RPF will not have any
issues

Change-Id: I5beaa0dd0cc3c886a1e77f244c8003595ed348e2
closes-bug: #1550312

Vrouter will track tcp flags, but will not evict the flow
entry once the session is closed and let vrouter agent
look at the flag to delete the flow eventually.

This is required till vrouter agent handles evict event
in a more stable way

Partial-Bug: 1550759
Change-Id: Ic7074442b22fc2c11362274e4e390654f3f2400a

We call vr_dpdk_virtio_stop() from uvhm_client_munmap() which in turn
is called from vr_uvh_nl_vif_del_handler().

These are as tiny as possible changes based on the the abandoned
refactoring commit: https://review.opencontrail.org/#/c/17178/

Closes-bug: #1551093
Change-Id: I4653601635dbb7f29d7af9ce15a18193904f583f

was tunneled or not

Once the packet is submitted for GRO, all datapath information is
lost. Post GRO, only values that are saved in the packet are the
vif and the nexthop. vif is a recent addition to the saved
information that helped us to identify which interface the packet
came from originally. Once the vif value was set properly, the logic
that checked whether the packet should be trapped to agent or not
based on the presence of label (basically fabric arp responses should
be trapped or not), misbehaved since label information is not saved
pre-GRO and hence not available in the metadata post GRO. For now,
fix the specific logic by checking whether the egress vrf is different
from the ingress vrf, which will be the case since physical interface
vrf will not be the same as vm's vrf.

Change-Id: Iba000889039bc8a5020fc11a462ba1b1a68ce1c8
Closes-BUG: #1551382

A mirror action needs its own forwarding metadata since the forwarding
parameeters that are used for mirroring will be different from those
that are used for packet forwarding. In this particular case, the vrf
to which the packets are mirrored are different from the vrf to which
packets need to be classified, and hence the packets were dropped in the
flow module with no source route as the drop reason.

Change-Id: I21930818a5cdec560818acb79f671ce29ac8bc85
Closes-BUG: #1552101

Currently when a flow entry is deleted, the corresponding hash entry is
kept at the head of the free list and after successfully inserting into
the list the entry's flags are reset. If any other core is
attempting to fetch a free entry, there is a likely chance that just
added entry will be given as free entry before the flags are reset as
this entry is at the head of the list. Because of this there is a race
condition for setting the flags between deletion of entry and additin of
entry. If deletion overwrites the addition flags, the Valid flags gets
overwritten. Because of this the entry would not be in free list but
still would not be considered a valid entry. Searching this entry by
index fails as this is not a valid entry.

As a fix, the flags while inserting the entry to free list are modified
before inserting so that there would not be any race condition.

Change-Id: I67b1077e75a8a9f4ca5ddcfe3a7513061fd20681
closes-bug: #1552544

I have no hardware with 16 cores, but I guess with lots
of lcores assigned to vRouter/DPDK some of them might get
sleep due to no RX queues assigned.

Change-Id: I7e37e14ef9aebfc3613ef5e908091ee35093d1bb
Closes-bug: #1505472

In case of ICMP error packets for ICMP errors, we were not initializing
flow key and trying to form a flow out of that key, resulting in wrong
key length and corrupted flow entry(s).

We will drop such packets.

Change-Id: Idae46a7e128482ad89da8b5bd1bd0ef6b17ef28e
Closes-BUG: #1556363

For an ICMP packet, the port numbers remain the same in either direction
i.e.: source port remains the same for both foward and the reverse flows
as does the destination port. Hence, we should not be swapping ports in
calculating the flow key while trying to tag an ICMP error packet to a
flow set up for the original stream.

Change-Id: Ic5df8aec5f1009441aefd3d177568d55f3cb0d2c
Closes-BUG: #1554236

…o R3.0

A '--get' switch for the 'rt' to match a particular route and dump it.
Currently, only for inet and inet6 routes.

Change-Id: I3b53dda635f4f4af5b7f79ddf47e14313f372f81
Partial-BUG: #1548757

Support GET for L2 routes

Support 'GET' operation for a specific route in the vRouter bridge
table too.

Also, support giving a specific prefix length to the route and return
a match based on that specific prefix.

Change-Id: I93980925e70f45482c372ba3beeca8bfbd3028b2
Closes-BUG: #1548757

Adding flow gen id info to agent header for vrouter
agent to identify the latest transistion

Partial-Bug: 1554423
Change-Id: I0c0d0ca5b5a5ee2edd1ed5c7a45852cbfd7663b2
(cherry picked from commit b81f978)

Packet size is passed to the ixgbe driver as a buffer
size. Then it is calculated to get the buffer size in kilobytes
using right bitshift by 10. 9160 >> 10 is 8. This leads to truncating
incoming 9kB frames to 8kB. Changing packet size to integer multiple
of 1kB solves the problem.

Change-Id: I202c7f9430c5952b5e89b1ef9fff101ed36bfe82
Closes-bug: #1547782

Post copying the metadata to the one supposed to be used for mirroring
and modifying the vrf value in it, we are not passing the copy to the
mirror.

Change-Id: Id3cbc5dcc296fc005d06a9aa797339c1cc4a10cc
Closes-BUG: #1552101

Every alloc and free of memory in vRouter is accounted for by the memory
statistics subsystem of vRouter. While unloading the module, we are
freeing malloc statistics memory before packet drop statstics memory is
freed. While we do update the memory statistics only if the memory
statistics block pointer is not null, we do not seem to be zeroing the
pointer that holds the address of the memory block post release. Hence,
reverse the order of release and NULL-ify the memory statistics pointer.

Also, unregister the net device notifier before going ahead and freeing
the memory that the vhost driver keeps. If the notifier is not unregistered
first, it can potentially access freed memory that vhost driver maintains.

Change-Id: I79c4cdec4f0501e61abf38698e44e461a90c370b
Closes-BUG: #1561589

Change-Id: Ie64707d76fbbe3566ec3b6df5eb0be61ca09bde2
Closes-bug: #1561634

On some hardware (e100e, virtual functions, etc) the MAC is random,
so we check if vif and NIC MACs are match and set the NIC MAC.

Change-Id: Ifbb20b534c49f3f618e5a729f8a03b0a200bf05b
Closes-bug: #1561636

When somebody does a tcpdump or an equivalent operation of listening
on an interface for all protocol packets, linux kernel prints protocol
xyz is buggy if the network header is positioned at an offset that is
not sane, for e.g.: network header offset is lesser than the data offset
(which is where the data starts).

vRouter is not setting network header offsets for packets that don't
undergo GRO or for non-tunnel packets. If such packets egress an
interface and if a tcpdump like application is running on that interface,
then we will see this issue.

Set skb network header to packet network header for such packets

Change-Id: I82f7550722798e53c94092788b5135603f6045c8
Closes-BUG: #1564242

It has been observed that if the less specific route is deleted first
and then all the more specific routes, the less specific route doesn't
go away. For e.g.: if 1.1.1.0/24 is deleted first and later 1.1.1.1/32
in a table where there are no other routes, 1.1.1.0/24 remains in the
table.

When we delete a non leaf node, if it is a bucket we do not update the
prefix length, flags and label values. If these values do not match with
those of other nodes in the same bucket, then the bucket will remain
forever. Hence, update the node with the values in the request before
traversing the tree down.

Change-Id: I71778a83093a04c462b40e6c7e05b1d993f3373e
Closes-BUG: #1563734

The goal is to have one CPU core dedicated to doing TX/RX from
the NIC (and no vRouter processing, handling packets from VM etc.
on this one core).

Change-Id: Id834ce950fbb312a79f837a85d3fe1b85c89f275
Closes-bug: #1567470

Change-Id: I2db021e58e8912bd55684cacef7e506974425cfb
Partial-BUG: #1559016

In case of bonding, the VLAN offloading was not enabled in the
hardware even though it was enabled in the vif. As a result,
the DPDK used to get VLAN tagged packets and was not stripping
resulting in breakage of the data path. The patch fixes the same.

Change-Id: I10a8b1eb08065b10146a64a99b295f0b28e73120
Closes-Bug: 1565124

- Enable vrouter TCP flow Eviction
- return EBADF if gen-id mismatch, even if the key is same
- returning EFAULT for cases if gen-id matches but key
  doesnot, this case ideally should not happen but in case
  it does vrouter-agent will log an Error and recover

Closes-Bug: 1554423
Change-Id: I14b898708f132b2e67504cb2afe021502730b62a
(cherry picked from commit a71739a)

Change-Id: I31e17f9229e675e1dfff0f34073b4c21c0c8d855
Partial-bug: 1556290

When the pkt0 interface is getting a lot of traffic as
a result of trapping packets to agent. When a large number
of packets are trapped in this manner, the NetLink thread
freezes (i.e. no commands like vif/nh can be run as they just hang).

Change-Id: I18db6d5cc96a812eab61609f8a369728a315eaa7
Closes-bug: #1569441

Closes=Bug: #1555511

Change-Id: I84db0b0fb853f049aeddb8bbdba67fc9f54eb59d

When Agent deletes a flow, the flow entry is not immediately deleted in
Vrouter. Vrouter uses work queues and rcu callbacks to streamline the
deletion. After these asynchronous callbacks, flow entry is treated as
deleted. If there are any packets hitting this flow entry before marking
as "not active" those packets are dropped. On a loaded system with huge
number of flows, these call backs take a considerable time(in the worst
case as much as 30 ms). Packets hitting this flow entry will be dropped
for all this time.

To avoid this issue, when Agent deletes the flow entry, entry is "marked
deleted". A delete marked entry is no more treated as active entry,
hence flow lookup does not return this entry. As a result, a new flow
entry gets created. All the subsequent packets hit the new entry. "flow"
utility displays this particular entry as "Dm".

Change-Id: I0e150bbeb4b3fe3bf3fa1f367e074586363786f2
closes-bug: #1569786

…lity

The uses flow table count and bridge table count is not displayed as
part of any utility. "vrouter" utility is extended to display this
count. This can be further extended to display all the Vrouter table
count like mpls, nh etc. As of now, bridge table and flow table count
along with its over flow table is displayed as part of "vrouter --info"

Change-Id: I2e54fb8e4fd89a15ecafdf5551f022448728a5f3
closes-bug: #1569791

…to VIF's VRF

This issue is valid only for unicast ARP request packets. As multicast ARP
request packets are always handled in Multicast Composite nexthop and as
they are  never subjected to GRO, this issue is not observed for
multicast ARP packets.
When an unicast ARP request is received on Fabric interface it is treated as ARP
reqest for VM if there is a label attached to it. Due to the changes in
GRO, post GRO, the label is not going to be present in fmd. So ARP
packets are treated as if they are meant for fabric network. This is
resulting in unicast ARP requests never being answered.

As a fix, if the VRF of fmd is different from VIF's VRF, these packets
are treated as VM's ARP packets.

Change-Id: I013b83c38642697c81e32460be936154e42a067e
closes-bug: #1570180

Change-Id: Id75ee6dc4f739f78073e72fae08bbbcffcde1618
Partial-BUG: #1513001

…R3.0

Intel 82599 NIC hash just src/dst IPs for UDP traffic, not
the src/dst ports. So we force vRouter to recalculate the hashes.

Change-Id: I1b330d605cb0c0401d2f45578535740dcc49b4c7
Closes-bug: #1570907

Change-Id: I345f772a37a20c2ec344815f73e11d383a1c48cd
Partial-bug: #1570918

When the Tx or Rx port mirroring is enabled on the port, vif utility is
not printing the mirror index. For debugging purpose it is better to
print the index. VIF utility is modified to print the index if port
mirroring is enabled

Change-Id: I0714b0dfb2bfb8c0044ab7dad7d953f6995aaeea
closes-bug: #1571950

…mpared to VIF's VRF" into R3.0

…er" utility" into R3.0

Right now the BGP As A Service uses the same methodlogy as Link local
services and sets up the flow with link local flag. Once this flag is
set the destination port is added to a bit map by Vrouter and uses when
the packet arrives on Fabric to subject it to Flow. If the flag is
removed from the Flow entry, the port is removed from Bitmap. This
mechanism has a problem if multiple flows use the same destination port
with Link Local flag. Removing the flag from one flow removes the port
from bitmap and because of this packets belonging to other flow never
gets subjected to flow processing as the bitmap does not have the port
any more.

As a temporary fix, a new flag is introduced in flow entry. When this
flag is set, the port is added to bitmap and is never removed from
bitmap even if the flag is removed from flow entry. This way, even if
multiple flows use the same port there would not be any issues.

This fix would be revoked once a new messaging comes between Agent and
Vrouter.

partial-bug: #1551576

Change-Id: I0474a91c3d1275d542f3e4d2ae11bc15f62cdbcf

Currently the overflow table sizes of flow and bridge are kept at 8k and
4k respectively as constant, irrespective of the main flow table size.
Now this is changed to 20% of the main table. If user specifies over
flow entries as module parameter, the value is untouched and left as is.
If user specifies only the main table entries, then over flow table
entries are again calculated as 20% of main table. While doing the
calculation, it is adjusted to upper bound 1k.

Change-Id: I45bb463013f850824af050ef9fb6d86118569f52
closes-bug: #1573381

When we set MTU of vhost0, the same should be applied to the vif of PMD
But the existing check was not allowing the same. Removing it.

Change-Id: I1dc0bb529f9b6a84830d7ed8a73d7d8a286b3c2f
Closes-bug: 1491680

…to R3.0

Change-Id: I58932fe80739414f96c0918de279965fac3d30c3
Closes-bug: #1567470

HOLD

If the reverse flow action is HOLD, it is possible that we might not
flush the packets that are in the hold queue when we do eviction.
There is also an unidentified case where such flows remain in the
table in the eviction marked state.

Also, free the vrouter operation request structure once the request
is done.

Change-Id: I75d54367c7f7a3b32c3a09332be4f01a64e06d2a
Partial-BUG: #1570203

Currently, in the receiving Vrouter, if the checksum of the UDP packets
is FFFF, it is treated as DIAG packets. But there can be some UDP
packets whose checksum can be FFFF. These should not be treated as DIAG
packets. To achieve this, DIAG packets are treated like below.

Agent ensures that checksum of DIAG packets is not FFFF, but stores FFFF
as checksum in UDP header. In the receiving Vrouter if UDP's checksum is
seen as FFFF, checksum is validated again to verify whether that is
correct checksum or not. If that is a wrong checksum, it would be marked
as DIAG packet. If right checksum, it would be processed as any other
regular packet.

Also incase of MplsoUDP encapsulation, even if the
configuration is to calculate the outer UDP checksum, if DIAG packet,
the outer UDP checksum is not computed. This ensures that,on the
receiving side, if checksum is validated by NIC, we will not have to
compute the checksum for the inner packet once again. To ensure that
there are not transmit errors, Agent calcualtes the checksum in the
payload and validates it after receiving.

Change-Id: Ie5f88deeea70e15aefda4b9dce49ccc48df3f117
closes-bug: #1576506

Put global PMD stats to lcore 0.

Change-Id: Ic2956676204277aacf06e5dc244b4726c9d0762b
Closes-bug: #1567470

Change-Id: I5c23af5c9963972599982549568da9432ac42469
Closes-Bug: 1577097

-----
whenever the flow entry is getting synced to the vrouter,
by the that time mirror entry dependency is not resolved.
And we try to access that miror entry causes this crash
Fix:
---
Added Timer based trigger to Sync the flow entry to vrouter.
If the mirror entry is not present at and analyzer attached,
flow_entry will be enqueued.and based on timer trigger will revesit the queue,
And update the Ksync entry, will retry for 4 attempts still if mirror entry is
not present will mark the flow to short flow. for this in the
vrouter module short flow reason is been added.

Change-Id: I3d4e3fb0dfc54e76588c6c1b4a6fb1f9abc19a1e
partial-bug: #1564239
(cherry picked from commit 26a7a71)

…vrouter, by the that time mirror entry dependency is not resolved. And we try to access that miror entry causes this crash Fix: --- Added Timer based trigger to Sync the flow entry to vrouter. If the mirror entry is not present at and analyzer attached, flow_entry will be enqueued.and based on timer trigger will revesit the queue, And update the Ksync entry, will retry for 4 attempts still if mirror entry is not present will mark the flow to short flow. for this in the vrouter module short flow reason is been added." into R3.0

…th_dev structure

Change-Id: I2a8c084b8f434bf2ad255bbea0784f6fff78a253
Closes-Bug: 1579243

…from HOLD" into R3.0

The "NEW" flag is set whenever a flow becomes active and is in
the transient state. If agent tries to modify the entry in that
state, a possibility because of reuse of an entry due to
eviction, a condition could happen where the flags used by datapath
could come from the flags set by agent, more specifically the
Modified flag, and thus be in a state where nothing can be done
in the entry. Hence, prevent agent from acting upon NEW flows.

Change-Id: I017fd7d32f0488cef90a17c491c6021bbdd181c7
Closes-BUG: #1580855

…n rte_eth_dev structure" into R3.0

. If any fragment other than the HEAD comes to the assembler, then
it means that datapath was not able to find the flow information
for that fragment, since HEAD had not yet passed through it. Hence,
there is an explicit assumption in the assembler that HEAD will
always come later than at least one fragment. Once the HEAD arrives,
the assembler will look for all the fragments of that packet and
flush the fragments.

Since the assembler is an asynchronous entity with respect to the
datapath, it is possible that by the time it gets the event and
processes the input fragments, HEAD also would have arrived, and
possibly in a different CPU than the other fragments.  If the HEAD
then is processed first, the assembler will not find any fragments
that will need the information that is supplied by the HEAD and hence
the fragments that arrived in the system before the HEAD will stay in
the assembler queue till they get timed out.

. Because of the asynchronous nature of the assembler, the IP header
of the cloned HEAD is not a safe access, since the original packet
might have undergone NATing, resulting in wrong IPs being used for
selecting the queues to search for fragments. Hence, store the IPs
in the packet node along with the fragment information so that
assembler will make the right calculations.

. Initialize the packet node flags field to zero. Uninitialized pnode
flags resulted in the label being treated as a VNID and hence an unset
packet nexthop and thus a wrong key nexthop in the flow key, resulting
in HOLD flows.

Change-Id: I5d2c5abcda9c612c9d13378c79ae5d8392fd2c7b
Closes-BUG: #1579828

Change-Id: I33e5f26b50c0532c3a802acba8025f3a268be4fb
Closes-bug: 1573255

Change-Id: Iad9a60ba9fa737167a650cd80997ff149cc8c9cf
Closes-bug: 1573255

When the packets are received on Fabric interface, these are subjected
to GRO before transmitting them to Tap interface. If Tx port mirroring
is enabled on Tap interface, as of now, mirroring is applied after GRO
of the packets. If the mirroring server is on another compute node, these
mirrored packets have GSO enabled. Vrouter makes use of Linux GSO routines
and these GSO routines expect that skb in skb_list of head_skb does not
contain any linear data (skb_headlen should be zero). Due to GRO the
skb_headle of some skb's in skb_list contains linear data resulting in
GSO routiness hitting a BUG_ON.

To over come this, the GRO needs to be applied post mirroring. To
enabled GSO on the mirrored packets the skb's gso_len also need to be
supplied. Instead of this fix, GRO is disabled if Tx port mirroring is
enabled on Tap interface as stop gap fix till the complete fix is in
place.

Change-Id: I7dd86e1bd90fef60efa4c9dbac78e853952c4fdc
closes-bug: #1577473

Change-Id: I4d62d23fff5d9e34477f3d706197322c1f2c94a7
Closes-bug: 1573255

…V VF." into R3.0