On 08/29, Jakub Kicinski wrote:
> On Thu, 29 Aug 2019 16:13:59 -0700, Brian Vazquez wrote:
> > > We need a per-map implementation of the exec side, but roughly maps
> > > would do:
> > >
> > > LIST_HEAD(deleted);
> > >
> > > for entry in map {
> > > struct map_op_ctx {
> > > .key = entry->key,
> > > .value = entry->value,
> > > };
> > >
> > > act = BPF_PROG_RUN(filter, &map_op_ctx);
> > > if (act & ~ACT_BITS)
> > > return -EINVAL;
> > >
> > > if (act & DELETE) {
> > > map_unlink(entry);
> > > list_add(entry, &deleted);
> > > }
> > > if (act & STOP)
> > > break;
> > > }
> > >
> > > synchronize_rcu();
> > >
> > > for entry in deleted {
> > > struct map_op_ctx {
> > > .key = entry->key,
> > > .value = entry->value,
> > > };
> > >
> > > BPF_PROG_RUN(dumper, &map_op_ctx);
> > > map_free(entry);
> > > }
> > >
> > Hi Jakub,
> >
> > how would that approach support percpu maps?
> >
> > I'm thinking of a scenario where you want to do some calculations on
> > percpu maps and you are interested on the info on all the cpus not
> > just the one that is running the bpf program. Currently on a pcpu map
> > the bpf_map_lookup_elem helper only returns the pointer to the data of
> > the executing cpu.
>
> Right, we need to have the iteration outside of the bpf program itself,
> and pass the element in through the context. That way we can feed each
> per cpu entry into the program separately.
My 2 cents:
I personally like Jakub's/Quentin's proposal more. So if I get to choose
between this series and Jakub's filter+dump in BPF, I'd pick filter+dump
(pending per-cpu issue which we actually care about).
But if we can have both, I don't have any objections; this patch
series looks to me a lot like what Brian did, just extended to more
commands. If we are fine with the shortcomings raised about the
original series, then let's go with this version. Maybe we can also
look into addressing these independently.
But if I pretend that we live in an ideal world, I'd just go with
whatever Jakub and Quentin are doing so we don't have to support
two APIs that essentially do the same (minus batching update, but
it looks like there is no clear use case for that yet; maybe).
I guess you can hold off this series a bit and discuss it at LPC,
you have a talk dedicated to that :-) (and afaiu, you are all going)
