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

On 10/22/2015 09:35 PM, Eric W. Biederman wrote: Daniel Borkmann writes: On 10/20/2015 08:56 PM, Eric W. Biederman wrote: ... Just FYI: Using a device for this kind of interface is pretty much a non-starter as that quickly gets you into situations where things do not work in containers. If

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

On 10/22/2015 09:35 PM, Eric W. Biederman wrote: Daniel Borkmann writes: On 10/20/2015 08:56 PM, Eric W. Biederman wrote: ... Just FYI: Using a device for this kind of interface is pretty much a non-starter as that quickly gets you into situations where things do not

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

Daniel Borkmann writes: > On 10/20/2015 08:56 PM, Eric W. Biederman wrote: > ... >> Just FYI: Using a device for this kind of interface is pretty >> much a non-starter as that quickly gets you into situations where >> things do not work in containers. If someone gets a version of device >>

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

On 10/22/2015 12:44 AM, Alexei Starovoitov wrote: ... all users) When you have to hack drivers/base/core.c to get there it should have been a warning sign that something is wrong with this cdev approach. Hmm, you know, this had nothing to do with it, merely to save ~20 LoC that I can do just

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

Daniel Borkmann writes: > On 10/20/2015 08:56 PM, Eric W. Biederman wrote: > ... >> Just FYI: Using a device for this kind of interface is pretty >> much a non-starter as that quickly gets you into situations where >> things do not work in containers. If someone gets a

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

On 10/22/2015 12:44 AM, Alexei Starovoitov wrote: ... all users) When you have to hack drivers/base/core.c to get there it should have been a warning sign that something is wrong with this cdev approach. Hmm, you know, this had nothing to do with it, merely to save ~20 LoC that I can do just

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

On 10/21/15 11:34 AM, Thomas Graf wrote: So far, during this discussion, it was proposed to modify the file system >to a single-mount one and to stick this under/sys/kernel/bpf/. This >will not have "real" namespace support either, but it was proposed to >have a following structure: > >

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

On 10/21/15 at 05:17pm, Daniel Borkmann wrote: > On 10/20/2015 08:56 PM, Eric W. Biederman wrote: > ... > >Just FYI: Using a device for this kind of interface is pretty > >much a non-starter as that quickly gets you into situations where > >things do not work in containers. If someone gets a

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

On 10/20/2015 08:56 PM, Eric W. Biederman wrote: ... Just FYI: Using a device for this kind of interface is pretty much a non-starter as that quickly gets you into situations where things do not work in containers. If someone gets a version of device namespaces past GregKH it might be up for

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

On 10/20/2015 08:56 PM, Eric W. Biederman wrote: ... Just FYI: Using a device for this kind of interface is pretty much a non-starter as that quickly gets you into situations where things do not work in containers. If someone gets a version of device namespaces past GregKH it might be up for

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

On 10/21/15 at 05:17pm, Daniel Borkmann wrote: > On 10/20/2015 08:56 PM, Eric W. Biederman wrote: > ... > >Just FYI: Using a device for this kind of interface is pretty > >much a non-starter as that quickly gets you into situations where > >things do not work in containers. If someone gets a

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

On 10/21/15 11:34 AM, Thomas Graf wrote: So far, during this discussion, it was proposed to modify the file system >to a single-mount one and to stick this under/sys/kernel/bpf/. This >will not have "real" namespace support either, but it was proposed to >have a following structure: > >

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

Alexei Starovoitov writes: > On 10/20/15 1:46 AM, Daniel Borkmann wrote: >>> as we discussed in this thread and earlier during plumbers I think >>> it would be good to expose key/values somehow in this fs. >>> 'how' is a big question. >> >> Yes, it is a big question, and probably best left to

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

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

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

On 10/20/15 1:46 AM, Daniel Borkmann wrote: as we discussed in this thread and earlier during plumbers I think it would be good to expose key/values somehow in this fs. 'how' is a big question. Yes, it is a big question, and probably best left to the domain-specific application itself, which

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

