netdev - Re: [PATCH net-next] net/sched: cls_flower: Add user specified data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170104101437.GB24762@penelope.horms.nl>
Date:   Wed, 4 Jan 2017 11:14:39 +0100
From:   Simon Horman <simon.horman@...ronome.com>
To:     Paul Blakey <paulb@...lanox.com>
Cc:     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 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.