diff mbox series

ebpf issues with secondary process.

Message ID 20191017211952.6ebf0312@hermes.lan (mailing list archive)
State Not Applicable, archived
Headers show
Series ebpf issues with secondary process. | expand


Context Check Description
ci/Intel-compilation fail Compilation issues
ci/travis-robot warning Travis build: failed
ci/Performance-Testing fail build patch failure

Commit Message

Stephen Hemminger Oct. 18, 2019, 4:19 a.m. UTC
Trying to use the existing BPF code in BPF for packet filter is possible.
But one road block is that capture wants to allow a secondary process to
insert a packet filter. The current code in bpf_load() won't work for that.
The BPF program needs to be in shared area to allow secondary process
to work.

Why does the code use mmap() as an allocator instead of rte_malloc?

Something like the diff below (untested). JIT would have the same problem
but you would have issues with the mprotect stuff with huge pages.

I also noticed that bpf code is not using rte_memcpy and it has unnecessary
casts to void *.
diff mbox series


diff --git a/lib/librte_bpf/bpf.c b/lib/librte_bpf/bpf.c
index 7e1879ffa5b5..d6995bbf0ba9 100644
--- a/lib/librte_bpf/bpf.c
+++ b/lib/librte_bpf/bpf.c
@@ -22,7 +22,7 @@  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);
+		rte_free(bpf);
diff --git a/lib/librte_bpf/bpf_load.c b/lib/librte_bpf/bpf_load.c
index 2a3b901d74c3..9a8e438a8963 100644
--- a/lib/librte_bpf/bpf_load.c
+++ b/lib/librte_bpf/bpf_load.c
@@ -32,9 +32,8 @@  bpf_load(const struct rte_bpf_prm *prm)
 	bsz = sizeof(bpf[0]);
 	sz = insz + xsz + bsz;
-	buf = mmap(NULL, sz, PROT_READ | PROT_WRITE,
-	if (buf == MAP_FAILED)
+	buf = rte_malloc("bpf", sz, 0);
+	if (buf == NULL)
 		return NULL;
 	bpf = (void *)buf;