Age | Commit message (Collapse) | Author | Files | Lines |
|
If the corresponding vpp plugin is absent, return a non-zero
clib_error_t * from vat_plugin_register ("xxx plugin not loaded"). The
vat plugin calls dlclose on the vat plugin, and it disappears.
Depending on the plugin configuration, this can reduce the vpp virtual
size by several gigabytes.
Added a VAT_PLUGIN(<plugin-name>) macro to vat_helper_macros, clean up
boilerplate vat_plugin_register() implementations. Fixed a number of
non-standard vat_plugin_register methods.
Type: refactor
Change-Id: Iac908e5af7d5497c78d6aa9c3c51cdae08374045
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
The VAT calls to MEMIF_SOCKET_FILENAME_ADD_DEL erroneously
cleared the message memory after the M() macro call and
thus lost their message id. Don't do that.
While in the neighborhood, prevent a string copy from
referencing data that doesn't belong to the filename string.
Change-Id: Ib4309608ed617ef4f193880ecf4a0b35fda65e51
Signed-off-by: Jon Loeliger <jdl@netgate.com>
|
|
New API calls and corresponding CLI commands allow the user
to manage the socket filenames for memif connections using:
vppctl# create memif id <u32> filename <socket-filename>
vppctl# delete memif id <u32>
and then referencing it later in a memif interface:
vppctl# create memif <u32> socket-id <id> mode <mode> <master|slave> ...
Corresponding VAT cli entries have also been added.
The default memif socket file at id 0 are still always present.
The existing memif create/delete CLI commands have been slightly
altered into the new syntax:
vppctl# create interface memif ...
vppctl# delete interface memif ...
Change-Id: If2bdc7eac3d81e1d9011a5869747e52fc5e11639
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
If I remember correctly, I added the interface name filter catalog to
avoid cluttering up the vat interface table with [unused] packet
generator interfaces. Since we no longer create pg interfaces we're
not planning to use, the filter catalog does more harm than
good. Every new interface name prefix would have had to be added to
the list, and folks wouldn't likely know they should do that...
Change-Id: I4067f8ba70ad13c8dc5ebaf21a23759a2cf2675e
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
- separate client/server code for both memory and socket apis
- separate memory api code from generic vlib api code
- move unix_shared_memory_fifo to svm and rename to svm_fifo_t
- overall declutter
Change-Id: I90cdd98ff74d0787d58825b914b0f1eafcfa4dc2
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
- Teach vpp_api_test to send/receive API messages over sockets
- Add memfd-based shared memory
- Add api messages to create memfd-based shared memory segments
- vpp_api_test supports both socket and shared memory segment connections
- vpp_api_test pivot from socket to shared memory API messaging
- add socket client support to libvlibclient.so
- dead client reaper sends ping messages, container-friendly
- dead client reaper falls back to kill (<pid>, 0) live checking
if e.g. a python app goes silent for tens of seconds
- handle ping messages in python client support code
- teach show api ring about pairwise shared-memory segments
- fix ip probing of already resolved destinations (VPP-998)
We'll need this work to implement proper host-stack client isolation
Change-Id: Ic23b65f75c854d0393d9a2e9d6b122a9551be769
Signed-off-by: Dave Barach <dave@barachs.net>
Signed-off-by: Dave Wallace <dwallacelf@gmail.com>
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
While mode ip is supported via the CLI for creating a memif interface,
it is not settable from the binary API due to missing code.
While at it, update the help usage to include the missing keyword secret.
Change-Id: Ia9c71f4017210a5e1733ce4992fbb566b7d20c1a
Signed-off-by: Steven <sluong@cisco.com>
|
|
Change-Id: I4b1f27b95d67d48b7a13750ff8754c344ed7afa7
Signed-off-by: Chris Luke <chrisy@flirble.org>
|
|
Change-Id: I4d41def83a23f13701f1ddcea722d481e4c85cbc
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I01dc439fc84f9213e55ba56982eff34474637115
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
|