BMv2-Simple-Switch.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-The *Simple Switch* target is the de-facto architecture used in P4 development. The *Simple Switch* architecture is an implementation of the *abstract switch model* presented in the [*P4-14* Specification](https://p4.org/p4-spec/p4-14/v1.1.0/tex/p4.pdf) (the first version of the P4 language). The *Simple Switch* target has been implemented using the [*Behavioral Model* (BMv2) library](https://github.com/p4lang/behavioral-model), which is a framework that allows developers to implement their own software P4 targets.
+The *Simple Switch* target is the de-facto architecture used in P4 development. The *Simple Switch* architecture is an implementation of the *abstract switch model* presented in the [**P4_14** Specification](https://p4.org/p4-spec/p4-14/v1.1.0/tex/p4.pdf) (the first version of the P4 language). The *Simple Switch* target has been implemented using the [*Behavioral Model* (BMv2) library](https://github.com/p4lang/behavioral-model), which is a framework that allows developers to implement their own software P4 targets.
 
 The BMv2 repository implements two different versions of the *Simple Switch* that have different control plane interfaces.
 
@@ -20,15 +20,15 @@ The targets, however, still keep the **same** data plane configuration options u
 
 Further details are available in the [control plane documentation page](./Control-Plane).
 
-In the second version of the language (*P4-16*, the one we use in this repository), several backwards-incompatible changes were made to the language and syntax. In particular, a large number of language features were eliminated from the language and moved into libraries including counters, checksum units, meters, etc. And thus, the core of the *P4-16* language has been made very simple and advanced features that are unique to a target architecture are now described in the so called *architecture libraries*. The *v1model* architecture (the one we import at the beginning of every program) is the architecture library for the *Simple Switch* target. It includes the declaration of all the standard metadata and intrinsic metadata fields, extern functions, and switch architecture (or pipeline) package description.
+In the second version of the language (**P4_16**, the one we use in this repository), several backwards-incompatible changes were made to the language and syntax. In particular, a large number of language features were eliminated from the language and moved into libraries including counters, checksum units, meters, etc. And thus, the core of the **P4_16** language has been made very simple and advanced features that are unique to a target architecture are now described in the so called *architecture libraries*. The *v1model* architecture (the one we import at the beginning of every program) is the architecture library for the *Simple Switch* target. It includes the declaration of all the standard metadata and intrinsic metadata fields, extern functions, and switch architecture (or pipeline) package description.
 
-The *P4_16* language also now has a *Portable Switch Architecture* (PSA) defined in [its own specification](https://p4.org/p4-spec/docs/PSA-v1.1.0.pdf). As of September 2018, a partial implementation of the PSA architecture has been done, but it is not yet complete. It will be implemented in a separate executable program named `psa_switch`, different from the `simple_switch` program described here.
+The **P4_16** language also now has a *Portable Switch Architecture* (PSA) defined in [its own specification](https://p4.org/p4-spec/docs/PSA-v1.1.0.pdf). As of September 2018, a partial implementation of the PSA architecture has been done, but it is not yet complete. It will be implemented in a separate executable program named `psa_switch`, different from the `simple_switch` program described here.
 
 In this document we will provide you with important information regarding the `simple_switch` architecture and the *v1model* library.
 
 ## Standard metadata
 
-The [`v1model.p4`](https://github.com/p4lang/p4c/blob/main/p4include/v1model.p4) architecture defines a long list of metadata fields. Each field has a different usage, some are writable others are read only and others are both. Some fields are populated by the switch and give you useful information like the `ingress_port`, timestamps, etc. Other fields can be used to tell the switch what to do (i.e `egress_spec`). For a *P4_16* program using the *v1model* architecture and including the file `v1model.p4`, all of the fields below are part of the struct with type `standard_metadata_t`.
+The [`v1model.p4`](https://github.com/p4lang/p4c/blob/main/p4include/v1model.p4) architecture defines a long list of metadata fields. Each field has a different usage, some are writable others are read only and others are both. Some fields are populated by the switch and give you useful information like the `ingress_port`, timestamps, etc. Other fields can be used to tell the switch what to do (i.e `egress_spec`). For a **P4_16** program using the *v1model* architecture and including the file `v1model.p4`, all of the fields below are part of the struct with type `standard_metadata_t`.
 
 Here are the fields:
 
@@ -36,7 +36,7 @@ Here are the fields:
 
 - `packet_length (bit<32>)`: for new packets from a port, or recirculated packets, the length of the packet in bytes. For cloned or resubmitted packets, you may need to include this in a list of fields to preserve, otherwise its value will become `0`.
 
-- `egress_spec (bit<9>)` can be assigned a value in ingress code to control which output port a packet will go to. The *P4_14* primitive `drop`, and the *v1model* primitive action `mark_to_drop`, have the side effect of assigning an implementation specific value `DROP_PORT` to this field (`511` decimal for `simple_switch` by default, but can be changed through the `--drop-port` target-specific command-line option), such that if `egress_spec` has that value at the end of ingress processing, the packet will be dropped and not stored in the packet buffer, nor sent to egress processing. If your P4 program assigns a value of `DROP_PORT` to `egress_spec`, it will still behave accordingly, even if you never call `mark_to_drop` (*P4_16*) or `drop` (*P4_14*).
+- `egress_spec (bit<9>)` can be assigned a value in ingress code to control which output port a packet will go to. The **P4_14** primitive `drop`, and the *v1model* primitive action `mark_to_drop`, have the side effect of assigning an implementation specific value `DROP_PORT` to this field (`511` decimal for `simple_switch` by default, but can be changed through the `--drop-port` target-specific command-line option), such that if `egress_spec` has that value at the end of ingress processing, the packet will be dropped and not stored in the packet buffer, nor sent to egress processing. If your P4 program assigns a value of `DROP_PORT` to `egress_spec`, it will still behave accordingly, even if you never call `mark_to_drop` (**P4_16**) or `drop` (**P4_14**).
 
 - `egress_port (bit<9>)`: only intended to be accessed during egress processing, read only. The output port this packet is destined to.
 
@@ -51,7 +51,7 @@ Here are the fields:
   #define PKT_INSTANCE_TYPE_RESUBMIT 6
   ```
 
-- `parser_status` or `parser_error`: `parser_status` is the name in the *P4_14* language specification. It has been renamed to `parser_error` in *v1model*. The value `0` or `error.NoError` (according to *P4_16* and *v1model*) means no error. Otherwise, the value indicates what error occurred during parsing. Possible values are:
+- `parser_status` or `parser_error`: `parser_status` is the name in the **P4_14** language specification. It has been renamed to `parser_error` in *v1model*. The value `0` or `error.NoError` (according to **P4_16** and *v1model*) means no error. Otherwise, the value indicates what error occurred during parsing. Possible values are:
   ```
   error {
       NoError,           /// No error.
@@ -64,7 +64,7 @@ Here are the fields:
 
 ### Queueing Metadata
 
-Queueing metadata are populated by the switch when going from the ingress to the egress pipeline. Thus, this metadata fields can only be accessed from the egress pipeline and they are read-only. For a *P4_16* program using the *v1model* architecture and including the file `v1model.p4`, all of the fields below are part of the struct with type `standard_metadata_t`. There is no need to define your own struct type for these fields.
+Queueing metadata are populated by the switch when going from the ingress to the egress pipeline. Thus, this metadata fields can only be accessed from the egress pipeline and they are read-only. For a **P4_16** program using the *v1model* architecture and including the file `v1model.p4`, all of the fields below are part of the struct with type `standard_metadata_t`. There is no need to define your own struct type for these fields.
 
 Here are the fields: