[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