# Re: [GIT PULL] kdbus for 4.1-rc1

From: Borislav Petkov
Date: Thu Apr 23 2015 - 16:56:56 EST

On Thu, Apr 23, 2015 at 09:14:33PM +0200, Greg Kroah-Hartman wrote:
> I don't know what O(256) means here, O notation usually is used to
> show the complexity of a function, so this really is almost always the
> same amount of time, based on using the hash function.

This is iterating over 256 hash buckets. So O(n) complexity. Better?

> Yes, these looks like a lot of stuff but it's still really fast.

"really fast" - that's the right way to quantify things, right? Let me

> And we need it.

*Of* *course* you need it, what else. Lemme guess: there's no other
way to do this than the way it was done now, right? And we should stop
asking such stupid questions and accept it... Yeah, of course.

> Hm, this seems to be to be O(1), pretty constant, we do the same amount
> of work all the time.

The same *pile* of unnecessary and needless work. You go and collect
*all* that data on *every* packet send?!

How many packets per second are we talking here? 100, 1000, 10000...?

Let's say you're "really fast" because you've bought a "bigger machine"
and do that information collection per packet for, say 10 microseconds
(I'm probably too generous here but whatever).

So at peak rates of 10000 packets per second, and 10Âs preparation time
per packet, you're wasting 100000 Âs == 100 msec, i.e. 1/10th of a
second you're busy only with sending packets.

Hmm, but then the receiving side needs CPU time too...

Oh yeah, and then those pesky userspace processes need some CPU time
too...

Are you really serious or is this some tactic of deliberately asking
dumb questions? Let me know now so that I can stop wasting my time.

> I don't understand what a token provides that is different from what is
> happening here, please explain. How can that be faster than what we do
> today?

A token-based scheme would give you significantly less traffic;
throw the metadata collecting in the garbage can:

Example:

* A daemon issues a token, say, a capability to reboot.

* It gives that token (with the kernel as intermediary) to a recipient
which should be allowed to reboot.

* recipient can drop privileges, run in a sandbox, whatever, it still
has that token.

That's exactly one packet sent *without* any information collection.
Recipient has to authenticate itself to the kernel when requesting the
packet.

Clean and simple.

--
Regards/Gruss,
Boris.