Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
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: 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>
|