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  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]
Date:   Mon, 2 Jan 2017 20:22:23 -0500
From:   Jamal Hadi Salim <>
To:     John Fastabend <>,
        Paul Blakey <>,
        "David S. Miller" <>,
Cc:     Jiri Pirko <>,
        Hadar Hen Zion <>,
        Or Gerlitz <>,
        Roi Dayan <>, Roman Mashak <>,
        Simon Horman <>
Subject: Re: [PATCH net-next] net/sched: cls_flower: Add user specified data

On 17-01-02 05:58 PM, John Fastabend wrote:
> On 17-01-02 02:21 PM, Jamal Hadi Salim wrote:

> Well having the length value avoids ending up with cookie1, cookie2, ...
> values as folks push more and more data into the cookie.

Unless there is good reason I dont see why it shouldnt be a fixed length
value. u64/128 should be plenty.

> I don't see any use in the kernel interpreting it. It has no use
> for it as far as I can see. It doesn't appear to be metadata which
> we use skb->mark for at the moment.

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.

> The only thing I can think to do with this that I can't do with
> the above tuple and a simple userspace lookup is stick hardware specific
> "hints" in the cookie for the firmware to consume. Which would be
> very helpful for what its worth.

Ok, very different from our use case with actions.
We just use those values to map to stats info without needing to
know what flow or action (graph) it is associated with.

> Its a bit strange to push it as an action when its not really an
> action in the traditional datapath.

The action is part of a graph pointed to by a filter.

> I suspect the OVS usage is a simple 1:1 lookup from OVS id to TC id to
> avoid a userspace map lookup.

Not that i care about OVS but it sounds like a good use case (even for
tc), no?


Powered by blists - more mailing lists