Untitled :: Microchip UNG BSP Documentation

1. TC and VCAP

1.1. Introduction

The abbreviation VCAP stands for Versatile Content-Aware Processor.

A VCAP is approximately the same as a TCAM (ternary content-addressable memory) with configurable key, action and a counter.

A VCAP is used to match frames using a selection of keys and then execute one or more actions on the matched frames.

Each VCAP may have one or more lookups that can be used individually. The lookups are typically serviced in order of increasing lookup id.

1.2. VCAP Information

Here is an overview of which VCAPs are supported on the different switches, where each (VCAP, lookup) combination is assigned to a specific chain index:

1.2.1. Sparx5 and LAN969x VCAPs

VCAP Name	Description	Sparx5 Addresses	LAN969x Addresses	Counter	Lookups	Chain Ids
IS0	Ingress Classification	18432	9216	1 bit	6	L0: 1000000
L1: 1100000
L2: 1200000
L3: 1300000
L4: 1400000
L5: 1500000
IS2	Ingress Access Control	12288	9216	Ext 32 bit	4	L0: 8000000
L1: 8100000
L2: 8200000
L3: 8300000
ES0	Egress Rewriter	4096	1536	1 bit	1	L0: 10000000
ES2	Egress Access Control	12288	1024	Ext 32 bit	2	L0: 20000000
L1: 20100000

VCAP Name

Description

Sparx5 Addresses

LAN969x Addresses

Counter

Lookups

Chain Ids

IS0

Ingress Classification

18432

9216

1 bit

L0: 1000000

L1: 1100000

L2: 1200000

L3: 1300000

L4: 1400000

L5: 1500000

IS2

Ingress Access Control

12288

9216

Ext 32 bit

L0: 8000000

L1: 8100000

L2: 8200000

L3: 8300000

ES0

Egress Rewriter

4096

1536

1 bit

L0: 10000000

ES2

Egress Access Control

12288

1024

Ext 32 bit

L0: 20000000

L1: 20100000

The 6 lookups in IS0 are done serially and returns an action for each enabled VCAP lookup. If the lookup matches an entry in the IS0 VCAP, the associated action is returned.

For IS2 the first and the third lookups are done in parallel. The same applies to the second and the fourth lookups. Consequently, the actions from the first and the third lookups are processed before the actions from the second and the fourth lookups. Most actions are ordered so that the last action processed takes precedence, but some are sticky meaning they cannot be undone. The datasheet contains a list of these actions in section 4.20.1.7 Processing of VCAP IS2 Actions.

For ES2 the two lookups are done in parallel. If both result in an action then the second takes precedence, but there is a FWD_MODE action that has a special resolution table, and there are actions that a sticky meaning they cannot be overwritten by later actions. Section 4.25.1.5 Processing Actions in the datasheet contains the details.

All counters in the 4 VCAPs have 1 bit counters, but it is possible to use external 32 bit counters in IS2 and ES2, so this is what is currently being configured. Each rule in all VCAPs is given a unique rule id, which also serves as a counter id for the external counters.

The IS0 VCAP is sometimes referred to as CLM in the datasheet.

The LAN969x switch provides the same VCAPs with the same number of lookups, but have fewer address blocks for the VCAP instances.

1.2.2. LAN966x VCAPs

VCAP Name	Description	Addresses	Counter	Lookups	Chain Ids
IS1	Ingress Classification	768	32 bit	3	L0: 1000000
L1: 1100000
L2: 1200000
IS2	Ingress Access Control	256	32 bit	2	L0: 8000000
L1: 8100000
ES0	Egress Rewriter	64	1 bit	1	L0: 10000000

VCAP Name

Description

Addresses

Counter

Lookups

Chain Ids

IS1

Ingress Classification

768

32 bit

L0: 1000000

L1: 1100000

L2: 1200000

IS2

Ingress Access Control

256

32 bit

L0: 8000000

L1: 8100000

ES0

Egress Rewriter

1 bit

L0: 10000000

The three lookups in IS1 are done simultaneously and the potentially three IS1 action vectors are applied in three steps. If the actions overlap the last lookup wins.

Then the two lookups in IS2 are done simultaneously and the potentially two IS2 action vectors are applied in two steps. Consult the datasheet to see how the two lookups are combined.

When the switch has selected on which port(s) to forward the packet, a single lookup in ES0 is done and the potential action vectors are applied before the packet is transmitted on the egress port(s).

1.3. TC commands

