[dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples

[Ananyev, Konstantin]

Hi Jerin,
> > > Add few simple eBPF programs as an example.
> > >
> > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev at 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