Can the table property 'add-on-miss' co-exist with 'pna_direct_counter' or 'pna_direct_meter' ? about pna HOT 7 OPEN

Proposal for consideration:

It seems fairly straightforward to define what it means to define a table with both add_on_miss=true, and a direct counter. That is, when a new entry is added, the initial value of the packet/byte counters associated with the new table entry are 0. Note that this would avoid counting the packet/byte count of the packet that caused the entry to be added, but perhaps that is acceptable. I suppose if someone really wanted to get fancy, the add_entry call could somehow specify the initial value of the packet/byte counters of the direct counter associated with the new entry.

For a table that combines add_on_miss=true and a direct meter, the biggest question in my mind is how that new entry gets its meter peak/committed rate and bucket size configured. One answer would be that there is a defined control plane API that gives the same default configuration for every table entry added by the data plane. Another would be that the add_entry() call should have additional parameters that specify this meter configuration for the new entry.

Of course, as usual, implementations would be able to document "I don't implement these combinations of features on the same table", but it does seem reasonable to define what their behavior should be for implementations that want to implement the combination.

from pna.

Any table, including the add-on-miss table, should support a direct counter. The data plane could use the counter. Regarding meter, only if the add-on-miss table is used by metering, the question arises if the table should support a direct meter and the table should.

from pna.

Just wanted to say that this question is a good one. We should nail it down.

from pna.

I am trying to understand the scenario or Use Case that requires "add_on_miss" with "pna_direct_counter" or "pna_direct_meter".

Assumed, the table is enabled with "add-on-miss" property + “pna_direct_counter”

For direct counter, it is true that we do not required initial configuration, new entries can start with
counter value 0.
The question here is, not how do we implement! rather How or When to use this feature ?

1. Can this counter information collected by control plane ?
   I doubt! since the control plane does not know the table entry information as it is added by data plane.

2. Is this counter values can be used in the data plane itself ? Then,
   What is the Use Case ?
   (or)
   When the data plane is needed to use the counter value of the table entry ? Why ?

If control plane or data plane is not going to use this counters then why do we need to enable ?

The same question applies for the "pna_direct_meter", when and why it is required with add_on_miss ?

from pna.

The control plane might not know the entries added by the data plane as they are added, but as long as the control plane supports a "read all entries and their counters" API, which I believe at least P4Runtime API and TDI do, and seems like a reasonable thing to expect most control plane APIs to support, the control plane could retrieve the current key, action, and counter values for what happens to be in that table right now.

I grant you that if the table has add_on_miss=true and ALSO does data plane deletions on idle timeout, then there is NO guarantee that the control plane will ever see an entry that was added, if it does not read the entries often enough. There is also NO guarantee that the control plane will know about the "final" counter values of an entry just before the data plane deletes it, unless the data plane supports an option to send the key/action + counter values of data-plane-deleted entries as it deletes them, which is likely to be a lossy communication channel if data-plane-delete-of-entries is faster than the control plane can keep up with.

One could also imagine an add_on_miss=true table that only allows the control plane to delete entries. I don't know if anyone has good use cases for such a thing, given that if you don't want the overhead of adding new table entries for new flows in the control plane, you probably also don't want the control plane load for deleting old entries, either.

I'm not claiming that I think we should REQUIRE implementations to support these combinations. I am trying to propose what behavior would make sense, if a target implemented this combination. Whether it is useful or not, for the reasons stated above, it really depends upon why you want the direct counters associated with such a table.

If it is for "I guarantee I export a count of every packet on every table entry, with no losses", then that requires no losses in exporting all this data for deleted entries from the data plane to the control plane, which sounds like a fairly special situation to me that someone would want to implement that.

If it is for a case where the control plane gets a best-effort view of some of the packet/byte counts, but knows that it will typically be missing out on many of those, then it sounds fairly straightforward to implement.

from pna.

@kamalakannanr89 Are you interested in creating a PR for the PNA specification document that would start by saying that the combination of add_on_miss=true and direct resources on a table are not specified by PNA, and need not be supported?

We can always define what supporting those combinations means later, if there is a desire by the working group to do so.

from pna.

Yes, I will create the PR with changes.

from pna.