-----Original Message----- > Date: Fri, 30 Mar 2018 17:42:22 +0000 > From: "Ananyev, Konstantin" <konstantin.anan...@intel.com> > To: 'Jerin Jacob' <jerin.ja...@caviumnetworks.com> > CC: "'dev@dpdk.org'" <dev@dpdk.org> > Subject: RE: [dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples > > 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).
I think, rte_mbuf_common.h should be the way to go. IMO, KNI also benefited with that. I guess, There is NO ABI change if we move the generic stuff to rte_mbuf_common.h. But if you think, it is quite controversial change then we could postpone to next release.(Only my worry is that, once it is postponed it may not happen). I am fine with either way. > 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
