summaryrefslogtreecommitdiffstats
path: root/src/vnet/devices/tap/tap.h
AgeCommit message (Collapse)AuthorFilesLines
2019-06-20tap: add support to configure tap interface host MTU sizeMohsin Kazmi1-0/+6
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-02-19tap gso: experimental supportAndrew Yourtchenko1-0/+3
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-01-07tapv2: add "tap_flags" field to the TAPv2 interface APIAndrew Yourtchenko1-0/+2
Change-Id: I26f99d95f52c9fe107d17dcbbf5c6185523beade Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2018-04-27TAP memory leaks:Neale Ranns1-3/+3
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/+3
Change-Id: Ieac9cf50156dbbb4962411e900d59256441915ef Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Klement Sekera <ksekera@cisco.com>
2018-01-18tapv2: add option to set host-side default gwDamjan Marion1-0/+4
Change-Id: I76fd655ecd9445299b94b3b5af10e7b1588584e4 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-12-14tap_v2: include host-side parameters in the dump binary APIMilan Lenco1-2/+13
Change-Id: I097a738b96a304621520f1842dcac7dbf61a8e3f Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
2017-12-08tapv2: multiple improvementsDamjan Marion1-3/+11
- 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/+63
virtio backend stays in vnet/devices/virtio Change-Id: Idbf04f1c645a809ed408670ba330662859fe9309 Signed-off-by: Damjan Marion <damarion@cisco.com>