summaryrefslogtreecommitdiffstats
path: root/src/vnet/geneve/geneve_api.c
AgeCommit message (Collapse)AuthorFilesLines
2019-12-10api: multiple connections per processDave Barach1-1/+1
Type: feature Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I2272521d6e69edcd385ef684af6dd4eea5eaa953
2019-10-10geneve: API cleanupJakub Grajciar1-16/+13
Use consistent API types. Type: fix Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com> Change-Id: I1964e4f0afe6f030ae9c8e28fcba5fd81aa1f130
2019-04-08fixing typosJim Thompson1-1/+1
Change-Id: I215e1e0208a073db80ec6f87695d734cf40fabe3 Signed-off-by: Jim Thompson <jim@netgate.com>
2018-10-23c11 safe string handling supportDave Barach1-1/+1
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-01-11api: remove transport specific code from handlersFlorin Coras1-10/+8
This does not update api client code. In other words, if the client assumes the transport is shmem based, this patch does not change that. Furthermore, code that checks queue size, for tail dropping, is not updated. Done for the following apis: Plugins - acl - gtpu - memif - nat - pppoe VNET - bfd - bier - tapv2 - vhost user - dhcp - flow - geneve - ip - punt - ipsec/ipsec-gre - l2 - l2tp - lisp-cp/one-cp - lisp-gpe - map - mpls - policer - session - span - udp - tap - vxlan/vxlan-gpe - interface VPP - api/api.c OAM - oam_api.c Stats - stats.c Change-Id: I0e33ecefb2bdab0295698c0add948068a5a83345 Signed-off-by: Florin Coras <fcoras@cisco.com>
2018-01-09api: refactor vlibmemoryFlorin Coras1-2/+2
- 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>
2017-10-06Initial GENEVE TUNNEL implementation and tests.Marco Varlese1-0/+237
Notes on this first implementation: * First version of the implementation does NOT support GENEVE OPTIONS HEADER: it isn't well understood what the purpose of the OPTIONS will be and/or what content would be placed in the variable option data; Once the IETF work will evolve and further information will be available it could be possible to modify the frame rewrite to contemplate the actual GENEVE OPTIONS. Change-Id: Iddfe6f408cc45bb0800f00ce6a3e302e48a4ed52 Signed-off-by: Marco Varlese <marco.varlese@suse.com>