Hi Jerin, > > > Add few simple eBPF programs as an example. > > > > > > Signed-off-by: Konstantin Ananyev <konstantin.anan...@intel.com> > > > diff --git a/test/bpf/mbuf.h b/test/bpf/mbuf.h > > > new file mode 100644 > > > index 000000000..aeef6339d > > > --- /dev/null > > > +++ b/test/bpf/mbuf.h > > > @@ -0,0 +1,556 @@ > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > + * Copyright(c) 2010-2014 Intel Corporation. > > > + * Copyright 2014 6WIND S.A. > > > + */ > > > + > > > +/* > > > + * Snipper from dpdk.org rte_mbuf.h. > > > + * used to provide BPF programs information about rte_mbuf layout. > > > + */ > > > + > > > +#ifndef _MBUF_H_ > > > +#define _MBUF_H_ > > > + > > > +#include <stdint.h> > > > +#include <rte_common.h> > > > +#include <rte_memory.h> > > > > Is it worth to keep an copy of mbuf for standalone purpose? > > Since clang is already supported, I think, if someone need mbuf then > > they can include DPDK headers. Just thinking in maintainability > > perspective. > > That would be ideal. > I made a snippet just to avoid compiler errors for bpf target. > Will try to address it in next version. >
I looked at it a bit more and it seems that it wouldn't be that straightforward as I thought. There are things not supported by bpf target (thread local-storage and simd related definitions) inside include chain. So to fix it some changes in our core include files might be needed . The simplest way would probably be to move struct rte_mbuf and related macros definitions into a separate file (rte_mbuf_common.h or so). Though it is quite controversial change and I think it is better to postpone it till a separate patch and probably next release. So for now I left a snipper test/bpf/mbuf.h in place. Konstantin