Message-ID: <786655e9-de6a-29e9-a043-207afedcedc2@mellanox.com>
Date:   Wed, 4 Jan 2017 13:45:28 +0200
From:   Paul Blakey <paulb@...lanox.com>
To:     Simon Horman <simon.horman@...ronome.com>
CC:     <paulb@...lanox.com>, Jamal Hadi Salim <jhs@...atatu.com>,
        John Fastabend <john.fastabend@...il.com>,
        "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Hadar Hen Zion <hadarh@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Roi Dayan <roid@...lanox.com>, Roman Mashak <mrv@...atatu.com>
Subject: Re: [PATCH net-next] net/sched: cls_flower: Add user specified data



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.

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

Powered by blists - more mailing lists