summaryrefslogtreecommitdiffstats
path: root/vnet/vnet/replication.c
AgeCommit message (Collapse)AuthorFilesLines
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-293/+0
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-10-14FIB2.0: Adjacency complete pull model (VPP-487)Neale Ranns1-0/+6
Change the adjacency completion model to pull not push. A complete adjacency has a rewirte string, an incomplete one does not. the re-write string for a peer comes either from a discovery protocol (i.e. ARP/ND) or can be directly derived from the link type (i.e. GRE tunnels). Which method it is, is interface type specific. For each packet type sent on a link to a peer there is a corresponding adjacency. For example, if there is a peer 10.0.0.1 on Eth0 and we need to send to it IPv4 and MPLS packets, there will be two adjacencies; one for the IPv4 and one for the MPLS packets. The adjacencies are thus distinguished by the packets the carry, this is known as the adjacency's 'link-type'. It is not an L3 packet type, since the adjacency can have a link type of Ethernet (for L2 over GRE). The discovery protocols are not aware of all the link types required - only the FIB is. the FIB will create adjacencies as and when they are required, and it is thus then desirable to 'pull' from the discovery protocol the re-write required. The alternative (that we have now) is that the discovery protocol pushes (i.e. creates) adjacencies for each link type - this creates more adjacencies than we need. To pull, FIB now requests from the interface-type to 'complete' the adjacency. The interface can then delegate to the discovery protocol (on ethernet links) or directly build the re-write (i.e on GRE). Change-Id: I61451789ae03f26b1012d8d6524007b769b6c6ee Signed-off-by: Neale Ranns <nranns@cisco.com>
2016-08-08VPP-311 Coding standards cleanup for vnet/vnet/*.[ch]Dave Barach1-149/+167
Change-Id: I08ed983f594072bc8c72202e77205a7789eea599 Signed-off-by: Dave Barach <dave@barachs.net>
2016-06-30Fix buffer leak from L2 flooding replication processPierre Pfister1-0/+1
vlib_buffer_free_inline actually checks (b->flags & VLIB_BUFFER_RECYCLE) in order to decide whether to free the packet or not. Although the flag was correctly set in replication_prep, it is not removed by replication_recycle during last iteration. This patch just removes VLIB_BUFFER_RECYCLE when is_last is set. Change-Id: I2445ebce908d94d95535e706b40407b4f15906e4 Signed-off-by: Pierre Pfister <ppfister@cisco.com>
2016-06-18Move pkt replication counter to the opaque2 cache lineDave Barach1-6/+5
Change-Id: I5e6edfd03ab41949be2c768dfe68aa824bbc1f38 Signed-off-by: Dave Barach <dave@barachs.net>
2016-05-31VPP97: Flooding of pkts with multiple buffers in BD with BVI crashes VPPJohn Lo1-9/+2
The loopback interface should use vnet_interface_output_no_flatten so follow-on buffers of a jumbo packet do not get put on the output frame and be sent back to ethernet-input or l2-input node. The replication_recycle_callback() function should not assume follow-on buffers of a jumbo packet are on the buffer free list. Change-Id: Ide646a6d9b43e82782c0581ea3022a9e70f82582 Signed-off-by: John Lo <loj@cisco.com>
2016-04-22Add clib_memcpy macro based on DPDK rte_memcpy implementationDamjan Marion1-2/+2
Change-Id: I22cb443c4bd0bf298abb6f06e8e4ca65a44a2854 Signed-off-by: Damjan Marion <damarion@cisco.com>
2015-12-08Initial commit of vpp code.v1.0.0Ed Warnicke1-0/+276
Change-Id: Ib246f1fbfce93274020ee93ce461e3d8bd8b9f17 Signed-off-by: Ed Warnicke <eaw@cisco.com>