PSA Add extern to make switch port status readable to P4 programs

[jafingerhut]

If a P4 program could read the up/down status of one or all physical ports during packet processing, it could help implement some forms of fast re-route of traffic to go around failed links.

While the ability to read the status of a single port given the port number (as a value of type PortId_t) is potentially useful, I would guess that it is more useful to be able to read a value of type bit<N> to get the up/down status of all physical ports in a single operation, since P4 does not really allow loops, but does support operations on wide bit vectors.

I am sure that one issue that would arise here is whether such a bit vector would have lots of "useless bits" in it, in case the numeric space of physical port ids is sparse in the range 0 through N-1.

[jafingerhut]

To flesh out one possible approach on this issue:

You call some new extern function psa_port_status (out bit<N> ports_up_down) where N is at least the number of physical ports on the device. Since that can vary from one device to another, we define a new PSA custom type, like the existing 7 PSA types whose bit widths can vary from one implementation to another, e.g. PortId_t.  Bit position j is equal to 1 if the port is up, 0 if it is down.  P4 code can do whatever it wants with that value, or not call the extern at all.   Note: In an actual implementation, the value you read might continue to be 1 for a short time after the port goes down, because of the time for hardware and software to detect that it has gone down.  The idea of such an extern is that the failure of port j would cause bit position j to become 0 within a very short time period, as fast as the platform is able to detect this change.   What could P4 code possibly do with this?  Whatever it wants, of course, but for example, one could imagine using it to bitwise AND with some bit vector of ports that are on shortest paths, and only pick among the ones that are up.  Or the P4 program could examine bit position j after j was determined to be the 1st choice of output port, and if the 1st choice port is down, run some more P4 code to pick a 2nd choice.   People would still want the control plane to respond on a slower time scale by updating routes, LAG memberships, etc.  This mechanism would enable P4 code developers to respond on the shortest possible time scale, perhaps in a non-optimal way.

[vgurevich]

What is the advantage of having a dedicated extern, compared to a table with a single entry that returns such a bitmap? Or a table with the egress_port being the key that returns 0 or 1?

Please, keep in mind that:

1. On many devices port state needs to be communicated to the data plane via the control plane anyway
2. For the bitmap to be useful, the device needs to support shifts by the amount specified at runtime (and in many case the bitmaps will be quite wide). This is not a common feature

[jafingerhut]

control pstatus (out bit<N> s) {
action get_port_status (out bit<N> status) {
    tbd = status;
}
table port_status {
    // no key
    actions = { get_port_status; }
    const default_action = get_port_status;
}
apply {
    port_status.apply(): 
}
}