S1-runtime.json range type debugging

Getting Started with P4
1

For s1-runtime.json range type entries, I’m currently using the following format:

{
            "table": "MyIngress.node_4",
            "match": {
                "hdr.ipv4.srcAddr": [
                    0,
                    1073741823
                ],
                "hdr.ipv4.dstAddr": [
                    0,
                    2147483647
                ],
                "hdr.ports.srcPort": [
                    0,
                    32767
                ],
                "hdr.ports.dstPort": [
                    0,
                    65535
                ],
                "hdr.ipv4.protocol": [
                    0,
                    255
                ]
            },
            "priority": 1,
            "action_name": "MyIngress.ipv4_forward",
            "action_params": {
                "port": 2
            }
        },

But I’m running into the following error chain and am having trouble debugging/figuring out what is going wrong. I’m not even sure how to interpret the following: Any help would be greatly appreciated.

image
image1705×728 64.3 KB

To provide additional context, I turned on dry_run in switch.py and for the range entries, got the following output. It all looks in order to me so I’m not sure what is causing all the grpc errors.

- MyIngress.node_4: (default action) => MyIngress.drop()
P4Runtime Write: election_id {
  low: 1
}
updates {
  type: MODIFY
  entity {
    table_entry {
      table_id: 48973626
      action {
        action {
          action_id: 25652968
        }
      }
      is_default_action: true
    }
  }
}

 - MyIngress.node_4: hdr.ipv4.srcAddr=[0, 1073741823], hdr.ipv4.dstAddr=[0, 2147483647], hdr.ports.srcPort=[0, 32767], hdr.ports.dstPort=[0, 65535], hdr.ipv4.protocol=[0, 255] => MyIngress.ipv4_forward(dstAddr=08:00:00:00:02:22, port=2)
P4Runtime Write: election_id {
  low: 1
}
updates {
  type: INSERT
  entity {
    table_entry {
      table_id: 48973626
      match {
        field_id: 1
        range {
          low: "\000\000\000\000"
          high: "?\377\377\377"
        }
      }
      match {
        field_id: 2
        range {
          low: "\000\000\000\000"
          high: "\177\377\377\377"
        }
      }
      match {
        field_id: 3
        range {
          low: "\000\000"
          high: "\177\377"
        }
      }
      match {
        field_id: 4
        range {
          low: "\000\000"
          high: "\377\377"
        }
      }
      match {
        field_id: 5
        range {
          low: "\000"
          high: "\377"
        }
      }
      action {
        action {
          action_id: 28792405
          params {
            param_id: 1
            value: "\010\000\000\000\002\""
          }
          params {
            param_id: 2
            value: "\000\002"
          }
        }
      }
      priority: 2
    }
  }
}

 - MyIngress.node_4: hdr.ipv4.srcAddr=[0, 1073741823], hdr.ipv4.dstAddr=[0, 2147483647], hdr.ports.srcPort=[0, 32767], hdr.ports.dstPort=[16384, 32767], hdr.ipv4.protocol=[0, 255] => MyIngress.ipv4_forward(dstAddr=08:00:00:00:03:33, port=3)
P4Runtime Write: election_id {
  low: 1
}
updates {
  type: INSERT
  entity {
    table_entry {
      table_id: 48973626
      match {
        field_id: 1
        range {
          low: "\000\000\000\000"
          high: "?\377\377\377"
        }
      }
      match {
        field_id: 2
        range {
          low: "\000\000\000\000"
          high: "\177\377\377\377"
        }
      }
      match {
        field_id: 3
        range {
          low: "\000\000"
          high: "\177\377"
        }
      }
      match {
        field_id: 4
        range {
          low: "@\000"
          high: "\177\377"
        }
      }
      match {
        field_id: 5
        range {
          low: "\000"
          high: "\377"
        }
      }
      action {
        action {
          action_id: 28792405
          params {
            param_id: 1
            value: "\010\000\000\000\0033"
          }
          params {
            param_id: 2
            value: "\000\003"
          }
        }
      }
      priority: 1
    }
  }
}
2

I wanted to add on an interesting discovery: when I lower the number of range matches for one table entry from 5 ranges to 3 ranges, the error goes away. Therefore, I played around by modifying the number of range matches in different entries and stumbled across some very undefined indeterministic behavior:

image
image1870×190 22.5 KB

As you can see, in the first table entry, 3 range matches seems to work fine. Then the next entry has 4 range matches which also works fine. Then the next has 5 which suddenly works and it suddenly doesn’t work anymore. This is very inconsistent and something seems to be wrong. There seems to be a correlation between number of range matches and whether it fails or works.
I don’t fully understand the tutorial environment setup and grpc is a bit confusing to me.

Could the grpc error be because of some timeout or input size? I’m really lost on this. For reference, I reattached the original error message:

image
image1549×687 45.4 KB

Also, the s1-p4runtime-requests.txt entry for the problematic table entries shows:
Message too long (1026 bytes)! Skipping log…

3

Another update: I’ve narrowed it down to some issue with size 1024. In p4runtimelib/switch.py, if the message is longer than 1024 length, it doesn’t work. I also noticed the MSG_LOG_MAX_LEN constant is set to 1024. Can someone help explain what is going on and how I can fix this? Thank you