Age | Commit message (Collapse) | Author | Files | Lines |
|
This is complete rework of DPDK PCI initialization. It drops
previous scheme where lspci/route/awk/sed are used and instead
sysfs is solely used for discovering Ethernet PCI devices. Criteria
for blacklisting device is changed from exsiting routing table entry
to simple interface state obtained by SIOCGIFFLAGS ioctl().
It checks for IFF_UP flag, so as long as interface is declared
up and even when carrier is down interface will be blacklisted.
Change-Id: I59961ddcf1c19c728934e7fe746f343983741bf1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
The current mechanism for setting up arp-input and ip6-discover-neighbor
output nodes for interfaces using their interface link up/down callback
function is inefficient and has potential timing issue, as observed for
bonded interface. Now both nodes will setup output interface sw_if_index
in the the sw_if_index[VLIB_TX] field of current packet buffer and then
use the interface-ouput node to tx the packet.
One side effect is that vlib_node_add_next_with_slot() needs to be
modified to allow the same output node-id to be put at the specified
slot, even if another slot contain that same node-id already exist. This
requirement is caused by BVI support where all loopback interfaces set
up as BVIs will have the same output node-id being l2-input while, for
output-interface node, the output slot must match the hw_if_index of the
interface.
Change-Id: I18bd1d4fe9bea047018796f7b8a4d4c20ee31d6e
Signed-off-by: John Lo <loj@cisco.com>
|
|
Change-Id: I42b26c8f95c17577006f13e3419b8ccc9ef7c4f3
Signed-off-by: Todd Foggoa <tfoggoa@cisco.com>
|
|
Change-Id: Idda59272a029ffcbc029f9bb167508d7bd5e6e21
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Without this, frames can be double-freed to nodes like "error-punt",
leading to buffer leaks and other problems.
Change-Id: Ie28a4f504254ee439f720dbaac7f12206cea753b
Signed-off-by: Todd Foggoa <tfoggoa@cisco.com>
|
|
I noticed while mucking about with lsof that vpp
was listening on port 5000.
telnet 0 5000 revealed that it was listening for
the cli on that port.
Digging into the code, it turns out that if you
do not configure cli-listen (Example:
unix {
cli-listen localhost:5002
}
)
Then vpp is listening on the first available port
starting at port 5000 anyway. This is a simple
patch to *not* listen unless configured to do so.
Change-Id: Id7f6f4d69e0a1642d2767849a90b21f38f21ecaa
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|
|
Change-Id: Ieacbfa4dbbfd13b38eaa2d37f618f212cef4e492
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ieb2e4043fc7bc3b4a5436a7a6aa35f573d8d4506
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I984debeffe0dce36c9e7ab963f25d862cc7550cc
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: If3fc88a35bc0b736376113a39667caea42802ea1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Do not propagate flags into cloned vlib_next_frame_t's.
vlib_next_frame_init(...) sets nf->frame_index to ~0. If it turns out
that the original flags include VLIB_FRAME_IS_ALLOCATED, the wheels
fall off. And so on.
Change-Id: I8de18653acfcc8eb20cee36f4eb5b9e82234f21b
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
This is 1st drop of VPP native driver for linux AF_PACKET.
New CLI:
create host-interface name <host-if-name> [hw-addr <mac-address>]
References:
- Documentation/networking/packet_mmap.txt in the Linux kernel tree
- man 7 packet
Known issues:
- attaching to linux bridge doesn't work
- it is not expected to work in multicore setup
Change-Id: I1cb1c3d305f349759e90e76e25696718b73bd73d
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
The VLIB_FRAME_NO_FREE_AFTER_DISPATCH flag is not preserved when cloning
next_frames, as a result VLIB_FRAME_FREE_AFTER_DISPATCH can
erroneously be set for a frame (see vlib_get_next_frame_internal())
Change-Id: Ice1d7ddcb807e1168aa0c157d9474be492d102c2
Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
|
|
Change-Id: I3a0726d7645f775738253d0a47ee04d94d138c9a
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
It turns out that unix_physmem_init(...) has been effectively disabled
for a very long time. The vnet library supplied a weak symbol override
for the vlib_app_physmem_init(...) which returned 1, meaning "do
nothing." When we switched libvnet.a -> libvnet.so, the symbol
override stopped working.
Presto: unix_physmem_init(...) romps all over the data set up by
vlib_buffer_pool_create(...), leading to ASSERT failures and/or bus
errors, but only when using worker threads. Even then, the failure
depended in some complicated way on library dynamic load order.
We should remove .../vlib/vlib/unix/physmem.c entirely once we're sure
we'll never want it back.
Change-Id: I27747edbeb0de88d2f2d8728f7f8eb3135e7f0cf
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
This avoids checking the buffer flags bit if tracing is not enabled.
Change-Id: I32e1a90b5fd10318254c611344488bc2a441c71e
Signed-off-by: Todd Foggoa (tfoggoa) <tfoggoa@cisco.com>
|
|
Change-Id: Icaa71957f67b923bc9795baa78c7495055615672
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Turn of srp, mainly as an example of how to restructure a featurette
for selective disablement.
Change-Id: Id3364c58a8711b103939f4434adfa67177380f67
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
This code provided inter-VM (2 cores per VM) throughput of
22Gbps using iperf through VPP (1 core) with 9k frames.
With the same setup and pktgen running on both sides, it
reached 5Mpps with no packets drop (Equivalent to before the patch).
During the tests the average vector length was about 1, which
likely means that VPP is not the bottleneck.
The patch also includes some generic functions for vlib buffers
allowing for chained buffer construction whether or not DPDK is enabled.
Change-Id: Icfd1803e84b2b4578f305ab730576211f6242d6a
Signed-off-by: Pierre Pfister <ppfister@cisco.com>
|
|
It also includes check to ensure that number of
per-cpu mheaps is not lower than number of cpus.
Change-Id: Ibc68b34dda130f922243f9ea15b03e44bbcac269
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Iac68b38dda1a0f9e2242f9eab5b03e44bbcac269
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Icfd91cca3cd686e5efa8a988f04483238605e1cb
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I642c4b8e83dd07708658a10ad46e9fd2c28a7f1f
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I7b0aa42a61607d4d30fe3627032d3837b2838982
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I4b65b29f9291b3fd47e05576d9a0789af8912982
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
does not close the socket. Resulting in the main thread being stuck
in a tight infinite loop polling on the erronous socket.
Change-Id: I630b84b97c059acce117d56e41cd201131db4cab
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
The DPDK glue did not support cloned packets which do not
have a freelist handler. Add support for this case.
Change-Id: I8f17cd4952df97989d90d3f3e39792bc3739705c
Signed-off-by: Kevin Paul Herbert <kph@cisco.com>
|
|
Limit buffer tracing to 50 in order to limit large output, unless
the user over rides the max "sh trace max <number>".
Add trace filtering, to be able to only trace packets that were
processed by a specific node or exclude packets processed by a node.
Example, only include packets processed by error-drop:
# trace filter include error-drop 1
# trace add dpdk-input 1000000
<wait for packets, to come in>
# show trace
Change-Id: I5d9e15d2268ea55e6ef87b2b8756049c49b2791b
Signed-off-by: Todd Foggoa <tfoggoa@cisco.com>
|
|
Change-Id: I53730fd2ccd78fb73e11af77f8ffff19d75ebd95
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Add some more ASSERTs to track down improper frees.
Change-Id: I2bd4b69fb14f522c82e6006131b6ad982f6f7e6b
Signed-off-by: Kevin Paul Herbert <kph@cisco.com>
|
|
output is certain to contain a NULL byte.
Change-Id: Id80e1334d7a2cb6788f1db33cde142f84826db36
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ib0a05f9d1b08bacef09f6d7c101391737031ee0d
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I0834eac9c17941d3d5b2aa5791d6deaabd8f6977
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|
|
Change-Id: Ifb2de64347526e3218e22067452f249ff878fd32
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I30db8f678b14303a64ad3aaa16b5caf9081603d8
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
This fixed performance issue in muti-threaded setup
due to sharing of the same cacheline between multiple threads
Change-Id: I930ee44c17a83d4da350d15b4b97b8bb4633a9b0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I7f23b8b8e5136cb56768bac3a7473e6df5ee4993
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I05895827ed52be292112484cee7d0a2591b67335
Signed-off-by: Matus Fabian <matfabia@cisco.com>
|
|
Change-Id: Ib246f1fbfce93274020ee93ce461e3d8bd8b9f17
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|