On 03/01/2017 13:44, Jamal Hadi Salim wrote:
On 17-01-02 11:33 PM, John Fastabend wrote:
On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:
[..]
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.
Just extend the tuple <hostname:ifindex:qdisc:prio:handle> that
should be unique in the domain of hostname's, or use some other domain
wide machine identifier.
May work for the case of filter identification. The nice thing for
allowing cookies is you can let the user define it define their
own scheme.
Although actions can be shared so the cookie can be shared across
filters. Maybe its useful but it doesn't uniquely identify a filter
in the shared case but the user would have to specify that case
so maybe its not important.
Note: the action cookies and filter cookies are unrelated/orthogonal.
Their basic concept of stashing something in the cookie to help improve
what user space does (in our case millions of actions of which some are
used for accounting) is similar.
I have no objections to the flow cookies; my main concern was it should
be applicable to all classifiers not just flower. And the arbitrary size
of the cookie that you pointed out is questionable.
cheers,
jamal
Hi all,
Our use case is replacing OVS rules with TC filters for HW offload, and
you're are right the cookie would
have saved us the mapping from OVS rule ufid to the tc filter
handle/prio... that was generated for it.
It also was going to be used to store other info like which OVS output
port corresponds to the ifindex,
so we need 128+32 for now. It helps us with dumping the the flows back,
when we lose data on crash
or restarting the user space daemon.
HW hints is another thing that might be helpful.
Its binary blob because user/app specifc and its usage might change in
the future and its and that's why there
is some headroom with size as well.
I don't mind having it on TC level but I didn't want to intervene with
all filters/TC.