Here we will show how to use a combination of tc commands to configure VCAPs.

The examples in the remainder of this section uses the LAN966x VCAP as examples. You can perform the same operations on Sparx5 but the VCAPs have other names and in some cases the key support is different.

Figure 1. Ingress pipeline for LAN966x IS1 and IS2:

Figure 2. Egress pipeline for LAN966x ES0:

1.4. TC initial setup

Tc rules operate in general on a single interface only.

Microchip switches support Shared Filter Blocks on the ingress side but for now, we will use eth0 as the single interface.

Start by creating a clsact qdisc:

$ tc qdisc add dev eth0 clsact

This is the qdisc where all filters are attached. A filter refers to this qdisc by using the keyword 'ingress' or 'egress'.

In order to simulate the VCAP functionality on a SW target you must create the following default rules:

Create a default lowest priority matchall rule in chain 0, which is the default chain, with a goto chain 1000000 (IS1 lookup 0) as the only action:

$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 matchall \
     action goto chain 1000000

Create a default lowest priority flower rule in chain 1000000 (IS1 lookup 0) with a goto chain 1100000 (IS1 lookup 1) as the only action:

$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 1000000 flower \
     action goto chain 1100000

Create a default lowest priority flower rule in chain 1100000 (IS1 lookup 1) with a goto chain 1200000 (IS1 lookup 2) as the only action:

$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 1100000 flower \
     action goto chain 1200000

Create a default lowest priority flower rule in chain 1200000 (IS1 lookup 2) with a goto chain 8000000 (IS2 lookup 0) as the only action:

$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 1200000 flower \
     action goto chain 8000000

Create a default lowest priority flower rule in chain 8000000 (IS2 lookup 0) with a goto chain 8100000 (IS2 lookup 1) as the only action:

$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 8000000 flower \
     action goto chain 8100000

Create a default lowest priority flower rule in every chain you plan to use from 8000001 to 8000255 (IS2 lookup 0) with a goto chain 8100000 (IS2 lookup 1) as the only action:

$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 8000001 flower \
     action goto chain 8100000
$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 800007 flower \
     action goto chain 8100000
$ tc filter add dev eth0 ingress protocol all prio 0xffff handle 0 chain 800042 flower \
     action goto chain 8100000

It is not necessary to create a default rule in chain 8100000 (IS2 lookup 1) as the VCAP stops processing after this lookup.

All user-defined flower rules must end with a goto <next chain> action in order to stop further processing if there is a match.

1.5. Linking TC filters between VCAPs

The switch allows filters to be linked between the IS0/IS1 and the other VCAPs by specifying a 'offset' to the usual chain value.

In the source filter the goto action must specify the lookup chain id plus an offset value from 1 to 255 (larger values are available for other chains) and similarly the destination filter must be added on the same chain id.

Example of a source filter action specification using an offset of 21:

action goto chain 8000021

Example of a destination filter chain specification using the same offset as above:

tc filter add dev eth12 ingress chain 8000021 ...

In e.g the IS0/IS1 VCAP this is done by adding an action in the source filter that sets the 8 bit wide PAG (Policy Association Group) value in the frame metadata when the filter matches the frame, and then add a key match on the same PAG value in the destination filter in the IS2 VCAP, so the second filter only matches if also the first (source) filter was matched.

Here is an overview of the link keys between the VCAPs:

Source	Destination	Key	Size	Sparx5	LAN966x
IS0/IS1	IS2	PAG	8 bit	✔	✔
IS0	ES0	ISDX	12 bit	✔	·
IS0	ES2	ISDX	12 bit	✔	·

Source

Destination

Key

Size

Sparx5

LAN966x

IS0/IS1

IS2

PAG

8 bit

✔

IS0

ES0

ISDX

12 bit

✔

IS0

ES2

ISDX

12 bit

✔

Here is an example of a source filter that uses chain 1200000 (IS1 lookup 2) and chains to IS2 lookup 0 with PAG 1:

$ tc filter add dev eth0 ingress protocol ip prio 10 handle 0 chain 1200000 flower \
     dst_mac 00:11:22:33:44:55 \
     dst_ip 10.10.0.42 \
     action skbedit priority 6\
     action goto chain 8000001

This example assigns priority 6 to all ipv4 packets that match dst_mac and dst_ip and then go to chain 8000001 which corresponds to PAG 1.

When running on the target, the PAG is derived from the goto chain number and assigned as a VCAP action in IS1 lookup 2, The PAG is assigned as a key in IS2 lookup 0 and depends on the selected chain.

