On Wed, Jan 04, 2017 at 01:45:28PM +0200, Paul Blakey wrote: > On 04/01/2017 12:14, Simon Horman wrote: > >On Tue, Jan 03, 2017 at 02:22:05PM +0200, Paul Blakey wrote: > >> > >>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, > >Possibly off-topic but I am curious to know why you need to store the port. > >My possibly naïve assumption is that a filter is attached to the netdev > >corresponding to the input port and mirred or other actions are used to > >output > >to netdevs corresponding to output ports. > > Right, its for the output ports, OVS uses ovs port numbers and mirred action > uses the device ifindex, so there is need > to translate it back to OVS port on dump.
Understood, that is a tedious abstraction to support. But I don't see an easy way around it at this time. If I read Jamal's emails correctly he is working on per-action cookies. They may be better than per-flow cookies for storing the OvS port number (though not the UUID of the flow). ...