Hello Alexei, On Tue, Oct 20, 2015, at 03:09, Alexei Starovoitov wrote: > On 10/19/15 4:02 PM, Hannes Frederic Sowa wrote: > > I bet commercial software will make use of this ebpf framework, too. And > > the kernel always helped me and gave me a way to see what is going on, > > debug which part

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

Hey Alexei, On Tue, Oct 20, 2015, at 02:30, Alexei Starovoitov wrote: > On 10/19/15 3:17 PM, Daniel Borkmann wrote: > > On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: > >> On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: > >>> > >>> I doubt it will stay a lightweight feature as it should not

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

On 10/20/2015 02:30 AM, Alexei Starovoitov wrote: On 10/19/15 3:17 PM, Daniel Borkmann wrote: On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space

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

On 10/20/2015 02:30 AM, Alexei Starovoitov wrote: On 10/19/15 3:17 PM, Daniel Borkmann wrote: On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space

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

Hey Alexei, On Tue, Oct 20, 2015, at 02:30, Alexei Starovoitov wrote: > On 10/19/15 3:17 PM, Daniel Borkmann wrote: > > On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: > >> On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: > >>> > >>> I doubt it will stay a lightweight feature as it should not

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

Hello Alexei, On Tue, Oct 20, 2015, at 03:09, Alexei Starovoitov wrote: > On 10/19/15 4:02 PM, Hannes Frederic Sowa wrote: > > I bet commercial software will make use of this ebpf framework, too. And > > the kernel always helped me and gave me a way to see what is going on, > > debug which part

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

On 10/20/15 1:46 AM, Daniel Borkmann wrote: as we discussed in this thread and earlier during plumbers I think it would be good to expose key/values somehow in this fs. 'how' is a big question. Yes, it is a big question, and probably best left to the domain-specific application itself, which

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

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

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

Alexei Starovoitov writes: > On 10/20/15 1:46 AM, Daniel Borkmann wrote: >>> as we discussed in this thread and earlier during plumbers I think >>> it would be good to expose key/values somehow in this fs. >>> 'how' is a big question. >> >> Yes, it is a big question, and

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

On 10/19/15 4:02 PM, Hannes Frederic Sowa wrote: I bet commercial software will make use of this ebpf framework, too. And the kernel always helped me and gave me a way to see what is going on, debug which part of my operating system universe interacts with which other part. Merely dropping file

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

On 10/19/15 3:17 PM, Daniel Borkmann wrote: On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space to provide those debug facilities. It feels we're

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

Hello Alexei, On Mon, Oct 19, 2015, at 22:48, Alexei Starovoitov wrote: > On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: > > > > I doubt it will stay a lightweight feature as it should not be in the > > responsibility of user space to provide those debug facilities. > > It feels we're talking

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

On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space to provide those debug facilities. It feels we're talking past each other. I want to solve

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

On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space to provide those debug facilities. It feels we're talking past each other. I want to solve 'persistent map' problem. debugging of maps/progs,

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

Hi Alexei, On Mon, Oct 19, 2015, at 21:34, Alexei Starovoitov wrote: > On 10/19/15 11:46 AM, Hannes Frederic Sowa wrote: > > Hi, > > > > On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote: > >> On 10/19/15 10:37 AM, Daniel Borkmann wrote: > >>> An eBPF program or map loading/destruction is

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

On 10/19/15 11:46 AM, Hannes Frederic Sowa wrote: Hi, On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote: On 10/19/15 10:37 AM, Daniel Borkmann wrote: An eBPF program or map loading/destruction is *not* by any means to be considered fast-path. We currently hold a global mutex during

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

Hi, On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote: > On 10/19/15 10:37 AM, Daniel Borkmann wrote: > > An eBPF program or map loading/destruction is *not* by any means to be > > considered fast-path. We currently hold a global mutex during loading. > > So, how can that be considered

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

On 10/19/15 10:37 AM, Daniel Borkmann wrote: An eBPF program or map loading/destruction is *not* by any means to be considered fast-path. We currently hold a global mutex during loading. So, how can that be considered fast-path? Similarly, socket creation/ destruction is also not fast-path, etc.

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

