> On 25.10.2021., at 19:02, Mrityunjay Kumar <kumarn...@gmail.com> wrote: > > Damjon Hi, > > I am users of DPDK since August 2011, and VPP guess it was Jan 2017, VPP is just open-sourced in 2017. It started back in 2004: https://patents.google.com/patent/US7961636B1/en > > Not sure, about contributor but we should think to take dpdk as main frame in > VPP, > > For this, we need to deprecate vlib_buffer_t, marry entire VPP with > rte_mbuf, Why is rte_mbuf better than vlib_buffer_t ? > > > This can lead to avoid extra overhead to translate the dpdk vs VPP metadata. Do we have all fields needed by vpp features in rte_mbuf? > > > I am sure, we can get significant performance count as well. > > What is your input. I doubt that will happen for many reasons, one of them is that it will require all features to be rewritten. > > > > > On Mon, 25 Oct, 2021, 9:37 pm Damjan Marion via lists.fd.io, > <dmarion=me....@lists.fd.io> wrote: > > Ok, i’m affraid that to implement this you will need to introduce lot of mess. > At the end probably will be easier to implement that functionality natively. > > Which exact implementation of the dpdk mempool you are looking to use (ring, > stack, bucket, ...)? > > — > Damjan > > > > > On 25.10.2021., at 17:39, <bjerem...@gmail.com> <bjerem...@gmail.com> wrote: > > > > Hi Damjan, > > > > Thanks for the reply > > > > Here are the details: > > > > 1. We want to use only the rte_mempool infrastructure for lockless global > > memory pools. We will not be using any mbuf infrastructure from dpdk > > 2. We want to use this infra across our multiple plugins > > 3. We want to be able to include rte_mempool data structures from our > > multiple header files (.h files ) > > 4. We want to be able to make calls to rte_mempool apis from our source > > code ( .c files ) > > > > -----Original Message----- > > From: Damjan Marion <dmar...@me.com> > > Sent: Monday, October 25, 2021 5:22 AM > > To: bjerem...@gmail.com > > Cc: vpp-dev@lists.fd.io > > Subject: Re: [vpp-dev] Linking DPDK libs to plugins > > > > > > > > > >> On 25.10.2021., at 01:13, bjerem...@gmail.com wrote: > >> > >> Greetings, > >> > >> Let me preface this by saying that I really do not know much about the > >> CMake utility. But I am trying to see if there is a way to make the DPDK > >> libs accessible to other plugins (aside from the dpdk plugin) that are in > >> their own project/subdirectory similar. I am working with v20.05 currently > >> (although we are upgrading to 21.06 if that make a difference). > >> > >> Initially it was suggested to me that I could just add a couple lines > >> to my CMakeLists to link the dpdk_plugin.so to my own plugin.. but I > >> have not been able to get this to work.. It never seems to recognize > >> the path to the .so, even if I give the absolute path > >> > >> set(DPDK_PLUGIN_LINK_FLAGS "${DPDK_PLUGIN_LINK_FLAGS} -L <dir to vpp > >> plugins> -ldpdk_plugin.so") > >> > >> add_vpp_plugin(my_plugin > >> …. > >> LINK_FLAGS > >> “${ DPDK_PLUGIN_LINK_FLAGS }” > >> > >> Another approach suggested was to maybe use dlsym to dynamically load > >> symbols… Anyway, I was thinking that someone has to have had done this > >> before, or maybe have more of a clue as to how to do this then I currently > >> do. > >> > > > > > > > > Please note that VPP is not DPDK application, DPDK is just optional device > > driver layer for us. > > > > Even if you manage to get your plugin linked against DPDK libs, there is no > > guarantee that you will be able to use all dpdk data structures. Most > > obvious example, rte_mbuf structure for a packet buffer may not be > > populated for you. > > > > Also use of DPDK comes with a performance cost, we need to copy buffer > > metadata left and right on both RX and TX side. > > > > What specific DPDK library you would like to use? We may have alternative > > proposal…. > > > > — > > Damjan > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20386): https://lists.fd.io/g/vpp-dev/message/20386 Mute This Topic: https://lists.fd.io/mt/86565585/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
