VCAP Tool
The VCAP tool is a low-level interface that can be used to configure and query the VCAPs.
With this tool, it is possible to configure all key and action fields in the VCAPs.
This is needed in cases where a specific VCAP configuration is not possible via the tc commands,
such as IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER).
The layout of the VCAPs depends on the actual hardware. Please consult the datasheet for details.
The following examples are for the LAN966X platform.
Use vcap -h to see the usage:
Create, modify, get and delete VCAP rules
Usage:
vcap [options] [command] [arguments]
Options:
-h This help
-p Get platform information
-v VCAP_NAME Get vcap information
-o VCAP_NAME Get vcap port information
-l LEVEL Rule information level: 3=FULL, 2=SOME, 1=MINIMAL, 0=NONE
-d PLATFORM_NAME Handling platform name, when multiple platforms exist
Command:
add RULE_ID Add a new rule with id, keys and actions
del RULE_ID Delete an existing
get RULE_ID Get and display an existing rule
mod RULE_ID Modify keys and actions of an existing rule
reset RULE_ID Reset the counter of an existing rule
list List all known rules
platforms List all known platforms
def_plat PLATFORM_NAME Set default platform
Arguments to the add or mod commands:
VCAP_NAME Name of VCAP. Found in platform information
PRIORITY Rule priority
VCAP_LOOKUP VCAP lookup index
KEYSET_NAME Found in vcap information
(KEY_NAME key_value key_mask)* Found in vcap keyset information
A '=' value/mask sets all bits
[-] Get a list of possible actionsets or actions
ACTIONSET_NAME Found in vcap information
(ACTION_NAME action_value)* Found in vcap actionset information
PLATFORM_NAME Found in vcap platforms
It is possible to query the platform information, like e.g. showing the supported VCAPs:
Use vcap -p to get the platform information:
Platform: lan966x - [0]: es0 - [3]: is1 - [4]: is2
More details are available for each of the VCAP, by getting the VCAP information:
Use vcap -v is2 to get the IS2 VCAP information:
VCAP[4]: is2
instance: 0
name: is2
rows: 64
sw_count: 4
sw_width: 96
sticky_width: 32
act_width: 31
default_cnt: 11
require_cnt_dis: 1
version: 1
vtype: 4
vinst: 0
first_cid: 8000000
last_cid: 8199999
lookups: 2
first_valid_addr: 0
last_valid_addr: 255
last_used_addr: 256
keyset: [4]: VCAP_KFS_ARP
key: [5]: 8021Q_DEI_CLS, type: BIT, width: 1
key: [9]: 8021Q_PCP_CLS, type: U32, width: 3
key: [17]: 8021Q_VID_CLS, type: U32, width: 12
key: [19]: 8021Q_VLAN_TAGGED_IS, type: BIT, width: 1
key: [21]: ARP_ADDR_SPACE_OK_IS, type: BIT, width: 1
key: [22]: ARP_LEN_OK_IS, type: BIT, width: 1
key: [23]: ARP_OPCODE, type: U32, width: 2
key: [24]: ARP_OPCODE_UNKNOWN_IS, type: BIT, width: 1
key: [25]: ARP_PROTO_SPACE_OK_IS, type: BIT, width: 1
key: [26]: ARP_SENDER_MATCH_IS, type: BIT, width: 1
key: [27]: ARP_TGT_MATCH_IS, type: BIT, width: 1
key: [31]: HOST_MATCH, type: BIT, width: 1
key: [35]: IF_IGR_PORT_MASK, type: U32, width: 9
key: [46]: ISDX_GT0_IS, type: BIT, width: 1
key: [47]: L2_BC_IS, type: BIT, width: 1
...
Each port on the switch has its keyset configuration per lookup. You can inspect this information.
Use vcap -o is2 to get the port configuration for IS2:
is2:
port[00] (eth2):
state: on
L:0:
snap: mac_snap
arp: arp
oam: oam
ipv4_tcp_udp: ipv4_tcp_udp
ipv4_other: ipv4_other
ipv6: ipv6_tcp_udp or ipv6_other
L:1:
snap: mac_snap
arp: arp
oam: oam
ipv4_tcp_udp: ipv4_tcp_udp
ipv4_other: ipv4_other
ipv6: ipv6_tcp_udp or ipv6_other
...
To add a rule in IS1:
# vcap add 1 is1 10 0 \ VCAP_KFS_NORMAL ETYPE 0x887f = IF_IGR_PORT_MASK 0x0 0x0 \ VCAP_AFS_S1 QOS_ENA 1 QOS_VAL 5
The second line defines the keys and the third line defines the actions.
The = is a shorthand notation that set the mask to all ones (all bits in the key value is used for matching)
If the key 'IF_IGR_PORT_MASK' is missing then the entry will be added on chip
port 0, which might not be the expected. Therefore set ingress port mask to none
such that this will match the frames on all the ports in this case.
To modify the above rule in IS1:
# vcap mod 1 ETYPE 0x88f7 =
Note that the rule must exist and you cannot change the size of the key and action.
To read the hit counter in the above rule in IS1:
# vcap get 1
Rule: 1, is1, priority: 10, lookup: 0, address: 766-767 (X2), Counter: 4, Hit: 1
Keyset: VCAP_KFS_NORMAL
KEY: ETYPE: W16, 0x88f7/0xffff
KEY: LOOKUP_INDEX: W2, 0x0/0x3
KEY: TYPE: W1, 0/1
Actionset: VCAP_AFS_S1
ACTION: QOS_ENA: W1, 1
ACTION: QOS_VAL: W3, 0x5
This shows that the rule have been hit 4 times.
| Some counters are only one bit wide, so you can only see if they have been hit or not. See VCAP Information |
You can reset the counter with:
# vcap reset 1 Rule 1 counter reset
To delete the above rule in IS1:
# vcap del 1
1. VCAP Debugging tools
Besides the vcap tool you can also dump VCAP specific information in debugfs.
Show administration info for IS1 on LAN966x:
# cat /sys/kernel/debug/lan966x/vcaps/is1_0 name: is1 rows: 192 sw_count: 4 sw_width: 96 sticky_width: 32 act_width: 123 default_cnt: 0 require_cnt_dis: 1 version: 1 vtype: 3 vinst: 0 first_cid: 1000000 last_cid: 1299999 lookups: 3 first_valid_addr: 0 last_valid_addr: 767 last_used_addr: 768 #
If there are rules present in the IS1 VCAP they will also be listed in a format like shown with the vcap tool.
It is also possible to see the raw rule data, and in this case just one line is printed per rule.
# cat /sys/kernel/debug/lan966x/vcaps/raw_is1_0 addr: 766, X2 rule, keysets: VCAP_KFS_NORMAL VCAP_KFS_NORMAL_DMAC, actionset: VCAP_AFS_S1
A VCAP rule occupies 1, 2, 3, 4, 6 or 12 addresses and is called and X1 to X12 correspondingly. Only Sparx5 uses the X3, X6 and X12 size rules.
-
X1 rules can be located on any address
-
Xn rules can only be located on address values modulo n
You cannot specify the address when you add a rule.
The location depends on the size and the priority.
The rules are added in size order, so that larger rules are added first (on the higher number addresses).
Rules with a priority of low numerical value have the highest priority and are located first within their size group.
If you add a rule with the same priority, the last added rule has the highest priority (located first).
The LAN966x IS1 VCAP generates an different keyset on the ports
To see the current mapping from frame type to keys in LAN966x IS1:
# cat /sys/kernel/debug/lan966x/vcaps/eth0
...
is1:
port[2] (eth0):
state: on
Lookup 0:
other: normal
ipv4: 5tuple_ipv4
ipv6: 5tuple_ip6
rt: normal
Lookup 1:
other: normal
ipv4: 5tuple_ipv4
ipv6: 5tuple_ip6
rt: normal
Lookup 2:
other: normal
ipv4: 5tuple_ipv4
ipv6: 5tuple_ip6
rt: normal
...
If you want to use another keyset on a specific combination of port and lookup you must change the generated key by
using a tc chain template. See the Chain section on the TC Introduction page on how to
set up a tc chain template.
To change the all keyset generation for IS1 Lookup 0, you can add a chain that selects this protocol, where the dmac and smac keys will ensure that a different keyset will be selected.
Before running the following command, it is required to have a queue discipline created:
# tc qdisc add dev eth0 clsact
# tc chain add dev eth0 ingress chain 1000000 prio 10000 handle 10000 protocol all flower skip_sw \ dst_mac 00:00:00:00:00:00 src_mac 00:00:00:00:00
Looking at the mapping again shows that the keyset has changed to 5tuple_ipv4:
# cat /sys/kernel/debug/lan966x/ports
...
is1:
port[2] (eth0):
state: on
Lookup 0:
other: 7tuple
ipv4: 7tuple
ipv6: 7tuple
rt: normal
Lookup 1:
other: normal
ipv4: 5tuple_ipv4
ipv6: 5tuple_ip6
rt: normal
Lookup 2:
other: normal
ipv4: 5tuple_ipv4
ipv6: 5tuple_ip6
rt: normal
...
It is not necessary to use tc chain templates on Sparx5 ES0 and LAN966x IS2 and ES0 VCAPs as the keys generated here
only depends on the frame type.