[dpdk-dev] [RFC PATCH 1/7] eal: add linear thread id as pthread-local variable
Hi Steve,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang
> Sent: Thursday, December 11, 2014 2:05 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC PATCH 1/7] eal: add linear thread id as
> pthread-local variable
>
>
> Signed-off-by: Cunming Liang
> ---
> lib/librte_eal/common/include/rte_eal.h | 5 ++
> lib/librte_eal/common/include/rte_lcore.h | 12
> lib/librte_eal/linuxapp/eal/eal_thread.c | 115
> --
> 3 files changed, 126 insertions(+), 6 deletions(-)
>
> diff --git a/lib/librte_eal/common/include/rte_eal.h
> b/lib/librte_eal/common/include/rte_eal.h
> index f4ecd2e..2640167 100644
> --- a/lib/librte_eal/common/include/rte_eal.h
> +++ b/lib/librte_eal/common/include/rte_eal.h
> @@ -262,6 +262,11 @@ rte_set_application_usage_hook( rte_usage_hook_t
> usage_func );
> */
> int rte_eal_has_hugepages(void);
>
> +#ifndef RTE_MAX_THREAD
> +#define RTE_MAX_THREADRTE_MAX_LCORE
> +#endif
> +
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_eal/common/include/rte_lcore.h
> b/lib/librte_eal/common/include/rte_lcore.h
> index 49b2c03..cd83d47 100644
> --- a/lib/librte_eal/common/include/rte_lcore.h
> +++ b/lib/librte_eal/common/include/rte_lcore.h
> @@ -73,6 +73,7 @@ struct lcore_config {
> extern struct lcore_config lcore_config[RTE_MAX_LCORE];
>
> RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per core "core id". */
> +RTE_DECLARE_PER_LCORE(unsigned, _thread_id); /**< Per thread "linear tid". */
>
> /**
> * Return the ID of the execution unit we are running on.
> @@ -86,6 +87,17 @@ rte_lcore_id(void)
> }
>
> /**
> + * Return the linear thread ID of the cache unit we are running on.
> + * @return
> + * core ID
> + */
> +static inline unsigned long
> +rte_linear_thread_id(void)
> +{
> + return RTE_PER_LCORE(_thread_id);
> +}
> +
> +/**
> * Get the id of the master lcore
> *
> * @return
> diff --git a/lib/librte_eal/linuxapp/eal/eal_thread.c
> b/lib/librte_eal/linuxapp/eal/eal_thread.c
> index 80a985f..52478d6 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_thread.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_thread.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -51,12 +52,19 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "eal_private.h"
> #include "eal_thread.h"
>
> +#define LINEAR_THREAD_ID_POOL"THREAD_ID_POOL"
> +
> RTE_DEFINE_PER_LCORE(unsigned, _lcore_id);
>
> +/* define linear thread id as thread-local variables */
> +RTE_DEFINE_PER_LCORE(unsigned, _thread_id);
> +
> /*
> * Send a message to a slave lcore identified by slave_id to call a
> * function f with argument arg. Once the execution is done, the
> @@ -94,12 +102,13 @@ rte_eal_remote_launch(int (*f)(void *), void *arg,
> unsigned slave_id)
> return 0;
> }
>
> +
> /* set affinity for current thread */
> static int
> -eal_thread_set_affinity(void)
> +__eal_thread_set_affinity(pthread_t thread, unsigned lcore)
> {
> +
> int s;
> - pthread_t thread;
>
> /*
> * According to the section VERSIONS of the CPU_ALLOC man page:
> @@ -126,9 +135,8 @@ eal_thread_set_affinity(void)
>
> size = CPU_ALLOC_SIZE(RTE_MAX_LCORE);
> CPU_ZERO_S(size, cpusetp);
> - CPU_SET_S(rte_lcore_id(), size, cpusetp);
> + CPU_SET_S(lcore, size, cpusetp);
>
> - thread = pthread_self();
> s = pthread_setaffinity_np(thread, size, cpusetp);
> if (s != 0) {
> RTE_LOG(ERR, EAL, "pthread_setaffinity_np failed\n");
> @@ -140,9 +148,8 @@ eal_thread_set_affinity(void)
> #else /* CPU_ALLOC */
> cpu_set_t cpuset;
> CPU_ZERO( );
> - CPU_SET( rte_lcore_id(), );
> + CPU_SET(lcore, );
>
> - thread = pthread_self();
> s = pthread_setaffinity_np(thread, sizeof( cpuset ), );
> if (s != 0) {
> RTE_LOG(ERR, EAL, "pthread_setaffinity_np failed\n");
> @@ -152,6 +159,15 @@ eal_thread_set_affinity(void)
> return 0;
> }
>
> +/* set affinity for current thread */
> +static int
> +eal_thread_set_affinity(void)
> +{
> + pthread_t thread = pthread_self();
> +
> + return __eal_thread_set_affinity(thread, rte_lcore_id());
> +}
> +
> void eal_thread_init_master(unsigned lcore_id)
> {
> /* set the lcore ID in per-lcore memory area */
> @@ -162,6 +178,87 @@ void eal_thread_init_master(unsigned lcore_id)
> rte_panic("cannot set affinity\n");
> }
>
> +/* linear thread id control block */
> +struct eal_thread_cb {
> + rte_spinlock_t lock;
> + uint64_t nb_bucket;
> + uint64_t bitmap[0];
> +};
> +
> +static struct eal_thread_cb *
> +__create_tid_pool(void)
> +{
> + const struct rte_memzone *mz;
> + struct eal_thread_cb *pcb;
> + uint64_t sz;
> + uint64_t nb_bucket;
> +
> + nb_bucket = RTE_ALIGN_CEIL(RTE_MAX_THREAD, 64) / 64;
> + sz = sizeof(*pcb) +
[dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning
> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Monday, December 22, 2014 4:35 PM > > On Mon, Dec 22, 2014 at 02:01:10PM +, Gonzalez Monroy, Sergio wrote: > > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > Sent: Saturday, December 20, 2014 9:02 PM > > We could move the ifneq($(LIB),) to the _INSTALL variable (top of the same > file). > > Something like this: > > > > -_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > > $(RTE_OUTPUT)/lib/$(LIB) > > +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) ifneq ($(LIB),) > > +_INSTALL += $(RTE_OUTPUT)/lib/$(LIB) endif > > > Actually, as I look at it, this second one doesn't seem to make any sense to > me. > _INSTALL as a variable doesn't seem to get used anywhere that I can see, > certainly not in the capacity of copying shared libraries into the build/lib > area > so that the example apps can get linked with them. So I'm not sure this > makes sense. > The _INSTALL var gets expanded for the rule '_install' in mk/internal/rte.install-post.mk if I am not mistaken. That would trigger the rule $(RTE_OUTPUT)/lib/$(LIB) which in turn builds and copy the shared/static library to build/lib. If we do not add $(RTE_OUTPUT)/lib/$(LIB) to _INSTALL, then the rule will not trigger. Regards, Sergio > Neil >
[dpdk-dev] [PATCH RFC 3/3] examples: example showing use of callbacks.
Rough example showing how callbacks can be used to insert a timestamp into each packet on RX. Then on TX the timestamp is used to calculate the packet latency in cycles through the app. Signed-off-by: Bruce Richardson --- examples/rxtx_callbacks/Makefile | 57 ++ examples/rxtx_callbacks/basicfwd.c | 222 + examples/rxtx_callbacks/basicfwd.h | 46 3 files changed, 325 insertions(+) create mode 100644 examples/rxtx_callbacks/Makefile create mode 100644 examples/rxtx_callbacks/basicfwd.c create mode 100644 examples/rxtx_callbacks/basicfwd.h diff --git a/examples/rxtx_callbacks/Makefile b/examples/rxtx_callbacks/Makefile new file mode 100644 index 000..4a5d99f --- /dev/null +++ b/examples/rxtx_callbacks/Makefile @@ -0,0 +1,57 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# 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. + +ifeq ($(RTE_SDK),) +$(error "Please define RTE_SDK environment variable") +endif + +# Default target, can be overridden by command line or environment +RTE_TARGET ?= x86_64-native-linuxapp-gcc + +include $(RTE_SDK)/mk/rte.vars.mk + +# binary name +APP = basicfwd + +# all source are stored in SRCS-y +SRCS-y := basicfwd.c + +CFLAGS += $(WERROR_FLAGS) + +# workaround for a gcc bug with noreturn attribute +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) +CFLAGS_main.o += -Wno-return-type +endif + +EXTRA_CFLAGS += -O3 -g -Wfatal-errors + +include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/rxtx_callbacks/basicfwd.c b/examples/rxtx_callbacks/basicfwd.c new file mode 100644 index 000..0209bf4 --- /dev/null +++ b/examples/rxtx_callbacks/basicfwd.c @@ -0,0 +1,222 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. + * 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
[dpdk-dev] [PATCH RFC 2/3] ethdev: Add in data rxtx callback support
Add in support for inline processing of packets inside the RX or
TX call. For an RX callback, what happens is that we get a set of
packets from the NIC and then pass them to a callback function, if
configured, to allow additional processing to be done on them, e.g.
filling in more mbuf fields, before passing back to the application.
On TX, the packets are similarly post-processed before being handed
to the NIC for transmission.
Signed-off-by: Bruce Richardson
---
lib/librte_ether/rte_ethdev.c | 91 --
lib/librte_ether/rte_ethdev.h | 125 +-
2 files changed, 210 insertions(+), 6 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 87a5323..882507b 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -337,6 +337,15 @@ rte_eth_dev_rx_queue_config(struct rte_eth_dev *dev,
uint16_t nb_queues)
dev->data->nb_rx_queues = 0;
return -(ENOMEM);
}
+ dev->rx_cbs = rte_zmalloc("ethdev->rx_cbs",
+ sizeof(*dev->rx_cbs) * nb_queues,
+ RTE_CACHE_LINE_SIZE);
+ if (dev->rx_cbs == NULL) {
+ rte_free(dev->data->rx_queues);
+ dev->data->rx_queues = NULL;
+ dev->data->nb_rx_queues = 0;
+ return -(ENOMEM);
+ }
} else { /* re-configure */
FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_release, -ENOTSUP);
@@ -348,10 +357,18 @@ rte_eth_dev_rx_queue_config(struct rte_eth_dev *dev,
uint16_t nb_queues)
RTE_CACHE_LINE_SIZE);
if (rxq == NULL)
return -(ENOMEM);
+ dev->rx_cbs = rte_realloc(dev->rx_cbs, sizeof(*dev->rx_cbs) *
+ nb_queues, RTE_CACHE_LINE_SIZE);
+ if (dev->rx_cbs == NULL)
+ return -(ENOMEM);
- if (nb_queues > old_nb_queues)
+ if (nb_queues > old_nb_queues) {
+ uint16_t new_qs = nb_queues - old_nb_queues;
memset(rxq + old_nb_queues, 0,
- sizeof(rxq[0]) * (nb_queues - old_nb_queues));
+ sizeof(rxq[0]) * new_qs);
+ memset(dev->rx_cbs + old_nb_queues, 0,
+ sizeof(dev->rx_cbs[0]) * new_qs);
+ }
dev->data->rx_queues = rxq;
@@ -479,6 +496,15 @@ rte_eth_dev_tx_queue_config(struct rte_eth_dev *dev,
uint16_t nb_queues)
dev->data->nb_tx_queues = 0;
return -(ENOMEM);
}
+ dev->tx_cbs = rte_zmalloc("ethdev->tx_cbs",
+ sizeof(*dev->tx_cbs) * nb_queues,
+ RTE_CACHE_LINE_SIZE);
+ if (dev->tx_cbs == NULL) {
+ rte_free(dev->data->tx_queues);
+ dev->data->tx_queues = NULL;
+ dev->data->nb_tx_queues = 0;
+ return -(ENOMEM);
+ }
} else { /* re-configure */
FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_queue_release, -ENOTSUP);
@@ -490,10 +516,19 @@ rte_eth_dev_tx_queue_config(struct rte_eth_dev *dev,
uint16_t nb_queues)
RTE_CACHE_LINE_SIZE);
if (txq == NULL)
return -(ENOMEM);
+ dev->tx_cbs = rte_realloc(dev->tx_cbs, sizeof(*dev->tx_cbs) *
+ nb_queues, RTE_CACHE_LINE_SIZE);
+ if (dev->tx_cbs == NULL)
+ return -(ENOMEM);
+
- if (nb_queues > old_nb_queues)
+ if (nb_queues > old_nb_queues) {
+ uint16_t new_qs = nb_queues - old_nb_queues;
memset(txq + old_nb_queues, 0,
- sizeof(txq[0]) * (nb_queues - old_nb_queues));
+ sizeof(txq[0]) * new_qs);
+ memset(dev->tx_cbs + old_nb_queues, 0,
+ sizeof(dev->tx_cbs[0]) * new_qs);
+ }
dev->data->tx_queues = txq;
@@ -3269,3 +3304,51 @@ rte_eth_dev_filter_ctrl(uint8_t port_id, enum
rte_filter_type filter_type,
FUNC_PTR_OR_ERR_RET(*dev->dev_ops->filter_ctrl, -ENOTSUP);
return (*dev->dev_ops->filter_ctrl)(dev, filter_type, filter_op, arg);
}
+
+void *
+rte_eth_add_rx_callback(uint8_t port_id, uint16_t queue_id,
+ rte_rxtx_callback_fn fn, void *user_param)
+{
+ /* check input parameters */
+ if (port_id >= nb_ports || fn == NULL ||
+ queue_id >= rte_eth_devices[port_id].data->nb_rx_queues) {
+ rte_errno = EINVAL;
+ return
[dpdk-dev] [PATCH RFC 1/3] ethdev: rename callbacks field to intr_cbs
The callbacks member of the rte_eth_dev structure has been renamed
to intr_cbs to make it clear that it refers to callbacks from NIC
interrupts. This then allows us to add other types of callbacks to
the structure without ambiguity.
Signed-off-by: Bruce Richardson
---
app/test/virtual_pmd.c | 2 +-
lib/librte_ether/rte_ethdev.c | 12 ++--
lib/librte_ether/rte_ethdev.h | 2 +-
lib/librte_pmd_bond/rte_eth_bond_api.c | 2 +-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index ade6cb0..8845ba8 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -576,7 +576,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
eth_dev->data->nb_rx_queues = (uint16_t)1;
eth_dev->data->nb_tx_queues = (uint16_t)1;
- TAILQ_INIT(&(eth_dev->callbacks));
+ TAILQ_INIT(&(eth_dev->intr_cbs));
eth_dev->data->dev_link.link_status = 0;
eth_dev->data->dev_link.link_speed = ETH_LINK_SPEED_1;
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 95f2ceb..87a5323 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -265,7 +265,7 @@ rte_eth_dev_init(struct rte_pci_driver *pci_drv,
eth_dev->data->rx_mbuf_alloc_failed = 0;
/* init user callbacks */
- TAILQ_INIT(&(eth_dev->callbacks));
+ TAILQ_INIT(&(eth_dev->intr_cbs));
/*
* Set the default MTU.
@@ -2697,7 +2697,7 @@ rte_eth_dev_callback_register(uint8_t port_id,
dev = _eth_devices[port_id];
rte_spinlock_lock(_eth_dev_cb_lock);
- TAILQ_FOREACH(user_cb, &(dev->callbacks), next) {
+ TAILQ_FOREACH(user_cb, &(dev->intr_cbs), next) {
if (user_cb->cb_fn == cb_fn &&
user_cb->cb_arg == cb_arg &&
user_cb->event == event) {
@@ -2711,7 +2711,7 @@ rte_eth_dev_callback_register(uint8_t port_id,
user_cb->cb_fn = cb_fn;
user_cb->cb_arg = cb_arg;
user_cb->event = event;
- TAILQ_INSERT_TAIL(&(dev->callbacks), user_cb, next);
+ TAILQ_INSERT_TAIL(&(dev->intr_cbs), user_cb, next);
}
rte_spinlock_unlock(_eth_dev_cb_lock);
@@ -2738,7 +2738,7 @@ rte_eth_dev_callback_unregister(uint8_t port_id,
rte_spinlock_lock(_eth_dev_cb_lock);
ret = 0;
- for (cb = TAILQ_FIRST(>callbacks); cb != NULL; cb = next) {
+ for (cb = TAILQ_FIRST(>intr_cbs); cb != NULL; cb = next) {
next = TAILQ_NEXT(cb, next);
@@ -2752,7 +2752,7 @@ rte_eth_dev_callback_unregister(uint8_t port_id,
* then remove it.
*/
if (cb->active == 0) {
- TAILQ_REMOVE(&(dev->callbacks), cb, next);
+ TAILQ_REMOVE(&(dev->intr_cbs), cb, next);
rte_free(cb);
} else {
ret = -EAGAIN;
@@ -2771,7 +2771,7 @@ _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
struct rte_eth_dev_callback dev_cb;
rte_spinlock_lock(_eth_dev_cb_lock);
- TAILQ_FOREACH(cb_lst, &(dev->callbacks), next) {
+ TAILQ_FOREACH(cb_lst, &(dev->intr_cbs), next) {
if (cb_lst->cb_fn == NULL || cb_lst->event != event)
continue;
dev_cb = *cb_lst;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index f66805d..c76a5d0 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1564,7 +1564,7 @@ struct rte_eth_dev {
const struct eth_driver *driver;/**< Driver for this device */
struct eth_dev_ops *dev_ops;/**< Functions exported by PMD */
struct rte_pci_device *pci_dev; /**< PCI info. supplied by probing */
- struct rte_eth_dev_cb_list callbacks; /**< User application callbacks */
+ struct rte_eth_dev_cb_list intr_cbs; /**< User application callbacks on
interrupt*/
};
struct rte_eth_dev_sriov {
diff --git a/lib/librte_pmd_bond/rte_eth_bond_api.c
b/lib/librte_pmd_bond/rte_eth_bond_api.c
index ef5ddf4..01e8f21 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_api.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_api.c
@@ -247,7 +247,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
eth_dev->data->nb_rx_queues = (uint16_t)1;
eth_dev->data->nb_tx_queues = (uint16_t)1;
- TAILQ_INIT(&(eth_dev->callbacks));
+ TAILQ_INIT(&(eth_dev->intr_cbs));
eth_dev->data->dev_link.link_status = 0;
--
1.9.3
[dpdk-dev] [PATCH v2 4/4] docs: Add ABI documentation
Adding a document describing rudimentary ABI policy and adding notice space for any deprecation announcements Signed-off-by: Neil Horman CC: Thomas Monjalon CC: "Richardson, Bruce" --- doc/abi.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644 doc/abi.txt diff --git a/doc/abi.txt b/doc/abi.txt new file mode 100644 index 000..b6dcc7d --- /dev/null +++ b/doc/abi.txt @@ -0,0 +1,17 @@ +ABI policy: + ABI versions are set at the time of major release labeling, and ABI may +change multiple times between the last labeling and the HEAD label of the git +tree without warning + + ABI versions, once released are available until such time as their +deprecation has been noted here for at least one major release cycle, after it +has been tagged. E.g. the ABI for DPDK 1.8 is shipped, and then the decision to +remove it is made during the development of DPDK 1.9. The decision will be +recorded here, shipped with the DPDK 1.9 release, and actually removed when DPDK +1.10 ships. + + ABI versions may be deprecated in whole, or in part as needed by a given +update. + +Deprecation Notices: + -- 1.9.3
[dpdk-dev] [PATCH v2 3/4] Add library version extenstion
To differentiate libraries that break ABI, we add a library version number suffix to the library, which must be incremented when a given libraries ABI is broken. This patch enforces that addition, sets the initial abi soname extension to 1 for each library and creates a symlink to the base SONAME so that the test applications will link properly. Signed-off-by: Neil Horman CC: Thomas Monjalon CC: "Richardson, Bruce" --- lib/librte_acl/Makefile | 2 ++ lib/librte_cfgfile/Makefile | 2 ++ lib/librte_cmdline/Makefile | 2 ++ lib/librte_compat/Makefile | 2 ++ lib/librte_distributor/Makefile | 2 ++ lib/librte_eal/bsdapp/eal/Makefile | 2 ++ lib/librte_eal/linuxapp/eal/Makefile | 2 ++ lib/librte_ether/Makefile| 2 ++ lib/librte_hash/Makefile | 2 ++ lib/librte_ip_frag/Makefile | 2 ++ lib/librte_ivshmem/Makefile | 2 ++ lib/librte_kni/Makefile | 2 ++ lib/librte_kvargs/Makefile | 2 ++ lib/librte_lpm/Makefile | 2 ++ lib/librte_malloc/Makefile | 2 ++ lib/librte_mbuf/Makefile | 2 ++ lib/librte_mempool/Makefile | 2 ++ lib/librte_meter/Makefile| 2 ++ lib/librte_pipeline/Makefile | 2 ++ lib/librte_pmd_af_packet/Makefile| 2 ++ lib/librte_pmd_bond/Makefile | 2 ++ lib/librte_pmd_e1000/Makefile| 2 ++ lib/librte_pmd_enic/Makefile | 2 ++ lib/librte_pmd_i40e/Makefile | 2 ++ lib/librte_pmd_ixgbe/Makefile| 2 ++ lib/librte_pmd_pcap/Makefile | 2 ++ lib/librte_pmd_ring/Makefile | 2 ++ lib/librte_pmd_virtio/Makefile | 2 ++ lib/librte_pmd_vmxnet3/Makefile | 2 ++ lib/librte_pmd_xenvirt/Makefile | 2 ++ lib/librte_port/Makefile | 2 ++ lib/librte_power/Makefile| 2 ++ lib/librte_ring/Makefile | 2 ++ lib/librte_sched/Makefile| 2 ++ lib/librte_table/Makefile| 2 ++ lib/librte_timer/Makefile| 2 ++ lib/librte_vhost/Makefile| 2 ++ mk/rte.lib.mk| 11 +-- 38 files changed, 83 insertions(+), 2 deletions(-) diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile index 45cbf80..765deb1 100644 --- a/lib/librte_acl/Makefile +++ b/lib/librte_acl/Makefile @@ -39,6 +39,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) EXPORT_MAP := rte_acl_version.map +LIBABIVER := 1 + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile index a4f73de..032c240 100644 --- a/lib/librte_cfgfile/Makefile +++ b/lib/librte_cfgfile/Makefile @@ -41,6 +41,8 @@ CFLAGS += $(WERROR_FLAGS) EXPORT_MAP := rte_cfgfile_version.map +LIBABIVER := 1 + # # all source are stored in SRCS-y # diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile index 3c71831..719dff6 100644 --- a/lib/librte_cmdline/Makefile +++ b/lib/librte_cmdline/Makefile @@ -38,6 +38,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 EXPORT_MAP := rte_cmdline_version.map +LIBABIVER := 1 + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := cmdline.c SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_cirbuf.c diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile index 3415c7b..a23d349 100644 --- a/lib/librte_compat/Makefile +++ b/lib/librte_compat/Makefile @@ -32,6 +32,8 @@ include $(RTE_SDK)/mk/rte.vars.mk +LIBABIVER := 1 + # install includes SYMLINK-y-include := rte_compat.h diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile index 3674a2c..4c9af17 100644 --- a/lib/librte_distributor/Makefile +++ b/lib/librte_distributor/Makefile @@ -39,6 +39,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) EXPORT_MAP := rte_distributor_version.map +LIBABIVER := 1 + # all source are stored in SRCS-y SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile index 0b5f9d9..ae214a4 100644 --- a/lib/librte_eal/bsdapp/eal/Makefile +++ b/lib/librte_eal/bsdapp/eal/Makefile @@ -48,6 +48,8 @@ CFLAGS += $(WERROR_FLAGS) -O3 EXPORT_MAP := rte_eal_version.map +LIBABIVER := 1 + # specific to linuxapp exec-env SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) := eal.c SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_memory.c diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile index bae8af1..e117cec 100644 --- a/lib/librte_eal/linuxapp/eal/Makefile +++ b/lib/librte_eal/linuxapp/eal/Makefile @@ -35,6 +35,8 @@ LIB = librte_eal.a EXPORT_MAP := rte_eal_version.map +LIBABIVER := 1 + VPATH += $(RTE_SDK)/lib/librte_eal/common CFLAGS += -I$(SRCDIR)/include diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile index 80ad78d..c0e5768 100644 --- a/lib/librte_ether/Makefile +++ b/lib/librte_ether/Makefile @@ -41,6 +41,8
[dpdk-dev] [PATCH v2 2/4] Provide initial versioning for all DPDK libraries
Add linker version script files to each DPDK library to put a stake in the ground from which we can start cleaning up API's Signed-off-by: Neil Horman CC: Thomas Monjalon CC: "Richardson, Bruce" --- Change Notes: v2) * Updated export map to not require full path --- lib/librte_acl/Makefile| 2 + lib/librte_acl/rte_acl_version.map | 21 lib/librte_cfgfile/Makefile| 2 + lib/librte_cfgfile/rte_cfgfile_version.map | 14 +++ lib/librte_cmdline/Makefile| 2 + lib/librte_cmdline/rte_cmdline_version.map | 69 + lib/librte_distributor/Makefile| 2 + lib/librte_distributor/rte_distributor_version.map | 16 +++ lib/librte_eal/bsdapp/eal/Makefile | 2 + lib/librte_eal/bsdapp/eal/rte_eal_version.map | 90 lib/librte_eal/linuxapp/eal/Makefile | 2 + lib/librte_eal/linuxapp/eal/rte_eal_version.map| 90 lib/librte_ether/Makefile | 2 + lib/librte_ether/rte_ether_version.map | 113 + lib/librte_hash/Makefile | 2 + lib/librte_hash/rte_hash_version.map | 18 lib/librte_ip_frag/Makefile| 2 + lib/librte_ip_frag/rte_ipfrag_version.map | 14 +++ lib/librte_ivshmem/Makefile| 2 + lib/librte_ivshmem/rte_ivshmem_version.map | 13 +++ lib/librte_kni/Makefile| 2 + lib/librte_kni/rte_kni_version.map | 20 lib/librte_kvargs/Makefile | 2 + lib/librte_kvargs/rte_kvargs_version.map | 10 ++ lib/librte_lpm/Makefile| 2 + lib/librte_lpm/rte_lpm_version.map | 24 + lib/librte_malloc/Makefile | 2 + lib/librte_malloc/rte_malloc_version.map | 19 lib/librte_mbuf/Makefile | 2 + lib/librte_mbuf/rte_mbuf_version.map | 14 +++ lib/librte_mempool/Makefile| 2 + lib/librte_mempool/rte_mempool_version.map | 18 lib/librte_meter/Makefile | 2 + lib/librte_meter/rte_meter_version.map | 13 +++ lib/librte_pipeline/Makefile | 2 + lib/librte_pipeline/rte_pipeline_version.map | 23 + lib/librte_pmd_af_packet/Makefile | 2 + .../rte_pmd_af_packet_version.map | 7 ++ lib/librte_pmd_bond/Makefile | 2 + lib/librte_pmd_bond/rte_eth_bond_version.map | 21 lib/librte_pmd_e1000/Makefile | 2 + lib/librte_pmd_e1000/rte_pmd_e1000_version.map | 5 + lib/librte_pmd_enic/Makefile | 2 + lib/librte_pmd_enic/rte_pmd_enic_version.map | 5 + lib/librte_pmd_i40e/Makefile | 2 + lib/librte_pmd_i40e/rte_pmd_i40e_version.map | 5 + lib/librte_pmd_ixgbe/Makefile | 2 + lib/librte_pmd_ixgbe/rte_pmd_ixgbe_version.map | 5 + lib/librte_pmd_pcap/Makefile | 2 + lib/librte_pmd_pcap/rte_pmd_pcap_version.map | 5 + lib/librte_pmd_ring/Makefile | 2 + lib/librte_pmd_ring/rte_eth_ring.c | 2 +- lib/librte_pmd_ring/rte_eth_ring.h | 6 -- lib/librte_pmd_ring/rte_eth_ring_version.map | 10 ++ lib/librte_pmd_virtio/Makefile | 1 + lib/librte_pmd_virtio/rte_pmd_virtio_version.map | 5 + lib/librte_pmd_vmxnet3/Makefile| 2 + lib/librte_pmd_vmxnet3/rte_pmd_vmxnet3_version.map | 5 + lib/librte_pmd_xenvirt/Makefile| 2 + lib/librte_pmd_xenvirt/rte_eth_xenvirt_version.map | 8 ++ lib/librte_port/Makefile | 2 + lib/librte_port/rte_port_version.map | 18 lib/librte_power/Makefile | 2 + lib/librte_power/rte_power_version.map | 18 lib/librte_ring/Makefile | 2 + lib/librte_ring/rte_ring_version.map | 12 +++ lib/librte_sched/Makefile | 2 + lib/librte_sched/rte_sched_version.map | 22 lib/librte_table/Makefile | 2 + lib/librte_table/rte_table_version.map | 22 lib/librte_timer/Makefile | 2 + lib/librte_timer/rte_timer_version.map | 16 +++ lib/librte_vhost/Makefile | 2 + lib/librte_vhost/rte_vhost_version.map | 14 +++ mk/rte.lib.mk | 2 +- 75 files changed, 875 insertions(+), 8 deletions(-) create mode 100644
[dpdk-dev] [PATCH v2 1/4] compat: Add infrastructure to support symbol versioning
Add initial pass header files to support symbol versioning. Signed-off-by: Neil Horman CC: Thomas Monjalon CC: "Richardson, Bruce" CC: "Gonzalez Monroy, Sergio" Change Notes: V2) Moved ifeq to _INSTALL target --- lib/Makefile | 1 + lib/librte_compat/Makefile | 38 + lib/librte_compat/rte_compat.h | 96 ++ mk/rte.lib.mk | 9 +++- 4 files changed, 143 insertions(+), 1 deletion(-) create mode 100644 lib/librte_compat/Makefile create mode 100644 lib/librte_compat/rte_compat.h diff --git a/lib/Makefile b/lib/Makefile index 0ffc982..d617d81 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -31,6 +31,7 @@ include $(RTE_SDK)/mk/rte.vars.mk +DIRS-y += librte_compat DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal DIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += librte_malloc DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile new file mode 100644 index 000..3415c7b --- /dev/null +++ b/lib/librte_compat/Makefile @@ -0,0 +1,38 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Neil Horman +# 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 + + +# install includes +SYMLINK-y-include := rte_compat.h + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_compat/rte_compat.h b/lib/librte_compat/rte_compat.h new file mode 100644 index 000..d99e362 --- /dev/null +++ b/lib/librte_compat/rte_compat.h @@ -0,0 +1,96 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2014 Neil Horman . + * 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. + */ + +#ifndef _RTE_COMPAT_H_ +#define _RTE_COMPAT_H_ + +/* + * This is just a stringification macro for use below. + */ +#define SA(x) #x + +#ifdef RTE_BUILD_SHARED_LIB + +/* + * Provides backwards compatibility when
[dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning
On Mon, Dec 22, 2014 at 02:00:17PM -0500, Neil Horman wrote: > On Mon, Dec 22, 2014 at 05:09:55PM +, Gonzalez Monroy, Sergio wrote: > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > Sent: Monday, December 22, 2014 4:35 PM > > > > > > On Mon, Dec 22, 2014 at 02:01:10PM +, Gonzalez Monroy, Sergio wrote: > > > > > > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > > Sent: Saturday, December 20, 2014 9:02 PM > > > > We could move the ifneq($(LIB),) to the _INSTALL variable (top of the > > > > same > > > file). > > > > Something like this: > > > > > > > > -_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > > > > $(RTE_OUTPUT)/lib/$(LIB) > > > > +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) ifneq ($(LIB),) > > > > +_INSTALL += $(RTE_OUTPUT)/lib/$(LIB) endif > > > > > > > Actually, as I look at it, this second one doesn't seem to make any sense > > > to > > > me. > > > _INSTALL as a variable doesn't seem to get used anywhere that I can see, > > > certainly not in the capacity of copying shared libraries into the > > > build/lib area > > > so that the example apps can get linked with them. So I'm not sure this > > > makes sense. > > > > > The _INSTALL var gets expanded for the rule '_install' in > > mk/internal/rte.install-post.mk if I am not mistaken. > > That would trigger the rule $(RTE_OUTPUT)/lib/$(LIB) which in turn builds > > and copy the shared/static library to build/lib. > > > > If we do not add $(RTE_OUTPUT)/lib/$(LIB) to _INSTALL, then the rule will > > not trigger. > > > I get all of that, but something isn't right with either your reasoning, or my > coding, as If I make the change you suggest, nothing ever gets copied into the > build/lib directory, either for a static or DSO build. > > Neil > Ah, nm, I figured it out, I had accidentally deleted the copy operation which needs to remain there. I'll fix this up and repost. Neil > > Regards, > > Sergio > > > > > Neil > > > > > >
[dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning
Hi Neil, Just a couple of minor comments. > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Saturday, December 20, 2014 9:02 PM > Subject: [PATCH 1/4] compat: Add infrastructure to support symbol > versioning > > Add initial pass header files to support symbol versioning. > [...] > > diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk index 81bf8e1..2299cbe 100644 > --- a/mk/rte.lib.mk > +++ b/mk/rte.lib.mk > @@ -40,8 +40,12 @@ VPATH += $(SRCDIR) > > ifeq ($(RTE_BUILD_SHARED_LIB),y) > LIB := $(patsubst %.a,%.so,$(LIB)) > + > +CPU_LDFLAGS += --version-script=$(EXPORT_MAP) What about setting --version-script=$(SRCDIR)/$(EXPORT_MAP) so we can do: Ie. 'EXPORT_MAP = rte_eal_version.map' instead of 'EXPORT_MAP = $(RTE_SDK)/lib/librte_eal/linuxapp/eal/rte_eal_version.map' > + > endif > > + > _BUILD = $(LIB) > _INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > $(RTE_OUTPUT)/lib/$(LIB) _CLEAN = doclean @@ -161,7 +165,9 @@ endif > $(RTE_OUTPUT)/lib/$(LIB): $(LIB) > @echo " INSTALL-LIB $(LIB)" > @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib > +ifneq ($(LIB),) > $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib > +endif > We could move the ifneq($(LIB),) to the _INSTALL variable (top of the same file). Something like this: -_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) $(RTE_OUTPUT)/lib/$(LIB) +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) +ifneq ($(LIB),) +_INSTALL += $(RTE_OUTPUT)/lib/$(LIB) +endif Thanks, Sergio > # > # Clean all generated files > -- > 1.9.3
[dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning
On Mon, Dec 22, 2014 at 05:09:55PM +, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Monday, December 22, 2014 4:35 PM > > > > On Mon, Dec 22, 2014 at 02:01:10PM +, Gonzalez Monroy, Sergio wrote: > > > > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > Sent: Saturday, December 20, 2014 9:02 PM > > > We could move the ifneq($(LIB),) to the _INSTALL variable (top of the same > > file). > > > Something like this: > > > > > > -_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > > > $(RTE_OUTPUT)/lib/$(LIB) > > > +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) ifneq ($(LIB),) > > > +_INSTALL += $(RTE_OUTPUT)/lib/$(LIB) endif > > > > > Actually, as I look at it, this second one doesn't seem to make any sense to > > me. > > _INSTALL as a variable doesn't seem to get used anywhere that I can see, > > certainly not in the capacity of copying shared libraries into the > > build/lib area > > so that the example apps can get linked with them. So I'm not sure this > > makes sense. > > > The _INSTALL var gets expanded for the rule '_install' in > mk/internal/rte.install-post.mk if I am not mistaken. > That would trigger the rule $(RTE_OUTPUT)/lib/$(LIB) which in turn builds and > copy the shared/static library to build/lib. > > If we do not add $(RTE_OUTPUT)/lib/$(LIB) to _INSTALL, then the rule will not > trigger. > I get all of that, but something isn't right with either your reasoning, or my coding, as If I make the change you suggest, nothing ever gets copied into the build/lib directory, either for a static or DSO build. Neil > Regards, > Sergio > > > Neil > > >
[dpdk-dev] rte_mempool_create fails with ENOMEM
On Sat, Dec 20, 2014 at 2:34 AM, Stephen Hemminger wrote: > You can reserve hugepages on the kernel cmdline (GRUB). Great, thanks, I'll try that! Newman > > On Fri, Dec 19, 2014 at 12:13 PM, Newman Poborsky > wrote: >> >> On Thu, Dec 18, 2014 at 9:03 PM, Ananyev, Konstantin < >> konstantin.ananyev at intel.com> wrote: >> >> > >> > >> > > -Original Message- >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, >> > > Konstantin >> > > Sent: Thursday, December 18, 2014 5:43 PM >> > > To: Newman Poborsky; dev at dpdk.org >> > > Subject: Re: [dpdk-dev] rte_mempool_create fails with ENOMEM >> > > >> > > Hi >> > > >> > > > -Original Message- >> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Newman Poborsky >> > > > Sent: Thursday, December 18, 2014 1:26 PM >> > > > To: dev at dpdk.org >> > > > Subject: [dpdk-dev] rte_mempool_create fails with ENOMEM >> > > > >> > > > Hi, >> > > > >> > > > could someone please provide any explanation why sometimes mempool >> > creation >> > > > fails with ENOMEM? >> > > > >> > > > I run my test app several times without any problems and then I >> > > > start >> > > > getting ENOMEM error when creating mempool that are used for >> > > > packets. >> > I try >> > > > to delete everything from /mnt/huge, I increase the number of huge >> > pages, >> > > > remount /mnt/huge but nothing helps. >> > > > >> > > > There is more than enough memory on server. I tried to debug >> > > > rte_mempool_create() call and it seems that after server is >> > > > restarted >> > free >> > > > mem segments are bigger than 2MB, but after running test app for >> > several >> > > > times, it seems that all free mem segments have a size of 2MB, and >> > since I >> > > > am requesting 8MB for my packet mempool, this fails. I'm not really >> > sure >> > > > that this conclusion is correct. >> > > >> > > Yes,rte_mempool_create uses rte_memzone_reserve() to allocate >> > > single physically continuous chunk of memory. >> > > If no such chunk exist, then it would fail. >> > > Why physically continuous? >> > > Main reason - to make things easier for us, as in that case we don't >> > have to worry >> > > about situation when mbuf crosses page boundary. >> > > So you can overcome that problem like that: >> > > Allocate max amount of memory you would need to hold all mbufs in >> > > worst >> > case (all pages physically disjoint) >> > > using rte_malloc(). >> > >> > Actually my wrong: rte_malloc()s wouldn't help you here. >> > You probably need to allocate some external (not managed by EAL) memory >> > in >> > that case, >> > may be mmap() with MAP_HUGETLB, or something similar. >> > >> > > Figure out it's physical mappings. >> > > Call rte_mempool_xmem_create(). >> > > You can look at: app/test-pmd/mempool_anon.c as a reference. >> > > It uses same approach to create mempool over 4K pages. >> > > >> > > We probably add similar function into mempool API >> > (create_scatter_mempool or something) >> > > or just add a new flag (USE_SCATTER_MEM) into rte_mempool_create(). >> > > Though right now it is not there. >> > > >> > > Another quick alternative - use 1G pages. >> > > >> > > Konstantin >> > >> >> >> Ok, thanks for the explanation. I understand that this is probably an OS >> question more than DPDK, but is there a way to again allocate a contiguous >> memory for n-th run of my test app? It seems that hugepages get >> divded/separated to individual 2MB hugepage. Shouldn't OS's memory >> management system try to group those hupages back to one contiguous chunk >> once my app/process is done? Again, I know very little about Linux >> memory >> management and hugepages, so forgive me if this is a stupid question. >> Is rebooting the OS the only way to deal with this problem? Or should I >> just try to use 1GB hugepages? >> >> p.s. Konstantin, sorry for the double reply, I accidentally forgot to >> include dev list in my first reply :) >> >> Newman >> >> > >> > > > >> > > > Does anybody have any idea what to check and how running my test app >> > > > several times affects hugepages? >> > > > >> > > > For me, this doesn't make any since because after test app exits, >> > resources >> > > > should be freed, right? >> > > > >> > > > This has been driving me crazy for days now. I tried reading a bit >> > > > more >> > > > theory about hugepages, but didn't find out anything that could help >> > me. >> > > > Maybe it's something else and completely trivial, but I can't figure >> > > > it >> > > > out, so any help is appreciated. >> > > > >> > > > Thank you! >> > > > >> > > > BR, >> > > > Newman P. >> > > >
[dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning
On Mon, Dec 22, 2014 at 02:01:10PM +, Gonzalez Monroy, Sergio wrote: > Hi Neil, > > Just a couple of minor comments. > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Saturday, December 20, 2014 9:02 PM > > Subject: [PATCH 1/4] compat: Add infrastructure to support symbol > > versioning > > > > Add initial pass header files to support symbol versioning. > > > [...] > > > > diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk index 81bf8e1..2299cbe 100644 > > --- a/mk/rte.lib.mk > > +++ b/mk/rte.lib.mk > > @@ -40,8 +40,12 @@ VPATH += $(SRCDIR) > > > > ifeq ($(RTE_BUILD_SHARED_LIB),y) > > LIB := $(patsubst %.a,%.so,$(LIB)) > > + > > +CPU_LDFLAGS += --version-script=$(EXPORT_MAP) > > What about setting --version-script=$(SRCDIR)/$(EXPORT_MAP) so we can do: > Ie. 'EXPORT_MAP = rte_eal_version.map' instead of 'EXPORT_MAP = > $(RTE_SDK)/lib/librte_eal/linuxapp/eal/rte_eal_version.map' > > > + > > endif > > > > + > > _BUILD = $(LIB) > > _INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > > $(RTE_OUTPUT)/lib/$(LIB) _CLEAN = doclean @@ -161,7 +165,9 @@ endif > > $(RTE_OUTPUT)/lib/$(LIB): $(LIB) > > @echo " INSTALL-LIB $(LIB)" > > @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib > > +ifneq ($(LIB),) > > $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib > > +endif > > > We could move the ifneq($(LIB),) to the _INSTALL variable (top of the same > file). > Something like this: > > -_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) $(RTE_OUTPUT)/lib/$(LIB) > +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > +ifneq ($(LIB),) > +_INSTALL += $(RTE_OUTPUT)/lib/$(LIB) > +endif > Actually, as I look at it, this second one doesn't seem to make any sense to me. _INSTALL as a variable doesn't seem to get used anywhere that I can see, certainly not in the capacity of copying shared libraries into the build/lib area so that the example apps can get linked with them. So I'm not sure this makes sense. Neil > Thanks, > Sergio > > > # > > # Clean all generated files > > -- > > 1.9.3 > >
[dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning
On Mon, Dec 22, 2014 at 02:01:10PM +, Gonzalez Monroy, Sergio wrote: > Hi Neil, > > Just a couple of minor comments. > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Saturday, December 20, 2014 9:02 PM > > Subject: [PATCH 1/4] compat: Add infrastructure to support symbol > > versioning > > > > Add initial pass header files to support symbol versioning. > > > [...] > > > > diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk index 81bf8e1..2299cbe 100644 > > --- a/mk/rte.lib.mk > > +++ b/mk/rte.lib.mk > > @@ -40,8 +40,12 @@ VPATH += $(SRCDIR) > > > > ifeq ($(RTE_BUILD_SHARED_LIB),y) > > LIB := $(patsubst %.a,%.so,$(LIB)) > > + > > +CPU_LDFLAGS += --version-script=$(EXPORT_MAP) > > What about setting --version-script=$(SRCDIR)/$(EXPORT_MAP) so we can do: > Ie. 'EXPORT_MAP = rte_eal_version.map' instead of 'EXPORT_MAP = > $(RTE_SDK)/lib/librte_eal/linuxapp/eal/rte_eal_version.map' > > > + > > endif > > > > + > > _BUILD = $(LIB) > > _INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > > $(RTE_OUTPUT)/lib/$(LIB) _CLEAN = doclean @@ -161,7 +165,9 @@ endif > > $(RTE_OUTPUT)/lib/$(LIB): $(LIB) > > @echo " INSTALL-LIB $(LIB)" > > @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib > > +ifneq ($(LIB),) > > $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib > > +endif > > > We could move the ifneq($(LIB),) to the _INSTALL variable (top of the same > file). > Something like this: > > -_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) $(RTE_OUTPUT)/lib/$(LIB) > +_INSTALL = $(INSTALL-FILES-y) $(SYMLINK-FILES-y) > +ifneq ($(LIB),) > +_INSTALL += $(RTE_OUTPUT)/lib/$(LIB) > +endif > Yeah, this all seems reasonable, I'll repost shortly Thanks Neil > Thanks, > Sergio > > > # > > # Clean all generated files > > -- > > 1.9.3 > >
[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
On Mon, 22 Dec 2014 09:46:03 + Bruce Richardson wrote: > On Mon, Dec 22, 2014 at 01:51:27AM +, Liang, Cunming wrote: > > ... > > > I'm conflicted on this one. However, I think far more applications would > > > be > > > broken > > > to start having to use thread_id in place of an lcore_id than would be > > > broken > > > by having the lcore_id no longer actually correspond to a core. > > > I'm actually struggling to come up with a large number of scenarios where > > > it's > > > important to an app to determine the cpu it's running on, compared to the > > > large > > > number of cases where you need to have a data-structure per thread. In > > > DPDK > > > libs > > > alone, you see this assumption that lcore_id == thread_id a large number > > > of > > > times. > > > > > > Despite the slight logical inconsistency, I think it's better to avoid > > > introducing > > > a thread-id and continue having lcore_id representing a unique thread. > > > > > > /Bruce > > > > Ok, I understand it. > > I list the implicit meaning if using lcore_id representing the unique > > thread. > > 1). When lcore_id less than RTE_MAX_LCORE, it still represents the logical > > core id. > > 2). When lcore_id large equal than RTE_MAX_LCORE, it represents an unique > > id for thread. > > 3). Most of APIs(except rte_lcore_id()) in rte_lcore.h suggest to be used > > only in CASE 1) > > 4). rte_lcore_id() can be used in CASE 2), but the return value no matter > > represent a logical core id. > > > > If most of us feel it's acceptable, I'll prepare for the RFC v2 base on > > this conclusion. > > > > /Cunming > > Sorry, I don't like that suggestion either, as having lcore_id values greater > than RTE_MAX_LCORE is terrible, as how will people know how to dimension > arrays > to be indexes by lcore id? Given the choice, if we are not going to just use > lcore_id as a generic thread id, which is always between 0 and RTE_MAX_LCORE > we can look to define a new thread_id variable to hold that. However, it > should > have a bounded range. > From an ease-of-porting perspective, I still think that the simplest option > is to > use the existing lcore_id and accept the fact that it's now a thread id rather > than an actual physical lcore. Question is, is would that cause us lots of > issues > in the future? > > /Bruce The current rte_lcore_id() has different meaning the thread. Your proposal will break code that uses lcore_id to do per-cpu statistics and the lcore_config code in the samples. q
[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> -Original Message- > From: Richardson, Bruce > Sent: Monday, December 22, 2014 10:46 AM > To: Liang, Cunming > Cc: Walukiewicz, Miroslaw; dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore > > On Mon, Dec 22, 2014 at 01:51:27AM +, Liang, Cunming wrote: > > ... > > > I'm conflicted on this one. However, I think far more applications would > be > > > broken > > > to start having to use thread_id in place of an lcore_id than would be > broken > > > by having the lcore_id no longer actually correspond to a core. > > > I'm actually struggling to come up with a large number of scenarios where > it's > > > important to an app to determine the cpu it's running on, compared to > the large > > > number of cases where you need to have a data-structure per thread. In > DPDK > > > libs > > > alone, you see this assumption that lcore_id == thread_id a large number > of > > > times. > > > > > > Despite the slight logical inconsistency, I think it's better to avoid > introducing > > > a thread-id and continue having lcore_id representing a unique thread. > > > > > > /Bruce > > > > Ok, I understand it. > > I list the implicit meaning if using lcore_id representing the unique > > thread. > > 1). When lcore_id less than RTE_MAX_LCORE, it still represents the logical > core id. > > 2). When lcore_id large equal than RTE_MAX_LCORE, it represents an > unique id for thread. > > 3). Most of APIs(except rte_lcore_id()) in rte_lcore.h suggest to be used > only in CASE 1) > > 4). rte_lcore_id() can be used in CASE 2), but the return value no matter > represent a logical core id. > > > > If most of us feel it's acceptable, I'll prepare for the RFC v2 base on this > conclusion. > > > > /Cunming > > Sorry, I don't like that suggestion either, as having lcore_id values greater > than RTE_MAX_LCORE is terrible, as how will people know how to dimension > arrays > to be indexes by lcore id? Given the choice, if we are not going to just use > lcore_id as a generic thread id, which is always between 0 and > RTE_MAX_LCORE > we can look to define a new thread_id variable to hold that. However, it > should > have a bounded range. > From an ease-of-porting perspective, I still think that the simplest option > is to > use the existing lcore_id and accept the fact that it's now a thread id rather > than an actual physical lcore. Question is, is would that cause us lots of > issues > in the future? > I would prefer keeping the RTE_MAX_LCORES as Bruce suggests and determine the HW core on base of following condition if we really have to know this. int num_cores_online = count of cores encountered in the core mask provided by cmdline parameter Rte_lcore_id() < num_cores_online -> physical core (pthread first started on the core) Rte_lcore_id() >= num_cores_online -> pthread created by rte_pthread_create Mirek > /Bruce
[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
On Mon, Dec 22, 2014 at 01:51:27AM +, Liang, Cunming wrote: > ... > > I'm conflicted on this one. However, I think far more applications would be > > broken > > to start having to use thread_id in place of an lcore_id than would be > > broken > > by having the lcore_id no longer actually correspond to a core. > > I'm actually struggling to come up with a large number of scenarios where > > it's > > important to an app to determine the cpu it's running on, compared to the > > large > > number of cases where you need to have a data-structure per thread. In DPDK > > libs > > alone, you see this assumption that lcore_id == thread_id a large number of > > times. > > > > Despite the slight logical inconsistency, I think it's better to avoid > > introducing > > a thread-id and continue having lcore_id representing a unique thread. > > > > /Bruce > > Ok, I understand it. > I list the implicit meaning if using lcore_id representing the unique thread. > 1). When lcore_id less than RTE_MAX_LCORE, it still represents the logical > core id. > 2). When lcore_id large equal than RTE_MAX_LCORE, it represents an unique id > for thread. > 3). Most of APIs(except rte_lcore_id()) in rte_lcore.h suggest to be used > only in CASE 1) > 4). rte_lcore_id() can be used in CASE 2), but the return value no matter > represent a logical core id. > > If most of us feel it's acceptable, I'll prepare for the RFC v2 base on this > conclusion. > > /Cunming Sorry, I don't like that suggestion either, as having lcore_id values greater than RTE_MAX_LCORE is terrible, as how will people know how to dimension arrays to be indexes by lcore id? Given the choice, if we are not going to just use lcore_id as a generic thread id, which is always between 0 and RTE_MAX_LCORE we can look to define a new thread_id variable to hold that. However, it should have a bounded range. >From an ease-of-porting perspective, I still think that the simplest option is >to use the existing lcore_id and accept the fact that it's now a thread id rather than an actual physical lcore. Question is, is would that cause us lots of issues in the future? /Bruce
[dpdk-dev] [PATCH RFC 5/7] ethdev: unification of flow types
Hi Konstantin
> > -
> > -/**
> > * A structure used to define the input for IPV4 flow
> > */
> > struct rte_eth_ipv4_flow {
> > @@ -291,7 +302,7 @@ struct rte_eth_fdir_flow_ext {
> > * A structure used to define the input for a flow director filter entry
> > */
> > struct rte_eth_fdir_input {
> > - enum rte_eth_flow_type flow_type; /**< Type of flow */
> > + uint16_t flow_type; /**< Type of flow */
>
> Wonder, why do you need to switch from int to uinsigned short for flow_type?
> Konstantin
Actually there are same things in rte_ethdev.h and rte_eth_ctrl.h, though seems
different.
The goal is to unify them, so the original type of MACRO was chosen. Using
uint16_t but
not enum is also beneficial for compilation, as rte_eth_ctrl.h is included in
rte_ethdev.h.
In rte_ethdev.h, it is,
/* Supported RSS offloads */
/* for 1G & 10G */
#define ETH_RSS_IPV4_SHIFT0
#define ETH_RSS_IPV4_TCP_SHIFT1
#define ETH_RSS_IPV6_SHIFT2
#define ETH_RSS_IPV6_EX_SHIFT 3
#define ETH_RSS_IPV6_TCP_SHIFT4
#define ETH_RSS_IPV6_TCP_EX_SHIFT 5
#define ETH_RSS_IPV4_UDP_SHIFT6
#define ETH_RSS_IPV6_UDP_SHIFT7
#define ETH_RSS_IPV6_UDP_EX_SHIFT 8
/* for 40G only */
#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31
#define ETH_RSS_NONF_IPV4_TCP_SHIFT 33
#define ETH_RSS_NONF_IPV4_SCTP_SHIFT 34
#define ETH_RSS_NONF_IPV4_OTHER_SHIFT 35
#define ETH_RSS_FRAG_IPV4_SHIFT 36
#define ETH_RSS_NONF_IPV6_UDP_SHIFT 41
#define ETH_RSS_NONF_IPV6_TCP_SHIFT 43
#define ETH_RSS_NONF_IPV6_SCTP_SHIFT 44
#define ETH_RSS_NONF_IPV6_OTHER_SHIFT 45
#define ETH_RSS_FRAG_IPV6_SHIFT 46
#define ETH_RSS_FCOE_OX_SHIFT 48
#define ETH_RSS_FCOE_RX_SHIFT 49
#define ETH_RSS_FCOE_OTHER_SHIFT 50
#define ETH_RSS_L2_PAYLOAD_SHIFT 63
In rte_eth_ctrl.h, it is,
/**
* Flow type
*/
enum rte_eth_flow_type {
RTE_ETH_FLOW_TYPE_NONE = 0,
RTE_ETH_FLOW_TYPE_UDPV4,
RTE_ETH_FLOW_TYPE_TCPV4,
RTE_ETH_FLOW_TYPE_SCTPV4,
RTE_ETH_FLOW_TYPE_IPV4_OTHER,
RTE_ETH_FLOW_TYPE_FRAG_IPV4,
RTE_ETH_FLOW_TYPE_UDPV6,
RTE_ETH_FLOW_TYPE_TCPV6,
RTE_ETH_FLOW_TYPE_SCTPV6,
RTE_ETH_FLOW_TYPE_IPV6_OTHER,
RTE_ETH_FLOW_TYPE_FRAG_IPV6,
RTE_ETH_FLOW_TYPE_MAX = 64,
};
Regards,
Helin
>
> > union rte_eth_fdir_flow flow;
> > /**< Flow fields to match, dependent on flow_type */
> > struct rte_eth_fdir_flow_ext flow_ext; @@ -371,7 +382,7 @@ struct
> > rte_eth_flex_payload_cfg {
> > * for each flow type
> > */
> > struct rte_eth_fdir_flex_mask {
> > - enum rte_eth_flow_type flow_type; /**< Flow type */
> > + uint16_t flow_type; /**< Flow type */
> > uint8_t mask[RTE_ETH_FDIR_MAX_FLEXLEN];
> > /**< Mask for the whole flexible payload */ }; @@ -385,7 +396,7 @@
> > struct rte_eth_fdir_flex_conf {
> > uint16_t nb_flexmasks; /**< The number of following mask */
> > struct rte_eth_flex_payload_cfg flex_set[RTE_ETH_PAYLOAD_MAX];
> > /**< Flex payload configuration for each payload type */
> > - struct rte_eth_fdir_flex_mask flex_mask[RTE_ETH_FLOW_TYPE_MAX];
> > + struct rte_eth_fdir_flex_mask flex_mask[ETH_FLOW_TYPE_MAX];
> > /**< Flex mask configuration for each flow type */ };
[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
... > I'm conflicted on this one. However, I think far more applications would be > broken > to start having to use thread_id in place of an lcore_id than would be broken > by having the lcore_id no longer actually correspond to a core. > I'm actually struggling to come up with a large number of scenarios where it's > important to an app to determine the cpu it's running on, compared to the > large > number of cases where you need to have a data-structure per thread. In DPDK > libs > alone, you see this assumption that lcore_id == thread_id a large number of > times. > > Despite the slight logical inconsistency, I think it's better to avoid > introducing > a thread-id and continue having lcore_id representing a unique thread. > > /Bruce Ok, I understand it. I list the implicit meaning if using lcore_id representing the unique thread. 1). When lcore_id less than RTE_MAX_LCORE, it still represents the logical core id. 2). When lcore_id large equal than RTE_MAX_LCORE, it represents an unique id for thread. 3). Most of APIs(except rte_lcore_id()) in rte_lcore.h suggest to be used only in CASE 1) 4). rte_lcore_id() can be used in CASE 2), but the return value no matter represent a logical core id. If most of us feel it's acceptable, I'll prepare for the RFC v2 base on this conclusion. /Cunming
[dpdk-dev] [PATCH v6] VFIO: Avoid to enable vfio while the module not loaded
On 12/19/2014 4:24 PM, Thomas Monjalon wrote: > 2014-12-19 07:09, Qiu, Michael: >> Hi Thomas, >> >> Will you plan to merge this patch? If yes, you plan to merge it into >> 1.8 or 2.0? > It won't be in 1.8 for 2 reasons: > - there is a risk to break something in some environments, so need more tests > - you add a function protoype in eal common without bsd implementation OK, fair enough, I check with you just as a reminder to be ensure that you do not miss this thread.
