Age | Commit message (Collapse) | Author | Files | Lines |
|
The vlib init function subsystem now supports a mix of procedural and
formally-specified ordering constraints. We should eliminate procedural
knowledge wherever possible.
The following schemes are *roughly* equivalent:
static clib_error_t *init_runs_first (vlib_main_t *vm)
{
clib_error_t *error;
... do some stuff...
if ((error = vlib_call_init_function (init_runs_next)))
return error;
...
}
VLIB_INIT_FUNCTION (init_runs_first);
and
static clib_error_t *init_runs_first (vlib_main_t *vm)
{
... do some stuff...
}
VLIB_INIT_FUNCTION (init_runs_first) =
{
.runs_before = VLIB_INITS("init_runs_next"),
};
The first form will [most likely] call "init_runs_next" on the
spot. The second form means that "init_runs_first" runs before
"init_runs_next," possibly much earlier in the sequence.
Please DO NOT construct sets of init functions where A before B
actually means A *right before* B. It's not necessary - simply combine
A and B - and it leads to hugely annoying debugging exercises when
trying to switch from ad-hoc procedural ordering constraints to formal
ordering constraints.
Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Make full use of well optimized function vlib_get_buffers
for ethernet_input_inline.
Change-Id: Iee7df570b87fa95c0902895686a62386d730f9a1
Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
|
|
Node tracing condition was wrongly reversed by commit "5ecd5a5d15 Move
pcap rx/tx trace code out of the dpdk plugin".
This prevented packet tracing in ethernet-input node and also impacted
performance in the no tracing case.
Change-Id: I345a11191d027c6c4ec474a2901995338050680a
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Moved code to the ethernet input node, and the interface output
path(s). Since we no longer skip ethernet-input, there's no reason
for device drivers to know anything about pcap rx tracing, etc.
Change-Id: I08d32fb1b90cbee1bd4f609837d533e047b36fa4
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
use address_t and mac_address_t for IPv6 and ARP entries
and all other API calls in ip.api aprat from the route ones,
that will follow in a separate commit
Change-Id: I67161737c2184d3f8fc1e79ebd2b55121c5b0191
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I21bdd8982d5f357590af8a2a0219bdebbaee4e74
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I0e89fbc51f30325655c4e9d0104aceb3ead3b16f
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I3befc762694e7c6d6847c361a144f72547038ba1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I4ec7750ef58363bd8966a16a2baeec6db18b7e9e
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
fastpass case (VPP-1444)
20e6d36b has moved the calculation of the l3_hdr_offset into the determine_next_node()
function, with the assumption that the current_data in the buffer is at
the L3 header. This is not the case for the single loop fastpath,
where the vlib_buffer_advance() call is made after the call to
determine_next_node(), as a day1 behavior. As a result - that path
incorrectly sets the l3_hdr_offset.
Solution: move the vlib_buffer_advance() call to before determine_next_node()
Change-Id: Id5eaa084c43fb6564f8239df4a0b3dc0412b15de
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
(cherry picked from commit 376414f4c3f53af44da4e82ee5d0b1843b291f8e)
|
|
The issue surfaced when developing the tap GSO code, with
an iteration where output path is reliant on
vnet_buffer (b0)->l3_hdr_offset being set correctly in
the input path, during performance testing.
Adding a workaround in the TX path shows that
the issue surfaces only for relatively few packets
during the test (about 100 out of 600000).
Analysis shows the issue arises if the ethernet-input
is handling two untagged packets with different sw_if_index
values - then the accelerated path punts to slow path,
before the setting of the l2.l2_len values is done,
thus resulting in them being 0, and l3_hdr_offset being
the same as l2_hdr_offset, wreaking havoc on TX path.
The solution is to move the l2_hdr_offset calculation
into a place where it is done for all the packets,
and move the l3_hdr_offset calculation into
the determine_next_node() function - as that function is
also the one setting the special-case l2.l2_len value for
tagged packets and moving the current_data for the L2 case.
Change-Id: If728c7715e011930c1887691188c98055bddde67
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
Removed 0-tags attribute for default-sub-if config
Moved default-sub-if check before untagged
Change-Id: I68043445aa2f79846e0743567b9015257fd87f8d
Signed-off-by: Mike Bly <mbly@ciena.com>
|
|
Change-Id: Idabdd1112ba7e390a7b14a83cc7fbd198c8754df
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I1aa196756b3ff4969b8ff2f117778d2cd87d6dd5
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
It is cheaper to get thread index from vlib_main_t if available...
Change-Id: I4582e160d06d9d7fccdc54271912f0635da79b50
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
A pipe resembles a unix pipe. Each end of the pipe is a full
VPP interface.
pipes can be used for e.g. packet recirculation, inter-BD, etc.
Change-Id: I185bb9fb43dd233ff45da63ac1b85ae2e1ceca16
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
Change-Id: Ibf3ef82950f50b746394a731cd2e7cba1cd16ec4
Signed-off-by: John Lo <loj@cisco.com>
|
|
Also it removes ethernet_frame_is_any_taged implemebntation
which seems to be equally costly compared to two
invocations of ethernet_frame_is_tagged.
Change-Id: If1c95f8267cd34b807ec07e0d675cbd0db2fdf9f
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I1771a1cca2a4bc394677b2a18f14c47f0633fa77
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
This happens when 2 packets belonging to 2 different interfaces hit
dual loop in the ethernet-input. Packets go to slow path which doesn't
set l2 hdr offset correctly for l3 packets.
Change-Id: I61d87c079db0b2e21f8af6f6b600bff14030535d
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Changes made in ethernet_input to set l2_hdr_offset,l3_hdr_offset, and
their corresponding flags.
Please note that ethernet_input, as a critical DP, incurs a few extra cpu
cycles due to this patch, but for a worthy cause.
Change-Id: Ie9ae352ea62959d2779ebcca98a1898e3d9e1d6f
Signed-off-by: Steven <sluong@cisco.com>
|
|
Change-Id: Idb97e573961b3bc2acdeef77582314590795f8c3
Signed-off-by: Pavel Kotucek <pkotucek@cisco.com>
|
|
To save space in the first cacheline following is changed:
- total_length_not_including_first_buffer moved to the 2nd cacheline.
This field is used only when VLIB_BUFFER_TOTAL_LENGTH_VALID and
VLIB_BUFFER_NEXT_PRESENT are both set.
- free_list_index is now stored in 4bits inside flags, which
allows up to 16 free lists. In case we need more we can store index
in the 2nd cachelin
Change-Id: Ic8521350819391af470d31d3fa1013e67ecb7681
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ic31b388cb972fb5f8a3fc42a5412401c3ee3e487
Signed-off-by: Christophe Fontaine <christophe.fontaine@enea.com>
|
|
a double version of is_tagged, uses "free lanes" in _mm_cmpeq_epi16
to check a second tag
this code was not yet tested for performance
Change-Id: I640017e1cc75c85a33d196ee911a7e4a512d9849
Signed-off-by: Eyal Bari <ebari@cisco.com>
|
|
l2_len was not updated for the third tag
as the ethernet node retracts by the vlan count after parse_header (using
ethernet_buffer_header_size) it ends up pointing before the ethernet header
+ some minor cleanups
Change-Id: I4ccaedd33928912e5d837376f146503b27071741
Signed-off-by: Eyal Bari <ebari@cisco.com>
|
|
Change-Id: I21b1ad39275495d4d006023b58f630a213445854
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I6ce21317fcaa25781199f4329be815f076ab8b09
Signed-off-by: Hongjun Ni <hongjun.ni@intel.com>
|
|
1 - interface-DPO
Used in the Data-plane to change a packet's input interface
2 - MPLS multicast FIB entry
Same as a unicast entry but it links to a replicate not a load-balance DPO
3 - Multicast MPLS tunnel
Update MPLS tunnels to use a FIB path-list to describe the endpoint[s]. Use the path-list to generate the forwarding chain (DPOs) to link to .
4 - Resolve a path via a local label (of an mLDP LSP)
For IP multicast entries to use an LSP in the replication list, we need to decribe the 'resolve-via-label' where the label is that of a multicast LSP.
5 - MPLS disposition path sets RPF-ID
For a interface-less LSP (i.e. mLDP not RSVP-TE) at the tail of the LSP we still need to perform an RPF check. An MPLS disposition DPO performs the MPLS pop validation checks and sets the RPF-ID in the packet.
6 - RPF check with per-entry RPF-ID
An RPF-ID is used instead of a real interface SW if index in the case the IP traffic arrives from an LSP that does not have an associated interface.
Change-Id: Ib92e177be919147bafeb599729abf3d1abc2f4b3
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
This patch deprecates stack-based thread identification,
Also removes requirement that thread stacks are adjacent.
Finally, possibly annoying for some folks, it renames
all occurences of cpu_index and cpu_number with thread
index. Using word "cpu" is misleading here as thread can
be migrated ti different CPU, and also it is not related
to linux cpu index.
Change-Id: I68cdaf661e701d2336fc953dcb9978d10a70f7c1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Interface can be in promiscuous mode if more than one of its sub-
interface is in L2 mode. In promiscuous mode, L3 interface need to
verify DMAC of packet to match that of the interface and drop if not.
This check was done on sub-interface only and now also added to main
interface path.
Fix incorrect MAC addresses in the flow-per-pkt plugin test, which
caused it to fail.
Fix MAC address usage in BFD tests.
Change-Id: I12a17ec05c7ab298ad10d400c90d082c97eca521
Signed-off-by: John Lo <loj@cisco.com>
Signed-off-by: Klement Sekera <ksekera@cisco.com>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|