-
Notifications
You must be signed in to change notification settings - Fork 2
/
issues.txt
185 lines (151 loc) · 6.5 KB
/
issues.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
Questions about P4 Language Specification Version 1.0.3
http://p4.org/wp-content/uploads/2016/11/p4-spec-latest.pdf
- Page 59,
exp ::=
exp bin_op exp | un_op exp | field_ref |
value | ( exp )
What is value? Is it const_value?
RESOLVED(Nate Foster): const_value
- Page 27,
counter_declaration ::=
counter counter_name {
type : counter_type ;
[ direct_or_static ; ]
[ instance_count : const_expr ; ]
[ min_width : const_expr ; ]
[ saturating ; ]
}
meter_declaration ::=
meter meter_name {
type : meter_type ;
[ result : field_ref ; ]
[ direct_or_static ; ]
[ instance_count : const_expr ; ]
}
What is const_expr? Is it const_value?
- What is atomic? What happens if a new rule is received while processing a packet?
- What happens if during checking if while a rule is being checked for matching, a new rule is added to the table?
- Does packets get processed in parallel or sequentially? (it affects the semantics)
- Page 13
field_list_declaration ::=
field_list field_list_name {
[ field_list_entry ; ] +
}
field_list_entry ::=
field_ref | header_ref | field_value | field_list_name | payload
field_ref ::= header_ref . field_name
header_ref ::= instance_name | instance_name "[" index "]"
index ::= const_value | last
Does it mean we can have hdr [ last ] in field_list_declaration ?
- field_ref in functions (actions) is different from field_ref in other places such as field_list_dec or return select
In the former, field_ref is actually reference to fields, in the later they are the value of the fields.
Isn't this a bad thing?
- "Select functions take a comma-separated list of fields and concatenate their values,
with the left-most field forming the most-significant bits of the concatenated value. The
select operation then compares the values in the order they occur in the program to the
entries to find a matching one."
Does it mean we do the same thing (concatenation) with the match cases and then compare the values?
- Is it possible to extract and already extracted header?
- Page 21
"The header reference latest refers to the most recently extracted header instance
within the parse function. It is an error to reference latest without a preceding
extract operation in the same function."
What kind of error is it? Runtime or compile time?
RESOLVED (figured out): it should be compile time
- Page 56
Page 54
action_specification ::=
actions { [ action_name ] + }
Shouldn't there be a semicolon?
- lpm: This is a special case of a ternary match. Each entry’s mask selects a prefix by
having a divide between 1s in the high order bits and 0s in the low order bits. The
number of 1 bits gives the length of the prefix which is used as the priority of the
entry.
in table t {
reads {
h.f1 : lpm
h.f2 : lpm
}
...
}
How the table entries are given priorities?
- When exactly the arguments are evaluated? When primitive actions are called or when any action
(including the compound actions are called)?
When exactly the the type of the arguments are inferred?
Is this possible to have something like this
action a (x) {
modify_field(x,10)
modify_field(ethernet.dstAddr,x)
}
How about this ?
action a (x){
modify_field(x.dstAddr,10)
}
- Page 53
"...With parallel semantics, both actions are started at the same time..."
Page 54
"P4 assumes parallel semantics for the application of all the primitive actions executing
as a result of a match in a given table."
Does it mean the order of actions are not important?
For example, what should be the result of:
action a (){
modify_field(ethernet.fieldA, 1);
modify_field(ethernet.fieldA, 2);
}
or this (Assuming ethernet is initially invalid):
action a(){
add_header(ethernet[1]);
add_header(ethernet[1]);
}
or this
action a(){
add_header(ethernet[1]);
add_header(ethernet[2]);
}
Generally, any two actions that have overlapping effects.
- What kind of values a table entry's action parameter can have? Is it only
const_value or can it be for example a reference to field or header or ...?
SOLVED: only VAL
- Just to make sure: if a default action in a table is defined and
the default action is taken, 1) is it a hit or miss? 2) does the default case
in a apply and select block gets gets elected?
If nothing matches in the table and there is no default action, does the default case
in a apply and select block gets gets elected?
https://github.com/p4lang/p4-spec/issues/447
(reg. miss: the spec says when no match is found it is a miss, so should not make a difference with default action)
- How exactly deparsing works?
- deparsing:
what happens when there is loop in parser graph?
is the order decided statically or dynamically?
what happens if an action adds a header that is not used in the parser?
- what happens if the unsigned value constant does not fit into the width specified?
is it an error or some implicit conversion happens?
- "For expressions, the value with largest bit width is identified and all other
values are converted to this width according to their own signedness.
The expression is then evaluated"
Does it mean 1 + 1 overflows?
- It seems that there is ambiguity between "-" in const_value and "-" in un_op.
e.g in - 5. Does this make difference in semantics? Because according to the spec
"For positive values the inferred width is the smallest number of bits required
to contain the value. For negative values the inferred width is one more than
the smallest number of bits required to contain the positive value."
and
"For expressions, the value with largest bit width is identified and all other
values are converted to this width according to their own signedness.
The expression is then evaluated"
Does - 5 , if evaluated as - (5) , yields 3 bits or 4 bits?
How about 6 - 5, 3 bits or 4 bits? (or 1 bit?)
How about 5 - 6 ?
https://github.com/p4lang/p4-spec/issues/408
- page 34 Table 5
for FLD, the type desciption says "A field reference of form header_instance.field_name which
refers to the Parsed Representation". Does this mean it can not be of the form for example h[0].f?
- Page 9
Minor:
Is there any width limit in calculation of ((8 * length) - sum-of-fixed-width-fields) ?
length is of type length_exp.
If yes, how is it calculated? If no, why length_exp allows ConstValue which allows specification of width?
- Page 12 section 2.2.2
Minor: "See the proposal in Appendix 17.8.2. Parser Repeat Loops
regarding how they may be parsed."
17.8.2 -> 15.9