summaryrefslogtreecommitdiffstats
path: root/src/vnet/interface_cli.c
AgeCommit message (Collapse)AuthorFilesLines
2021-01-21interface: rx queue infra rework, part oneDamjan Marion1-20/+69
Type: improvement Change-Id: I4008cadfd5141f921afbdc09a3ebcd1dcf88eb29 Signed-off-by: Damjan Marion <damarion@cisco.com>
2020-12-15classify: add pcap/trace classfier mgmt API callsJon Loeliger1-5/+3
Add lookup/get/set API calls to manage both PCAP and Trace filtering Classifier tables. The "lookup" call may be used to identify a Classifier table within a chain of tables taht matches a particular mask vector. For efficiency, this call should be used to determine to which table a match vector should be added. The "get" calls return the first table within a chain (either a PCAP or the Trace) set of tables. The "set" call may be used to add a new table to one such chain. If the "sort_masks" flag is set, the tables within the chain are ordered such that the most-specific mask is first, and the least-specific mask is last. A call that "sets" a chain to ~0 will delete and free all the tables with a chain. The PCAP filters are per-interface, with "local0", (that is, sw_if_index == 0) holding the system-wide PCAP filter. The Classifier used a reference-counted "set" for each PCAP or trace filter that it stored. The ref counts were not used, and the vector of tables was only used temporarily to establish a sorted order for tables based on masks. None of that complexity was actually warranted, and where it was used, the same could be achieved more simply. Type: refactor Signed-off-by: Jon Loeliger <jdl@netgate.com> Change-Id: Icc56116cca91b91c631ca0628e814fb53f3677d2
2020-12-14misc: refactor clib_bitmap_foreach macroDamjan Marion1-6/+6
Type: refactor Change-Id: I077110e1a422722e20aa546a6f3224c06ab0cde5 Signed-off-by: Damjan Marion <damarion@cisco.com>
2020-12-14misc: move to new pool_foreach macrosDamjan Marion1-10/+10
Type: refactor Change-Id: Ie67dc579e88132ddb1ee4a34cb69f96920101772 Signed-off-by: Damjan Marion <damarion@cisco.com>
2020-11-13ethernet: mac must support 64-bits loadsBenoît Ganne1-2/+2
ethernet dataplane loads MAC addresses as 64-bits loads for efficiency. We must make sure it is valid, especially for the vector of secondary MACs. Type: fix Change-Id: I851e319b8a973c154e85ff9f05f3b8e385939788 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-10-08interface: shorten vnet_hw_if_rx_modeDamjan Marion1-11/+11
This is part of bigger refactor. Type: refactor Change-Id: I6fc2c0a1e2d217a70952901bcf775b8485bd3c20 Signed-off-by: Damjan Marion <damarion@cisco.com>
2020-10-08l2: input performanceNeale Ranns1-21/+2
Type: improvement - cache the values form the BD on the input config to avoid loading - avoid the short write long read on the sequence number - use vlib_buffer_enqueue_to_next Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I33442b9104b457e4c638d26e9ad3bc965687a0bc
2020-09-09interface: support configuring RSS steering queuesChenmin Sun1-0/+83
This patch adds the RSS steering queues set interface, and it's implementation in DPDK device: /* Interface to set rss queues of the interface */ typedef clib_error_t *(vnet_interface_rss_queues_set_t) (struct vnet_main_t * vnm, struct vnet_hw_interface_t * hi, clib_bitmap_t *bitmap); This patch also introduces a command line to set the RSS queues: set interface rss queues <interface> <list <queue-list>> To display the rss queues, use "show hardware-interfaces" Below is the example to configure rss queues for interface Gig0: vpp# set interface rss queues Gig0 list 0,2,4-7 vpp# show hardware-interfaces brief Name Idx Link Hardware VirtualFunctionEthernet18/1/0 1 down VirtualFunctionEthernet18/1/0 Link speed: unknown RSS queues: 0 2 4 5 6 7 local0 0 down local0 Link speed: unknown vpp# Users can also configure the rss queues on a dpdk interface in startup.conf: dpdk { dev 0000:18:01.0 { rss-queues 0,2,5-7 } } Type: feature Signed-off-by: Chenmin Sun <chenmin.sun@intel.com> Change-Id: I1835595a1c54016a84eabee9fd62ce137935385d
2020-09-02misc: fix pcap [rx|tx|drop] filename stem overflowBenoît Ganne1-1/+1
Type: fix Change-Id: I2b6b7b6f28cbf7accf883743e390b0031dd13bbb Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-08-06misc: harmonize namesDave Barach1-1/+2
Type: fix Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: Ibad744788e200ce012ad88ff59c2c34920742454
2020-08-05interface: add pcap trace data preallocationDave Barach1-4/+46
Type: improvement Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I2e53fa85a0b4082666f57a3a58a09c04ae2001b5
2020-07-24interface: fix show/clear hardware-interfaces string overflowBenoît Ganne1-5/+19
Type: fix Change-Id: Iab99bc1f6c309fae6eaa714b484274fe7072a4cb Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-06-16interface: add minimal vpp pkt trace for error-dropDave Barach1-1/+1
Provide a minimal trace [ip4/ip6 src/dst address] for dropped pkts when the user specifies "trace add error-drop XXXX", but does not trace pkts from the original input node. This is a wireshark dissector problem. Packets thrown at error-drop may be well-formed, or not. VPP must not crash, no matter what. The minimal trace capture and decode could be enhanced. Anyone interested in doing that must consider all of the corner-cases involved. This version should be at least somewhat useful. Note that "pcap trace drop ..." - and the packet generator - seem like the right tools to use when researching more complex issues. Type: improvement Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I961ca133980ffa2a1e5707879a443b21442ed894
2020-01-27classify: pcap / packet trace debug CLI bugsDave Barach1-1/+1
"classify filter trace ... " and "classify filter pcap ..." are mutually exclusive. vnet_pcap_dispatch_trace_configure needs to check for set->table_indices == NULL. Type: fix Ticket: VPP-1827 Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I43733364087ffb0a43de92e450955033431d559d
2020-01-14classify: Reduce the include dependencies on vnet_classify.hNeale Ranns1-0/+1
Type: refactor currently vnet_classify.h is included in ip.h where it's not required. Change-Id: Id55682637601655aa2edda681536a979c8e323bd Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-12-19interface: Prevent bad inner-dot1q any exact-match configurationJon Loeliger1-3/+3
Someone much more knowledgeable than I wrote: For L3 IP forwarding, any VLAN tags on a packet must be exact match to a sub-interface which means both outer and inner VLAN tag IDs must be exact-matched to specific values defined of that sub-interface. Without exact match on a L3 sub-interface, VPP has no mechanism to know what VLAN tags to use for packet output, such as ARP request packets or IP packets, on that sub-interface. Thus, sub-interface with "inner-dot1q any" is not an exact match sub-interface by definition since no match is present on inner tag. While in the area, fix a memory leak that would ensue on poorly configured interfaces. Change-Id: I8d17a96dbca3e3724c297ecc935ca61764e6ce2e Type: fix Signed-off-by: Jon Loeliger <jdl@netgate.com>
2019-11-12interface: Allow VLAN tag-rewrite on non-sub-interfaces too.Jon Loeliger1-2/+26
This fix was first made in commit fdea5c6a00b74971dbb1b7ec4e25839a871006ca but was subsequently lost in commit 053204ab039d34a990ff0e14c32ce3b294fcce0e Added unit test for setting VTR on a non-sub-interface to help ensure no future regressions of this ability. Type: fix Change-Id: I71ce2684fb72383741455829ae2d397ea2e95eae Signed-off-by: Jon Loeliger <jdl@netgate.com>
2019-10-09interface: callback to manage extra MAC addressesMatthew Smith1-0/+152
Type: feature New callback vnet_hw_interface_add_del_mac_address(). Add or delete secondary MAC addresses on a hardware interface. This will allow packets to be processed which have a destination MAC address other than the primary programmed MAC address without needing to put the device into promiscuous mode. Change-Id: I6beecbcb8932fc1fe45b567f76fa3706feefae2c Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2019-09-26misc: add vnet classify filter set supportDave Barach1-7/+15
Type: feature Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I79b216d2499df143f53977e5b70382f6f887e0bc
2019-09-23misc: unify pcap rx / tx / drop traceDave Barach1-65/+120
Use a single vnet_pcap_t in vlib_global_main, specifically to support unified tracing Update sphinx docs, doxygen tags Type: refactor Ticket: VPP-1776 Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: Id15d41a596712968c0714cef1bd2cd5bc9cbdd55
2019-09-23interface: use the correct condition for checking if the pcap fd is openAndrew Yourtchenko1-1/+1
The 9af7e2e87e used a comparison that fd is >= 0 to check that the pcap needs closing. While the pcap_close() function does reset the file descriptor to -1, the freshly initialized structure has it equal to 0. This causes the VPP to close stdin if the packets are being seen on pg interface without the capture file being opened. This triggers the vpp attempting to read from STDIN (another bug), which results in running out of memory. Change-Id: I11d61422701500a9b3e0dd52d59383f297d57f54 Type: fix Fixes: 9af7e2e87e Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2019-09-20misc: classifier-based packet trace filterDave Barach1-2/+19
See .../src/vnet/classify/trace_classify.h for the business end of the scheme. It would be best to hash pkts, prefetch buckets, and do the primary table lookups two at a time. The inline as given works, but perf tuning will be required. "At least it works..." Add "classify filter" debug cli, for example: classify filter mask l3 ip4 src dst \ match l3 ip4 dst 192.168.2.10 src 192.168.1.10 Add "pcap rx | tx trace ... filter" to use the current classify filter chain Patch includes sphinx documentation and doxygen tags. Next step: device-driver integration Type: feature Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I05b1358a769f61e6d32470e0c87058f640486b26
2019-09-10misc: clean up "pcap [rx|tx] trace" debug CLIDave Barach1-168/+149
Separate debug CLI arg parsing from the underlying action function. Fixes a number of subtle ordering dependencies, and will allow us to add a binary API to control the feature at some point in the future. Type: refactor Ticket: VPP-1770 Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: Id0dbeda06dad20e756c941c691e2088ce3c50ec7
2019-08-20fix pcap_write functionJack Xu1-0/+2
when use pcap cli to capture pcakets into two files rx01.pcap && rx02.pcap, the first time: 1)pcap rx trace on max 100 intfc any file rx01.pcap 2)......the process of capture data to buffer...... 3)pcap rx trace off the second time: 4)pcap rx trace on max 100 intfc any file rx02.pcap 5)......the process of capture data to buffer...... 6)pcap rx trace off the pcap_write function bug in this two lines pm->n_packets_captured = 0; if (pm->n_packets_captured >= pm->n_packets_to_capture) referring to calling pcap_close() will result in that the twice pcap cli both writes the packets into rx01.pcap, but nothing into rx02.pcap. Beside, the rx02.pcap file will not be created. solution: separate the pcap_close() out of pcap_write() Change-Id: Iedeb46f9cf0a4cb12449fd75a4014f95f3bb3fa8 Signed-off-by: Jack Xu <jack.c.xu@ericsson.com>
2019-08-01interface: fix pcap tx/rx trace cli handlingJohn Lo1-9/+4
Provide default packet_to_capture value. Display interface name correctly for "pcap tx/rx trace status". Type: fix Signed-off-by: John Lo <loj@cisco.com> Change-Id: I7064d0dbea236a9aff68bba7fbaf2c4a73b16c6f Signed-off-by: John Lo <loj@cisco.com>
2019-05-17Add a debug-CLI leak-checkerDave Barach1-26/+14
leak-check { <any-debug-cli-command-and-args> } Hint: "set term history off" or you'll have to sort through a bunch of bogus leaks related to the debug cli history mechanism. Cleaned up a set of reported leaks in the "show interface" command. At some point, we thought about making a per-thread vlib_mains vector, but we never did that. Several interface-related CLI's maintained local static cache vectors. Not a bad idea, but not useful as things shook out. Removed the static vectors. Change-Id: I756bf2721a0d91993ecfded34c79da406f30a548 Signed-off-by: Dave Barach <dave@barachs.net>
2019-05-03mp_safe SW_INTERFACE_DUMP, SW_INTERFACE_DETAILS, SW_INTERFACE_TAG_ADD_DEL,Steven Luong1-0/+1
BRIDGE_DOMAIN_DUMP, CONTROL_PING, CONTROL_PING_REPLY, and show interface CLI Change-Id: I2927573b66bb5dd134b37ffb72af0e6676750917 Signed-off-by: Steven Luong <sluong@cisco.com> (cherry picked from commit 15c31921a628c5500cbed2ebc588d7ddbaa970a3)
2019-04-16vpp-1647: fix typo in pcap_trace_command_internalDave Barach1-1/+1
pcap rx trace on max 100 intfc tap0 then pcap rx trace status Displays "local0" instead of "tap0" due to a typo in pcap_trace_command_internal(...). Change-Id: Id2de6a24174aac24d9051b7404f01edc806a6573 Signed-off-by: Dave Barach <dave@barachs.net>
2019-04-05fix pcap_trace cli output issueJack Xu1-2/+4
Change-Id: Ia2be56e198c960788430705b356170f8cc12c450 Signed-off-by: Jack Xu <jack.c.xu@ericsson.com>
2019-02-26Move pcap rx/tx trace code out of the dpdk pluginDave Barach1-0/+286
Moved code to the ethernet input node, and the interface output path(s). Since we no longer skip ethernet-input, there's no reason for device drivers to know anything about pcap rx tracing, etc. Change-Id: I08d32fb1b90cbee1bd4f609837d533e047b36fa4 Signed-off-by: Dave Barach <dave@barachs.net>
2018-11-13L2 feautre bitmaps output verbose/non-verbose modeNeale Ranns1-2/+3
Change-Id: I15ff191ee8724a3354c074db590472db05e0652e Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-10-23c11 safe string handling supportDave Barach1-1/+1
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-09-26vnet: show interface rx-placement may display garbage charactersSteven1-1/+1
Before ------ DBGvpp# sh int rx-mode sh int rx-mode Thread 1 (vpp_wk_0^@): node vmxnet3-input: vmxnet3-0/b/0/0 queue 0 (polling) Thread 2 (vpp_wk_1^@): node vmxnet3-input: vmxnet3-0/13/0/0 queue 0 (polling) DBGvpp# After ----- DBGvpp# sh int rx-placement sh int rx-placement Thread 1 (vpp_wk_0): node vmxnet3-input: vmxnet3-0/b/0/0 queue 0 (polling) Thread 2 (vpp_wk_1): node vmxnet3-input: vmxnet3-0/13/0/0 queue 0 (polling) DBGvpp# Change-Id: I5910d502757054c3942fac9d20c5104e95fc6b56 Signed-off-by: Steven <sluong@cisco.com>
2018-09-24Trivial: Clean up some typos.Paul Vinciguerra1-4/+4
Change-Id: I085615fde1f966490f30ed5d32017b8b088cfd59 Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
2018-08-24rx-placement: Add API call for interface rx-placementMohsin Kazmi1-23/+42
Change-Id: I9228ce29e9d2fc862a2d076b4072bcdd728d6dd1 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2018-07-20IP directed broadcastNeale Ranns1-0/+40
with ip direct broadcast enable a packet to the interface's subnet broadcast address with be sent L2 broadcast on the interface. dissabled, it will be dropped. it is disabled by default, which preserves current behaviour Change-Id: If154cb92e64834e97a541b32624354348a0eafb3 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-06-11MTU: Software interface / Per-protocol MTU supportOle Troan1-14/+36
This patch separates setting of hardware interfaec and software interface MTU. Software MTU is L2 payload MTU (i.e. not including L2 header). Per-protocol MTU for IPv4, IPv6 and MPLS can also be set. Currently only IP4, IP6 are enabled in adjacency / rewrite code. Documentation in src/vnet/MTU.md Change-Id: Iee2fd6f0bbc8210748dd8e073ab9fab87d323690 Signed-off-by: Ole Troan <ot@cisco.com>
2018-05-27VPP-1294: add missing feature arc constraintDave Barach1-39/+51
the ip4-dhcp-client-detect feature MUST run prior to nat44-out2in, or inbound dhcp broadcast packets will be dropped. Certain dhcp servers answer lease renewal dhcp-request packets with broadcast dhcp-acks, leading to unrecoverable lease loss. In detail, this constraint: VNET_FEATURE_INIT (ip4_snat_out2in, static) = { .arc_name = "ip4-unicast", .node_name = "nat44-out2in", .runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa"), }; doesn't get the job done: ip4-unicast: [17] nat44-out2in [23] ip4-dhcp-client-detect [26] ip4-not-enabled Add a proper constraint: VNET_FEATURE_INIT (ip4_snat_out2in, static) = { .arc_name = "ip4-unicast", .node_name = "nat44-out2in", .runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa", "ip4-dhcp-client-detect"), }; and the interface feature order is OK, at least in this regard: ip4-unicast: [17] ip4-dhcp-client-detect [18] nat44-out2in [26] ip4-not-enabled We need to carefully audit (especially) the ip4-unicast feature arc, which has [gasp] 37 features on it! Change-Id: I5e749ead7ab2a25d80839a331de6261e112977ad Signed-off-by: Dave Barach <dave@barachs.net>
2018-04-13Revert "MTU: Setting of MTU on software interface (instead of hardware ↵Damjan Marion1-20/+23
interface)" This reverts commit 70083ee74c3141bbefb185525315f1b34497dcaa. Reverting as this patch is causing following crash: 0: /home/damarion/cisco/vpp3/build-data/../src/vnet/devices/devices.h:131 (vnet_get_device_input_thread_index) assertion `queue_id < vec_len (hw->input_node_thread_index_by_queue)' fails Aborted Change-Id: Ie2a365032110b1f67be7a9d832885b9899813d39 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-04-13MTU: Setting of MTU on software interface (instead of hardware interface)Ole Troan1-23/+20
Change-Id: I98bd454a761a1032738a21edeb0fe847e801f901 Signed-off-by: Ole Troan <ot@cisco.com>
2018-03-18Remove unnumbered configuration on interface deleteNeale Ranns1-41/+13
Change-Id: Iae5532c3d53e208831f3b2782242d9e59d367087 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-02-12Improve MTU handlingNeale Ranns1-6/+1
- setting MTU on an interface updates the L3 max bytes too - value cached in the adjacency is also updated - MTU exceeded generates ICMP to sender Change-Id: I343ec71d8e903b529594c4bd0543f04bc7f370b3 Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
2018-01-13Improve "show xxx tunnel" and "show int addr" outputJohn Lo1-65/+45
Improve "show xxx tunnel" output functions format_xxx_tunnel() for GRE, VXLAN, VXLAN-GPE, GENEVE and GTPU tunnels to make their output more consistent and provide better information. Improved the output of "show int addr" to make its info more consistent with tunnels and provide fib-index info. Change-Id: Icd4b5b85a5bec417f8ee19afea336c770ad3b4c5 Signed-off-by: John Lo <loj@cisco.com>
2017-10-31Fix set interface mac address API to be endian neutralJohn Lo1-2/+2
Store and pass MAC address as 6 byte u8 array instead of u64 to make MAC address handling in set interface MAC endian neutral. The previous API handler only works for little endian. Change-Id: Ie4ec33a840bc5122ab1f17e25977e58f3466253b Signed-off-by: John Lo <loj@cisco.com>
2017-10-29devices: Add binary API for set interface <interface> rx-modeSteven1-18/+31
Also add vat test code to test the subject API. The format is sw_interface_set_rx_mode sw_if_index <index> [queue <id>] <polling|nterrupt|adaptive> Change-Id: Ib810d85d430077865bead8cc08a070f8ae478225 Signed-off-by: Steven <sluong@cisco.com>
2017-10-04Set MAC address needs the HW interface indexNeale Ranns1-1/+3
Change-Id: I7b175d57b85e626aab00221b6dac0498aebcbeae Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-09-07Devices: Set interface rx-mode may cause SIGSEGV with nonexistent queueSteven1-2/+7
When I type in set interface rx-mode with a nonexistent queue, I got a crash with the following traceback. It looks like the vm is NULL when vlib_node_get_runtime is called. DBGvpp# sh int rx Thread 0 (vpp_main): node dpdk-input: TenGigabitEthernet5/0/0 queue 0 (polling) TenGigabitEthernet5/0/1 queue 0 (polling) TenGigabitEthernet7/0/0 queue 0 (polling) TenGigabitEthernet7/0/1 queue 0 (polling) node vhost-user-input: VirtualEthernet0/0/2 queue 0 (adaptive) DBGvpp# set interface rx-mode VirtualEthernet0/0/2 queue 1 polling Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. 0x00007ffff6d4e0bc in vlib_node_get_runtime (vm=0x0, node_index=125) at /home/sluong/vpp/build-data/../src/vlib/node_funcs.h:92 92 vlib_node_t *n = vec_elt (nm->nodes, node_index); (gdb) where at /home/sluong/vpp/build-data/../src/vlib/node_funcs.h:92 at /home/sluong/vpp/build-data/../src/vlib/node_funcs.h:112 vnm=0x6f0fa0 <vnet_main>, hw_if_index=7, queue_id=1, mode=0x7fffb62099e8) at /home/sluong/vpp/build-data/../src/vnet/devices/devices.c:307 hw_if_index=7, queue_id=1, mode=VNET_HW_INTERFACE_RX_MODE_POLLING) at /home/sluong/vpp/build-data/../src/vnet/interface_cli.c:1192 vm=0x7ffff7b9d440 <vlib_global_main>, input=0x7fffb6209ef0, cmd=0x7fffb61d5d14) at /home/sluong/vpp/build-data/../src/vnet/interface_cli.c:1288 vm=0x7ffff7b9d440 <vlib_global_main>, cm=0x7ffff7b9d630 <vlib_global_main+496>, input=0x7fffb6209ef0, parent_command_index=18) at /home/sluong/vpp/build-data/../src/vlib/cli.c:588 vm=0x7ffff7b9d440 <vlib_global_main>, cm=0x7ffff7b9d630 <vlib_global_main+496>, input=0x7fffb6209ef0, parent_command_index=12) The fix is to add a check for vec_len(hw->input_node_thread_index_by_queue) and vec_len (hw->rx_mode_by_queue) to reject the command if the queue_id is out of bound. While at it, I notice inputting queue_id=-1 is being interpreted as all queues. An easy fix is to not overload the queue_id variable with -1 to mean something else. Change-Id: Id70ec3e7d06ccc67635e6d28ef53420bdac4a988 Signed-off-by: Steven <sluong@cisco.com>
2017-08-15VPP-939: Update CLI Helptext for rx-placement commandsBilly McFall1-94/+264
The CLI commands were change from 'set/show interface placement' to 'set/show interface rx-placement', but the associated help text was not updated. On the 'set interface rx-placement', some of the parameters were renamed, which was confusing when looking at the documentation for help. While in the file interface_cli.c, cleaned up several other CLI commands. There are still other commands in the file that need addressing. Change-Id: Ifdc357c73ad9f3362133c495217b5a6b3a411eab Signed-off-by: Billy McFall <bmcfall@redhat.com>
2017-07-31CLI:add l2 input/outut to "sh int features"Eyal Bari1-14/+28
Change-Id: If608bbc7f4c8b0d5c3a237098a20279e407c82d3 Signed-off-by: Eyal Bari <ebari@cisco.com>
2017-07-06devices: show interface rx-placement displays the wrong information (VPP-894)Steven1-1/+3
show interface rx-placement somtimes displays the wrong interface names. This happens when there exists subinterfaces in VPP. The problem is due to the function show_interface_rx_placement_fn is calling format_vnet_sw_if_index_name with hw_if_index instead of sw_if_index. VPP has the concept of sw_if_index and hw_if_index. Each serves a different purpose. When there is no subinterfaces, both hw_if_index and sw_if_index may happen to have the same value. But don't count on it. When the API calls for sw_if_index, we must pass the sw_if_index although the hw_if_index has the same type which the compiler does not catch. Passing hw_if_index for an API which requires sw_if_index may have an unpredictable result such as described in the VPP-894 and sometimes it may even crash if the particular index does not exist. Change-Id: I76c4834f79b88a1c20684fcba64f14b2da142d77 Signed-off-by: Steven <sluong@cisco.com> (cherry picked from commit bafa4d048439fdbcc0bd577e43a2784d1b89bfc5)