-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wildcard read vs "Don't care" entry read #462
Comments
This issue came up in the GenericTable discussion and we found out that this issue was present in p4runtime outside GenericTables too |
That's a real issue, and I wished that we had wrapped the Even if one feels that in order to read "one entry which has all don't care bits", one has to provide the correct |
Do you think it makes sense to wrap both |
I thought of that too:
Unfortunately, it doesn't seem to work for all the cases we currently support or want to support. For example, if I provide
|
I would suggest that if you are designing new message formats for GenericTable, and you want to support wildcard reads that can match 0 or more entries installed in the device and return all matching ones, that you strongly consider an approach where there is a completely separate field or fields in a read request message, e.g. a new boolean field wildcardRead, that when false means that the read is always targeting at most one entry, and when true means that the read is definitely targeting all matching entries (and that you then precisely define what a matching entry means, vs. what is in the message). Anything else seems to me to lead to very subtle edge cases. |
That still wouldn't let you read all entries where a particular field was a wild card or something like that though. One possible scheme that I think allows everything we want is to make the meaning of omitting a match field in a write request and read request a bit different:
Or something like that. |
@jonathan-dilorenzo |
Ah, sorry. When I say 'with the mask set to 0' I suppose I mean just an empty match field message as supposed to an omitted one (which are distinguishable in the wire protocol, and the former isn't allowed in write requests). |
The spec has guidelines for wildcard reads here.
But if there exists a table with just ternary fields and there is one entry which has all don't care bits, there is no way to specify whether user wants to execute wildcard read or reading that specific don't care read.
The text was updated successfully, but these errors were encountered: