Age | Commit message (Collapse) | Author | Files | Lines |
|
When the NIC does not support mac filter, we rely on ethernet-input
node to do the destination mac check, ie, when the interface is in L3,
the mac address for the packet must be the mac address of the
interface where the packet arrives. This works fine in ethernet-input
node when all packets in the frame might have different interfaces, ie,
ETH_INPUT_FRAME_F_SINGLE_SW_IF_ID is not set in the frame. However,
when all packets are having the same interface,
ETH_INPUT_FRAME_F_SINGLE_SW_IF_ID is set, ethernet-input node goes
through the optimized routine eth_input_single_int -> eth_input_process_frame.
That is where dmac check has a bug when all packets in the frame are
either, ip4, ip6, or mpls without vlan tags. Because without vlan tags,
the code handles all packets in fast path and ignores dmac check.
With vlan tags, the code goes to slow path where dmac check is handled
properly.
The fix is to check if we have a bad dmac in the fast path and force the
code to go to slow path which will handle dmac check properly.
Also do a wholesale correction on all the testcases which do not use
the proper dmac when sending L3 packets.
Type: fix
Change-Id: I73153a805cecdc24c4eefcc781676de04737ae2c
Signed-off-by: Steven Luong <sluong@cisco.com>
|
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Ensure that the ethernet_input_inline_dmac_check which directly derefererences ei,
is called only if ei is set.
Type: fix
Change-Id: I2d3bce63ee457825a5d375a6102225f3abf67703
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
Following the discussion during the review
of b46a4e69e5db18ef792415439d04a0ab22c59386,
remove the redundant ei0. This resulted in realization
that in order for this code to do anything useful,
the ei must be always non-zero, so rewrite the logical
condition for it. Also, make it a conjunction which seems simpler
to understand.
Type: improvement
Change-Id: Ibd7b2a63e4aeaf97eb1a98af8e69aed2ff7dd577
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
Check that the pointer is non-null before dereferencing it.
Type: fix
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: I611a1042d08bbe455dd09a4fa5711fe86c440240
|
|
Type: improvement
Change-Id: Iac01d7830b53819ace8f199554be10ab89ecdb97
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
|
|
Type: refactor
Change-Id: Id10cbf52e8f2dd809080a228d8fa282308be84ac
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: style
reduce the number of files recompiled after changing pg.h from 1110 to
102.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I50611eba818eeb3a2dffd437a3c72c77766bed80
|
|
Type: fix
Change-Id: Ic32550ee9c5d76d232d8b67a7810611f6c8b9177
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
It naturally belogns there...
Type: refactor
Change-Id: I05f7ba01103a5e9b3756f1ea69c8cc5d8f26f0a0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: fix
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I6a3348c7edd1cce6b407d336443103f77392bc5d
|
|
ethernet dataplane loads MAC addresses as 64-bits loads for efficiency.
We must make sure it is valid, especially for the vector of secondary
MACs.
Type: fix
Change-Id: I851e319b8a973c154e85ff9f05f3b8e385939788
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: fix
Due to confusion between ethernet flags and hw interface flags, DMAC
filtering was not happening, most of the time.
Signed-off-by: Ivan Shvedunov <ivan4th@gmail.com>
Change-Id: I95209e1ea0f95f9be0b1a82ec9fcbc80955428d2
|
|
Type: fix
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Ibad744788e200ce012ad88ff59c2c34920742454
|
|
Fix and optimize DMAC check in ethernet-input node to utilize NIC or
driver which support L3 DMAC-filtering mode so that DMAC check can be
bypassed safely for interfaces/sub-interfaces in L3 mode.
Checking of interface in L3-DMAC-filtering state to avoid DMAC check
require the following:
a) Fix interface driver init sequence for devices which supports L3
DMAC-filtering to indicate its capability and initialize interface
to L3 DMAC-filtering state.
b) Fix ethernet_set_flags() function and its associated callback
flags_change() functions registered by various drivers in interface
infra to provide proper L3 DMAC filtering status.
Maintain interface/sub-interface L3 config count so DMAC checks can be
bypassed if L3 forwarding is not setup on any main/sub-interfaces.
Type: fix
Ticket: VPP-1868
Signed-off-by: John Lo <loj@cisco.com>
Change-Id: I204d90459c13e9e486cfcba4e64e3d479bc9f2ae
|
|
Identified and removed executable bit from source files in the tree.
find . -perm 755 -name *.[ch] -exec chmod a-x {} \;
Type: improvement
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Change-Id: I00710d59fcc46ce5be5233109af4c8077daff74b
|
|
Type: fix
Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
Change-Id: I617fb365def22a28d48f75013dea38f8e1703a44
|
|
Type: improvement
Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
Change-Id: I0eaedeee03dd3b4453edec7fca2a5c741a98de23
|
|
The patch brings 0.8 clocks saved per pkt in IPv4 l3fwd case on Skylake.
Type: improvement
Signed-off-by: Zhiyong Yang <zhiyong.yang@intel.com>
Change-Id: Ia8d3a27773bf959433380d7c219602b1e4a8e5bd
|
|
Type: feature
In ethernet_input_inline(), when verifying that the destination
mac address on a received packet matches the mac address of the
interface where the packet was received, check the secondary
addresses on the interface if the primary address does not match.
This was done previously for eth_input_single_int().
Change-Id: I45716184dd789d83852271f9c79cedf5f6cbf75b
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
Finish the feature, and fix a couple of doc bugs
Type: feature
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I2c62745fda137776204c8fc4fca0e7e288051573
|
|
Static analysis says that a possibly null pointer is dereferenced.
Check it first.
Type: fix
Change-Id: I3d1a1548162d1dfc26f19fbcf159f0f1f91eb7c4
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
Maintain a list of secondary MAC addresses on ethernet_interface_t.
In ethernet-input dmac filtering, If packets do not match the
primary interface hardware address, check to see if they match the
other addresses.
Type: feature
Change-Id: Ie0edf45cae0d85c038a61086c47b3ae82d7e162d
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
Type: feature
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I79b216d2499df143f53977e5b70382f6f887e0bc
|
|
Use a single vnet_pcap_t in vlib_global_main, specifically to support
unified tracing
Update sphinx docs, doxygen tags
Type: refactor
Ticket: VPP-1776
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Id15d41a596712968c0714cef1bd2cd5bc9cbdd55
|
|
See .../src/vnet/classify/trace_classify.h for the business end
of the scheme.
It would be best to hash pkts, prefetch buckets, and do the primary
table lookups two at a time. The inline as given works, but perf
tuning will be required. "At least it works..."
Add "classify filter" debug cli, for example:
classify filter mask l3 ip4 src dst \
match l3 ip4 dst 192.168.2.10 src 192.168.1.10
Add "pcap rx | tx trace ... filter" to use the current classify filter chain
Patch includes sphinx documentation and doxygen tags.
Next step: device-driver integration
Type: feature
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I05b1358a769f61e6d32470e0c87058f640486b26
|
|
In eth_input_process_frame(), destination MAC addresses are
compared to the interface hardware address in a loop. Move
this to a separate inline function to facilitate making changes
to the filtering logic more cleanly.
Type: refactor
Change-Id: I0978f01667e78af5214dbbc9ba223f5b84ce6b7e
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
In eth_input_process_frame(), a loop which checks the destination
MAC address of received packets had a different condition for avx2
than it did for the non-avx2 version of the loop. It could result
in one unnecessary execution of the loop body after all packets
had been processed.
Type: fix
Fixes: 8d6f34e2b1cbfde5702e88686631527d5e1e10a0
Change-Id: Ib673f45917a0dea461987fdc8f0ca318b749fb1a
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
worker threads
Type: fix
Change-Id: Ie9a3a78b45b53344a0a5d7e2027c0e0354a49ebe
Signed-off-by: Wei CHEN <weichen@astri.org>
|
|
Type: fix
Ticket: VPP-1649
Change-Id: I93a393eca80065c379035478500e75e855f39b12
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
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>
|