Skip to content

PSA Meeting Minutes Jan 17, 2018

Jump to bottom
Calin Cascaval edited this page Jan 18, 2018 · 1 revision

Attendees:

  • AndyF, Tom,
  • online: Samar, AndyK, James, Calin, Vladimir, Joe Tardo, BapiV

Agenda

Discussion

Release v1.0

  • need Parser Values Sets -- AI: Han to follow up on the opened issue/PR.
  • All to think about issues that may need to be removed or change the semantics
  • AndyK: what test programs do we have? Need experience to finalize the spec
  • Calin: have a definition that people can start implementing. Nate will have a student (Rakesh) who will start an implementation with advice from BFN folks.
  • AndyK: let's be careful with what promises we make in terms of introducing changes.

Packet ordering

  • soften to recommendation and note that targets should document deviation from what is recommended
  • Andy: desirable in certain cases and switch vendors make an effort to guarantee such behaviors
  • Bapi: imposes a memory requirement and the depth of what you support can become a significant issue. Very hard to verify.
  • Andy: no guarantees on how easy is to verify
  • Vladimir, Andy, James: arguing how ordering and having state (register) can impact what programs people write.
  • James: not have it as a requirement. Programs should be able to request that a PSA device enforce packet ordering.
    • Compiler flag to request such behavior and compiler fails if the target can not support such behavior.
    • With the flag on, the compiler is asked to verify that the program is correct against a target that is going to preserve ordering? No, just an architecture property.
  • Andy: there are protocols that are order dependent.
  • Vladimir:
    • order preserved per port for ingress/egress, but not between -- as a requirement?
    • order on the egress port preserved
    • recommendation for PRE behavior for ordering (as we have in the text today)
  • James: recommendation all throughout and flag to check whether it is supported.
  • Tom: uncommon program that really requires this and giving more flexibility to the hw designer is desirable
  • AI: Andy to move to an appendix, make it a recommendation and explain why this is nice to have. Ask for documenting deviations.

Atomicity

  • any table add/modify/delete atomic w.r.t data plane -- explicitly in PSA
  • similar guarantees for externs (action selectors/profiles)
  • Tom: what about batch transactions? No guarantees.
  • Every stateful extern: what is the atomicity behavior from CP perspective?
    • read: is it guaranteed to be an atomic read between packets? Yes, it should be a requirement.
    • write: again atomic w.r.t. data plane guaranteed
    • no CP atomic read/modify/write
  • AI: Andy to add in text to this effect

Counters, meters, and other limits

  • there can be only one direct counters/meters associated with a table.
  • PSA will support the combination of them
  • counters and action selectors are mutually exclusive
  • limits on parameters: issue #478
    • hashes and randoms have power of two limits
    • if there are no power of two, then we need the 3 args
  • Vladimir: one arg method looks better
  • AI: to continue to discuss issue.

Congestion

  • Samar: ECN bit and congestion
  • PRE requirement -- are we willing to impose constraints on the PRE implementation?
  • Is the packet modified in the PRE? No, the current assumption is that the PRE does not modify the header.
  • Vladimir: congestion is typically done between MAC and PRE. PFC packet goes out?
  • Is there a metadata bit that comes out of PRE that reports congestion?
  • Samar: packets that require this should be marked accordingly and only those have the bit marked
  • Vladimir: need to think about flows and how will this work
  • AI: Samar to make a more fleshed out proposal.
Clone this wiki locally