On 10/19/2015 06:22 PM, Alexei Starovoitov wrote: On 10/19/15 7:23 AM, Daniel Borkmann wrote: The mknod is not the holder but rather the kobject which should be represented in sysfs will be. So you can still get the map major:minor by looking up the /dev file in the correspdonding sysfs

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

On 10/19/15 7:23 AM, Daniel Borkmann wrote: The mknod is not the holder but rather the kobject which should be represented in sysfs will be. So you can still get the map major:minor by looking up the /dev file in the correspdonding sysfs directory or I think we should provide a 'unbind' file,

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

On 10/19/2015 11:51 AM, Daniel Borkmann wrote: On 10/19/2015 09:36 AM, Hannes Frederic Sowa wrote: On Sun, Oct 18, 2015, at 22:59, Alexei Starovoitov wrote: On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here:

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

On 10/19/2015 09:36 AM, Hannes Frederic Sowa wrote: Hi, On Sun, Oct 18, 2015, at 22:59, Alexei Starovoitov wrote: On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here:

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

Hi, On Sun, Oct 18, 2015, at 22:59, Alexei Starovoitov wrote: > On 10/18/15 9:49 AM, Daniel Borkmann wrote: > > Okay, I have pushed some rough working proof of concept here: > > > > https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5 > > > > So the idea eventually had to

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

Hi, On Sun, Oct 18, 2015, at 22:59, Alexei Starovoitov wrote: > On 10/18/15 9:49 AM, Daniel Borkmann wrote: > > Okay, I have pushed some rough working proof of concept here: > > > > https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5 > > > > So the idea eventually had to

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

On 10/19/2015 09:36 AM, Hannes Frederic Sowa wrote: Hi, On Sun, Oct 18, 2015, at 22:59, Alexei Starovoitov wrote: On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here:

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

On 10/19/2015 11:51 AM, Daniel Borkmann wrote: On 10/19/2015 09:36 AM, Hannes Frederic Sowa wrote: On Sun, Oct 18, 2015, at 22:59, Alexei Starovoitov wrote: On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here:

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

Hi Alexei, On Mon, Oct 19, 2015, at 21:34, Alexei Starovoitov wrote: > On 10/19/15 11:46 AM, Hannes Frederic Sowa wrote: > > Hi, > > > > On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote: > >> On 10/19/15 10:37 AM, Daniel Borkmann wrote: > >>> An eBPF program or map loading/destruction is

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

On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space to provide those debug facilities. It feels we're talking past each other. I want to solve 'persistent map' problem. debugging of maps/progs,

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

On 10/19/2015 06:22 PM, Alexei Starovoitov wrote: On 10/19/15 7:23 AM, Daniel Borkmann wrote: The mknod is not the holder but rather the kobject which should be represented in sysfs will be. So you can still get the map major:minor by looking up the /dev file in the correspdonding sysfs

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

Hi, On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote: > On 10/19/15 10:37 AM, Daniel Borkmann wrote: > > An eBPF program or map loading/destruction is *not* by any means to be > > considered fast-path. We currently hold a global mutex during loading. > > So, how can that be considered

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

On 10/19/15 10:37 AM, Daniel Borkmann wrote: An eBPF program or map loading/destruction is *not* by any means to be considered fast-path. We currently hold a global mutex during loading. So, how can that be considered fast-path? Similarly, socket creation/ destruction is also not fast-path, etc.

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

On 10/19/15 11:46 AM, Hannes Frederic Sowa wrote: Hi, On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote: On 10/19/15 10:37 AM, Daniel Borkmann wrote: An eBPF program or map loading/destruction is *not* by any means to be considered fast-path. We currently hold a global mutex during

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

On 10/19/15 3:17 PM, Daniel Borkmann wrote: On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space to provide those debug facilities. It feels we're

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

On 10/19/2015 10:48 PM, Alexei Starovoitov wrote: On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: I doubt it will stay a lightweight feature as it should not be in the responsibility of user space to provide those debug facilities. It feels we're talking past each other. I want to solve

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

Hello Alexei, On Mon, Oct 19, 2015, at 22:48, Alexei Starovoitov wrote: > On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote: > > > > I doubt it will stay a lightweight feature as it should not be in the > > responsibility of user space to provide those debug facilities. > > It feels we're talking

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