Currently, it is not enforced that you set up all the default chains when running on target but it is expected that we will enforce this going forward.

1.6. TC flower syntax

The tc filter and flower syntax can be shown with these commands:

$ tc filter help
$ tc filter add flower help

If you want to modify an existing filter you can use the 'change' or 'replace' option:

$ tc filter add dev eth0 ingress protocol ip prio 10 handle 0 chain 1200000 flower \
     dst_mac 00:11:22:33:44:55 \
     dst_ip 10.10.0.42 \
     action skbedit priority 6 \
     action goto chain 8000001

$ tc filter change dev eth0 ingress protocol ip prio 10 handle 0 chain 1200000 flower \
     dst_mac 00:11:22:33:44:55 \
     dst_ip 10.10.0.84 \
     action skbedit priority 6 \
     action goto chain 8000001

In this example, dst_ip was changed from 10.10.0.42 to 10.10.0.84.

Each VCAP supports different protocols, keys, and actions which will be explained in the following sections.

The following options are common for all flower filters:

1.6.1. Prio

prio <PRIO> (or pref <PRIO>) sets the sequence of filters.

Filters with lower numbers are examined first and thus have higher priority.

PRIO is a number from 0 to 0xffff.

1.6.2. Handle

handle <FILTERID> is a reference to the filter. Use this is if you need to reference the filter later.

FILTERID is a number from 0 to 0xffffffff.

1.6.3. Chain

chain <CHAIN_INDEX> is the chain to use for this filter.

Chain 0 is the default chain if this option is missing.

CHAIN_INDEX is a number from 0 to 0xffffffff.

1.7. LAN966x IS1

All three IS1 lookups generate by default an S1_7TUPLE key which defines the possible match keys.

If another key than S1_7TUPLE is needed, a chain template must be used. See page Classification (IS1), where the different IS1 keys are documented.

1.7.1. Protocol

protocol <PROTO> is the protocol to match.

PROTO can be one of: all, 802_2 (LLC), snap, 802.1q (ctag), 802.1ad (stag), 0xf1c1 (rtag), arp, ip, ipv6, or a 16-bit number >= 0x0600 for EtherType.

protocol is always the EtherType after mac addresses or vlan tag(s).

Set protocol to all if you want to match on all kind of packets.

Setting protocol to other than all limits the matches to the specific kind of packets.

1.7.2. Keys

Most match keys can be specified as a value or a value/mask. A missing match key is the same as a wildcard (mask is all zeros).

The following match keys are supported in all protocols:

dst_mac <MAC> - Match on DMAC. Value only: xx:xx:xx:xx:xx:xx or value/mask: xx:xx:xx:xx:xx:xx/yy:yy:yy:yy:yy:yy.
src_mac <MAC> - Match on SMAC. Same as dst_mac.

The following match keys are supported when protocol is 802.1q (ctag) or 802.1ad (stag). They match on the outer VLAN tag:

vlan_id <VID> - Match on outer VLAN ID. Value only: x or value/mask: x/y.
vlan_prio <PCP> - Match on outer VLAN PCP. Value only: x or value/mask: x/y.
vlan_ethtype <PROTO> - Match on EtherType after outer VLAN.

Some of the IS1 keys support matching a second VLAN tag. The match keys for the second VLAN tag are:

cvlan_id <VID> - Match on inner VLAN ID. Value only: x or value/mask: x/y.
cvlan_prio <PCP> - Match on inner VLAN PCP. Value only: x or value/mask: x/y.
cvlan_ethtype <PROTO> - Match on EtherType after inner VLAN.

See page Classification (IS1) for documentation regarding supported match keys in the different IS1 keys.

1.7.3. Actions

The supported actions in IS1 are:

pass - a do-nothing action used to stop lookup in the VCAP.
vlan modify id <VID> [priority <PCP>] - set the classified VID and PCP. Classified PCP is set to 0 if priority is not present.
skbedit priority <PRIO> - set the classified priority to PRIO
goto chain <CHAIN_INDEX>

Every flower filter requires a goto as the last action and this is enforced by the driver.

On a SW target, these goto’s are needed in order to simulate the behaviour of the VCAP, where the search stops after the first match.

On the HW target, these goto’s are actually only needed in IS1 Lookup 2, where the PAG (Policy Association Group) value is assigned based on the goto action.

