Shoehorn Overview
6.3 Aggregating Components
Example 1. Example 2.
Matches:
eth.src: ternary Actions:[count]
Matches:
eth.dst: ternary Actions:[output]
Matches:
eth.src: ternary Actions:[count]
Matches:
eth.dst: ternary Actions:[output, drop]
hit
Figure 6.2:Two examples of sections of pipelines that cannot be aggregated without requiring a Cartesian product of table entries in the physical table. The key for this and other diagrams in this chapter is shown in Figure 6.3.
Table Conditional Action Module
Indicates a transformation applied to a section of the vir- tual pipeline by Shoehorn to allow them to be mapped to a physical pipeline.
Figure 6.3:The key for the diagrams used in this chapter and in chapter 8. Ar- rows between components indicate the components applied following the associated evaluation of the conditional or the hit field of the table’s apply result (§2.3.4). Branching arrows indicate that the pipeline applies multiple components following the associated result.
two scenarios where this may occur:
1. When a pipeline applies multiple tables to an overlapping set of packets, shown in Figure 6.2, Example 1.
2. When a pipeline applies one table to a subset of packets that match another table, shown in Figure 6.2, Example 2.
These situations only apply if the tables use ternarymatches, or if the tables use different matches. For instance, taking the Cartesian product of entries from two tables that both only perform exact matching on Ethernet desti- nation, results in a physical table that matches the total number of Ethernet destinations matched in the two virtual tables. However, aggregating a table that has alpmmatch on IPv4 destination and anexactmatch on IPv4 source,
Matches:
eth.src: ternary Actions:[drop]
Matches:
eth.dst: ternary Actions:[output]
Matches:
eth.src: ternary eth.dst: ternary Actions:[drop, output]
Figure 6.4:A mapping can aggregate a table that drops every packet it matches with other tables without increasing the total number of table entries, even if a packet can match entries in both tables.
with a table that has alpmmatch on IPv4 source and anexactmatch on IPv4 destination, can still result in a Cartesian product of the two tables.
One other relevant exception to this is when a virtual pipeline has two tables applied to overlapping sets of packets, and one of the tables only drops packets.
If the other table only uses actions that are no-ops when applied to packets that are subsequently dropped (for instance, setting an output port or modifying a header field), then the mapping can aggregate the two tables without increasing the total number of entries. The mapping must prioritise entries from the drop table over those from the other table, and as all actions in the other table are no-ops when combined with a drop, the mapping does not need to combine entries. An example of this kind of aggregation is shown in Figure 6.4.
6.3.2 Aggregating Conditionals
Mappings can aggregate conditionals with other components without increas- ing the number of table entries in the following cases:
• mappings can always aggregate a conditional with another conditional;
• mappings can always aggregate a conditional with a table that uses
IPv6
Matches:
ipv6.dst: lpm Actions:[output]
Default:None true
Matches:
eth.type: exact ipv6.dst: lpm Actions:[output]
Default:None
Figure 6.5:A mapping can aggregate a conditional with a table without increasing the number of table entries required in the physical pipeline.
IPv6
Matches:
ipv6.dst: ternary Actions:[output]
Matches:
ipv4.dst: ternary Actions:[output]
true
false
Matches:
ethernet.type: all_or_exact ipv4.dst: ternary ipv6.dst: ternary
Actions:[output]
Figure 6.6:Mappings can aggregate mutually exclusive tables without increasing the overall number of table entries.
ternarymatch kinds; and
• mappings can aggregate a conditional with a table using lpm or exact match kinds, provided the conditional fields are unmasked, the table is applied when the packet matches the conditional fields, and the table has no default action.
An illustration of aggregating a conditional into a table is shown in Figure 6.5.
Matches:
ipv6.dst: ternary Actions:[output, drop]
Matches:
ipv6.src: ternary Actions:[output, drop]
miss
Matches:
ipv6.src: ternary ipv6.dst: ternary Actions:[output, drop]
Figure 6.7:Mappings can concatenate ternary tables when the second table is ac- cessed on a miss in the first table without increasing the overall number of table entries.
6.3.3 Aggregating Mutually Exclusive Tables
Mappings can straightforwardly aggregate tables where packets cannot match both tables without increasing the number of entries. Figure 6.6 demonstrates merging two components when the sets of packets to which they are applied are mutually exclusive.
6.3.4 Concatenating Ternary Tables
When a ternarytable is applied following a miss on another ternary table, a mapping can aggregate these tables by concatenating the two tables, without increasing the overall number of entries. The entries from the first table are given higher priorities and the entries from the second table must apply the default action from the first table as well as their usual actions. This is shown in Figure 6.7.
Matches:
ipv6.dst: ternary Actions:[output, drop]
Action Module
Matches:
ipv6.src: ternary Actions:[output, drop]
Matches:
meta.recirculation: ternary
ipv6.dst: ternary
ipv6.src: ternary
Actions:[output, drop, recirculate]
Action Module
recirculate
Figure 6.8:Tables separated by a recirculation can always be aggregated without increasing the overall number of table entries.
6.3.5 Aggregation after Recirculation
Figure 6.8 shows an example of aggregating tables after a recirculation. Map- pings can aggregate tables after a recirculation, without increasing the overall number of table entries, provided the physical table is able to match recircu- lation metadata.