Messages in this thread | | | Subject | Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs | From | Alexei Starovoitov <> | Date | Tue, 20 Oct 2015 11:44:51 -0700 |
| |
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 :)
| |