To keep the same configuration on both kinds of platforms the goto is required in all flower filters.

At IS2 Lookup 1 and ES0 Lookup 0, where the pipeline ends, there is no next chain to go to. In this case, a goto with a chain number greater than the current one is accepted and required by the driver.

You cannot goto a chain with a lower number than the current one. This is enforced when running on the HW target but cannot be enforced on the SW target.

1.7.4. Examples

Here is an example that contains almost all possible keys and actions and goto chain 8000001 (IS2 lookup 0 PAG 1):

$ tc filter add dev eth0 ingress protocol 802.1ad prio 10 handle 0 chain 1200000 flower \
     dst_mac 00:11:22:33:44:55 \
     src_mac 00:44:55:00:00:00/ff:ff:ff:0:0:0 \
     vlan_id 100 \
     vlan_prio 1 \
     vlan_ethtype 802.1q \
     cvlan_id 200 \
     cvlan_prio 2 \
     cvlan_ethtype ip \
     dst_ip 10.10.20.42 \
     src_ip 10.10.30.00/255.255.255.0 \
     ip_flags frag/nofirstfrag \
     ip_tos 0x0f/0x3f \
     ip_proto tcp \
     dst_port 1000 \
     src_port 2000 \
     action skbedit priority 6 \
     action vlan modify id 300 3 \
     action goto chain 8000001

You can match a ctag after an stag tag by setting protocol to 802.1ad and vlan_ethtype to 802.1q.
You can match an rtag after a ctag tag by setting protocol to 802.1q and vlan_ethtype to 0xf1c1.

1.8. LAN966x IS2

Both IS2 lookups generate a key based on the content of the frame. The current default configuration is that IPv6 packets are matched against IP4_TCP_UDP or IP4_OTHER entries in both lookups.

1.8.1. Protocol

protocol <PROTO> is the protocol to match.

PROTO can be one of: all, 802_2 (LLC), snap, 802.1q, arp, rarp, ip, ipv6 or a 16 bit number for EtherType. + Specifying 0x8809, 0x88ee, or 0x8902 will be treated as OAM packets and will match for all of them.

protocol is always the EtherType after mac addresses or vlan tag(s).

Set protocol to 'all' if you want to match on all kinds of packets.

Setting protocol to other than all limits the matches to the specific kind of packets.

If you set protocol to all you cannot match on any fields, which means that all packets are matched. + If you set protocol to 802.1q and vlan_ethtype to all, you can match on all packets on a specific VLAN.

1.8.2. Keys

Most match keys can be specified as a value or a value/mask. A missing key is the same as a wildcard (mask is all zeros).

The following match keys are supported when the protocol is 802.1q.

vlan_id <VID> - Match on classified VLAN ID. Value only: x or value/mask: x/y.
vlan_prio <PCP> - Match on classified VLAN PCP. Value only: x or value/mask: x/y.
vlan_ethtype <PROTO> - Match on EtherType after outer VLAN.

See page ACL (IS2) for documentation regarding supported match keys in the different IS2 keys.

1.8.3. Actions

The supported actions in IS2 are:

pass - a do-nothing action used to stop lookup in the VCAP.
trap - send the packet to CPU
drop - drop the packet
police rate <BPS> burst <BYTES> - police packets. Set rate to BPS bits per second and burst to BYTES bytes. Policers are only supported in the first lookup.
mirred - mirror packet on the monitor port
goto chain <CHAIN_INDEX>

1.8.4. Examples

Here is an example that polices all packets on VLAN 100 with rate 1Mbps and goto chain 8100000 (IS2 lookup 1):

$ tc filter add dev eth0 ingress protocol 802.1q prio 10 handle 0 chain 8000000 flower \
     vlan_id 100 \
     vlan_ethtype all \
     action police rate 1000000 burst 16000 \
     action goto chain 8100000

Here is an example that mirrors all snap packets with DMAC 00:44:55:66:77:88 on monitor port eth3 and goto chain 8100000 (IS2 lookup 1):

$ tc filter add dev eth0 ingress protocol snap prio 10 handle 0 chain 8000000 flower \
     dst_mac 00:44:55:66:77:88 \
     action mirred egress mirror dev eth3 \
     action goto chain 8100000

Here is an example that drops all snap packets with DMAC 00:44:55:XX:XX:XX and goto chain 8100000 (IS2 lookup 1):

