Age | Commit message (Collapse) | Author | Files | Lines |
|
- hashCode & equals
- toString
Change-Id: I5f8bc8868c216862a307dcc8f6b423f0ce29e7b5
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
|
|
Change-Id: If03efcea871641e33fa079d3c1c308dc8e23cdcc
Signed-off-by: Keith Burns (alagalah) <alagalah@gmail.com>
|
|
jvpp_common.la
Change-Id: I886d087532d20bf7e6555da44e4e75ee0ca38268
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|
|
Change-Id: I98e5bdbd0472c2973885defe2712b53d9da8a536
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Splits jvpp into two jars
jvpp-registry.jar - base jvpp functionality
jvpp-core.jar - Java wrapper for vpe.api
Plugins can be generated the same way jvpp-core.jar is.
Example (nsh):
https://gerrit.fd.io/r/#/c/2118/
Change-Id: I2254f90b2c3e423563bb91bf70877979f1e90a7d
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: I2254f90b2c3e423563bb91bf70877979f1e86a6b
Signed-off-by: Ed Warnicke <eaw@cisco.com>
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
- updates jvpp generator to raise exception
if array[0] is present in reply/detail/counter message
- fixes vpe.api reply/detail/counter messages
that use incorrect variable array syntax.
Additional info:
Variable arrays in reply/detail/counter messages needs to have
lenght defined in other variable within the message.
The other variable can have any name, so it is impossible to
generate Java/Python code handling.
New syntax introduced by
https://gerrit.fd.io/r/#/c/1617/
fixes the problem:
u32 some_var;
XX array[some_var];
Change-Id: I0af50f1ef1d94d95b56d9326d4e944e72b4edcdd
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: Ieb5182a7a3612e09bd2b28eb6a4abbdb4d29d34b
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: I239082622ceabdd1d0a7b6b6489a2789096a01fc
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: I8d746cfae4d64ae200ff0053de23b80ee951c290
Signed-off-by: Keith Burns (alagalah) <alagalah@gmail.com>
|
|
MANUAL_JAVA flag (used only by the japi)
was also removed.
Change-Id: Ied21521b2410af1c357afb04cbf9e849632ddc5f
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
The information is aleardy stored in array.length field, but
vpe.api syntax should be uniform.
Change-Id: Id84cd95c088281609c70548346cf0e408a6f49ff
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Also enable silent rules where missing
Change-Id: Ia521886815c862b013f01df4cc18fd8a298aaaa1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I6dda9eb8d58a2bc9a1e4d6636688dfa1f8bb88c6
Signed-off-by: Jan Srnicek <jan.srnicek@pantheon.tech>
|
|
* provides length information for variable length arrays
in classify table/sessione reply messages
* provides jvpp example for reading classify tables/sessions
Change-Id: I47f8fca5c849ec874d4e23f28177e310689db522
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Install vpp api header files in /usr/include/vpp-api, instead of
/usr/include/api. Someone will eventually complain if we continue with
the status quo.
Generate /usr/bin/vpp_plugin_configure, to correctly configure
standalone plugin compilation against header files installed from the
dev package.
If a plugin's CFLAGS don't precisely match the installed vpp engine
binary, subtle misbehavior can and will occur. Example: the ip4/ip6
main_t structure size / member offsets depend on DPDK=[0|1]. Screw
that one up, and your brand-new configurable ip feature will
mysteriously fail to appear, even though the plugin loads perfectly.
Change-Id: I20c97fe1042808a79935863209d995c31953b98c
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
* extends VPP's message definition language with the following syntax:
u32 count:
u8 array[count];
which is traslated to:
u32 count;
u8 array[0];
but now, python API representation generated by vppapigen
contains information about where the array length is stored.
* modifies existing response messages to use the new syntax
Change-Id: I68210bc7a3a755d03d067e9b79a567f40e2d31f3
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
- add notification DTOs to JVpp
- add notification callbacks
- add notification registry
- provide/implement notification registry from future and callback facades
Change-Id: I1060ef2ec8ba1eb2e8cff279c93b73aa7c9f9aee
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
|
|
Send calls throws VppInvocationException on failure
Failed requests (negative retval) reported over onError callback interface method
Removed retval attributes from dto/xxxReply.java calls
Change-Id: Ibd4e90c320d080e02d75b4bd056a7b11c8e37aa7
Signed-off-by: Tibor Sirovatka <tsirovat@cisco.com>
|
|
Change-Id: I4d52c113336deac80dfcbad91b21a7a70eea2213
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
|
|
Change-Id: I9fd0cd49e4636d5d8978567fa914487785035c8a
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: I6e5ed2562c65dde6c9f6f085c8b9d40f80684894
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: Ic67b3c0623d98c5ee3f1ffa1e1bd9cfb96b233bd
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Simplified construction, autoconnected; possible connect/close
See updated sample test cases with changed interface usage
Change-Id: Ib53e855880bc414868aa2b9bb8f5df086917e375
Signed-off-by: Tibor Sirovatka <tsirovat@cisco.com>
|
|
The nature of Java artifact versioning is different
that rpm/apt versioning in that artifacts are
traditionally numbered:
${NEXT_RELEASE_NUMBER)-SNAPSHOT
This patch sets ${NEXT_RELEASE_NUMBER) correctly for master.
Change-Id: Iab34c26c7440d5e04d6d05f46598832e9adf6920
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|
|
+ Fail build when JVpp does not compile
Change-Id: I4ad3ffb5d7ff6edaad89de66a9f0bd79a14fb690
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
|
|
Review changes incorporated
Change-Id: Ia04b62144a0d3643095b518db538c7eb5137c048
Signed-off-by: Tibor Sirovatka <tsirovat@cisco.com>
|
|
Added jclass reference caching and updated JNI version to 1.8
Change-Id: Ie8dbbd4b91b90bf9e4e9a6148313e46056b0d67e
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
|
|
Change-Id: Ibca8fc8c1962ca36d91898c1523afb2df6dfdc49
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
|
|
These specific methods remove the need for casting on client
side code while using generic send method
Change-Id: Ic0240359333831b676a7d205f63ac1c3f3f8af4c
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
|
|
Added comments generation for C and Java files.
Change-Id: Ifb670a5592eb871bfe68804f0a8d8f9b5b14f00a
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|
|
The old japi has two main drawbacks:
* it is not fully generated (requres manual coding for
every new api call that returns data other thanstatus code)
* it is not asynchronous from Java perspective (requires
active wait loops - big overhead due to JNI boundary being
crossed lots of times).
The new api is lightweight (fully generated except for connect,
disconenct and ping) and truly asynchronous (uses callbacks,
utilities that offer java.util.concurrent.Future interface
are also provided).
Change-Id: I531080ef651e8a74f19210490c71d161221ab600
Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|
|
Refactors the VXLAN node to work with both IPv4 and IPv6 transports.
There is a discussion thread for this change at
https://lists.fd.io/pipermail/vpp-dev/2016-March/000279.html
Note that this changes the binary configuration API to support both
address families; each address uses the same memory for either address
type and a flag to indicate which is in use. This also includes changes
to the Java API to support both address families.
The CLI and VAT syntax remains unchanged; the code detects whether an
IPv4 or an IPv6 address was given.
Configuration examples:
IPv4 CLI: create vxlan tunnel src 192.168.1.1 dst 192.168.1.2
vni 10 encap-vrf-id 0 decap-next l2
IPv6 CLI: create vxlan tunnel src 2620:124:9000::1 dst 2620:124:9000::2
vni 16 encap-vrf-id 0 decap-next l2
IPv4 VAT: vxlan_add_del_tunnel src 192.168.1.1 dst 192.168.1.2
vni 10 encap-vrf-id 0 decap-next l2
IPv6 VAT: vxlan_add_del_tunnel src 2620:124:9000::1 dst 2620:124:9000::2
vni 16 encap-vrf-id 0 decap-next l2
TODO: The encap path is not as optimal as it could be.
Change-Id: I87be8bf0501e0c9cd7e401be4542bb599f1b6e47
Signed-off-by: Chris Luke <chrisy@flirble.org>
|
|
Change-Id: Ia504ccdac1deac20f20cf7fb76f78b2d8c505474
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I7a4bc4678fea723c35bbeac1b893c5c52235aa67
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I22cb443c4bd0bf298abb6f06e8e4ca65a44a2854
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
See: https://wiki.fd.io/view/VPP/Python_API
Change-Id: If135fc32208c7031787e1935b399d930e0e1ea1f
Signed-off-by: Ole Troan <ot@cisco.com>
|