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. > 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.