On 10/19/15 4:02 PM, Hannes Frederic Sowa wrote: I bet commercial software will make use of this ebpf framework, too. And the kernel always helped me and gave me a way to see what is going on, debug which part of my operating system universe interacts with which other part. Merely dropping file

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

On 10/19/15 7:23 AM, Daniel Borkmann wrote: The mknod is not the holder but rather the kobject which should be represented in sysfs will be. So you can still get the map major:minor by looking up the /dev file in the correspdonding sysfs directory or I think we should provide a 'unbind' file,

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

On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here: https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5 So the idea eventually had to be slightly modified after giving this further thoughts and is the following: We

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

On 10/18/2015 05:03 PM, Daniel Borkmann wrote: On 10/18/2015 04:20 AM, Alexei Starovoitov wrote: ... that indeed sounds cleaner, less lines of code, no fs, etc, but I don't see how it will work yet. I'll have some code ready very soon to show the concept. Will post it here tonight, stay

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

On 10/18/2015 04:20 AM, Alexei Starovoitov wrote: ... that indeed sounds cleaner, less lines of code, no fs, etc, but I don't see how it will work yet. I'll have some code ready very soon to show the concept. Will post it here tonight, stay tuned. ;) Cheers, Daniel -- To unsubscribe from this

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

On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here: https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5 So the idea eventually had to be slightly modified after giving this further thoughts and is the following: We

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

On 10/18/2015 04:20 AM, Alexei Starovoitov wrote: ... that indeed sounds cleaner, less lines of code, no fs, etc, but I don't see how it will work yet. I'll have some code ready very soon to show the concept. Will post it here tonight, stay tuned. ;) Cheers, Daniel -- To unsubscribe from this

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

On 10/18/2015 05:03 PM, Daniel Borkmann wrote: On 10/18/2015 04:20 AM, Alexei Starovoitov wrote: ... that indeed sounds cleaner, less lines of code, no fs, etc, but I don't see how it will work yet. I'll have some code ready very soon to show the concept. Will post it here tonight, stay

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

On 10/17/15 5:28 AM, Daniel Borkmann wrote: Anyway, another idea I've been brainstorming with Hannes today a bit is about the following: We register two major numbers, one for eBPF maps (X), one for eBPF progs (Y). A user can either via cmdline call something like ... mknod

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

On 10/17/2015 04:43 AM, Alexei Starovoitov wrote: On 10/16/15 4:44 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: We can argue about api for 2nd, whether it's mount with fd=1234 string or else, but for the first mount style doesn't make sense. Why does mount not make sense? It is

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

On 10/17/15 5:28 AM, Daniel Borkmann wrote: Anyway, another idea I've been brainstorming with Hannes today a bit is about the following: We register two major numbers, one for eBPF maps (X), one for eBPF progs (Y). A user can either via cmdline call something like ... mknod

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

On 10/17/2015 04:43 AM, Alexei Starovoitov wrote: On 10/16/15 4:44 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: We can argue about api for 2nd, whether it's mount with fd=1234 string or else, but for the first mount style doesn't make sense. Why does mount not

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

On 10/16/15 4:44 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: We can argue about api for 2nd, whether it's mount with fd=1234 string or else, but for the first mount style doesn't make sense. Why does mount not make sense? It is exactly what you are looking for so why does it

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

Alexei Starovoitov writes: > We can argue about api for 2nd, whether it's mount with fd=1234 string > or else, but for the first mount style doesn't make sense. Why does mount not make sense? It is exactly what you are looking for so why does it not make sense? Eric -- To unsubscribe from

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

On 10/16/15 12:53 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: On 10/16/15 11:41 AM, Eric W. Biederman wrote: [...] I am missing something. When I suggested using a filesystem it was my thought there would be exactly one superblock per map, and the map would be specified at

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

Alexei Starovoitov writes: > On 10/16/15 11:41 AM, Eric W. Biederman wrote: [...] >> I am missing something. >> >> When I suggested using a filesystem it was my thought there would be >> exactly one superblock per map, and the map would be specified at mount >> time. You clearly are not

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

