On 17-01-02 05:58 PM, John Fastabend wrote:
On 17-01-02 02:21 PM, Jamal Hadi Salim wrote:
Well having the length value avoids ending up with cookie1, cookie2, ... values as folks push more and more data into the cookie.
Unless there is good reason I dont see why it shouldnt be a fixed length value. u64/128 should be plenty.
I don't see any use in the kernel interpreting it. It has no use for it as far as I can see. It doesn't appear to be metadata which we use skb->mark for at the moment.
Like all cookie semantics it is for storing state. The receiver (kernel) is not just store it and not intepret it. The user when reading it back simplifies what they have to do for their processing.
The tuple <ifindex:qdisc:prio:handle> really should be unique why not use this for system wide mappings?
I think on a single machine should be enough, however: typically the user wants to define the value in a manner that in a distributed system it is unique. It would be trickier to do so with well defined values such as above.
The only thing I can think to do with this that I can't do with the above tuple and a simple userspace lookup is stick hardware specific "hints" in the cookie for the firmware to consume. Which would be very helpful for what its worth.
Ok, very different from our use case with actions. We just use those values to map to stats info without needing to know what flow or action (graph) it is associated with.
Its a bit strange to push it as an action when its not really an action in the traditional datapath.
The action is part of a graph pointed to by a filter.
I suspect the OVS usage is a simple 1:1 lookup from OVS id to TC id to avoid a userspace map lookup.
Not that i care about OVS but it sounds like a good use case (even for tc), no? cheers, jamal
