Re: [dpdk-dev] [RFC PATCH 0/7] RFC:EventDev OPDL PMD
Hi Jerin, Many thanks for your comments. Please check my comment below. On 25 Nov 02:25, Jerin Jacob wrote: > -Original Message- > > Date: Fri, 24 Nov 2017 11:23:45 + > > From: liang.j...@intel.com > > To: jerin.ja...@caviumnetworks.com > > CC: dev@dpdk.org, harry.van.haa...@intel.com, bruce.richard...@intel.com, > > deepak.k.j...@intel.com, john.ge...@intel.com > > Subject: [RFC PATCH 0/7] RFC:EventDev OPDL PMD > > X-Mailer: git-send-email 2.7.5 > > > > From: Liang Ma > > > Thanks Liang Ma for the RFC. > > > > > The OPDL (Ordered Packet Distribution Library) eventdev is a specific > > implementation of the eventdev API. It is particularly suited to packet > > processing workloads that have high throughput and low latency > > requirements. All packets follow the same path through the device. > > The order which packets follow is determinted by the order in which > > queues are set up. Packets are left on the ring until they are transmitted. > > As a result packets do not go out of order. > > > > Features: > > > > The OPDL eventdev implements a subset of features of the eventdev API; > > > > Queues > > * Atomic > > * Ordered (Parallel is supported as parallel is a subset of Ordered) > > * Single-Link > > > > Ports > > * Load balanced (for Atomic, Ordered, Parallel queues) > > * Single Link (for single-link queues) > > > > Single Port Queue > > > > It is possible to create a Single Port Queue > > RTE_EVENT_QUEUE_CFG_SINGLE_LINK. Packets dequeued from this queue do > > not need to be re-enqueued (as is the case with an ordered queue). The > > purpose of this queue is to allow for asynchronous handling of packets in > > the middle of a pipeline. Ordered queues in the middle of a pipeline > > cannot delete packets. > > > > > > Queue Dependencies > > > > As stated the order in which packets travel through queues is static in > > nature. They go through the queues in the order the queues are setup at > > initialisation rte_event_queue_setup(). For example if an application > > sets up 3 queues, Q0, Q1, Q2 and has 3 assoicated ports P0, P1, P2 and > > P3 then packets must be > > > > * Enqueued onto Q0 (typically through P0), then > > > > * Dequeued from Q0 (typically through P1), then > > > > * Enqueued onto Q1 (also through P1), then > > > > * Dequeued from Q2 (typically through P2), then > > > > * Enqueued onto Q3 (also through P2), then > > > > * Dequeued from Q3 (typically through P3) and then transmitted on the > >relevant eth port > > > > > > Limitations > > > > The opdl implementation has a number of limitations. These limitations are > > due to the static nature of the underlying queues. It is because of this > > that the implementation can achieve such high throughput and low latency > > > > The following list is a comprehensive outline of the what is supported and > > the limitations / restrictions imposed by the opdl pmd > > > > - The order in which packets moved between queues is static and fixed > >(dynamic scheduling is not supported). > > > > - NEW, RELEASE op type are not explicitly supported. RX (first enqueue) > >implicitly adds NEW event types, and TX (last dequeue) implicitly does > >RELEASE event types. > > > > - All packets follow the same path through device queues. > > > > - Flows within queues are NOT supported. > > > > - Event priority is NOT supported. > > > > - Once the device is stopped all inflight events are lost. Applications > > should > >clear all inflight events before stopping it. > > > > - Each port can only be associated with one queue. > > > > - Each queue can have multiple ports associated with it. > > > > - Each worker core has to dequeue the maximum burst size for that port. > > > > - For performance, the rte_event flow_id should not be updated once > > packet is enqueued on RX. > > Some top-level comments, > > # How does application knows this PMD has above limitations? > > I think, We need to add more capability RTE_EVENT_DEV_CAP_* > to depict these constraints. On the same note, I believe this > PMD is "radically" different than other SW/HW PMD then anyway > we cannot write the portable application using this PMD. So there > is no point in abstracting it as eventdev PMD. Could you please > work on the new capabilities are required to enable this PMD. > If it needs more capability flags to express this PMD capability, > we might have a different library for this as it defects the > purpose of portable eventdev applications. > Agree with improve capability information with add more details with RTE_EVENT_DEV_CAP_*. While the OPDL is designed around a different load-balancing architecture, that of load-balancing across pipeline stages where a consumer is only working on a single stage, this does not necessarily mean that it is completely incompatible with other eventdev implementations. Although, it is true that an application written to use one of the e
Re: [dpdk-dev] [RFC PATCH 0/7] RFC:EventDev OPDL PMD
On 29 Nov 04:56, Jerin Jacob wrote: > -Original Message- > > Date: Wed, 29 Nov 2017 12:19:54 + > > From: "Ma, Liang" > > To: Jerin Jacob > > CC: dev@dpdk.org, "Van Haaren, Harry" , > > "Richardson, Bruce" , "Jain, Deepak K" > > , "Mccarthy, Peter" > > Subject: Re: [RFC PATCH 0/7] RFC:EventDev OPDL PMD > > User-Agent: Mutt/1.5.20 (2009-06-14) > > > > Hi Jerin, > >Many thanks for your comments. Please check my comment below. > > > > On 25 Nov 02:25, Jerin Jacob wrote: > > > -Original Message- > > > > Date: Fri, 24 Nov 2017 11:23:45 + > > > > From: liang.j...@intel.com > > > > To: jerin.ja...@caviumnetworks.com > > > > CC: dev@dpdk.org, harry.van.haa...@intel.com, > > > > bruce.richard...@intel.com, > > > > deepak.k.j...@intel.com, john.ge...@intel.com > > > > Subject: [RFC PATCH 0/7] RFC:EventDev OPDL PMD > > > > X-Mailer: git-send-email 2.7.5 > > > > > > > > From: Liang Ma > > > > > > > > > Thanks Liang Ma for the RFC. > > > > > > > > > > > The OPDL (Ordered Packet Distribution Library) eventdev is a specific > > > > implementation of the eventdev API. It is particularly suited to packet > > > > processing workloads that have high throughput and low latency > > > > requirements. All packets follow the same path through the device. > > > > The order which packets follow is determinted by the order in which > > > > queues are set up. Packets are left on the ring until they are > > > > transmitted. > > > > As a result packets do not go out of order. > > > > > > > > Features: > > > > > > > > The OPDL eventdev implements a subset of features of the eventdev API; > > > > > > > > Queues > > > > * Atomic > > > > * Ordered (Parallel is supported as parallel is a subset of Ordered) > > > > * Single-Link > > > > > > > > Ports > > > > * Load balanced (for Atomic, Ordered, Parallel queues) > > > > * Single Link (for single-link queues) > > > > > > > > Single Port Queue > > > > > > > > It is possible to create a Single Port Queue > > > > RTE_EVENT_QUEUE_CFG_SINGLE_LINK. Packets dequeued from this queue do > > > > not need to be re-enqueued (as is the case with an ordered queue). The > > > > purpose of this queue is to allow for asynchronous handling of packets > > > > in > > > > the middle of a pipeline. Ordered queues in the middle of a pipeline > > > > cannot delete packets. > > > > > > > > > > > > Queue Dependencies > > > > > > > > As stated the order in which packets travel through queues is static in > > > > nature. They go through the queues in the order the queues are setup at > > > > initialisation rte_event_queue_setup(). For example if an application > > > > sets up 3 queues, Q0, Q1, Q2 and has 3 assoicated ports P0, P1, P2 and > > > > P3 then packets must be > > > > > > > > * Enqueued onto Q0 (typically through P0), then > > > > > > > > * Dequeued from Q0 (typically through P1), then > > > > > > > > * Enqueued onto Q1 (also through P1), then > > > > > > > > * Dequeued from Q2 (typically through P2), then > > > > > > > > * Enqueued onto Q3 (also through P2), then > > > > > > > > * Dequeued from Q3 (typically through P3) and then transmitted on the > > > >relevant eth port > > > > > > > > > > > > Limitations > > > > > > > > The opdl implementation has a number of limitations. These limitations > > > > are > > > > due to the static nature of the underlying queues. It is because of this > > > > that the implementation can achieve such high throughput and low latency > > > > > > > > The following list is a comprehensive outline of the what is supported > > > > and > > > > the limitations / restrictions imposed by the opdl pmd > > > > > > > > - The order in which packets moved between queues is static and fixed > > > >(dynamic scheduling is not supported). > > > > > > > > - NEW, RELEASE
Re: [dpdk-dev] [RFC v2 PATCH 0/8] event: eventdev OPDL PMD
ChangeLog [v2] 1. merge the opdl eventdev unit test code into opdl pmd. 2. propose three new capability capability flags for overall eventdev. 3. remove the opdl pmd example code. 4. remove the opdl pmd example doc. On 15 Dec 11:26, Liang Ma wrote: > The OPDL (Ordered Packet Distribution Library) eventdev is a specific > implementation of the eventdev API. It is particularly suited to packet > processing workloads that have high throughput and low latency > requirements. All packets follow the same path through the device. > The order which packets follow is determinted by the order in which > queues are set up. Packets are left on the ring until they are transmitted. > As a result packets do not go out of order. > > Features: > > The OPDL eventdev implements a subset of features of the eventdev API; > > Queues > * Atomic > * Ordered (Parallel is supported as parallel is a subset of Ordered) > * Single-Link > > Ports > * Load balanced (for Atomic, Ordered, Parallel queues) > * Single Link (for single-link queues) > > Single Port Queue > > It is possible to create a Single Port Queue > RTE_EVENT_QUEUE_CFG_SINGLE_LINK. Packets dequeued from this queue do > not need to be re-enqueued (as is the case with an ordered queue). The > purpose of this queue is to allow for asynchronous handling of packets in > the middle of a pipeline. Ordered queues in the middle of a pipeline > cannot delete packets. > > > Queue Dependencies > > As stated the order in which packets travel through queues is static in > nature. They go through the queues in the order the queues are setup at > initialisation rte_event_queue_setup(). For example if an application > sets up 3 queues, Q0, Q1, Q2 and has 3 assoicated ports P0, P1, P2 and > P3 then packets must be > > * Enqueued onto Q0 (typically through P0), then > > * Dequeued from Q0 (typically through P1), then > > * Enqueued onto Q1 (also through P1), then > > * Dequeued from Q2 (typically through P2), then > > * Enqueued onto Q3 (also through P2), then > > * Dequeued from Q3 (typically through P3) and then transmitted on the >relevant eth port > > > Limitations > > The opdl implementation has a number of limitations. These limitations are > due to the static nature of the underlying queues. It is because of this > that the implementation can achieve such high throughput and low latency > > The following list is a comprehensive outline of the what is supported and > the limitations / restrictions imposed by the opdl pmd > > - The order in which packets moved between queues is static and fixed >(dynamic scheduling is not supported). > > - NEW, RELEASE op type are not explicitly supported. RX (first enqueue) >implicitly adds NEW event types, and TX (last dequeue) implicitly does >RELEASE event types. > > - All packets follow the same path through device queues. > > - Flows within queues are NOT supported. > > - Event priority is NOT supported. > > - Once the device is stopped all inflight events are lost. Applications > should >clear all inflight events before stopping it. > > - Each port can only be associated with one queue. > > - Each queue can have multiple ports associated with it. > > - Each worker core has to dequeue the maximum burst size for that port. > > > Reference > General concept of event driven programming model > [http://dpdk.org/doc/guides/eventdevs/index.html] > > Original Ordered Pipeline Design slides > [https://dpdksummit.com/Archive/pdf/2017Asia/DPDK-China2017-Ma-OPDL.pdf] > > > Liang Ma (8): > event/opdl: add the opdl ring infrastructure library > event/opdl: add the opdl pmd header and init helper function > event/opdl: add the opdl pmd main body and xstats helper function > eventdev/opdl: opdl eventdev pmd unit test function > lib/librte_eventdev: extend the eventdev capability flags > event/*: apply the three new capability flags for sw/dppa2/octeontx > event/opdl: update the build system to enable compilation > doc: add eventdev opdl pmd docuement > > config/common_base|6 + > doc/guides/eventdevs/index.rst|1 + > doc/guides/eventdevs/opdl.rst | 162 +++ > drivers/event/Makefile|1 + > drivers/event/dpaa2/dpaa2_eventdev.c |5 +- > drivers/event/octeontx/ssovf_evdev.c |5 +- > drivers/event/opdl/Makefile | 66 ++ > drivers/event/opdl/opdl_evdev.c | 744 + > drivers/event/opdl/opdl_evdev.h | 354 ++ > drivers/event/opdl/opdl_evdev_init.c | 951 > drivers/event/opdl/opdl_evdev_xstats.c| 205 > drivers/event/opdl/opdl_ring.c| 1232 > + > drivers/event/opdl/opdl_ring.h| 601 ++ > drivers/event/opdl/opdl_test.c
Re: [dpdk-dev] [PATCH v2 1/8] event/opdl: add the opdl ring infrastructure library
On 15 Dec 07:38, Neil Horman wrote:
> On Fri, Dec 15, 2017 at 11:26:22AM +, Liang Ma wrote:
> > OPDL ring is the core infrastructure of OPDL PMD. OPDL ring library
> > provide the core data structure and core helper function set. The Ring
> > implements a single ring multi-port/stage pipelined packet distribution
> > mechanism. This mechanism has the following characteristics:
> >
> > • No multiple queue cost, therefore, latency is significant reduced.
> > • Fixed dependencies between queue/ports is more suitable for complex.
> > fixed pipelines of stateless packet processing (static pipeline).
> > • Has decentralized distribution (no scheduling core).
> > • Packets remain in order (no reorder core(s)).
> >
> > Signed-off-by: Liang Ma
> > Signed-off-by: Peter, Mccarthy
> > ---
> > drivers/event/opdl/Makefile | 66 ++
> > drivers/event/opdl/opdl_ring.c| 1232
> > +
> > drivers/event/opdl/opdl_ring.h| 601 ++
> > drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 +
> > 4 files changed, 1902 insertions(+)
> > create mode 100644 drivers/event/opdl/Makefile
> > create mode 100644 drivers/event/opdl/opdl_ring.c
> > create mode 100644 drivers/event/opdl/opdl_ring.h
> > create mode 100644 drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> >
> >
>
> > +
> > +#endif /* _OPDL_H_ */
> > diff --git a/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > b/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > new file mode 100644
> > index 000..5352e7e
> > --- /dev/null
> > +++ b/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > @@ -0,0 +1,3 @@
> > +DPDK_17.05 {
> > + local: *;
> > +};
> you need to ennumerate the functions you want to globally export here, or
> this won't work
> as a shared library. This also suggests you haven't tested this as a DSO yet,
> please do so.
>
> Neil
FYI, the subject of email has indicated that's part of the PMD.
there is no need to export any function globally.
you can reference
drivers/event/octeontx/rte_pmd_octeontx_ssovf_version.map
/drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
drivers/event/sw/rte_pmd_sw_event_version.map
BTW: I do test with shared library build.
>
> > --
> > 2.7.5
> >
> > --
> > Intel Research and Development Ireland Limited
> > Registered in Ireland
> > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> > Registered Number: 308263
> >
> >
> > This e-mail and any attachments may contain confidential material for the
> > sole
> > use of the intended recipient(s). Any review or distribution by others is
> > strictly prohibited. If you are not the intended recipient, please contact
> > the
> > sender and delete all copies.
Re: [dpdk-dev] [PATCH v2 1/8] event/opdl: add the opdl ring infrastructure library
On 15 Dec 16:23, Neil Horman wrote:
> On Fri, Dec 15, 2017 at 01:50:41PM +0000, Ma, Liang wrote:
> > On 15 Dec 07:38, Neil Horman wrote:
> > > On Fri, Dec 15, 2017 at 11:26:22AM +, Liang Ma wrote:
> > > > OPDL ring is the core infrastructure of OPDL PMD. OPDL ring library
> > > > provide the core data structure and core helper function set. The Ring
> > > > implements a single ring multi-port/stage pipelined packet distribution
> > > > mechanism. This mechanism has the following characteristics:
> > > >
> > > > • No multiple queue cost, therefore, latency is significant reduced.
> > > > • Fixed dependencies between queue/ports is more suitable for complex.
> > > > fixed pipelines of stateless packet processing (static pipeline).
> > > > • Has decentralized distribution (no scheduling core).
> > > > • Packets remain in order (no reorder core(s)).
> > > >
> > > > Signed-off-by: Liang Ma
> > > > Signed-off-by: Peter, Mccarthy
> > > > ---
> > > > drivers/event/opdl/Makefile | 66 ++
> > > > drivers/event/opdl/opdl_ring.c| 1232
> > > > +
> > > > drivers/event/opdl/opdl_ring.h| 601 ++
> > > > drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 +
> > > > 4 files changed, 1902 insertions(+)
> > > > create mode 100644 drivers/event/opdl/Makefile
> > > > create mode 100644 drivers/event/opdl/opdl_ring.c
> > > > create mode 100644 drivers/event/opdl/opdl_ring.h
> > > > create mode 100644 drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > >
> > > >
> > >
> > > > +
> > > > +#endif /* _OPDL_H_ */
> > > > diff --git a/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > > b/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > > new file mode 100644
> > > > index 000..5352e7e
> > > > --- /dev/null
> > > > +++ b/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > > @@ -0,0 +1,3 @@
> > > > +DPDK_17.05 {
> > > > + local: *;
> > > > +};
> > > you need to ennumerate the functions you want to globally export here, or
> > > this won't work
> > > as a shared library. This also suggests you haven't tested this as a DSO
> > > yet,
> > > please do so.
> > >
> > > Neil
> > FYI, the subject of email has indicated that's part of the PMD.
> I apologize, I didn't realize it was its own pmd, rather than part of the
> other
> pmds. I missed the pathing and thought you were creating a separate library
> for
> others to consume, rather than a PMD to be accessed via the ethdev api
>
> > there is no need to export any function globally.
> > you can reference
> > drivers/event/octeontx/rte_pmd_octeontx_ssovf_version.map
> > /drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
> > drivers/event/sw/rte_pmd_sw_event_version.map
> >
> > BTW: I do test with shared library build.
> What did you test with? I ask because with gcc version 7.2.1, the build
> throws
> several warnings that error the build out:
I test with Gcc 6.3.1 and some older version, no warning report.
gcc 7.2.1 is not in our test list rightnow, I will investigate the issue.
>
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c: In function
> ‘create_queues_and_rings’:
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:17: error:
> ‘%s’ directive writing up to 63 bytes into a region of size 32
> [-Werror=format-overflow=]
> sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
> ^~
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:2: note:
> ‘sprintf’ output between 3 and 75 bytes into a destination of size 32
> sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
> ^~
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:17: error:
> ‘%s’ directive writing up to 63 bytes into a region of size 32
> [-Werror=format-overflow=]
> sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
> ^~
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:2: note:
> ‘sprintf’ output between 3 and 75 bytes into a destination of size 32
> sprintf(name, "%s_%u", device->service_name, devic
Re: [dpdk-dev] [PATCH v3 1/8] event/opdl: add the opdl ring infrastructure library
> > OPDL ring is the core infrastructure of OPDL PMD. OPDL ring library > provide the core data structure and core helper function set. The Ring > implements a single ring multi-port/stage pipelined packet distribution > mechanism. This mechanism has the following characteristics: > > • No multiple queue cost, therefore, latency is significant reduced. > • Fixed dependencies between queue/ports is more suitable for complex. > fixed pipelines of stateless packet processing (static pipeline). > • Has decentralized distribution (no scheduling core). > • Packets remain in order (no reorder core(s)). > * Update build system to enable compilation. > > Signed-off-by: Liang Ma > Signed-off-by: Peter Mccarthy > --- > config/common_base|6 + > drivers/event/Makefile|1 + > drivers/event/opdl/Makefile | 62 + > drivers/event/opdl/opdl_log.h | 59 + > drivers/event/opdl/opdl_ring.c| 1250 + > drivers/event/opdl/opdl_ring.h| 628 +++ > drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 + > mk/rte.app.mk |1 + > mk/toolchain/gcc/rte.toolchain-compat.mk |6 + > mk/toolchain/icc/rte.toolchain-compat.mk |6 + > 10 files changed, 2022 insertions(+) > create mode 100644 drivers/event/opdl/Makefile > create mode 100644 drivers/event/opdl/opdl_log.h > create mode 100644 drivers/event/opdl/opdl_ring.c > create mode 100644 drivers/event/opdl/opdl_ring.h > create mode 100644 drivers/event/opdl/rte_pmd_evdev_opdl_version.map > > diff --git a/config/common_base b/config/common_base > index e74febe..67adaba 100644 > --- a/config/common_base > +++ b/config/common_base > @@ -594,6 +594,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF=y > CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF_DEBUG=n > > # > +# Compile PMD for OPDL event device > +# > +CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV=y > +CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV_DEBUG=n > + > +# > # Compile librte_ring > # > CONFIG_RTE_LIBRTE_RING=y > diff --git a/drivers/event/Makefile b/drivers/event/Makefile > index 1f9c0ba..d62 100644 > --- a/drivers/event/Makefile > +++ b/drivers/event/Makefile > @@ -35,5 +35,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_EVENTDEV) += skeleton > DIRS-$(CONFIG_RTE_LIBRTE_PMD_SW_EVENTDEV) += sw > DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF) += octeontx > DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV) += dpaa2 > +DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl > > include $(RTE_SDK)/mk/rte.subdir.mk > diff --git a/drivers/event/opdl/Makefile b/drivers/event/opdl/Makefile > new file mode 100644 > index 000..8277e25 > --- /dev/null > +++ b/drivers/event/opdl/Makefile > @@ -0,0 +1,62 @@ > +# BSD LICENSE > +# > +# Copyright(c) 2016-2017 Intel Corporation. All rights reserved. > +# > +# Redistribution and use in source and binary forms, with or without > +# modification, are permitted provided that the following conditions > +# are met: > +# > +# * Redistributions of source code must retain the above copyright > +# notice, this list of conditions and the following disclaimer. > +# * Redistributions in binary form must reproduce the above copyright > +# notice, this list of conditions and the following disclaimer in > +# the documentation and/or other materials provided with the > +# distribution. > +# * Neither the name of Intel Corporation nor the names of its > +# contributors may be used to endorse or promote products derived > +# from this software without specific prior written permission. > +# > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + > +include $(RTE_SDK)/mk/rte.vars.mk > + > +# library name > +LIB = librte_pmd_opdl_event.a > + > +# build flags > +CFLAGS += -O3 > +CFLAGS += $(WERROR_FLAGS) > +# for older GCC versions, allow us to initialize an event using > +# designated initializers. > +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) > +ifeq ($(shell test $(GCC_VERSION) -le 50 && echo 1), 1) > +CFLAGS += -Wno-missing-field-initializers > +endif > +endif > + > +LDLIBS += -lrte_eal -lrte_even