On 10/16/2015 09:27 PM, Alexei Starovoitov wrote: On 10/16/15 11:41 AM, Eric W. Biederman wrote: Daniel Borkmann writes: On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an

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

On 10/16/15 11:41 AM, Eric W. Biederman wrote: Daniel Borkmann writes: On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an empty fs (a new instance) or in one were one can

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

Daniel Borkmann writes: > On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: >> On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: >>> Another question: >>> Should multiple mount of the filesystem result in an empty fs (a new >>> instance) or in one were one can see other ebpf-fs entities? I think

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

On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an empty fs (a new instance) or in one were one can see other ebpf-fs entities? I think Daniel wanted to already use the

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

On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an empty fs (a new instance) or in one were one can see other ebpf-fs entities? I think Daniel wanted to already use the mountpoint as some kind of hierarchy delimiter. I would

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

On 10/16/15 10:27 AM, Daniel Borkmann wrote: but don't know how flexible we are in terms of adding S_IFBPF to the UAPI. I don't think it should be a problem. You referred to POSIX Standard in your other mail but I can't see any reason why not to establish a new file mode. Anyway, FreeBSD (e.g.

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

On 10/16/15 at 10:32am, Alexei Starovoitov wrote: > On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote: > >Oh, tracing does not allow daemons. Why? I can only imagine embedded > >users, no? > > yes and for networking: restartability and HA. > cannot really do that with fuse/daemons. Right, the

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

