Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs

From: Alexei Starovoitov
Date: Tue Oct 20 2015 - 14:45:01 EST


On 10/20/15 3:07 AM, Hannes Frederic Sowa wrote:
<off-topic>
Just a pretty obvious idea is accurate sampling of flows.
</off-topic>

ok, so you want to time out flows. Makes sense, but it should be
done by user space with little or none help from the kernel.

fdinfo tells me where my position in a file is and which locks the file
have?

obviously not. see the example fdinfo from the other email.

So far, if someone wants to delve into the details of a map my approach
would be to take the file descriptor and make it persistence. I have to
think about that some more.

nope. you cannot do that. admin should never interfere with running
process this way.

Yes, absolutely and I am absolutely against pretty printing key values
in kernel domain.

let's table that part. I think it can be useful, but it's
irrelevant for this discussion.

So cat-ing them will produce text output with some details about the
map? This is what I wanted to avoid. The concept with symlinks and small
files seems much cleaner and nicer to me. Also you cannot add writable
attributes to this filesystem or you overload stuff heavily?

nope. no writeable stuff. fdinfo is read-only.

It is not a tree but a graph, sure, that's why sysfs allows to break the
cyclic dependencies and create symlinks (see holders/ directories). ;)

that's an obvious example of another resource waste.
You can do that for real devices, but for thousands of maps and programs
it is really a waste.

And if you implement the same set of features IMHO you basically
re-implement sysfs. In the beginning we just expose the basic maps and
there won't be any features in sysfs, but it will be cheap to have
read/write flags on maps etc. etc. (I don't know what people will come
up with, yet.). In my opinion those are clearly attributes of a map and
should be defined and managed alongside with their holders.

nope. bpf syscall is the only interface to access maps.
if we expose them in bpffs it will be read-only for debugging only.

The pinfd feature will provide the future infrastructure alongside to
make this usable, so I think it is worth spending time to think about
it.

yes. but since we're going in circles, let's have a 'beer call' to
resolve it :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/