$ tc filter add dev eth0 ingress protocol snap prio 10 handle 0 chain 8000000 flower \
     dst_mac 00:44:55:00:00:00/ff:ff:ff:0:0:0 \
     action drop \
     action goto chain 8100000

Here is an enhancement of the example above that drops all snap packets with DMAC 00:44:55:XX:XX:XX except DMAC 00:44:55:66:77:88 and goto chain 8100000 (IS2 lookup 1):

$ tc filter add dev eth0 ingress protocol snap prio 9 handle 0 chain 8000000 flower \
     dst_mac 00:44:55:66:77:88 \
     action pass \
     action goto chain 8100000

$ tc filter add dev eth0 ingress protocol snap prio 10 handle 0 chain 8000000 flower \
     dst_mac 00:44:55:00:00:00/ff:ff:ff:0:0:0 \
     action drop \
     action goto chain 8100000

Here is an example that traps all arp request packets with SMAC 00:11:22:33:44:55 and goto chain 8100000 (IS2 lookup 1):

$ tc filter add dev eth0 ingress protocol arp prio 10 handle 0 chain 8000000 flower \
     src_mac 00:11:22:33:44:55 \
     arp_op request \
     action trap \
     action goto chain 8100000

Here is an example that drops specific ip/udp packets on VLAN 100 and goto chain 8100000 (IS2 lookup 1):

$ tc filter add dev eth0 ingress protocol 802.1q prio 10 handle 0 chain 8000000 flower \
     vlan_id 100 \
     vlan_ethtype ip \
     dst_ip 10.10.20.42 \
     src_ip 10.10.30.00/255.255.255.0 \
     ip_flags frag/nofirstfrag \
     ip_tos 0x0f/0x3f \
     ip_proto udp \
     dst_port 1000 \
     src_port 2000 \
     action drop \
     action goto chain 8100000

1.9. LAN966x ES0

ES0 has only one lookup (chain 10000000) and the filters are assigned to the egress part of the clsact qdisc. ES0 can only match on the classified VID and PCP values. Note that these values can be different from the values in the packet.

1.9.1. Protocol

protocol <PROTO> is the protocol to match.

PROTO can be one of: all or 802.1q.

Set protocol to 'all' if you want to match on all kinds of packets.
If you set protocol to 'all' you cannot match on any fields, which means that all packets are matched.
If you set protocol to '802.1q' and vlan_ethtype to 'all', you can match on all packets on a specific VLAN.

1.9.2. Keys

Most keys can be specified as a value or a value/mask. A missing key is the same as a wildcard (mask is all zeros).

The following keys are supported when the protocol is 802.1q.

vlan_id <VID> - Match on classified VLAN ID. Value only: x or value/mask: x/y.
vlan_prio <PCP> - Match on classified VLAN PCP. Value only: x or value/mask: x/y.
vlan_ethtype <PROTO> - Match on EtherType after outer VLAN.

See page VLAN Tagging for documentation regarding supported match keys.

1.9.3. Actions

The supported actions in ES0 are:

vlan pop - pop vlan tag
vlan modify [ protocol <PROTO> ] id <VID> [ priority <PCP> ] - modify VID and PCP. <PROTO> is one of 802.1q (default) or 802.1ad
vlan push [ protocol <PROTO> ] id <VID> [ priority <PCP> ] - push a new vlan tag. <PROTO> is one of 802.1q (default) or 802.1ad
goto chain <CHAIN_INDEX>

1.9.4. Examples

Here is an example that matches on VLAN 100, pops it, and goes to chain 10000001 (Dummy lookup):

$ tc filter add dev eth0 egress protocol 802.1q prio 10 handle 0 chain 10000000 flower \
     vlan_id 100 \
     vlan_ethtype all \
     action vlan pop \
     action goto chain 300001

Here is an example that matches on VLAN 100, modifies it to VLAN 200 c-tag, and goes to chain 10000001 (Dummy lookup):

$ tc filter add dev eth0 egress protocol 802.1q prio 10 handle 0 chain 10000000 flower \
     vlan_id 100 \
     vlan_ethtype all \
     action vlan modify id 200 priority 0 \
     action goto chain 300001

Here is an example that matches on VLAN 100, pushes VLAN 200 as outer s-tag, and goes to chain 10000001 (Dummy lookup):

$ tc filter add dev eth0 egress protocol 802.1q prio 10 handle 0 chain 10000000 flower \
     vlan_id 100 \
     vlan_ethtype all \
     action vlan push protocol 802.1ad id 200 priority 0 \
     action goto chain 300001