summaryrefslogtreecommitdiffstats
path: root/src/vnet/devices/tap/tap.c
AgeCommit message (Collapse)AuthorFilesLines
2019-12-11devices: tap API cleanupJakub Grajciar1-8/+20
Use consistent API types. Type: fix Change-Id: I11cc7f6347b7a60e5fd41e54f0c7994e2d81199f Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
2019-12-04gso: remove the interface countMohsin Kazmi1-7/+0
Type: refactor Change-Id: I51405b9d09fb6fb03d08569369fdd4e11c647908 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-11-25tap: fix coverity warning 205875Andrew Yourtchenko1-1/+6
check the return result from fcntl, and if error, behave the same way the expansion of _IOCTL macro does. Type: fix Change-Id: I6d537d1bdedae64470612aef64b46e07387fe84b Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2019-11-20tap: multiqueue supportDamjan Marion1-123/+242
Type: feature Change-Id: I7dcc8c6911d02729b3bda1b3a21a211c82c3b949 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-11-08tap: add check for vhost-net backendDamjan Marion1-0/+9
Type: feature Change-Id: I402f4c88dee70fbb0b3b61dc4e0a4034d24d8b56 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-10-30docs: devices-- add FEATURES.yamlPaul Vinciguerra1-1/+1
Type: docs Change-Id: I039ba9ad5385452b202366fba0b367506a21ea4f Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
2019-09-06tap: revert clean-up when linux will delete the tap interfaceMohsin Kazmi1-42/+0
Type: fix Ticket: VPP-1766 revert e4ac48e792f4eebfce296cfde844ee73b1abd62f Change-Id: I03feea4008a47859d570ad8d1d08ff3f30d139ef Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com> (cherry picked from commit 623a1b7053424b539a51faf866ab839d3da3f45b)
2019-09-03tap: fix tap interface not working on Arm issueLijian.Zhang1-1/+6
The VPP code tries to set all userspace memory in the table via IOCTL to VHOST_SET_MEM_TABLE. But on aarch64, the userspace address range is larger (48 bits) than that on x86 (47 bits). Below is an segment from /proc/[vpp]/maps. fffb41200000-fffb43a00000 rw-s 00000000 00:0e 532232 /anon_hugepage (deleted) Instead of setting all userspace memory space to vhost-net, will only set the address space reserved by pmalloc module during initialization. Type: fix Change-Id: I91cb35e990869b42094cf2cd0512593733d33677 Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com> Reviewed-by: Steve Capper <Steve.Capper@arm.com>
2019-07-30tap: fix segv when host-if-name is not givenMohsin Kazmi1-8/+10
Type: fix Fixes: c30d87e6139c64eceade54972715b402c625763d Change-Id: I86b606b18ff6a30709b7aff089fd5dd00103bd7f Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-07-24tap: print the interface name on cli when createdMohsin Kazmi1-0/+1
Type: feature Change-Id: If11f00574322c35c1780c31d5f7b47d30e083e35 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-07-23api: binary api cleanupDave Barach1-2/+4
Multiple API message handlers call vnet_get_sup_hw_interface(...) without checking the inbound sw_if_index. This can cause a pool_elt_at_index ASSERT in a debug image, and major disorder in a production image. Given that a number of places are coded as follows, add an "api_visible_or_null" variant of vnet_get_sup_hw_interface, which returns NULL given an invalid sw_if_index, or a hidden sw interface: - hw = vnet_get_sup_hw_interface (vnm, sw_if_index); + hw = vnet_get_sup_hw_interface_api_visible_or_null (vnm, sw_if_index); if (hw == NULL || memif_device_class.index != hw->dev_class_index) return clib_error_return (0, "not a memif interface"); Rename two existing xxx_safe functions -> xxx_or_null to make it obvious what they return. Type: fix Change-Id: I29996e8d0768fd9e0c5495bd91ff8bedcf2c5697 Signed-off-by: Dave Barach <dave@barachs.net>
2019-07-18tap: fix memory errors with create/delete APIBenoît Ganne1-7/+9
CLI allocates vectors consumed by tap_create_if(), whereas API pass null-terminated C-strings allocated on API segment. Do not try to be too clever here, and just allocate our own private copies. Type: fix Fixes: 8d879e1a6bac47240a232893e914815f781fd4bf Ticket: VPP-1724 Change-Id: I3ccdb8e0fcd4cb9be414af9f38cf6c33931a1db7 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2019-06-28tap: fix memory errors in create/deleteBenoît Ganne1-1/+5
If the host interface name is not specified at creation, host_if_name was wrongly set to a stack-allocated variable. Make sure it always points to a heap allocated vector. At deletion time, we must free all allocated vectors. Type:fix Change-Id: I17751f38e95097998d51225fdccbf3ce3c365593 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2019-06-20tap: add support to configure tap interface host MTU sizeMohsin Kazmi1-0/+47
This patch adds support to configure host mtu size using api, cli or startup.conf. Type: feature Change-Id: I8ab087d82dbe7dedc498825c1a3ea3fcb2cce030 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-05-28tap: crash in multi-thread environmentMohsin Kazmi1-4/+0
In tap tx routine, virtio_interface_tx_inline, there used to be an interface spinlock to ensure packets are processed in an orderly fashion clib_spinlock_lock_if_init (&vif->lockp); When virtio code was introduced in 19.04, that line is changed to clib_spinlock_lock_if_init (&vring->lockp); to accommodate multi-queues. Unfortunately, althrough the spinlock exists in the vring, it was never initialized for tap, only for virtio. As a result, many nasty things can happen when running tap interface in multi-thread environment. Crash is inevitable. The fix is to initialize vring->lockp for tap and remove vif->lockp as it is not used anymore. Change-Id: I82b15d3e9b0fb6add9b9ac49bf602a538946634a Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com> (cherry picked from commit c2c89782d34df0dc7197b18b042b4c2464a101ef)
2019-04-17tap: clean-up when linux will delete the tap interfaceMohsin Kazmi1-0/+42
When container is deleted which has tap interface attached, Linux also delete the tap interface leaving the VPP side of tap. This patch does a clean up job to remove that VPP side of tap interface. To produce the behavior: In VPP: create tap On linux: sudo ip netns add ns1 sudo ip link set dev tap0 netns ns1 sudo ip netns del ns1 Change-Id: Iaed1700073a9dc64e626c1d0c449f466c143f3ae Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-04-15tap: fix the crashMohsin Kazmi1-0/+3
Crash will happen when someone will try to setup a tap interface in host namespace without providing the host side of tap interface custom name. This patch fixes the problem by using the default name in this case. Change-Id: Ic1eaea5abd01bc6c766d0e0fcacae29ab7a7ec45 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-04-03virtio: Add support for multiqueueMohsin Kazmi1-12/+27
Change-Id: Id71ffa77e977651f219ac09d1feef334851209e1 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-03-28Add RDMA ibverb driver pluginBenoît Ganne1-10/+2
RDMA ibverb is a userspace API to efficiently rx/tx packets. This is an initial, unoptimized driver targeting Mellanox cards. Next steps should include batching, multiqueue and additional cards. Change-Id: I0309c7a543f75f2f9317eaf63ca502ac7a093ef9 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2019-02-22tapv2: coverity strikes backSteven Luong1-5/+4
while https://gerrit.fd.io/r/#/c/16590/ fixed the leaked fd which coverity reported at that time, new coverity run reports simailar leaked fd in a different goto punt path. It would be nice if coverity reported both of them at the same time. Or perhaps it did and I just missed it. Anyway, the new fix is to put the close (fd) statement prior to the return of tap_create_if routine which should catch all goto's. Change-Id: I0a51ed3710e32d5d74c9cd9b5066a667153e2f9d Signed-off-by: Steven Luong <sluong@cisco.com>
2019-02-19tap gso: experimental supportAndrew Yourtchenko1-0/+65
This commit adds a "gso" parameter to existing "create tap..." CLI, and a "no-gso" parameter for the compatibility with the future, when/if defaults change. It makes use of the lowest bit of the "tap_flags" field in the API call in order to allow creation of GSO interfaces via API as well. It does the necessary syscalls to enable the GSO and checksum offload support on the kernel side and sets two flags on the interface: virtio-specific virtio_if_t.gso_enabled, and vnet_hw_interface_t.flags & VNET_HW_INTERFACE_FLAG_SUPPORTS_GSO. The first one, if enabled, triggers the marking of the GSO-encapsulated packets on ingress with VNET_BUFFER_F_GSO flag, and setting vnet_buffer2(b)->gso_size to the desired L4 payload size. VNET_HW_INTERFACE_FLAG_SUPPORTS_GSO determines the egress packet processing in interface-output for such packets: When the flag is set, they are sent out almost as usual (just taking care to set the vnet header for virtio). When the flag is not enabled (the case for most interfaces), the egress path performs the re-segmentation such that the L4 payload of the transmitted packets equals gso_size. The operations in the datapath are enabled only when there is at least one GSO-compatible interface in the system - this is done by tracking the count in interface_main.gso_interface_count. This way the impact of conditional checks for the setups that do not use GSO is minimized. "show tap" CLI shows the state of the GSO flag on the interface, and the total count of GSO-enabled interfaces (which is used to enable the GSO-related processing in the packet path). This commit lacks IPv6 extension header traversal support of any kind - the L4 payload is assumed to follow the IPv6 header. Also it performs the offloads only for TCP (TSO - TCP segmentation offload). The UDP fragmentation offload (UFO) is not part of it. For debug purposes it also adds the debug CLI: "set tap gso {<interface> | sw_if_index <sw_idx>} <enable|disable>" Change-Id: Ifd562db89adcc2208094b3d1032cee8c307aaef9 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2019-02-06virtio: Use new buffer optimizationMohsin Kazmi1-0/+1
Change-Id: Ifc98373371b967c49a75989eac415ddda1dcf15f Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2019-01-21virtio: Native virtio driverMohsin Kazmi1-8/+18
Change-Id: Id7fccf2f805e578fb05032aeb2b649a74c3c0e56 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2018-12-22tapv2: coverity woeSteven1-2/+4
coverity complains about fd leaking inside the if statement because there is a goto which bypasses the statement close (fd). The fix is to close (fd) immediately after it is no longer used. Change-Id: Ic5035b07ec1f179ff3db77744843e47aa8067a3c Signed-off-by: Steven <sluong@cisco.com>
2018-10-23c11 safe string handling supportDave Barach1-5/+5
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-05-18tap: remove the local vlib_log_info definitionMohsin Kazmi1-9/+3
Change-Id: Idff55a19d27fed0d57e222f38d2e16c5367911cb Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2018-04-27TAP memory leaks:Neale Ranns1-23/+15
1 - use bit-map to re-use ID values and thus VLIB nodes 2 - free vrings 3 - free hw_address on HW interface delete (a HW * struct is memset on pool_get) 4 - free temporary node names during TX node setup Change-Id: Id114c8bb9c844fd4ceb02fbbeb4b511ecfeb61ce Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-04-17Add logging supportDamjan Marion1-0/+9
Change-Id: Ieac9cf50156dbbb4962411e900d59256441915ef Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Klement Sekera <ksekera@cisco.com>
2018-03-02tapv2: CLI and binary API fixesSteven1-2/+2
1. When interface create encouners an error (see test below), the same id cannot be used again. This is due to hash_set is called too early in the function. After the hash entry is set, there are different errors may cause the interface create to be aborted. But we didn't remove the hash entry when error is encountered. The fix is to move the hash_set call near the end which has no more "goto error" DBGvpp# create tap id 1 rx-ring-size 1021 tx-ring-size 1021 create tap id 1 rx-ring-size 1021 tx-ring-size 1021 create tap: ring size must be power of 2 DBGvpp# create tap id 1 rx-ring-size 1024 tx-ring-size 1024 create tap id 1 rx-ring-size 1024 tx-ring-size 1024 create tap: interface already exists DBGvpp# 2. multiple issues exist with api_format.c with the below command binary-api tap_create_v2 id 4 hw-addr 90:e2:ba:76:cf:2f rx-ring-size 1024 tx-ring-size 1024 - hw_addr is not taken due to the test for random mac is inverted - id is an integer, not a string - integer values were not converted to network format Change-Id: I5a669d702a80ad158517df46f0ab089e4d0d692e Signed-off-by: Steven <sluong@cisco.com>
2018-02-28tapv2: abort in tap_create_if (VPP-1179)Steven1-0/+1
The following command sequences cause the crash: create tap id 0 rx-ring-size 1024 tx-ring-size 1024 create tap id 1 rx-ring-size 1024 tx-ring-size 1024 set interface state tap0 up set interface state tap1 up delete tap tap0 delete tap tap1 create tap id 0 rx-ring-size 1024 tx-ring-size 1024 0: /home/sluong/vpp2/vpp/build-data/../src/vnet/interface_funcs.h:46 (vnet_get_hw_interface) assertion `! pool_is_free (vnm->interface_main.hw_interfaces, _e)' fails The reason for the crash is because when the tap interface is deleted, the code does not remove the entry from the device queue. But the interface is deleted anyway from vnet_main.interface_main.hw_interfaces. When an interface is created again, it may encounter the deleted entry in the device queue and crash. Notice create and delete a single entry does not cause a crash. Need to create and delete 2 interfaces to create a "hole" in the device queue. Change-Id: I42ce0b7943d73b3eab32a16751a0a3183de62d9f Signed-off-by: Steven <sluong@cisco.com>
2018-02-19virtio: add missing tx lock when running multithreadedDamjan Marion1-0/+4
Change-Id: I373f429c53c6f66ad38322addcfaccddb7761392 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-01-18tapv2: add option to set host-side default gwDamjan Marion1-0/+20
Change-Id: I76fd655ecd9445299b94b3b5af10e7b1588584e4 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-01-16tapv2: deleting tap interface may leak buffers (VPP-1124)Steven1-2/+2
Buffers may be allocated for indirect descriptors by tx thread and they are freed when tx thread is invoked in the next invocation. This is to allow the recipient (kernel) to have a chance to process them. But if the tap interface is deleted, the tx thread may not yet be called to clean up the indirect descriptors' buffers. In that case, we need to remove them without waiting for the tx thread to be called. Failure to do so may cause buffers leak when the tap interface is deleted. For the RX ring, leakage also exists for vring->buffers when the interface is removed. Change-Id: I3df313a0e60334776b19daf51a9f5bf20dfdc489 Signed-off-by: Steven <sluong@cisco.com> (cherry picked from commit d8a998e74b815dd3725dfcd80080e4e540940236)
2017-12-14tap_v2: include host-side parameters in the dump binary APIMilan Lenco1-2/+42
Change-Id: I097a738b96a304621520f1842dcac7dbf61a8e3f Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
2017-12-10tap_v2: fix issues reported by coverityDamjan Marion1-3/+3
Change-Id: I1bbd3f6ece255edfd4ebf268ac60f79dce1d10e7 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-12-08tapv2: multiple improvementsDamjan Marion1-28/+149
- change interface naming scheme - rework netlink code - add option to set link address, namespace Change-Id: Icf667babb3077a07617b0b87c45c957e345cb4d1 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-12-04tap_v2: move code to vnet/devices/tapDamjan Marion1-0/+352
virtio backend stays in vnet/devices/virtio Change-Id: Idbf04f1c645a809ed408670ba330662859fe9309 Signed-off-by: Damjan Marion <damarion@cisco.com>