On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote: Hi Alexei, On Fri, Oct 16, 2015, at 18:18, Alexei Starovoitov wrote: On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote: Namespaces at some point dealt with the same problem, they nowadays use bind mounts of/proc/$$/ns/* to some place in the file

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

On 10/16/2015 06:36 PM, Hannes Frederic Sowa wrote: On Fri, Oct 16, 2015, at 15:36, Daniel Borkmann wrote: On 10/16/2015 12:25 PM, Hannes Frederic Sowa wrote: On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: This eventually leads us to this patch, which implements a minimal eBPF file

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

On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > This eventually leads us to this patch, which implements a minimal > eBPF file system. The idea is a bit similar, but to the point that > these inodes reside at one or multiple mount points. A directory > hierarchy can be tailored to a

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

Hi Alexei, On Fri, Oct 16, 2015, at 18:18, Alexei Starovoitov wrote: > On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote: > > Namespaces at some point dealt with the same problem, they nowadays use > > bind mounts of/proc/$$/ns/* to some place in the file hierarchy to keep > > the namespace alive.

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

On Fri, Oct 16, 2015, at 15:36, Daniel Borkmann wrote: > On 10/16/2015 12:25 PM, Hannes Frederic Sowa wrote: > > On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > >> This eventually leads us to this patch, which implements a minimal > >> eBPF file system. The idea is a bit similar, but to

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

On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote: Namespaces at some point dealt with the same problem, they nowadays use bind mounts of/proc/$$/ns/* to some place in the file hierarchy to keep the namespace alive. This at least allows someone to build up its own hierarchy with normal unix tools

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

On 10/16/2015 12:25 PM, Hannes Frederic Sowa wrote: On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: This eventually leads us to this patch, which implements a minimal eBPF file system. The idea is a bit similar, but to the point that these inodes reside at one or multiple mount points. A

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

On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > This eventually leads us to this patch, which implements a minimal > eBPF file system. The idea is a bit similar, but to the point that > these inodes reside at one or multiple mount points. A directory > hierarchy can be tailored to a

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

On 10/16/15 at 10:32am, Alexei Starovoitov wrote: > On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote: > >Oh, tracing does not allow daemons. Why? I can only imagine embedded > >users, no? > > yes and for networking: restartability and HA. > cannot really do that with fuse/daemons. Right, the

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

On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an empty fs (a new instance) or in one were one can see other ebpf-fs entities? I think Daniel wanted to already use the mountpoint as some kind of hierarchy delimiter. I would

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

On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote: Hi Alexei, On Fri, Oct 16, 2015, at 18:18, Alexei Starovoitov wrote: On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote: Namespaces at some point dealt with the same problem, they nowadays use bind mounts of/proc/$$/ns/* to some place in the file

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

On 10/16/15 10:27 AM, Daniel Borkmann wrote: but don't know how flexible we are in terms of adding S_IFBPF to the UAPI. I don't think it should be a problem. You referred to POSIX Standard in your other mail but I can't see any reason why not to establish a new file mode. Anyway, FreeBSD (e.g.

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

On 10/16/15 11:41 AM, Eric W. Biederman wrote: Daniel Borkmann writes: On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an empty fs (a new instance)

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

On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > This eventually leads us to this patch, which implements a minimal > eBPF file system. The idea is a bit similar, but to the point that > these inodes reside at one or multiple mount points. A directory > hierarchy can be tailored to a

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

On 10/16/2015 06:36 PM, Hannes Frederic Sowa wrote: On Fri, Oct 16, 2015, at 15:36, Daniel Borkmann wrote: On 10/16/2015 12:25 PM, Hannes Frederic Sowa wrote: On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: This eventually leads us to this patch, which implements a minimal eBPF file

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

On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the filesystem result in an empty fs (a new instance) or in one were one can see other ebpf-fs entities? I think Daniel wanted to already use the

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

Daniel Borkmann writes: > On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: >> On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: >>> Another question: >>> Should multiple mount of the filesystem result in an empty fs (a new >>> instance) or in one were one can see other

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

On 10/16/2015 09:27 PM, Alexei Starovoitov wrote: On 10/16/15 11:41 AM, Eric W. Biederman wrote: Daniel Borkmann writes: On 10/16/2015 07:42 PM, Alexei Starovoitov wrote: On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote: Another question: Should multiple mount of the

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

On 10/16/15 12:53 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: On 10/16/15 11:41 AM, Eric W. Biederman wrote: [...] I am missing something. When I suggested using a filesystem it was my thought there would be exactly one superblock per map, and the map would

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

Alexei Starovoitov writes: > On 10/16/15 11:41 AM, Eric W. Biederman wrote: [...] >> I am missing something. >> >> When I suggested using a filesystem it was my thought there would be >> exactly one superblock per map, and the map would be specified at mount >> time. You

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

On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > This eventually leads us to this patch, which implements a minimal > eBPF file system. The idea is a bit similar, but to the point that > these inodes reside at one or multiple mount points. A directory > hierarchy can be tailored to a

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

On 10/16/2015 12:25 PM, Hannes Frederic Sowa wrote: On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: This eventually leads us to this patch, which implements a minimal eBPF file system. The idea is a bit similar, but to the point that these inodes reside at one or multiple mount points. A

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

On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote: Namespaces at some point dealt with the same problem, they nowadays use bind mounts of/proc/$$/ns/* to some place in the file hierarchy to keep the namespace alive. This at least allows someone to build up its own hierarchy with normal unix tools

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

Alexei Starovoitov writes: > We can argue about api for 2nd, whether it's mount with fd=1234 string > or else, but for the first mount style doesn't make sense. Why does mount not make sense? It is exactly what you are looking for so why does it not make sense? Eric -- To

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

On 10/16/15 4:44 PM, Eric W. Biederman wrote: Alexei Starovoitov writes: We can argue about api for 2nd, whether it's mount with fd=1234 string or else, but for the first mount style doesn't make sense. Why does mount not make sense? It is exactly what you are looking

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

On Fri, Oct 16, 2015, at 15:36, Daniel Borkmann wrote: > On 10/16/2015 12:25 PM, Hannes Frederic Sowa wrote: > > On Fri, Oct 16, 2015, at 03:09, Daniel Borkmann wrote: > >> This eventually leads us to this patch, which implements a minimal > >> eBPF file system. The idea is a bit similar, but to

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

Hi Alexei, On Fri, Oct 16, 2015, at 18:18, Alexei Starovoitov wrote: > On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote: > > Namespaces at some point dealt with the same problem, they nowadays use > > bind mounts of/proc/$$/ns/* to some place in the file hierarchy to keep > > the namespace alive.

  1   2   >