readme: Update logs path (p4lang#448)

* readme: remove trailing whitespaces

Signed-off-by: Radostin Stoyanov <[email protected]>

* readme: update path to log files

Fixes: p4lang#447

Signed-off-by: Radostin Stoyanov <[email protected]>

Author: rst0git

exercises/basic/README.md

@@ -10,7 +10,7 @@ With IPv4 forwarding, the switch must perform the following actions
 for every packet: (i) update the source and destination MAC addresses,
 (ii) decrement the time-to-live (TTL) in the IP header, and (iii)
 forward the packet out the appropriate port.
- 
+
 Your switch will have a single table, which the control plane will
 populate with static rules. Each rule will map an IP address to the
 MAC address and output port for the next hop. We have already defined
@@ -105,14 +105,14 @@ A complete `basic.p4` will contain the following components:
 2. **TODO:** Parsers for Ethernet and IPv4 that populate `ethernet_t` and `ipv4_t` fields.
 3. An action to drop a packet, using `mark_to_drop()`.
 4. **TODO:** An action (called `ipv4_forward`) that:
-	1. Sets the egress port for the next hop. 
-	2. Updates the ethernet destination address with the address of the next hop. 
-	3. Updates the ethernet source address with the address of the switch. 
+	1. Sets the egress port for the next hop.
+	2. Updates the ethernet destination address with the address of the next hop.
+	3. Updates the ethernet source address with the address of the switch.
 	4. Decrements the TTL.
 5. **TODO:** A control that:
     1. Defines a table that will read an IPv4 destination address, and
        invoke either `drop` or `ipv4_forward`.
-    2. An `apply` block that applies the table.   
+    2. An `apply` block that applies the table.
 6. **TODO:** A deparser that selects the order
     in which fields inserted into the outgoing packet.
 7. A `package` instantiation supplied with the parser, control, and deparser.
@@ -123,7 +123,7 @@ A complete `basic.p4` will contain the following components:
 ## Step 3: Run your solution
 
 Follow the instructions from Step 1. This time, you should be able to
-sucessfully ping between any two hosts in the topology. 
+sucessfully ping between any two hosts in the topology.
 
 ### Food for thought
 

exercises/basic_tunnel/README.md

@@ -89,47 +89,47 @@ to hosts. For this step you will need to add your forwarding rules to the
 1. In your shell, run:
    ```bash
    make run
-   ``` 
+   ```
    This will:
    * compile `basic_tunnel.p4`, and
    * start a Mininet instance with three switches (`s1`, `s2`, `s3`) configured
      in a triangle, each connected to one host (`h1`, `h2`, and `h3`).
    * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, and `10.0.3.3`.
 
 2. You should now see a Mininet command prompt. Open two terminals for `h1` and
-`h2`, respectively: 
+`h2`, respectively:
   ```bash
   mininet> xterm h1 h2
   ```
 3. Each host includes a small Python-based messaging client and server. In
-`h2`'s xterm, start the server: 
-  ```bash 
+`h2`'s xterm, start the server:
+  ```bash
   ./receive.py
   ```
 4. First we will test without tunneling. In `h1`'s xterm, send a message to
-`h2`: 
+`h2`:
   ```bash
   ./send.py 10.0.2.2 "P4 is cool"
   ```
-  The packet should be received at `h2`. If you examine the received packet 
+  The packet should be received at `h2`. If you examine the received packet
   you should see that is consists of an Ethernet header, an IP header, a TCP
   header, and the message. If you change the destination IP address (e.g. try
   to send to `10.0.3.3`) then the message should not be received by `h2`, and
   will instead be received by `h3`.
-5. Now we test with tunneling. In `h1`'s xterm, send a message to `h2`: 
+5. Now we test with tunneling. In `h1`'s xterm, send a message to `h2`:
   ```bash
   ./send.py 10.0.2.2 "P4 is cool" --dst_id 2
   ```
   The packet should be received at `h2`. If you examine the received packet you
   should see that is consists of an Ethernet header, a tunnel header, an IP header,
-  a TCP header, and the message. 
-6. In `h1`'s xterm, send a message: 
+  a TCP header, and the message.
+6. In `h1`'s xterm, send a message:
   ```bash
   ./send.py 10.0.3.3 "P4 is cool" --dst_id 2
   ```
   The packet should be received at `h2`, even though that IP address is the address
   of `h3`. This is because the switch is no longer using the IP header for routing
-  when the `MyTunnel` header is in the packet. 
+  when the `MyTunnel` header is in the packet.
 7. Type `exit` or `Ctrl-D` to leave each xterm and the Mininet command line.
 
 
@@ -169,7 +169,7 @@ implementation or forwarding rules.
 
 3. `basic_tunnel.p4` might compile, and the control plane rules might be
 installed, but the switch might not process packets in the desired way. The
-`/tmp/p4s.<switch-name>.log` files contain detailed logs that describing how
+`logs/sX.log` files contain detailed logs that describing how
 each switch processes each packet. The output is detailed and can help pinpoint
 logic errors in your implementation.
 

exercises/ecn/README.md

@@ -103,7 +103,7 @@ A complete `ecn.p4` will contain the following components:
 	1. Set the egress port for the next hop.
 	2. Update the ethernet destination address with the address of
            the next hop.
-	3. Update the ethernet source address with the address of the switch. 
+	3. Update the ethernet source address with the address of the switch.
 	4. Decrement the TTL.
 5. An egress control block that checks the ECN and
 `standard_metadata.enq_qdepth` and sets the ipv4.ecn.
@@ -165,12 +165,12 @@ There are several ways that problems might manifest:
    error emitted from the compiler and stop.
 2. `ecn.p4` compiles but does not support the control plane rules in
    the `sX-runtime.json` files that `make` tries to install using
-   a Python controller. In this case, `make` will log the controller output 
+   a Python controller. In this case, `make` will log the controller output
    in the `logs` directory. Use these error messages to fix your `ecn.p4`
    implementation.
 3. `ecn.p4` compiles, and the control plane rules are installed, but
    the switch does not process packets in the desired way.  The
-   `/tmp/p4s.<switch-name>.log` files contain trace messages
+   `logs/sX.log` files contain trace messages
    describing how each switch processes each packet.  The output is
    detailed and can help pinpoint logic errors in your implementation.
    The `build/<switch-name>-<interface-name>.pcap` also contains the

exercises/link_monitor/README.md

@@ -11,7 +11,7 @@ packet such that it is able to pick up the egress link utilization
 at each hop and deliver it to a host for monitoring purposes.
 
 Our probe packet will contain the following three header types:
-``` 
+```
 // Top-level probe header, indicates how many hops this probe
 // packet has traversed so far.
 header probe_t {
@@ -46,7 +46,7 @@ two register arrays:
 * `byte_cnt_reg` - counts the number of bytes transmitted out of
   each port since the last probe packet was transmitted out of
   the port.
-* `last_time_reg` - stores the last time that a probe packet was 
+* `last_time_reg` - stores the last time that a probe packet was
   transmitted out of each port.
 
 Our P4 program will be written for the V1Model architecture implemented
@@ -69,7 +69,7 @@ extend this skeleton program to fill out the fields in the probe
 packet.
 
 Before that, let's compile and test the incomplete `link_monitor.p4`
-program: 
+program:
 
 1. In your shell, run:
    ```bash
@@ -95,7 +95,7 @@ path indicated in link-monitor-topo.png.
    ```
 4. In the other terminal run the `receive.py` script to start
 receiving and parsing the probe packets. This allows us to monitor
-the link utilization within the network. 
+the link utilization within the network.
    ```bash
    ./receive.py
    ```

exercises/load_balance/README.md

@@ -1,4 +1,4 @@
-# Load Balancing 
+# Load Balancing
 
 In this exercise, you will implement a form of load balancing based on
 a simple version of Equal-Cost Multipath Forwarding. The switch you
@@ -25,20 +25,20 @@ up a switch in Mininet to test its behavior.
 1. In your shell, run:
    ```bash
    make
-   ```   
+   ```
    This will:
    * compile `load_balance.p4`, and
    * start a Mininet instance with three switches (`s1`, `s2`, `s3`) configured
      in a triangle, each connected to one host (`h1`, `h2`, `h3`).
-   * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, etc.  
+   * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, etc.
    * We use the IP address 10.0.0.1 to indicate traffic that should be
      load balanced between `h2` and `h3`.
 
 2. You should now see a Mininet command prompt.  Open three terminals
    for `h1`, `h2` and `h3`, respectively:
    ```bash
    mininet> xterm h1 h2 h3
-   ```   
+   ```
 3. Each host includes a small Python-based messaging client and
    server.  In `h2` and `h3`'s XTerms, start the servers:
    ```bash
@@ -113,7 +113,7 @@ fix your `load_balance.p4` implementation.
 
 3. `load_balance.p4` compiles, and the control plane rules are
 installed, but the switch does not process packets in the desired way.
-The `/tmp/p4s.<switch-name>.log` files contain trace messages
+The `logs/sX.log` files contain trace messages
 describing how each switch processes each packet.  The output is
 detailed and can help pinpoint logic errors in your implementation.
 

exercises/mri/README.md

@@ -37,7 +37,7 @@ switch in Mininet to test its behavior.
    * compile `mri.p4`, and
    * start a Mininet instance with three switches (`s1`, `s2`, `s3`) configured
      in a triangle. There are 5 hosts. `h1` and `h11` are connected to `s1`.
-     `h2` and `h22` are connected to `s2` and `h3` is connected to `s3`.     
+     `h2` and `h22` are connected to `s2` and `h3` is connected to `s3`.
    * The hosts are assigned IPs of `10.0.1.1`, `10.0.2.2`, etc
      (`10.0.<Switchid>.<hostID>`).
    * The control plane programs the P4 tables in each switch based on
@@ -128,16 +128,16 @@ store the switch ID and queue depth, and actions that increment the
 A complete `mri.p4` will contain the following components:
 
 1. Header type definitions for Ethernet (`ethernet_t`), IPv4 (`ipv4_t`),
-   IP Options (`ipv4_option_t`), MRI (`mri_t`), and Switch (`switch_t`). 
+   IP Options (`ipv4_option_t`), MRI (`mri_t`), and Switch (`switch_t`).
 2. Parsers for Ethernet, IPv4, IP Options, MRI, and Switch that will
 populate `ethernet_t`, `ipv4_t`, `ipv4_option_t`, `mri_t`, and
 `switch_t`.
 3. An action to drop a packet, using `mark_to_drop()`.
 4. An action (called `ipv4_forward`), which will:
 	1. Set the egress port for the next hop.
 	2. Update the ethernet destination address with the address of
-	the next hop.	
-	3. Update the ethernet source address with the address of the switch. 
+	the next hop.
+	3. Update the ethernet source address with the address of the switch.
 	4. Decrement the TTL.
 5. An ingress control that:
     1. Defines a table that will read an IPv4 destination address, and
@@ -220,7 +220,7 @@ There are several ways that problems might manifest:
 
 3. `mri.p4` compiles, and the control plane rules are installed, but
    the switch does not process packets in the desired way. The
-   `/tmp/p4s.<switch-name>.log` files contain trace messages
+   `logs/sX.log` files contain trace messages
    describing how each switch processes each packet. The output is
    detailed and can help pinpoint logic errors in your implementation.
    The `build/<switch-name>-<interface-name>.pcap` also contains the

exercises/multicast/README.md

@@ -23,7 +23,7 @@ connects four hosts as follow:
                 h1       h2
                  \      /
                   \    /
-                    s1  
+                    s1
                   /    \
                  /      \
                h3        h4

exercises/qos/README.md

@@ -78,7 +78,7 @@ missing piece.
 First we have to change the ipv4_t header by splitting the TOS field
 into DiffServ and ECN fields.  Remember to update the checksum block
 accordingly.  Then, in the egress control block we must compare the
-protocol in IP header with IP protocols. Based on the traffic classes 
+protocol in IP header with IP protocols. Based on the traffic classes
 and priority, the `diffserv` flag will be set.
 
 A complete `qos.p4` will contain the following components:
@@ -102,7 +102,7 @@ A complete `qos.p4` will contain the following components:
 
 Follow the instructions from Step 1. This time, when your message from
 `h1` is delivered to `h2`, you should see `tos` values change from 0x1
-to  0xb9 for UDP and 0xb1 for TCP. It depends upon the action you choose 
+to  0xb9 for UDP and 0xb1 for TCP. It depends upon the action you choose
 in Ingress processing.
 
 To easily track the `tos` values you may want to redirect the output
@@ -148,7 +148,7 @@ There are several ways that problems might manifest:
    implementation.
 3. `qos.p4` compiles, and the control plane rules are installed, but
    the switch does not process packets in the desired way.  The
-   `/tmp/p4s.<switch-name>.log` files contain trace messages
+   `logs/sX.log` files contain trace messages
    describing how each switch processes each packet.  The output is
    detailed and can help pinpoint logic errors in your implementation.
    The `build/<switch-name>-<interface-name>.pcap` also contains the

exercises/source_routing/README.md

@@ -60,13 +60,13 @@ bring up a network in Mininet to test its behavior.
 5. Type a list of port numbers. say `2 3 2 2 1`.  This should send the
    packet through `h1`, `s1`, `s2`, `s3`, `s1`, `s2`, and
    `h2`. However, `h2` will not receive the message.
-   
+
 6. Type `q` to exit send.py and type `exit` to leave each xterm and
    the Mininet command line.
 
 The message was not received because each switch is programmed with
 `source_routing.p4`, which drops all packets on arrival.  You can
-verify this by looking at `/tmp/p4s.s1.log`.  Your job is to extend
+verify this by looking at `logs/s1.log`.  Your job is to extend
 the P4 code so packets are delivered to their destination.
 
 ## Step 2: Implement source routing
@@ -84,7 +84,7 @@ A complete `source_routing.p4` will contain the following components:
    `ethernet` and `srcRoutes` fields.
 3. An action to drop a packet, using `mark_to_drop()`.
 4. **TODO:** An action (called `srcRoute_nhop`), which will:
-	1. Set the egress port for the next hop. 
+	1. Set the egress port for the next hop.
 	2. remove the first entry of srcRoutes
 5. A control with an `apply` block that:
     1. checks the existence of source routes.
@@ -123,7 +123,7 @@ There are several ways that problems might manifest:
    Do you have another instance of mininet running? Did the previous
    run of mininet crash?  if yes, check "Cleaning up Mininet" bellow.
 3. `source_routing.p4` compiles but the switch does not process
-   packets in the desired way. The `/tmp/p4s.<switch-name>.log`
+   packets in the desired way. The `logs/sX.log`
    files contain trace messages describing how each switch processes
    each packet. The output is detailed and can help pinpoint logic
    errors in your implementation.  The