You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are hoping to release a PSA v1.0 specification by 2018-Feb-24. We plan to have a "release candidate" version of the document by 2018-Feb-10. We plan to include the types below, intended to be used in packet headers between controllers and PSA devices. We intend to restrict these types to be multiples of 8 bits wide so any subset of them may be used within packet headers, even for P4-programmable devices where the headers are restricted to be a multiple of 8 bits long.
Because they are intended to be used in P4 source code for sending packets to the controller, or receive packets from a controller, we want them to be wide enough for use by all PSA v1.0 compliant devices.
If we make them a little bit wider than necessary, the worst result I can think of is more bytes in packet headers between PSA devices and controllers.
If we make them too narrow, the worst result is that some PSA devices will not be able to take advantage of the scale they designed into themselves for these quantities. That is a far worse result than a few more bytes in packet headers, hence the reason for creating this issue.
Why not just make them all 64 bits and be done with it? I suppose we could, but my mind just kind of recoils from using 64 bits for carrying a ClassOfService_t field that probably will only ever need 3 bits, even if the extra 61 bits only show up in packet headers between controller and PSA device. Maybe you should tell me to just suppress that feeling and be happy with 64-bit widths for all of these types. I think I could do that.
NOTE: PSA is still planning to have other typedefs, like the ones above, but without "InHeader" in the type names, that can have a different width on each PSA device. This allows P4 compilers for each device to economize on bit storage in the data plane when these fields are used as table search keys, or action parameters, etc.
The text was updated successfully, but these errors were encountered:
The only comment I have received on this was to increase the 16-bit wide PortIdInHeader_t to 32 bits wide. That change did not make it in time for PSA v1.0, but it has been committed to the latest working version of the PSA spec, which will be included in the next published version, perhaps called PSA v1.1.
@samar-abdi @vgurevich @cc10512 @gbrebner @antoninbas
Feel free to call attention to this issue to anyone else you think should review it.
We are hoping to release a PSA v1.0 specification by 2018-Feb-24. We plan to have a "release candidate" version of the document by 2018-Feb-10. We plan to include the types below, intended to be used in packet headers between controllers and PSA devices. We intend to restrict these types to be multiples of 8 bits wide so any subset of them may be used within packet headers, even for P4-programmable devices where the headers are restricted to be a multiple of 8 bits long.
Because they are intended to be used in P4 source code for sending packets to the controller, or receive packets from a controller, we want them to be wide enough for use by all PSA v1.0 compliant devices.
If we make them a little bit wider than necessary, the worst result I can think of is more bytes in packet headers between PSA devices and controllers.
If we make them too narrow, the worst result is that some PSA devices will not be able to take advantage of the scale they designed into themselves for these quantities. That is a far worse result than a few more bytes in packet headers, hence the reason for creating this issue.
Why not just make them all 64 bits and be done with it? I suppose we could, but my mind just kind of recoils from using 64 bits for carrying a ClassOfService_t field that probably will only ever need 3 bits, even if the extra 61 bits only show up in packet headers between controller and PSA device. Maybe you should tell me to just suppress that feeling and be happy with 64-bit widths for all of these types. I think I could do that.
NOTE: PSA is still planning to have other typedefs, like the ones above, but without "InHeader" in the type names, that can have a different width on each PSA device. This allows P4 compilers for each device to economize on bit storage in the data plane when these fields are used as table search keys, or action parameters, etc.
The text was updated successfully, but these errors were encountered: