[dpdk-dev] [PATCH v1 1/5] bpf: add BPF loading and execution framework
Ananyev, Konstantin
konstantin.ananyev at intel.com
Tue Mar 13 18:47:33 CET 2018
> > diff --git a/lib/librte_bpf/bpf.c b/lib/librte_bpf/bpf.c
> > new file mode 100644
> > index 000000000..4727d2251
> > --- /dev/null
> > +++ b/lib/librte_bpf/bpf.c
> > @@ -0,0 +1,48 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2018 Intel Corporation
> > + */
> > +
> > +#include <stdarg.h>
> > +#include <stdio.h>
> > +#include <string.h>
> > +#include <errno.h>
> > +#include <stdint.h>
> > +#include <inttypes.h>
> > +
> > +#include <rte_common.h>
> > +#include <rte_eal.h>
> > +
> > +#include "bpf_impl.h"
> > +
> > +__rte_experimental void
> > +rte_bpf_destroy(struct rte_bpf *bpf)
> > +{
> > + if (bpf != NULL) {
> > + if (bpf->jit.func != NULL)
> > + munmap(bpf->jit.func, bpf->jit.sz);
> > + munmap(bpf, bpf->sz);
>
>
> Any specific reason to not use this memory from huge page using rte_zmalloc
> to avoid normal TLB misses?
The main reason - I'd like to keep BPF code as read-only,
and jitted one as read-only and executable.
About your concern - I don't think it would cause a lot of TLB misses:
most BPF programs are quite small and should fit into few 4K pages.
At least so far, I didn't observe any dTLB miss-rate increase.
>
>
> > + }
> > +}
> > +
> > +__rte_experimental int
> > +rte_bpf_get_jit(const struct rte_bpf *bpf, struct rte_bpf_jit *jit)
> > +{
> > + if (bpf == NULL || jit == NULL)
> > + return -EINVAL;
> > +
> > + jit[0] = bpf->jit;
> > + return 0;
> > +}
> > +
> > +int
> > +bpf_jit(struct rte_bpf *bpf)
> > +{
> > + int32_t rc;
> > +
> > + rc = -ENOTSUP;
> > +
> > + if (rc != 0)
> > + RTE_LOG(WARNING, USER1, "%s(%p) failed, error code: %d;\n",
> > + __func__, bpf, rc);
>
> How about using new dynamic logging option for this library?
Good point, will try to switch to it with v2.
Konstantin
More information about the dev
mailing list