* [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api
2016-02-24 17:08 4% ` [dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev Tomasz Kulasek
@ 2016-02-24 17:08 2% ` Tomasz Kulasek
0 siblings, 0 replies; 200+ results
From: Tomasz Kulasek @ 2016-02-24 17:08 UTC (permalink / raw)
To: dev
Many sample apps include internal buffering for single-packet-at-a-time
operation. Since this is such a common paradigm, this functionality is
better suited to being implemented in the ethdev API.
The new APIs in the ethdev library are:
* rte_eth_tx_buffer_init - initialize buffer
* rte_eth_tx_buffer - buffer up a single packet for future transmission
* rte_eth_tx_buffer_flush - flush any unsent buffered packets
* rte_eth_tx_buffer_set_err_callback - set up a callback to be called in
case transmitting a buffered burst fails. By default, we just free the
unsent packets.
As well as these, an additional reference callback is provided, which
frees the packets (as the default callback does), as well as updating a
user-provided counter, so that the number of dropped packets can be
tracked.
v2 changes:
- reworked to use new buffer model
- buffer data and callbacks are removed from rte_eth_dev/rte_eth_dev_data,
so this patch doesn't brake an ABI anymore
- introduced RTE_ETH_TX_BUFFER macro and rte_eth_tx_buffer_init
- buffers are not attached to the port-queue
- buffers can be allocated dynamically during application work
- size of buffer can be changed without port restart
Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
---
lib/librte_ether/rte_ethdev.c | 36 +++++++
lib/librte_ether/rte_ethdev.h | 182 +++++++++++++++++++++++++++++++-
lib/librte_ether/rte_ether_version.map | 9 ++
3 files changed, 226 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 756b234..b8ab747 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1307,6 +1307,42 @@ rte_eth_tx_queue_setup(uint8_t port_id, uint16_t tx_queue_id,
}
void
+rte_eth_count_unsent_packet_callback(struct rte_mbuf **pkts, uint16_t unsent,
+ void *userdata)
+{
+ uint64_t *count = userdata;
+ unsigned i;
+
+ for (i = 0; i < unsent; i++)
+ rte_pktmbuf_free(pkts[i]);
+
+ *count += unsent;
+}
+
+int
+rte_eth_tx_buffer_set_err_callback(struct rte_eth_dev_tx_buffer *buffer,
+ buffer_tx_error_fn cbfn, void *userdata)
+{
+ buffer->cbfn = cbfn;
+ buffer->userdata = userdata;
+ return 0;
+}
+
+int
+rte_eth_tx_buffer_init(struct rte_eth_dev_tx_buffer *buffer, uint16_t size)
+{
+ if (buffer == NULL)
+ return -EINVAL;
+
+ buffer->size = size;
+ if (buffer->cbfn == NULL)
+ rte_eth_tx_buffer_set_err_callback(buffer,
+ rte_eth_count_unsent_packet_callback, (void *)&buffer->errors);
+
+ return 0;
+}
+
+void
rte_eth_promiscuous_enable(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..b0d4932 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -2655,6 +2655,186 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts);
}
+typedef void (*buffer_tx_error_fn)(struct rte_mbuf **unsent, uint16_t count,
+ void *userdata);
+
+/**
+ * Structure used to buffer packets for future TX
+ * Used by APIs rte_eth_tx_buffer and rte_eth_tx_buffer_flush
+ */
+struct rte_eth_dev_tx_buffer {
+ unsigned nb_pkts;
+ uint64_t errors;
+ /**< Total number of queue packets to sent that are dropped. */
+ buffer_tx_error_fn cbfn;
+ void *userdata;
+ uint16_t size; /**< Size of buffer for buffered tx */
+ struct rte_mbuf *pkts[];
+};
+
+/**
+ * Calculate the size of the tx buffer.
+ *
+ * @param sz
+ * Number of stored packets.
+ */
+#define RTE_ETH_TX_BUFFER_SIZE(sz) \
+ (sizeof(struct rte_eth_dev_tx_buffer) + (sz) * sizeof(struct rte_mbuf *))
+
+/**
+ * Initialize default values for buffered transmitting
+ *
+ * @param buffer
+ * Tx buffer to be initialized.
+ * @param size
+ * Buffer size
+ * @return
+ * 0 if no error
+ */
+int
+rte_eth_tx_buffer_init(struct rte_eth_dev_tx_buffer *buffer, uint16_t size);
+
+/**
+ * Send any packets queued up for transmission on a port and HW queue
+ *
+ * This causes an explicit flush of packets previously buffered via the
+ * rte_eth_tx_buffer() function. It returns the number of packets successfully
+ * sent to the NIC, and calls the error callback for any unsent packets. Unless
+ * explicitly set up otherwise, the default callback simply frees the unsent
+ * packets back to the owning mempool.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param queue_id
+ * The index of the transmit queue through which output packets must be
+ * sent.
+ * The value must be in the range [0, nb_tx_queue - 1] previously supplied
+ * to rte_eth_dev_configure().
+ * @param buffer
+ * Buffer of packets to be transmit.
+ * @return
+ * The number of packets successfully sent to the Ethernet device. The error
+ * callback is called for any packets which could not be sent.
+ */
+static inline uint16_t
+rte_eth_tx_buffer_flush(uint8_t port_id, uint16_t queue_id,
+ struct rte_eth_dev_tx_buffer *buffer)
+{
+ uint16_t sent;
+
+ uint16_t to_send = buffer->nb_pkts;
+
+ if (to_send == 0)
+ return 0;
+
+ sent = rte_eth_tx_burst(port_id, queue_id, buffer->pkts, to_send);
+
+ buffer->nb_pkts = 0;
+
+ /* All packets sent, or to be dealt with by callback below */
+ if (unlikely(sent != to_send))
+ buffer->cbfn(&buffer->pkts[sent], to_send - sent,
+ buffer->userdata);
+
+ return sent;
+}
+
+/**
+ * Buffer a single packet for future transmission on a port and queue
+ *
+ * This function takes a single mbuf/packet and buffers it for later
+ * transmission on the particular port and queue specified. Once the buffer is
+ * full of packets, an attempt will be made to transmit all the buffered
+ * packets. In case of error, where not all packets can be transmitted, a
+ * callback is called with the unsent packets as a parameter. If no callback
+ * is explicitly set up, the unsent packets are just freed back to the owning
+ * mempool. The function returns the number of packets actually sent i.e.
+ * 0 if no buffer flush occurred, otherwise the number of packets successfully
+ * flushed
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param queue_id
+ * The index of the transmit queue through which output packets must be
+ * sent.
+ * The value must be in the range [0, nb_tx_queue - 1] previously supplied
+ * to rte_eth_dev_configure().
+ * @param buffer
+ * Buffer used to collect packets to be sent.
+ * @param tx_pkt
+ * Pointer to the packet mbuf to be sent.
+ * @return
+ * 0 = packet has been buffered for later transmission
+ * N > 0 = packet has been buffered, and the buffer was subsequently flushed,
+ * causing N packets to be sent, and the error callback to be called for
+ * the rest.
+ */
+static inline uint16_t __attribute__((always_inline))
+rte_eth_tx_buffer(uint8_t port_id, uint16_t queue_id,
+ struct rte_eth_dev_tx_buffer *buffer, struct rte_mbuf *tx_pkt)
+{
+ buffer->pkts[buffer->nb_pkts++] = tx_pkt;
+ if (buffer->nb_pkts < buffer->size)
+ return 0;
+
+ return rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
+}
+
+/**
+ * Configure a callback for buffered packets which cannot be sent
+ *
+ * Register a specific callback to be called when an attempt is made to send
+ * all packets buffered on an ethernet port, but not all packets can
+ * successfully be sent. The callback registered here will be called only
+ * from calls to rte_eth_tx_buffer() and rte_eth_tx_buffer_flush() APIs.
+ * The default callback configured for each queue by default just frees the
+ * packets back to the calling mempool. If additional behaviour is required,
+ * for example, to count dropped packets, or to retry transmission of packets
+ * which cannot be sent, this function should be used to register a suitable
+ * callback function to implement the desired behaviour.
+ * The example callback "rte_eth_count_unsent_packet_callback()" is also
+ * provided as reference.
+ *
+ * @param buffer
+ * The port identifier of the Ethernet device.
+ * @param cbfn
+ * The function to be used as the callback.
+ * @param userdata
+ * Arbitrary parameter to be passed to the callback function
+ * @return
+ * 0 on success, or -1 on error with rte_errno set appropriately
+ */
+int
+rte_eth_tx_buffer_set_err_callback(struct rte_eth_dev_tx_buffer *buffer,
+ buffer_tx_error_fn cbfn, void *userdata);
+
+/**
+ * Callback function for tracking unsent buffered packets.
+ *
+ * This function can be passed to rte_eth_tx_buffer_set_err_callback() to
+ * adjust the default behaviour when buffered packets cannot be sent. This
+ * function drops any unsent packets, but also updates a user-supplied counter
+ * to track the overall number of packets dropped. The counter should be an
+ * uint64_t variable.
+ *
+ * NOTE: this function should not be called directly, instead it should be used
+ * as a callback for packet buffering.
+ *
+ * NOTE: when configuring this function as a callback with
+ * rte_eth_tx_buffer_set_err_callback(), the final, userdata parameter
+ * should point to an uint64_t value.
+ *
+ * @param pkts
+ * The previously buffered packets which could not be sent
+ * @param unsent
+ * The number of unsent packets in the pkts array
+ * @param userdata
+ * Pointer to an unsigned long value, which will be incremented by unsent
+ */
+void
+rte_eth_count_unsent_packet_callback(struct rte_mbuf **pkts, uint16_t unsent,
+ void *userdata);
+
/**
* The eth device event type for interrupt, and maybe others in the future.
*/
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index d8db24d..ad11c71 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -117,3 +117,12 @@ DPDK_2.2 {
local: *;
};
+
+DPDK_2.3 {
+ global:
+
+ rte_eth_count_unsent_packet_callback;
+ rte_eth_tx_buffer_init;
+ rte_eth_tx_buffer_set_err_callback;
+
+} DPDK_2.2;
--
1.7.9.5
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev
@ 2016-02-24 17:08 4% ` Tomasz Kulasek
2016-02-24 17:08 2% ` [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api Tomasz Kulasek
1 sibling, 1 reply; 200+ results
From: Tomasz Kulasek @ 2016-02-24 17:08 UTC (permalink / raw)
To: dev
Many sample apps include internal buffering for single-packet-at-a-time
operation. Since this is such a common paradigm, this functionality is
better suited to being implemented in the ethdev API.
The new APIs in the ethdev library are:
* rte_eth_tx_buffer_init - initialize buffer
* rte_eth_tx_buffer - buffer up a single packet for future transmission
* rte_eth_tx_buffer_flush - flush any unsent buffered packets
* rte_eth_tx_buffer_set_err_callback - set up a callback to be called in
case transmitting a buffered burst fails. By default, we just free the
unsent packets.
As well as these, an additional reference callback is provided, which
frees the packets (as the default callback does), as well as updating a
user-provided counter, so that the number of dropped packets can be
tracked.
Due to the feedback from mailing list, that buffer management facilities
in the user application are more preferable than API simplicity, we decided
to move internal buffer table, as well as callback functions and user data,
from rte_eth_dev/rte_eth_dev_data to the application space.
It prevents ABI breakage and gives some more flexibility in the buffer's
management such as allocation, dynamical size change, reuse buffers on many
ports or after fail, and so on.
The following steps illustrate how tx buffers can be used in application:
1) Initialization
a) Allocate memory for a buffer
struct rte_eth_dev_tx_buffer *buffer = rte_zmalloc_socket("tx_buffer",
RTE_ETH_TX_BUFFER_SIZE(MAX_PKT_BURST), 0, socket_id);
RTE_ETH_TX_BUFFER_SIZE(size) macro computes memory required to store
"size" packets in buffer.
b) Initialize allocated memory and set up default values. Threshold level
must be lower than or equal to the MAX_PKT_BURST from 1a)
rte_eth_tx_buffer_init(buffer, threshold);
c) Set error callback (optional)
rte_eth_tx_buffer_set_err_callback(buffer, callback_fn, userdata);
2) Store packet "pkt" in buffer and send them all to the queue_id on
port_id when number of packets reaches threshold level set up in 1b)
rte_eth_tx_buffer(port_id, queue_id, buffer, pkt);
3) Send all stored packets to the queue_id on port_id
rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
4) Flush buffer and free memory
rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
...
rte_free(buffer);
v2 changes:
- reworked to use new buffer model
- buffer data and callbacks are removed from rte_eth_dev/rte_eth_dev_data,
so this patch doesn't brake an ABI anymore
- introduced RTE_ETH_TX_BUFFER macro and rte_eth_tx_buffer_init
- buffers are not attached to the port-queue
- buffers can be allocated dynamically during application work
- size of buffer can be changed without port restart
Tomasz Kulasek (2):
ethdev: add buffered tx api
examples: rework to use buffered tx
examples/l2fwd-jobstats/main.c | 104 +++++------
examples/l2fwd-keepalive/main.c | 100 ++++-------
examples/l2fwd/main.c | 104 +++++------
examples/l3fwd-acl/main.c | 92 ++++------
examples/l3fwd-power/main.c | 89 ++++------
examples/link_status_interrupt/main.c | 107 +++++-------
.../client_server_mp/mp_client/client.c | 101 ++++++-----
examples/multi_process/l2fwd_fork/main.c | 97 +++++------
examples/packet_ordering/main.c | 122 +++++++++----
examples/qos_meter/main.c | 61 ++-----
lib/librte_ether/rte_ethdev.c | 36 ++++
lib/librte_ether/rte_ethdev.h | 182 +++++++++++++++++++-
lib/librte_ether/rte_ether_version.map | 9 +
13 files changed, 662 insertions(+), 542 deletions(-)
--
1.7.9.5
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] af_packet: make the device detachable
2016-02-11 16:37 3% [dpdk-dev] [PATCH v3] af_packet: make the device detachable Wojciech Zmuda
@ 2016-02-24 14:08 3% ` Iremonger, Bernard
0 siblings, 0 replies; 200+ results
From: Iremonger, Bernard @ 2016-02-24 14:08 UTC (permalink / raw)
To: Wojciech Zmuda, dev
Hi Wojciech,
<snip>
> Subject: [PATCH v3] af_packet: make the device detachable
>
> Allow dynamic deallocation of af_packet device through proper API
> functions. To achieve this:
> * set device flag to RTE_ETH_DEV_DETACHABLE
> * implement rte_pmd_af_packet_devuninit() and expose it
> through rte_driver.uninit()
> * copy device name to ethdev->data to make discoverable with
> rte_eth_dev_allocated()
> Moreover, make af_packet init function static, as there is no reason to keep
> it public.
>
> Signed-off-by: Wojciech Zmuda <woz@semihalf.com>
> ---
> v3:
> * Rephrased feature note in release notes.
> * Rephrased commit log.
> * Added API change note in release notes.
> * Made init function static.
> * Removed af_packet header file, as it is not needed
> after init function is not public anymore.
>
> v2:
> * Fixed typo and a comment.
> * Added feature to the 2.3 release notes.
> * Free memory allocated for rx and tx queues.
>
> doc/guides/rel_notes/release_2_3.rst | 6 +++
> drivers/net/af_packet/Makefile | 5 --
> drivers/net/af_packet/rte_eth_af_packet.c | 43 ++++++++++++++++--
> drivers/net/af_packet/rte_eth_af_packet.h | 53 ----------------------
> .../net/af_packet/rte_pmd_af_packet_version.map | 3 --
> 5 files changed, 45 insertions(+), 65 deletions(-) delete mode 100644
> drivers/net/af_packet/rte_eth_af_packet.h
>
> diff --git a/doc/guides/rel_notes/release_2_3.rst
> b/doc/guides/rel_notes/release_2_3.rst
> index 7945694..da4abc3 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
The release_2_3.rst file has been renamed to release_16_04.rst so this patch no longer applies.
> @@ -39,6 +39,9 @@ This section should contain new features added in this
> release. Sample format:
>
> Enabled virtio 1.0 support for virtio pmd driver.
>
> +* **Added af_packet dynamic removal function.**
> +
> + Af_packet device can now be detached using API, like other PMD devices.
>
> Resolved Issues
> ---------------
> @@ -91,6 +94,9 @@ This section should contain API changes. Sample format:
> * Add a short 1-2 sentence description of the API change. Use fixed width
> quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
> tense.
>
> +* Af_packet device init function is no longer public. Device should be
> +attached
> + with API.
> +
>
> ABI Changes
> -----------
> diff --git a/drivers/net/af_packet/Makefile
> b/drivers/net/af_packet/Makefile index ce5d239..cb1a7ae 100644
> --- a/drivers/net/af_packet/Makefile
> +++ b/drivers/net/af_packet/Makefile
> @@ -50,11 +50,6 @@ CFLAGS += $(WERROR_FLAGS) #
> SRCS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += rte_eth_af_packet.c
>
> -#
> -# Export include files
> -#
> -SYMLINK-y-include += rte_eth_af_packet.h
> -
> # this lib depends upon:
> DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_mbuf
> DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_ether diff -
> -git a/drivers/net/af_packet/rte_eth_af_packet.c
> b/drivers/net/af_packet/rte_eth_af_packet.c
> index 767f36b..5544528 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -53,8 +53,6 @@
> #include <unistd.h>
> #include <poll.h>
>
> -#include "rte_eth_af_packet.h"
> -
> #define ETH_AF_PACKET_IFACE_ARG "iface"
> #define ETH_AF_PACKET_NUM_Q_ARG "qpairs"
> #define ETH_AF_PACKET_BLOCKSIZE_ARG "blocksz"
> @@ -65,6 +63,8 @@
> #define DFLT_FRAME_SIZE (1 << 11)
> #define DFLT_FRAME_COUNT (1 << 9)
>
> +#define RTE_PMD_AF_PACKET_MAX_RINGS 16
> +
> struct pkt_rx_queue {
> int sockfd;
>
> @@ -667,11 +667,13 @@ rte_pmd_init_internals(const char *name,
> data->nb_tx_queues = (uint16_t)nb_queues;
> data->dev_link = pmd_link;
> data->mac_addrs = &(*internals)->eth_addr;
> + strncpy(data->name,
> + (*eth_dev)->data->name, strlen((*eth_dev)->data-
> >name));
>
> (*eth_dev)->data = data;
> (*eth_dev)->dev_ops = &ops;
> (*eth_dev)->driver = NULL;
> - (*eth_dev)->data->dev_flags = 0;
> + (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
> (*eth_dev)->data->drv_name = drivername;
> (*eth_dev)->data->kdrv = RTE_KDRV_NONE;
> (*eth_dev)->data->numa_node = numa_node; @@ -798,7 +800,7
> @@ rte_eth_from_packet(const char *name,
> return 0;
> }
>
> -int
> +static int
> rte_pmd_af_packet_devinit(const char *name, const char *params) {
> unsigned numa_node;
> @@ -836,10 +838,43 @@ exit:
> return ret;
> }
>
> +static int
> +rte_pmd_af_packet_devuninit(const char *name) {
> + struct rte_eth_dev *eth_dev = NULL;
> + struct pmd_internals *internals;
> + unsigned q;
> +
> + RTE_LOG(INFO, PMD, "Closing AF_PACKET ethdev on numa socket
> %u\n",
> + rte_socket_id());
> +
> + if (name == NULL)
> + return -1;
> +
> + /* find the ethdev entry */
> + eth_dev = rte_eth_dev_allocated(name);
> + if (eth_dev == NULL)
> + return -1;
> +
> + internals = eth_dev->data->dev_private;
> + for (q = 0; q < internals->nb_queues; q++) {
> + rte_free(internals->rx_queue[q].rd);
> + rte_free(internals->tx_queue[q].rd);
> + }
> +
> + rte_free(eth_dev->data->dev_private);
> + rte_free(eth_dev->data);
> +
> + rte_eth_dev_release_port(eth_dev);
> +
> + return 0;
> +}
> +
> static struct rte_driver pmd_af_packet_drv = {
> .name = "eth_af_packet",
> .type = PMD_VDEV,
> .init = rte_pmd_af_packet_devinit,
> + .uninit = rte_pmd_af_packet_devuninit,
> };
>
> PMD_REGISTER_DRIVER(pmd_af_packet_drv);
> diff --git a/drivers/net/af_packet/rte_eth_af_packet.h
> b/drivers/net/af_packet/rte_eth_af_packet.h
> deleted file mode 100644
> index 5d1bc7e..0000000
> --- a/drivers/net/af_packet/rte_eth_af_packet.h
> +++ /dev/null
> @@ -1,53 +0,0 @@
> -/*-
> - * 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.
> - */
> -
> -#ifndef _RTE_ETH_AF_PACKET_H_
> -#define _RTE_ETH_AF_PACKET_H_
> -
> -#ifdef __cplusplus
> -extern "C" {
> -#endif
> -
> -#define RTE_PMD_AF_PACKET_MAX_RINGS 16
> -
> -/**
> - * For use by the EAL only. Called as part of EAL init to set up any dummy
> NICs
> - * configured on command line.
> - */
> -int rte_pmd_af_packet_devinit(const char *name, const char *params);
> -
> -#ifdef __cplusplus
> -}
> -#endif
> -
> -#endif
> diff --git a/drivers/net/af_packet/rte_pmd_af_packet_version.map
> b/drivers/net/af_packet/rte_pmd_af_packet_version.map
> index de95169..ef35398 100644
> --- a/drivers/net/af_packet/rte_pmd_af_packet_version.map
> +++ b/drivers/net/af_packet/rte_pmd_af_packet_version.map
> @@ -1,7 +1,4 @@
> DPDK_2.0 {
> - global:
> -
> - rte_pmd_af_packet_devinit;
>
> local: *;
> };
Does making rte_pmd_af_packet_devinit local result in an ABI breakage?
Should the DPDK_2.0 structure be kept and a DPDK_2.3 structure added?
A deprecation notice may need to be added to the doc/guides/rel_notes/deprecation.rst file.
> --
> 1.9.1
Regards,
Bernard.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] config: remove duplicate configuration information
2016-02-22 13:53 6% [dpdk-dev] [PATCH] config: remove duplicate configuration information Keith Wiles
2016-02-22 15:09 0% ` Trahe, Fiona
@ 2016-02-24 13:58 0% ` Wiles, Keith
1 sibling, 0 replies; 200+ results
From: Wiles, Keith @ 2016-02-24 13:58 UTC (permalink / raw)
To: dev
>In order to cleanup the configuration files some and reduce
>the number of duplicate configuration information. Add a new
>file called common_base which contains just about all of the
>configuration lines in one place. Then have the common_bsdapp,
>common_linuxapp files include this one file. Then in those OS
>specific files add the delta configuration lines.
>
>Signed-off-by: Keith Wiles <keith.wiles@intel.com>
Ping, Does this patch have any more comments, do we want to use this patch?
>---
> config/common_base | 498 ++++++++++++++++++++++++++++
> config/common_bsdapp | 436 +-----------------------
> config/common_linuxapp | 491 +--------------------------
> config/defconfig_x86_64-native-bsdapp-clang | 1 +
> config/defconfig_x86_64-native-bsdapp-gcc | 1 +
> 5 files changed, 518 insertions(+), 909 deletions(-)
> create mode 100644 config/common_base
>
>diff --git a/config/common_base b/config/common_base
>new file mode 100644
>index 0000000..91a12eb
>--- /dev/null
>+++ b/config/common_base
>@@ -0,0 +1,498 @@
>+# BSD LICENSE
>+#
>+# Copyright(c) 2010-2016 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.
>+#
>+
>+#
>+# Use intrinsics or assembly code for key routines
>+#
>+CONFIG_RTE_FORCE_INTRINSICS=n
>+
>+#
>+# Machine forces strict alignment constraints.
>+#
>+CONFIG_RTE_ARCH_STRICT_ALIGN=n
>+
>+#
>+# Compile to share library
>+#
>+CONFIG_RTE_BUILD_SHARED_LIB=n
>+
>+#
>+# Combine to one single library
>+#
>+CONFIG_RTE_BUILD_COMBINE_LIBS=n
>+
>+#
>+# Use newest code breaking previous ABI
>+#
>+CONFIG_RTE_NEXT_ABI=y
>+
>+#
>+# Machine's cache line size
>+#
>+CONFIG_RTE_CACHE_LINE_SIZE=64
>+
>+#
>+# Compile Environment Abstraction Layer
>+#
>+CONFIG_RTE_LIBRTE_EAL=y
>+CONFIG_RTE_MAX_LCORE=128
>+CONFIG_RTE_MAX_NUMA_NODES=8
>+CONFIG_RTE_MAX_MEMSEG=256
>+CONFIG_RTE_MAX_MEMZONE=2560
>+CONFIG_RTE_MAX_TAILQ=32
>+CONFIG_RTE_LOG_LEVEL=8
>+CONFIG_RTE_LOG_HISTORY=256
>+CONFIG_RTE_LIBEAL_USE_HPET=n
>+CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
>+CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
>+CONFIG_RTE_EAL_IGB_UIO=y
>+CONFIG_RTE_EAL_VFIO=y
>+CONFIG_RTE_MALLOC_DEBUG=n
>+
>+# Default driver path (or "" to disable)
>+CONFIG_RTE_EAL_PMD_PATH=""
>+
>+#
>+# Special configurations in PCI Config Space for high performance
>+#
>+CONFIG_RTE_PCI_CONFIG=n
>+CONFIG_RTE_PCI_EXTENDED_TAG=""
>+CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
>+
>+#
>+# Compile Environment Abstraction Layer to support Vmware TSC map
>+#
>+CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
>+
>+#
>+# Compile the argument parser library
>+#
>+CONFIG_RTE_LIBRTE_KVARGS=y
>+
>+#
>+# Compile generic ethernet library
>+#
>+CONFIG_RTE_LIBRTE_ETHER=y
>+CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>+CONFIG_RTE_MAX_ETHPORTS=32
>+CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>+CONFIG_RTE_LIBRTE_IEEE1588=n
>+CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
>+CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
>+
>+#
>+# Support NIC bypass logic
>+#
>+CONFIG_RTE_NIC_BYPASS=n
>+
>+#
>+# Compile burst-oriented IGB & EM PMD drivers
>+#
>+CONFIG_RTE_LIBRTE_EM_PMD=y
>+CONFIG_RTE_LIBRTE_IGB_PMD=y
>+CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
>+CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
>+CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
>+
>+#
>+# Compile burst-oriented IXGBE PMD driver
>+#
>+CONFIG_RTE_LIBRTE_IXGBE_PMD=y
>+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
>+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>+CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>+CONFIG_RTE_IXGBE_INC_VECTOR=y
>+CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>+
>+#
>+# Compile burst-oriented I40E PMD driver
>+#
>+CONFIG_RTE_LIBRTE_I40E_PMD=y
>+CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
>+CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
>+CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
>+CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>+CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
>+CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
>+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
>+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
>+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>+# interval up to 8160 us, aligned to 2 (or default value)
>+CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>+
>+#
>+# Compile burst-oriented FM10K PMD
>+#
>+CONFIG_RTE_LIBRTE_FM10K_PMD=y
>+CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>+CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>+CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>+CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
>+
>+#
>+# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
>+#
>+CONFIG_RTE_LIBRTE_MLX4_PMD=n
>+CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
>+CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
>+CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
>+CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
>+CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
>+
>+#
>+# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
>+#
>+CONFIG_RTE_LIBRTE_MLX5_PMD=n
>+CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
>+CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
>+CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
>+CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
>+
>+#
>+# Compile burst-oriented Broadcom PMD driver
>+#
>+CONFIG_RTE_LIBRTE_BNX2X_PMD=n
>+CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
>+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>+
>+#
>+# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
>+#
>+CONFIG_RTE_LIBRTE_CXGBE_PMD=y
>+CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
>+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
>+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
>+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>+
>+#
>+# Compile burst-oriented Cisco ENIC PMD driver
>+#
>+CONFIG_RTE_LIBRTE_ENIC_PMD=y
>+CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>+
>+#
>+# Compile burst-oriented Netronome NFP PMD driver
>+#
>+CONFIG_RTE_LIBRTE_NFP_PMD=n
>+CONFIG_RTE_LIBRTE_NFP_DEBUG=n
>+
>+#
>+# Compile software PMD backed by SZEDATA2 device
>+#
>+CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
>+
>+#
>+# Compile burst-oriented VIRTIO PMD driver
>+#
>+CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
>+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>+
>+#
>+# Compile burst-oriented VMXNET3 PMD driver
>+#
>+CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
>+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
>+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
>+
>+#
>+# Compile example software rings based PMD
>+#
>+CONFIG_RTE_LIBRTE_PMD_RING=y
>+CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
>+CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>+
>+#
>+# Compile software PMD backed by PCAP files
>+#
>+CONFIG_RTE_LIBRTE_PMD_PCAP=n
>+
>+#
>+# Compile link bonding PMD library
>+#
>+CONFIG_RTE_LIBRTE_PMD_BOND=y
>+CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>+CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>+
>+#
>+# Compile software PMD backed by AF_PACKET sockets (Linux only)
>+#
>+CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>+
>+#
>+# Compile Xen PMD
>+#
>+CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
>+
>+#
>+# Compile null PMD
>+#
>+CONFIG_RTE_LIBRTE_PMD_NULL=y
>+
>+#
>+# Do prefetch of packet data within PMD driver receive function
>+#
>+CONFIG_RTE_PMD_PACKET_PREFETCH=y
>+
>+#
>+# Compile generic crypto device library
>+# EXPERIMENTAL: API may change without prior notice
>+#
>+CONFIG_RTE_LIBRTE_CRYPTODEV=y
>+CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>+CONFIG_RTE_CRYPTO_MAX_DEVS=64
>+CONFIG_RTE_CRYPTODEV_NAME_LEN=64
>+
>+#
>+# Compile PMD for QuickAssist based devices
>+#
>+CONFIG_RTE_LIBRTE_PMD_QAT=n
>+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
>+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
>+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
>+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
>+#
>+# Number of sessions to create in the session memory pool
>+# on a single QuickAssist device.
>+#
>+CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
>+
>+#
>+# Compile PMD for AESNI backed device
>+#
>+CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
>+CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
>+CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
>+CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
>+
>+#
>+# Compile librte_ring
>+#
>+CONFIG_RTE_LIBRTE_RING=y
>+CONFIG_RTE_LIBRTE_RING_DEBUG=n
>+CONFIG_RTE_RING_SPLIT_PROD_CONS=n
>+CONFIG_RTE_RING_PAUSE_REP_COUNT=0
>+
>+#
>+# Compile librte_mempool
>+#
>+CONFIG_RTE_LIBRTE_MEMPOOL=y
>+CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
>+CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
>+
>+#
>+# Compile librte_mbuf
>+#
>+CONFIG_RTE_LIBRTE_MBUF=y
>+CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>+CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>+CONFIG_RTE_PKTMBUF_HEADROOM=128
>+
>+#
>+# Compile librte_mbuf_offload
>+# EXPERIMENTAL: API may change without prior notice
>+#
>+CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
>+CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
>+
>+#
>+# Compile librte_timer
>+#
>+CONFIG_RTE_LIBRTE_TIMER=y
>+CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
>+
>+#
>+# Compile librte_cfgfile
>+#
>+CONFIG_RTE_LIBRTE_CFGFILE=y
>+
>+#
>+# Compile librte_cmdline
>+#
>+CONFIG_RTE_LIBRTE_CMDLINE=y
>+CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
>+
>+#
>+# Compile librte_hash
>+#
>+CONFIG_RTE_LIBRTE_HASH=y
>+CONFIG_RTE_LIBRTE_HASH_DEBUG=n
>+
>+#
>+# Compile librte_jobstats
>+#
>+CONFIG_RTE_LIBRTE_JOBSTATS=y
>+
>+#
>+# Compile librte_lpm
>+#
>+CONFIG_RTE_LIBRTE_LPM=y
>+CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>+
>+#
>+# Compile librte_acl
>+#
>+CONFIG_RTE_LIBRTE_ACL=y
>+CONFIG_RTE_LIBRTE_ACL_DEBUG=n
>+
>+#
>+# Compile librte_power
>+#
>+CONFIG_RTE_LIBRTE_POWER=y
>+CONFIG_RTE_LIBRTE_POWER_DEBUG=n
>+CONFIG_RTE_MAX_LCORE_FREQS=64
>+
>+#
>+# Compile librte_net
>+#
>+CONFIG_RTE_LIBRTE_NET=y
>+
>+#
>+# Compile librte_ip_frag
>+#
>+CONFIG_RTE_LIBRTE_IP_FRAG=y
>+CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
>+CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
>+CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
>+
>+#
>+# Compile librte_meter
>+#
>+CONFIG_RTE_LIBRTE_METER=y
>+
>+#
>+# Compile librte_sched
>+#
>+CONFIG_RTE_LIBRTE_SCHED=y
>+CONFIG_RTE_SCHED_DEBUG=n
>+CONFIG_RTE_SCHED_RED=n
>+CONFIG_RTE_SCHED_COLLECT_STATS=n
>+CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
>+CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
>+CONFIG_RTE_SCHED_VECTOR=n
>+
>+#
>+# Compile the distributor library
>+#
>+CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
>+
>+#
>+# Compile the reorder library
>+#
>+CONFIG_RTE_LIBRTE_REORDER=y
>+
>+#
>+# Compile librte_port
>+#
>+CONFIG_RTE_LIBRTE_PORT=y
>+CONFIG_RTE_PORT_STATS_COLLECT=n
>+
>+#
>+# Compile librte_table
>+#
>+CONFIG_RTE_LIBRTE_TABLE=y
>+CONFIG_RTE_TABLE_STATS_COLLECT=n
>+
>+#
>+# Compile librte_pipeline
>+#
>+CONFIG_RTE_LIBRTE_PIPELINE=y
>+CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>+
>+#
>+# Compile librte_kni
>+#
>+CONFIG_RTE_LIBRTE_KNI=y
>+CONFIG_RTE_KNI_KMOD=y
>+CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
>+CONFIG_RTE_KNI_KO_DEBUG=n
>+CONFIG_RTE_KNI_VHOST=n
>+CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
>+CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
>+CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
>+CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
>+
>+#
>+# Compile vhost library
>+# fuse-devel is needed to run vhost-cuse.
>+# fuse-devel enables user space char driver development
>+# vhost-user is turned on by default.
>+#
>+CONFIG_RTE_LIBRTE_VHOST=y
>+CONFIG_RTE_LIBRTE_VHOST_USER=y
>+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>+CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
>+
>+#
>+#Compile Xen domain0 support
>+#
>+CONFIG_RTE_LIBRTE_XEN_DOM0=n
>+
>+#
>+# Enable warning directives
>+#
>+CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
>+
>+#
>+# Compile the test application
>+#
>+CONFIG_RTE_APP_TEST=y
>+
>+#
>+# Compile the PMD test application
>+#
>+CONFIG_RTE_TEST_PMD=y
>+CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>+CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>diff --git a/config/common_bsdapp b/config/common_bsdapp
>index 696382c..de0ca7d 100644
>--- a/config/common_bsdapp
>+++ b/config/common_bsdapp
>@@ -1,6 +1,6 @@
> # BSD LICENSE
> #
>-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> # All rights reserved.
> #
> # Redistribution and use in source and binary forms, with or without
>@@ -37,74 +37,38 @@
> CONFIG_RTE_EXEC_ENV="bsdapp"
> CONFIG_RTE_EXEC_ENV_BSDAPP=y
>
>-##
>-## machine can define specific variables or action for a specific board
>-## RTE_MACHINE values are the directories in mk/machine/
>-##
>-#CONFIG_RTE_MACHINE="native"
>-#
>-##
>-## define the architecture we compile for.
>-## RTE_ARCH values are the directories in mk/arch/
>-##
>-#CONFIG_RTE_ARCH="x86_64"
>-#CONFIG_RTE_ARCH_X86_64=y
>-#CONFIG_RTE_ARCH_X86=y
>-#
>-##
>-## The compiler we use.
>-## RTE_TOOLCHAIN values are the directories in mk/toolchain/
>-##
>-#CONFIG_RTE_TOOLCHAIN="gcc"
>-#CONFIG_RTE_TOOLCHAIN_GCC=y
>-
>-#
>-# Use intrinsics or assembly code for key routines
>-#
>-CONFIG_RTE_FORCE_INTRINSICS=n
>+#include "common_base"
>
> #
>-# Machine forces strict alignment constraints.
>+# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
> #
>-CONFIG_RTE_ARCH_STRICT_ALIGN=n
>+CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
>
> #
>-# Compile to share library
>+# Compile Environment Abstraction Layer
> #
>-CONFIG_RTE_BUILD_SHARED_LIB=n
>+CONFIG_RTE_EAL_IGB_UIO=n
>+CONFIG_RTE_EAL_VFIO=n
>
> #
>-# Combine to one single library
>+# Compile software PMD backed by AF_PACKET sockets (Linux only)
> #
>-CONFIG_RTE_BUILD_COMBINE_LIBS=n
>+CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n
>
> #
>-# Use newest code breaking previous ABI
>+# Compile librte_power
> #
>-CONFIG_RTE_NEXT_ABI=y
>+CONFIG_RTE_LIBRTE_POWER=n
>
> #
>-# Machine's cache line size
>+# Compile librte_kni
> #
>-CONFIG_RTE_CACHE_LINE_SIZE=64
>+CONFIG_RTE_LIBRTE_KNI=n
>
> #
>-# Compile Environment Abstraction Layer
>+# Compile vhost library
> #
>-CONFIG_RTE_LIBRTE_EAL=y
>-CONFIG_RTE_MAX_LCORE=128
>-CONFIG_RTE_MAX_NUMA_NODES=8
>-CONFIG_RTE_MAX_MEMSEG=256
>-CONFIG_RTE_MAX_MEMZONE=2560
>-CONFIG_RTE_MAX_TAILQ=32
>-CONFIG_RTE_LOG_LEVEL=8
>-CONFIG_RTE_LOG_HISTORY=256
>-CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
>-CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
>-CONFIG_RTE_MALLOC_DEBUG=n
>-
>-# Default driver path (or "" to disable)
>-CONFIG_RTE_EAL_PMD_PATH=""
>+CONFIG_RTE_LIBRTE_VHOST=n
>
> #
> # FreeBSD contiguous memory driver settings
>@@ -113,373 +77,3 @@ CONFIG_RTE_CONTIGMEM_MAX_NUM_BUFS=64
> CONFIG_RTE_CONTIGMEM_DEFAULT_NUM_BUFS=2
> CONFIG_RTE_CONTIGMEM_DEFAULT_BUF_SIZE=1024*1024*1024
>
>-#
>-# Compile Environment Abstraction Layer for BSD
>-#
>-CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
>-
>-#
>-# Compile Environment Abstraction Layer for linux
>-#
>-CONFIG_RTE_LIBRTE_EAL_LINUXAPP=n
>-
>-#
>-# Compile Environment Abstraction Layer to support Vmware TSC map
>-#
>-CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
>-
>-#
>-# Compile the argument parser library
>-#
>-CONFIG_RTE_LIBRTE_KVARGS=y
>-
>-#
>-# Compile generic ethernet library
>-#
>-CONFIG_RTE_LIBRTE_ETHER=y
>-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>-CONFIG_RTE_MAX_ETHPORTS=32
>-CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>-CONFIG_RTE_LIBRTE_IEEE1588=n
>-CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
>-CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
>-
>-#
>-# Support NIC bypass logic
>-#
>-CONFIG_RTE_NIC_BYPASS=n
>-
>-#
>-# Compile burst-oriented IGB & EM PMD drivers
>-#
>-CONFIG_RTE_LIBRTE_EM_PMD=y
>-CONFIG_RTE_LIBRTE_IGB_PMD=y
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
>-
>-#
>-# Compile burst-oriented IXGBE PMD driver
>-#
>-CONFIG_RTE_LIBRTE_IXGBE_PMD=y
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>-CONFIG_RTE_IXGBE_INC_VECTOR=y
>-CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>-
>-#
>-# Compile burst-oriented I40E PMD driver
>-#
>-CONFIG_RTE_LIBRTE_I40E_PMD=y
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
>-CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>-CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
>-CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
>-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
>-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
>-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>-# interval up to 8160 us, aligned to 2 (or default value)
>-CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>-
>-#
>-# Compile burst-oriented FM10K PMD
>-#
>-CONFIG_RTE_LIBRTE_FM10K_PMD=y
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>-
>-#
>-# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
>-#
>-CONFIG_RTE_LIBRTE_MLX4_PMD=n
>-CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
>-CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
>-CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
>-CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
>-CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
>-
>-#
>-# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
>-#
>-CONFIG_RTE_LIBRTE_MLX5_PMD=n
>-CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
>-CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
>-CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
>-CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
>-
>-#
>-# Compile burst-oriented Broadcom PMD driver
>-#
>-CONFIG_RTE_LIBRTE_BNX2X_PMD=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>-
>-#
>-# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
>-#
>-CONFIG_RTE_LIBRTE_CXGBE_PMD=y
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>-
>-#
>-# Compile burst-oriented Cisco ENIC PMD driver
>-#
>-CONFIG_RTE_LIBRTE_ENIC_PMD=y
>-CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>-
>-#
>-# Compile software PMD backed by SZEDATA2 device
>-#
>-CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
>-
>-#
>-# Compile burst-oriented VIRTIO PMD driver
>-#
>-CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>-
>-#
>-# Compile burst-oriented VMXNET3 PMD driver
>-#
>-CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
>-
>-#
>-# Compile example software rings based PMD
>-#
>-CONFIG_RTE_LIBRTE_PMD_RING=y
>-CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
>-CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>-
>-#
>-# Compile software PMD backed by PCAP files
>-#
>-CONFIG_RTE_LIBRTE_PMD_PCAP=y
>-
>-#
>-# Compile link bonding PMD library
>-#
>-CONFIG_RTE_LIBRTE_PMD_BOND=y
>-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>-
>-#
>-# Compile null PMD
>-#
>-CONFIG_RTE_LIBRTE_PMD_NULL=y
>-
>-#
>-# Do prefetch of packet data within PMD driver receive function
>-#
>-CONFIG_RTE_PMD_PACKET_PREFETCH=y
>-
>-#
>-# Compile generic crypto device library
>-# EXPERIMENTAL: API may change without prior notice
>-#
>-CONFIG_RTE_LIBRTE_CRYPTODEV=y
>-CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>-CONFIG_RTE_CRYPTO_MAX_DEVS=64
>-CONFIG_RTE_CRYPTODEV_NAME_LEN=64
>-
>-#
>-# Compile PMD for QuickAssist based devices
>-#
>-CONFIG_RTE_LIBRTE_PMD_QAT=n
>-CONFIG_RTE_LIBRTE_QAT_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_QAT_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_QAT_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_QAT_DEBUG_DRIVER=n
>-#
>-# Number of sessions to create in the session memory pool
>-# on a single QuickAssist device.
>-#
>-CONFIG_RTE_MAX_QAT_SESSIONS=200
>-
>-#
>-# Compile PMD for AESNI backed device
>-#
>-CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
>-CONFIG_RTE_LIBRTE_AESNI_MB_DEBUG=n
>-
>-#
>-# Compile librte_ring
>-#
>-CONFIG_RTE_LIBRTE_RING=y
>-CONFIG_RTE_LIBRTE_RING_DEBUG=n
>-CONFIG_RTE_RING_SPLIT_PROD_CONS=n
>-CONFIG_RTE_RING_PAUSE_REP_COUNT=0
>-
>-#
>-# Compile librte_mempool
>-#
>-CONFIG_RTE_LIBRTE_MEMPOOL=y
>-CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
>-CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
>-
>-#
>-# Compile librte_mbuf
>-#
>-CONFIG_RTE_LIBRTE_MBUF=y
>-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>-CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>-CONFIG_RTE_PKTMBUF_HEADROOM=128
>-
>-#
>-# Compile librte_mbuf_offload
>-# EXPERIMENTAL: API may change without prior notice
>-#
>-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
>-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
>-
>-#
>-# Compile librte_timer
>-#
>-CONFIG_RTE_LIBRTE_TIMER=y
>-CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
>-
>-#
>-# Compile librte_cfgfile
>-#
>-CONFIG_RTE_LIBRTE_CFGFILE=y
>-
>-#
>-# Compile librte_cmdline
>-#
>-CONFIG_RTE_LIBRTE_CMDLINE=y
>-CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
>-
>-#
>-# Compile librte_hash
>-#
>-CONFIG_RTE_LIBRTE_HASH=y
>-CONFIG_RTE_LIBRTE_HASH_DEBUG=n
>-
>-#
>-# Compile librte_jobstats
>-#
>-CONFIG_RTE_LIBRTE_JOBSTATS=y
>-
>-#
>-# Compile librte_lpm
>-#
>-CONFIG_RTE_LIBRTE_LPM=y
>-CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>-
>-#
>-# Compile librte_acl
>-#
>-CONFIG_RTE_LIBRTE_ACL=y
>-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
>-
>-#
>-# Compile librte_power
>-#
>-CONFIG_RTE_LIBRTE_POWER=n
>-CONFIG_RTE_LIBRTE_POWER_DEBUG=n
>-CONFIG_RTE_MAX_LCORE_FREQS=64
>-
>-#
>-# Compile librte_net
>-#
>-CONFIG_RTE_LIBRTE_NET=y
>-
>-#
>-# Compile librte_ip_frag
>-#
>-CONFIG_RTE_LIBRTE_IP_FRAG=y
>-CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
>-CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
>-CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
>-
>-#
>-# Compile librte_meter
>-#
>-CONFIG_RTE_LIBRTE_METER=y
>-
>-#
>-# Compile librte_sched
>-#
>-CONFIG_RTE_LIBRTE_SCHED=y
>-CONFIG_RTE_SCHED_DEBUG=n
>-CONFIG_RTE_SCHED_RED=n
>-CONFIG_RTE_SCHED_COLLECT_STATS=n
>-CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
>-CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
>-CONFIG_RTE_SCHED_VECTOR=n
>-
>-#
>-# Compile the distributor library
>-#
>-CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
>-
>-#
>-# Compile the reorder library
>-#
>-CONFIG_RTE_LIBRTE_REORDER=y
>-
>-#
>-# Compile librte_port
>-#
>-CONFIG_RTE_LIBRTE_PORT=y
>-CONFIG_RTE_PORT_STATS_COLLECT=n
>-
>-#
>-# Compile librte_table
>-#
>-CONFIG_RTE_LIBRTE_TABLE=y
>-CONFIG_RTE_TABLE_STATS_COLLECT=n
>-
>-#
>-# Compile librte_pipeline
>-#
>-CONFIG_RTE_LIBRTE_PIPELINE=y
>-CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>-
>-#
>-# Enable warning directives
>-#
>-CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
>-
>-#
>-# Compile the test application
>-#
>-CONFIG_RTE_APP_TEST=y
>-
>-#
>-# Compile the PMD test application
>-#
>-CONFIG_RTE_TEST_PMD=y
>-CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>-CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>diff --git a/config/common_linuxapp b/config/common_linuxapp
>index f1638db..64ddbe9 100644
>--- a/config/common_linuxapp
>+++ b/config/common_linuxapp
>@@ -1,6 +1,6 @@
> # BSD LICENSE
> #
>-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> # All rights reserved.
> #
> # Redistribution and use in source and binary forms, with or without
>@@ -37,494 +37,9 @@
> CONFIG_RTE_EXEC_ENV="linuxapp"
> CONFIG_RTE_EXEC_ENV_LINUXAPP=y
>
>-##
>-## machine can define specific variables or action for a specific board
>-## RTE_MACHINE values are the directories in mk/machine/
>-##
>-#CONFIG_RTE_MACHINE="native"
>-#
>-##
>-## define the architecture we compile for.
>-## RTE_ARCH values are the directories in mk/arch/
>-##
>-#CONFIG_RTE_ARCH="x86_64"
>-#CONFIG_RTE_ARCH_X86_64=y
>-#CONFIG_RTE_ARCH_X86=y
>-#
>-##
>-## The compiler we use.
>-## RTE_TOOLCHAIN values are the directories in mk/toolchain/
>-##
>-#CONFIG_RTE_TOOLCHAIN="gcc"
>-#CONFIG_RTE_TOOLCHAIN_GCC=y
>-
>-#
>-# Use intrinsics or assembly code for key routines
>-#
>-CONFIG_RTE_FORCE_INTRINSICS=n
>-
>-#
>-# Machine forces strict alignment constraints.
>-#
>-CONFIG_RTE_ARCH_STRICT_ALIGN=n
>-
>-#
>-# Compile to share library
>-#
>-CONFIG_RTE_BUILD_SHARED_LIB=n
>-
>-#
>-# Combine to one single library
>-#
>-CONFIG_RTE_BUILD_COMBINE_LIBS=n
>-
>-#
>-# Use newest code breaking previous ABI
>-#
>-CONFIG_RTE_NEXT_ABI=y
>-
>-#
>-# Machine's cache line size
>-#
>-CONFIG_RTE_CACHE_LINE_SIZE=64
>-
>-#
>-# Compile Environment Abstraction Layer
>-#
>-CONFIG_RTE_LIBRTE_EAL=y
>-CONFIG_RTE_MAX_LCORE=128
>-CONFIG_RTE_MAX_NUMA_NODES=8
>-CONFIG_RTE_MAX_MEMSEG=256
>-CONFIG_RTE_MAX_MEMZONE=2560
>-CONFIG_RTE_MAX_TAILQ=32
>-CONFIG_RTE_LOG_LEVEL=8
>-CONFIG_RTE_LOG_HISTORY=256
>-CONFIG_RTE_LIBEAL_USE_HPET=n
>-CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
>-CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
>-CONFIG_RTE_EAL_IGB_UIO=y
>-CONFIG_RTE_EAL_VFIO=y
>-CONFIG_RTE_MALLOC_DEBUG=n
>-# Default driver path (or "" to disable)
>-CONFIG_RTE_EAL_PMD_PATH=""
>-
>-#
>-# Special configurations in PCI Config Space for high performance
>-#
>-CONFIG_RTE_PCI_CONFIG=n
>-CONFIG_RTE_PCI_EXTENDED_TAG=""
>-CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
>+#include "common_base"
>
> #
>-# Compile Environment Abstraction Layer for linux
>+# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
> #
> CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y
>-
>-#
>-# Compile Environment Abstraction Layer to support Vmware TSC map
>-#
>-CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
>-
>-#
>-# Compile the argument parser library
>-#
>-CONFIG_RTE_LIBRTE_KVARGS=y
>-
>-#
>-# Compile generic ethernet library
>-#
>-CONFIG_RTE_LIBRTE_ETHER=y
>-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>-CONFIG_RTE_MAX_ETHPORTS=32
>-CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>-CONFIG_RTE_LIBRTE_IEEE1588=n
>-CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
>-CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
>-
>-#
>-# Support NIC bypass logic
>-#
>-CONFIG_RTE_NIC_BYPASS=n
>-
>-#
>-# Compile burst-oriented IGB & EM PMD drivers
>-#
>-CONFIG_RTE_LIBRTE_EM_PMD=y
>-CONFIG_RTE_LIBRTE_IGB_PMD=y
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
>-
>-#
>-# Compile burst-oriented IXGBE PMD driver
>-#
>-CONFIG_RTE_LIBRTE_IXGBE_PMD=y
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>-CONFIG_RTE_IXGBE_INC_VECTOR=y
>-CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>-
>-#
>-# Compile burst-oriented I40E PMD driver
>-#
>-CONFIG_RTE_LIBRTE_I40E_PMD=y
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
>-CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>-CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
>-CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
>-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
>-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
>-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>-# interval up to 8160 us, aligned to 2 (or default value)
>-CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>-
>-#
>-# Compile burst-oriented FM10K PMD
>-#
>-CONFIG_RTE_LIBRTE_FM10K_PMD=y
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>-CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
>-
>-#
>-# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
>-#
>-CONFIG_RTE_LIBRTE_MLX4_PMD=n
>-CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
>-CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
>-CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
>-CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
>-CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
>-
>-#
>-# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
>-#
>-CONFIG_RTE_LIBRTE_MLX5_PMD=n
>-CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
>-CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
>-CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
>-CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
>-
>-#
>-# Compile burst-oriented Broadcom PMD driver
>-#
>-CONFIG_RTE_LIBRTE_BNX2X_PMD=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>-
>-#
>-# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
>-#
>-CONFIG_RTE_LIBRTE_CXGBE_PMD=y
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>-
>-#
>-# Compile burst-oriented Cisco ENIC PMD driver
>-#
>-CONFIG_RTE_LIBRTE_ENIC_PMD=y
>-CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>-
>-#
>-# Compile burst-oriented Netronome NFP PMD driver
>-#
>-CONFIG_RTE_LIBRTE_NFP_PMD=n
>-CONFIG_RTE_LIBRTE_NFP_DEBUG=n
>-
>-#
>-# Compile software PMD backed by SZEDATA2 device
>-#
>-CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
>-
>-#
>-# Compile burst-oriented VIRTIO PMD driver
>-#
>-CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>-
>-#
>-# Compile burst-oriented VMXNET3 PMD driver
>-#
>-CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
>-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
>-
>-#
>-# Compile example software rings based PMD
>-#
>-CONFIG_RTE_LIBRTE_PMD_RING=y
>-CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
>-CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>-
>-#
>-# Compile software PMD backed by PCAP files
>-#
>-CONFIG_RTE_LIBRTE_PMD_PCAP=n
>-
>-#
>-# Compile link bonding PMD library
>-#
>-CONFIG_RTE_LIBRTE_PMD_BOND=y
>-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>-
>-#
>-# Compile software PMD backed by AF_PACKET sockets (Linux only)
>-#
>-CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>-
>-#
>-# Compile Xen PMD
>-#
>-CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
>-
>-#
>-# Compile null PMD
>-#
>-CONFIG_RTE_LIBRTE_PMD_NULL=y
>-
>-#
>-# Do prefetch of packet data within PMD driver receive function
>-#
>-CONFIG_RTE_PMD_PACKET_PREFETCH=y
>-
>-#
>-# Compile generic crypto device library
>-# EXPERIMENTAL: API may change without prior notice
>-#
>-CONFIG_RTE_LIBRTE_CRYPTODEV=y
>-CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>-CONFIG_RTE_CRYPTO_MAX_DEVS=64
>-CONFIG_RTE_CRYPTODEV_NAME_LEN=64
>-
>-#
>-# Compile PMD for QuickAssist based devices
>-#
>-CONFIG_RTE_LIBRTE_PMD_QAT=n
>-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
>-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
>-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
>-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
>-#
>-# Number of sessions to create in the session memory pool
>-# on a single QuickAssist device.
>-#
>-CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
>-
>-#
>-# Compile PMD for AESNI backed device
>-#
>-CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
>-CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
>-CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
>-CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
>-
>-#
>-# Compile librte_ring
>-#
>-CONFIG_RTE_LIBRTE_RING=y
>-CONFIG_RTE_LIBRTE_RING_DEBUG=n
>-CONFIG_RTE_RING_SPLIT_PROD_CONS=n
>-CONFIG_RTE_RING_PAUSE_REP_COUNT=0
>-
>-#
>-# Compile librte_mempool
>-#
>-CONFIG_RTE_LIBRTE_MEMPOOL=y
>-CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
>-CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
>-
>-#
>-# Compile librte_mbuf
>-#
>-CONFIG_RTE_LIBRTE_MBUF=y
>-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>-CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>-CONFIG_RTE_PKTMBUF_HEADROOM=128
>-
>-#
>-# Compile librte_mbuf_offload
>-# EXPERIMENTAL: API may change without prior notice
>-#
>-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
>-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
>-
>-#
>-# Compile librte_timer
>-#
>-CONFIG_RTE_LIBRTE_TIMER=y
>-CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
>-
>-#
>-# Compile librte_cfgfile
>-#
>-CONFIG_RTE_LIBRTE_CFGFILE=y
>-
>-#
>-# Compile librte_cmdline
>-#
>-CONFIG_RTE_LIBRTE_CMDLINE=y
>-CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
>-
>-#
>-# Compile librte_hash
>-#
>-CONFIG_RTE_LIBRTE_HASH=y
>-CONFIG_RTE_LIBRTE_HASH_DEBUG=n
>-
>-#
>-# Compile librte_jobstats
>-#
>-CONFIG_RTE_LIBRTE_JOBSTATS=y
>-
>-#
>-# Compile librte_lpm
>-#
>-CONFIG_RTE_LIBRTE_LPM=y
>-CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>-
>-#
>-# Compile librte_acl
>-#
>-CONFIG_RTE_LIBRTE_ACL=y
>-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
>-
>-#
>-# Compile librte_power
>-#
>-CONFIG_RTE_LIBRTE_POWER=y
>-CONFIG_RTE_LIBRTE_POWER_DEBUG=n
>-CONFIG_RTE_MAX_LCORE_FREQS=64
>-
>-#
>-# Compile librte_net
>-#
>-CONFIG_RTE_LIBRTE_NET=y
>-
>-#
>-# Compile librte_ip_frag
>-#
>-CONFIG_RTE_LIBRTE_IP_FRAG=y
>-CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
>-CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
>-CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
>-
>-#
>-# Compile librte_meter
>-#
>-CONFIG_RTE_LIBRTE_METER=y
>-
>-#
>-# Compile librte_sched
>-#
>-CONFIG_RTE_LIBRTE_SCHED=y
>-CONFIG_RTE_SCHED_DEBUG=n
>-CONFIG_RTE_SCHED_RED=n
>-CONFIG_RTE_SCHED_COLLECT_STATS=n
>-CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
>-CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
>-CONFIG_RTE_SCHED_VECTOR=n
>-
>-#
>-# Compile the distributor library
>-#
>-CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
>-
>-#
>-# Compile the reorder library
>-#
>-CONFIG_RTE_LIBRTE_REORDER=y
>-
>-#
>-# Compile librte_port
>-#
>-CONFIG_RTE_LIBRTE_PORT=y
>-CONFIG_RTE_PORT_STATS_COLLECT=n
>-
>-#
>-# Compile librte_table
>-#
>-CONFIG_RTE_LIBRTE_TABLE=y
>-CONFIG_RTE_TABLE_STATS_COLLECT=n
>-
>-#
>-# Compile librte_pipeline
>-#
>-CONFIG_RTE_LIBRTE_PIPELINE=y
>-CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>-
>-#
>-# Compile librte_kni
>-#
>-CONFIG_RTE_LIBRTE_KNI=y
>-CONFIG_RTE_KNI_KMOD=y
>-CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
>-CONFIG_RTE_KNI_KO_DEBUG=n
>-CONFIG_RTE_KNI_VHOST=n
>-CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
>-CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
>-CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
>-CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
>-
>-#
>-# Compile vhost library
>-# fuse-devel is needed to run vhost-cuse.
>-# fuse-devel enables user space char driver development
>-# vhost-user is turned on by default.
>-#
>-CONFIG_RTE_LIBRTE_VHOST=y
>-CONFIG_RTE_LIBRTE_VHOST_USER=y
>-CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>-CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
>-
>-#
>-#Compile Xen domain0 support
>-#
>-CONFIG_RTE_LIBRTE_XEN_DOM0=n
>-
>-#
>-# Enable warning directives
>-#
>-CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
>-
>-#
>-# Compile the test application
>-#
>-CONFIG_RTE_APP_TEST=y
>-
>-#
>-# Compile the PMD test application
>-#
>-CONFIG_RTE_TEST_PMD=y
>-CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>-CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>diff --git a/config/defconfig_x86_64-native-bsdapp-clang b/config/defconfig_x86_64-native-bsdapp-clang
>index d2baf2c..8b870b3 100644
>--- a/config/defconfig_x86_64-native-bsdapp-clang
>+++ b/config/defconfig_x86_64-native-bsdapp-clang
>@@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
> CONFIG_RTE_ARCH="x86_64"
> CONFIG_RTE_ARCH_X86_64=y
> CONFIG_RTE_ARCH_X86=y
>+CONFIG_RTE_ARCH_64=y
>
> CONFIG_RTE_TOOLCHAIN="clang"
> CONFIG_RTE_TOOLCHAIN_CLANG=y
>diff --git a/config/defconfig_x86_64-native-bsdapp-gcc b/config/defconfig_x86_64-native-bsdapp-gcc
>index 5a6a4e8..4ea4433 100644
>--- a/config/defconfig_x86_64-native-bsdapp-gcc
>+++ b/config/defconfig_x86_64-native-bsdapp-gcc
>@@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
> CONFIG_RTE_ARCH="x86_64"
> CONFIG_RTE_ARCH_X86_64=y
> CONFIG_RTE_ARCH_X86=y
>+CONFIG_RTE_ARCH_64=y
>
> CONFIG_RTE_TOOLCHAIN="gcc"
> CONFIG_RTE_TOOLCHAIN_GCC=y
>--
>2.7.0
>
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
2016-02-24 12:11 0% ` Panu Matilainen
@ 2016-02-24 13:23 3% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2016-02-24 13:23 UTC (permalink / raw)
To: Panu Matilainen, Xie, Huawei, Olivier MATZ, dev; +Cc: dprovan
Hi Panu,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, February 24, 2016 12:12 PM
> To: Xie, Huawei; Olivier MATZ; dev@dpdk.org
> Cc: dprovan@bivio.net
> Subject: Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
>
> On 02/23/2016 07:35 AM, Xie, Huawei wrote:
> > On 2/22/2016 10:52 PM, Xie, Huawei wrote:
> >> On 2/4/2016 1:24 AM, Olivier MATZ wrote:
> >>> Hi,
> >>>
> >>> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
> >>>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
> >>>> the library ABI and should not be listed in the version map.
> >>>>
> >>>> I assume its inline for performance reasons, but then you lose the
> >>>> benefits of dynamic linking such as ability to fix bugs and/or improve
> >>>> itby just updating the library. Since the point of having a bulk API is
> >>>> to improve performance by reducing the number of calls required, does it
> >>>> really have to be inline? As in, have you actually measured the
> >>>> difference between inline and non-inline and decided its worth all the
> >>>> downsides?
> >>> Agree with Panu. It would be interesting to compare the performance
> >>> between inline and non inline to decide whether inlining it or not.
> >> Will update after i gathered more data. inline could show obvious
> >> performance difference in some cases.
> >
> > Panu and Oliver:
> > I write a simple benchmark. This benchmark run 10M rounds, in each round
> > 8 mbufs are allocated through bulk API, and then freed.
> > These are the CPU cycles measured(Intel(R) Xeon(R) CPU E5-2680 0 @
> > 2.70GHz, CPU isolated, timer interrupt disabled, rcu offloaded).
> > Btw, i have removed some exceptional data, the frequency of which is
> > like 1/10. Sometimes observed user usage suddenly disappeared, no clue
> > what happened.
> >
> > With 8 mbufs allocated, there is about 6% performance increase using inline.
> [...]
> >
> > With 16 mbufs allocated, we could still observe obvious performance
> > difference, though only 1%-2%
> >
> [...]
> >
> > With 32/64 mbufs allocated, the deviation of the data itself would hide
> > the performance difference.
> > So we prefer using inline for performance.
>
> At least I was more after real-world performance in a real-world
> use-case rather than CPU cycles in a microbenchmark, we know function
> calls have a cost but the benefits tend to outweight the cons.
>
> Inline functions have their place and they're far less evil in project
> internal use, but in library public API they are BAD and should be ...
> well, not banned because there are exceptions to every rule, but highly
> discouraged.
Why is that?
As you can see right now we have all mbuf alloc/free routines as static inline.
And I think we would like to keep it like that.
So why that particular function should be different?
After all that function is nothing more than a wrapper
around rte_mempool_get_bulk() unrolled by 4 loop {rte_pktmbuf_reset()}
So unless mempool get/put API would change, I can hardly see there could be any ABI
breakages in future.
About 'real world' performance gain - it was a 'real world' performance problem,
that we tried to solve by introducing that function:
http://dpdk.org/ml/archives/dev/2015-May/017633.html
And according to the user feedback, it does help:
http://dpdk.org/ml/archives/dev/2016-February/033203.html
Konstantin
>
> - Panu -
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
2016-02-23 5:35 0% ` Xie, Huawei
@ 2016-02-24 12:11 0% ` Panu Matilainen
2016-02-24 13:23 3% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-02-24 12:11 UTC (permalink / raw)
To: Xie, Huawei, Olivier MATZ, dev; +Cc: dprovan
On 02/23/2016 07:35 AM, Xie, Huawei wrote:
> On 2/22/2016 10:52 PM, Xie, Huawei wrote:
>> On 2/4/2016 1:24 AM, Olivier MATZ wrote:
>>> Hi,
>>>
>>> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>>>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
>>>> the library ABI and should not be listed in the version map.
>>>>
>>>> I assume its inline for performance reasons, but then you lose the
>>>> benefits of dynamic linking such as ability to fix bugs and/or improve
>>>> itby just updating the library. Since the point of having a bulk API is
>>>> to improve performance by reducing the number of calls required, does it
>>>> really have to be inline? As in, have you actually measured the
>>>> difference between inline and non-inline and decided its worth all the
>>>> downsides?
>>> Agree with Panu. It would be interesting to compare the performance
>>> between inline and non inline to decide whether inlining it or not.
>> Will update after i gathered more data. inline could show obvious
>> performance difference in some cases.
>
> Panu and Oliver:
> I write a simple benchmark. This benchmark run 10M rounds, in each round
> 8 mbufs are allocated through bulk API, and then freed.
> These are the CPU cycles measured(Intel(R) Xeon(R) CPU E5-2680 0 @
> 2.70GHz, CPU isolated, timer interrupt disabled, rcu offloaded).
> Btw, i have removed some exceptional data, the frequency of which is
> like 1/10. Sometimes observed user usage suddenly disappeared, no clue
> what happened.
>
> With 8 mbufs allocated, there is about 6% performance increase using inline.
[...]
>
> With 16 mbufs allocated, we could still observe obvious performance
> difference, though only 1%-2%
>
[...]
>
> With 32/64 mbufs allocated, the deviation of the data itself would hide
> the performance difference.
> So we prefer using inline for performance.
At least I was more after real-world performance in a real-world
use-case rather than CPU cycles in a microbenchmark, we know function
calls have a cost but the benefits tend to outweight the cons.
Inline functions have their place and they're far less evil in project
internal use, but in library public API they are BAD and should be ...
well, not banned because there are exceptions to every rule, but highly
discouraged.
- Panu -
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH RFC v3 2/3] vhost: make buf vector for scatter RX local.
@ 2016-02-24 11:47 4% ` Ilya Maximets
0 siblings, 0 replies; 200+ results
From: Ilya Maximets @ 2016-02-24 11:47 UTC (permalink / raw)
To: dev, Huawei Xie, Yuanhan Liu; +Cc: Dyasly Sergey, Ilya Maximets
Array of buf_vector's is just an array for temporary storing information
about available descriptors. It used only locally in virtio_dev_merge_rx()
and there is no reason for that array to be shared.
Fix that by allocating local buf_vec inside virtio_dev_merge_rx().
buf_vec field of struct vhost_virtqueue marked as deprecated.
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
---
doc/guides/rel_notes/deprecation.rst | 1 +
lib/librte_vhost/rte_virtio_net.h | 2 +-
lib/librte_vhost/vhost_rxtx.c | 49 ++++++++++++++++++------------------
3 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..40f350d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -7,6 +7,7 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* Field buf_vec of struct vhost_virtqueue have been deprecated.
* The following fields have been deprecated in rte_eth_stats:
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
index 4a2303a..e6e5cf3 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -93,7 +93,7 @@ struct vhost_virtqueue {
int enabled;
uint64_t log_guest_addr; /**< Physical address of used ring, for logging */
uint64_t reserved[15]; /**< Reserve some spaces for future extension. */
- struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
+ struct buf_vector buf_vec[BUF_VECTOR_MAX] __rte_deprecated; /**< @deprecated Buffer for scatter RX. */
} __rte_cache_aligned;
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 14c2159..a8e2582 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -340,7 +340,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
static inline uint32_t __attribute__((always_inline))
copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
uint16_t res_base_idx, uint16_t res_end_idx,
- struct rte_mbuf *pkt)
+ struct rte_mbuf *pkt, struct buf_vector *buf_vec)
{
uint32_t vec_idx = 0;
uint32_t entry_success = 0;
@@ -371,7 +371,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
*/
vq = dev->virtqueue[queue_id];
- vb_addr = gpa_to_vva(dev, vq->buf_vec[vec_idx].buf_addr);
+ vb_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
vb_hdr_addr = vb_addr;
/* Prefetch buffer address. */
@@ -386,24 +386,24 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
rte_memcpy((void *)(uintptr_t)vb_hdr_addr,
(const void *)&virtio_hdr, vq->vhost_hlen);
- vhost_log_write(dev, vq->buf_vec[vec_idx].buf_addr, vq->vhost_hlen);
+ vhost_log_write(dev, buf_vec[vec_idx].buf_addr, vq->vhost_hlen);
PRINT_PACKET(dev, (uintptr_t)vb_hdr_addr, vq->vhost_hlen, 1);
seg_avail = rte_pktmbuf_data_len(pkt);
vb_offset = vq->vhost_hlen;
- vb_avail = vq->buf_vec[vec_idx].buf_len - vq->vhost_hlen;
+ vb_avail = buf_vec[vec_idx].buf_len - vq->vhost_hlen;
entry_len = vq->vhost_hlen;
if (vb_avail == 0) {
- uint32_t desc_idx = vq->buf_vec[vec_idx].desc_idx;
+ uint32_t desc_idx = buf_vec[vec_idx].desc_idx;
if ((vq->desc[desc_idx].flags & VRING_DESC_F_NEXT) == 0) {
idx = cur_idx & (vq->size - 1);
/* Update used ring with desc information */
- vq->used->ring[idx].id = vq->buf_vec[vec_idx].desc_idx;
+ vq->used->ring[idx].id = buf_vec[vec_idx].desc_idx;
vq->used->ring[idx].len = entry_len;
vhost_log_used_vring(dev, vq,
@@ -416,12 +416,12 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
}
vec_idx++;
- vb_addr = gpa_to_vva(dev, vq->buf_vec[vec_idx].buf_addr);
+ vb_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
/* Prefetch buffer address. */
rte_prefetch0((void *)(uintptr_t)vb_addr);
vb_offset = 0;
- vb_avail = vq->buf_vec[vec_idx].buf_len;
+ vb_avail = buf_vec[vec_idx].buf_len;
}
cpy_len = RTE_MIN(vb_avail, seg_avail);
@@ -431,7 +431,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
rte_memcpy((void *)(uintptr_t)(vb_addr + vb_offset),
rte_pktmbuf_mtod_offset(pkt, const void *, seg_offset),
cpy_len);
- vhost_log_write(dev, vq->buf_vec[vec_idx].buf_addr + vb_offset,
+ vhost_log_write(dev, buf_vec[vec_idx].buf_addr + vb_offset,
cpy_len);
PRINT_PACKET(dev,
@@ -450,12 +450,12 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
* entry reach to its end.
* But the segment doesn't complete.
*/
- if ((vq->desc[vq->buf_vec[vec_idx].desc_idx].flags &
+ if ((vq->desc[buf_vec[vec_idx].desc_idx].flags &
VRING_DESC_F_NEXT) == 0) {
/* Update used ring with desc information */
idx = cur_idx & (vq->size - 1);
vq->used->ring[idx].id
- = vq->buf_vec[vec_idx].desc_idx;
+ = buf_vec[vec_idx].desc_idx;
vq->used->ring[idx].len = entry_len;
vhost_log_used_vring(dev, vq,
offsetof(struct vring_used, ring[idx]),
@@ -467,9 +467,9 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
vec_idx++;
vb_addr = gpa_to_vva(dev,
- vq->buf_vec[vec_idx].buf_addr);
+ buf_vec[vec_idx].buf_addr);
vb_offset = 0;
- vb_avail = vq->buf_vec[vec_idx].buf_len;
+ vb_avail = buf_vec[vec_idx].buf_len;
cpy_len = RTE_MIN(vb_avail, seg_avail);
} else {
/*
@@ -488,7 +488,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
* from buf_vec.
*/
uint32_t desc_idx =
- vq->buf_vec[vec_idx].desc_idx;
+ buf_vec[vec_idx].desc_idx;
if ((vq->desc[desc_idx].flags &
VRING_DESC_F_NEXT) == 0) {
@@ -512,9 +512,9 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
/* Get next buffer from buf_vec. */
vec_idx++;
vb_addr = gpa_to_vva(dev,
- vq->buf_vec[vec_idx].buf_addr);
+ buf_vec[vec_idx].buf_addr);
vb_avail =
- vq->buf_vec[vec_idx].buf_len;
+ buf_vec[vec_idx].buf_len;
vb_offset = 0;
}
@@ -528,7 +528,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
/* Update used ring with desc information */
idx = cur_idx & (vq->size - 1);
vq->used->ring[idx].id
- = vq->buf_vec[vec_idx].desc_idx;
+ = buf_vec[vec_idx].desc_idx;
vq->used->ring[idx].len = entry_len;
vhost_log_used_vring(dev, vq,
offsetof(struct vring_used, ring[idx]),
@@ -544,7 +544,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
static inline void __attribute__((always_inline))
update_secure_len(struct vhost_virtqueue *vq, uint32_t id,
- uint32_t *secure_len, uint32_t *vec_idx)
+ uint32_t *secure_len, uint32_t *vec_idx, struct buf_vector *buf_vec)
{
uint16_t wrapped_idx = id & (vq->size - 1);
uint32_t idx = vq->avail->ring[wrapped_idx];
@@ -555,9 +555,9 @@ update_secure_len(struct vhost_virtqueue *vq, uint32_t id,
do {
next_desc = 0;
len += vq->desc[idx].len;
- vq->buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
- vq->buf_vec[vec_id].buf_len = vq->desc[idx].len;
- vq->buf_vec[vec_id].desc_idx = idx;
+ buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
+ buf_vec[vec_id].buf_len = vq->desc[idx].len;
+ buf_vec[vec_id].desc_idx = idx;
vec_id++;
if (vq->desc[idx].flags & VRING_DESC_F_NEXT) {
@@ -582,6 +582,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
uint16_t avail_idx;
uint16_t res_base_idx, res_cur_idx;
uint8_t success = 0;
+ struct buf_vector buf_vec[BUF_VECTOR_MAX];
LOG_DEBUG(VHOST_DATA, "(%"PRIu64") virtio_dev_merge_rx()\n",
dev->device_fh);
@@ -620,8 +621,8 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
if (unlikely(res_cur_idx == avail_idx))
goto merge_rx_exit;
- update_secure_len(vq, res_cur_idx,
- &secure_len, &vec_idx);
+ update_secure_len(vq, res_cur_idx, &secure_len,
+ &vec_idx, buf_vec);
res_cur_idx++;
} while (pkt_len > secure_len);
@@ -632,7 +633,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
} while (success == 0);
entry_success = copy_from_mbuf_to_vring(dev, queue_id,
- res_base_idx, res_cur_idx, pkts[pkt_idx]);
+ res_base_idx, res_cur_idx, pkts[pkt_idx], buf_vec);
rte_smp_wmb();
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] mk: replace the combined library with a linker script
@ 2016-02-23 22:20 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-23 22:20 UTC (permalink / raw)
To: pmatilai; +Cc: dev
From: Panu Matilainen <pmatilai@redhat.com>
The physically linked-together combined library has been an increasing
source of problems, as was predicted when library and symbol versioning
was introduced. Replace the complex and fragile construction with a
simple linker script which achieves the same without all the problems,
remove the related kludges from eg mlx drivers.
Since creating the linker script is practically zero cost, remove the
config option and just create it always.
Based on a patch by Sergio Gonzales Monroy, linker script approach
initially suggested by Neil Horman.
Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Suggested-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
v2:
- move RTE_LIBNAME assignment rte.vars.mk to rte.combinedlib.mk
- update crypto
- update doc
- update rte.app.mk
- update test-build.sh
config/common_bsdapp | 5 --
config/common_linuxapp | 5 --
doc/guides/contributing/patches.rst | 12 ++-
doc/guides/nics/mlx4.rst | 5 --
doc/guides/nics/mlx5.rst | 5 --
drivers/crypto/Makefile | 3 +-
drivers/net/Makefile | 1 -
drivers/net/mlx4/Makefile | 6 --
drivers/net/mlx5/Makefile | 6 --
lib/Makefile | 1 -
mk/rte.app.mk | 17 +---
drivers/crypto/Makefile => mk/rte.combinedlib.mk | 28 +++++-
mk/rte.lib.mk | 16 ----
mk/rte.sdkbuild.mk | 4 +-
mk/rte.sharelib.mk | 105 -----------------------
mk/rte.vars.mk | 2 -
scripts/test-build.sh | 7 +-
17 files changed, 36 insertions(+), 192 deletions(-)
copy drivers/crypto/Makefile => mk/rte.combinedlib.mk (81%)
delete mode 100644 mk/rte.sharelib.mk
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 696382c..7df5ac6 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -74,11 +74,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
# Use newest code breaking previous ABI
#
CONFIG_RTE_NEXT_ABI=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index f1638db..26df137 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -74,11 +74,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
# Use newest code breaking previous ABI
#
CONFIG_RTE_NEXT_ABI=y
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 5dd8f79..3ebe95b 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -267,7 +267,7 @@ Checking Compilation
Compilation of patches and changes should be tested using the the ``test-build.sh`` script in the ``scripts``
directory of the DPDK repo::
- scripts/test-build.sh x86_64-native-linuxapp-gcc+next+shared+combined
+ scripts/test-build.sh x86_64-native-linuxapp-gcc+next+shared
The script usage is::
@@ -283,10 +283,8 @@ Where:
Examples of configs are::
x86_64-native-linuxapp-gcc
- x86_64-native-linuxapp-gcc+next+shared+combined
- x86_64-native-linuxapp-gcc+shared+next
- x86_64-native-linuxapp-clang+shared+combined
- i686-native-linuxapp-gcc+combined
+ x86_64-native-linuxapp-gcc+next+shared
+ x86_64-native-linuxapp-clang+shared
The builds can be modifies via the following environmental variables:
@@ -302,8 +300,8 @@ These can be set from the command line or in the config files shown above in the
The recommended configurations and options to test compilation prior to submitting patches are::
x86_64-native-linuxapp-gcc+shared+next
- x86_64-native-linuxapp-clang+shared+combined
- i686-native-linuxapp-gcc+combined
+ x86_64-native-linuxapp-clang+shared
+ i686-native-linuxapp-gcc
export DPDK_DEP_ZLIB=y
export DPDK_DEP_PCAP=y
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 7757013..49f4626 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -47,11 +47,6 @@ There is also a `section dedicated to this poll mode driver
be enabled manually by setting ``CONFIG_RTE_LIBRTE_MLX4_PMD=y`` and
recompiling DPDK.
-.. warning::
-
- ``CONFIG_RTE_BUILD_COMBINE_LIBS`` with ``CONFIG_RTE_BUILD_SHARED_LIB``
- is not supported and thus the compilation will fail with this configuration.
-
Implementation details
----------------------
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index b2a12ce..66794e6 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -48,11 +48,6 @@ There is also a `section dedicated to this poll mode driver
be enabled manually by setting ``CONFIG_RTE_LIBRTE_MLX5_PMD=y`` and
recompiling DPDK.
-.. warning::
-
- ``CONFIG_RTE_BUILD_COMBINE_LIBS`` with ``CONFIG_RTE_BUILD_SHARED_LIB``
- is not supported and thus the compilation will fail with this configuration.
-
Implementation details
----------------------
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index d07ee96..d0258da 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -34,5 +34,4 @@ include $(RTE_SDK)/mk/rte.vars.mk
DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb
DIRS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += qat
-include $(RTE_SDK)/mk/rte.sharelib.mk
-include $(RTE_SDK)/mk/rte.subdir.mk
\ No newline at end of file
+include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6e4497e..0c3393f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -52,5 +52,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile
index 23b766d..d2f5692 100644
--- a/drivers/net/mlx4/Makefile
+++ b/drivers/net/mlx4/Makefile
@@ -31,12 +31,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-all:
- @echo 'MLX4: Not supported in a combined shared library'
- @false
-endif
-
# Library name.
LIB = librte_pmd_mlx4.a
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index ae568e6..736d205 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -31,12 +31,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-all:
- @echo 'MLX5: Not supported in a combined shared library'
- @false
-endif
-
# Library name.
LIB = librte_pmd_mlx5.a
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..6840f87 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,5 +64,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 8ecab41..daac09f 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -59,10 +59,6 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
_LDLIBS-y += --whole-archive
-_LDLIBS-$(CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME)
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor
_LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder
@@ -88,8 +84,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt
_LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
ifeq ($(CONFIG_RTE_LIBRTE_VHOST_NUMA),y)
_LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lnuma
endif
@@ -99,9 +93,8 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lfuse
endif
# The static libraries do not know their dependencies.
-# The combined library fails also to store this information.
-# So linking with static or combined library requires explicit dependencies.
-ifneq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),ny)
+# So linking with static library requires explicit dependencies.
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lpcap
_LDLIBS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += -lz
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs
@@ -111,12 +104,10 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += -lxenstore
_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lgxio
# QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC precomputes
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += -lcrypto
-endif # CONFIG_RTE_BUILD_COMBINE_LIBS or not CONFIG_RTE_BUILD_SHARED_LIBS
+endif # !CONFIG_RTE_BUILD_SHARED_LIBS
_LDLIBS-y += --start-group
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_KVARGS) += -lrte_kvargs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF) += -lrte_mbuf
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF_OFFLOAD) += -lrte_mbuf_offload
@@ -161,8 +152,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += -L$(AESNI_MULTI_BUFFER_LIB_PATH)
endif # ! $(CONFIG_RTE_BUILD_SHARED_LIB)
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
_LDLIBS-y += $(EXECENV_LDLIBS)
_LDLIBS-y += --end-group
_LDLIBS-y += --no-whole-archive
diff --git a/drivers/crypto/Makefile b/mk/rte.combinedlib.mk
similarity index 81%
copy from drivers/crypto/Makefile
copy to mk/rte.combinedlib.mk
index d07ee96..fe4817b 100644
--- a/drivers/crypto/Makefile
+++ b/mk/rte.combinedlib.mk
@@ -31,8 +31,28 @@
include $(RTE_SDK)/mk/rte.vars.mk
-DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb
-DIRS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += qat
+default: all
-include $(RTE_SDK)/mk/rte.sharelib.mk
-include $(RTE_SDK)/mk/rte.subdir.mk
\ No newline at end of file
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+EXT:=.so
+else
+EXT:=.a
+endif
+
+RTE_LIBNAME := dpdk
+COMBINEDLIB := lib$(RTE_LIBNAME)$(EXT)
+
+LIBS := $(notdir $(wildcard $(RTE_OUTPUT)/lib/*$(EXT)))
+
+all: FORCE
+ $(Q)echo "GROUP ( $(LIBS) )" > $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+#
+# Clean all generated files
+#
+.PHONY: clean
+clean:
+ $(Q)rm -f $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+.PHONY: FORCE
+FORCE:
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 24c81e7..8f7e021 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -138,14 +138,6 @@ endif
$(depfile_newer)),\
$(O_TO_S_DO))
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(EXTLIB_BUILD),yn)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
else
$(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
@@ -161,14 +153,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_A_DO))
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(EXTLIB_BUILD),yn)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
endif
#
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 85f603c..eec5241 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -77,8 +77,8 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
- @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ @if [ $@ = drivers ]; then \
+ $(MAKE) -f $(RTE_SDK)/mk/rte.combinedlib.mk; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
deleted file mode 100644
index 70c49a8..0000000
--- a/mk/rte.sharelib.mk
+++ /dev/null
@@ -1,105 +0,0 @@
-# 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.
-
-include $(RTE_SDK)/mk/internal/rte.build-pre.mk
-
-# VPATH contains at least SRCDIR
-VPATH += $(SRCDIR)
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
-LIB_ONE := lib$(RTE_LIBNAME).so
-else
-LIB_ONE := lib$(RTE_LIBNAME).a
-endif
-COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
-COMBINED_LDFLAGS += --version-script=$(COMBINED_MAP)
-endif
-
-.PHONY:sharelib
-sharelib: $(LIB_ONE) FORCE
-
-OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)
-
-ifeq ($(LINK_USING_CC),1)
-# Override the definition of LD here, since we're linking with CC
-LD := $(CC) $(CPU_CFLAGS)
-O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
- $(call linkerprefix,$(COMBINED_LDFLAGS)) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-else
-O_TO_S = $(LD) $(CPU_LDFLAGS) $(COMBINED_LDFLAGS) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-endif
-
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
-O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)")
-O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
-O_TO_S_DO = @set -e; \
- echo $(O_TO_S_DISP); \
- $(O_TO_S)
-
-O_TO_A = $(AR) crus $(RTE_OUTPUT)/lib/$(LIB_ONE) $(OBJS)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
-O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)"," LD $(@)")
-O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
-O_TO_A_DO = @set -e; \
- echo $(O_TO_A_DISP); \
- $(O_TO_A)
-#
-# Archive objects to share library
-#
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- @$(SRCDIR)/scripts/merge-maps.sh > $(COMBINED_MAP)
- $(O_TO_S_DO)
-else
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_A_DO)
-endif
-endif
-
-#
-# Clean all generated files
-#
-.PHONY: clean
-clean: _postclean
-
-.PHONY: doclean
-doclean:
- $(Q)rm -rf $(LIB_ONE)
-
-.PHONY: FORCE
-FORCE:
diff --git a/mk/rte.vars.mk b/mk/rte.vars.mk
index 7e7ee14..2d734bd 100644
--- a/mk/rte.vars.mk
+++ b/mk/rte.vars.mk
@@ -66,8 +66,6 @@ endif
RTE_TARGET ?= $(RTE_ARCH)-$(RTE_MACHINE)-$(RTE_EXEC_ENV)-$(RTE_TOOLCHAIN)
-RTE_LIBNAME := dpdk
-
ifeq ($(BUILDING_RTE_SDK),)
# if we are building an external app/lib, include internal/rte.extvars.mk that will
# define RTE_OUTPUT, RTE_SRCDIR, RTE_EXTMK, RTE_SDK_BIN, (etc ...)
diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 6d28c5d..ead7b47 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -55,7 +55,7 @@ print_help () {
-s short test with only first config without examples/doc
config: defconfig name followed by switches delimited with "+" sign
- Example: x86_64-native-linuxapp-gcc+next+shared+combined
+ Example: x86_64-native-linuxapp-gcc+next+shared
Default is to enable most of the options.
The external dependencies are setup with DPDK_DEP_* variables.
END_OF_HELP
@@ -101,8 +101,6 @@ config () # <directory> <target> <options>
sed -ri 's,(NEXT_ABI=)y,\1n,' $1/.config
! echo $3 | grep -q shared || \
sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
- ! echo $3 | grep -q combined || \
- sed -ri 's,(COMBINE_LIBS=)n,\1y,' $1/.config
echo $2 | grep -q '^i686' || \
sed -ri 's,(NUMA=)n,\1y,' $1/.config
sed -ri 's,(PCI_CONFIG=)n,\1y,' $1/.config
@@ -110,7 +108,6 @@ config () # <directory> <target> <options>
sed -ri 's,(BYPASS=)n,\1y,' $1/.config
test "$DPDK_DEP_MOFED" != y || \
echo $2 | grep -q '^clang$' || \
- echo $3 | grep -q 'shared.*combined' || \
sed -ri 's,(MLX._PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_SZE" != y || \
echo $2 | grep -q '^i686' || \
@@ -122,11 +119,9 @@ config () # <directory> <target> <options>
sed -ri 's,(PCAP=)n,\1y,' $1/.config
test -z "$AESNI_MULTI_BUFFER_LIB_PATH" || \
echo $2 | grep -q '^i686' || \
- echo $3 | grep -q 'shared.*combined' || \
sed -ri 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
echo $2 | grep -q '^i686' || \
- echo $3 | grep -q 'shared.*combined' || \
sed -ri 's,(PMD_QAT=)n,\1y,' $1/.config
sed -ri 's,(KNI_VHOST.*=)n,\1y,' $1/.config
sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
--
2.7.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
2016-02-22 14:49 0% ` Xie, Huawei
@ 2016-02-23 5:35 0% ` Xie, Huawei
2016-02-24 12:11 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Xie, Huawei @ 2016-02-23 5:35 UTC (permalink / raw)
To: Olivier MATZ, Panu Matilainen, dev; +Cc: dprovan
On 2/22/2016 10:52 PM, Xie, Huawei wrote:
> On 2/4/2016 1:24 AM, Olivier MATZ wrote:
>> Hi,
>>
>> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
>>> the library ABI and should not be listed in the version map.
>>>
>>> I assume its inline for performance reasons, but then you lose the
>>> benefits of dynamic linking such as ability to fix bugs and/or improve
>>> itby just updating the library. Since the point of having a bulk API is
>>> to improve performance by reducing the number of calls required, does it
>>> really have to be inline? As in, have you actually measured the
>>> difference between inline and non-inline and decided its worth all the
>>> downsides?
>> Agree with Panu. It would be interesting to compare the performance
>> between inline and non inline to decide whether inlining it or not.
> Will update after i gathered more data. inline could show obvious
> performance difference in some cases.
Panu and Oliver:
I write a simple benchmark. This benchmark run 10M rounds, in each round
8 mbufs are allocated through bulk API, and then freed.
These are the CPU cycles measured(Intel(R) Xeon(R) CPU E5-2680 0 @
2.70GHz, CPU isolated, timer interrupt disabled, rcu offloaded).
Btw, i have removed some exceptional data, the frequency of which is
like 1/10. Sometimes observed user usage suddenly disappeared, no clue
what happened.
With 8 mbufs allocated, there is about 6% performance increase using inline.
inline non-inline
2780738888 2950309416
2834853696 2951378072
2823015320 2954500888
2825060032 2958939912
2824499804 2898938284
2810859720 2944892796
2852229420 3014273296
2787308500 2956809852
2793337260 2958674900
2822223476 2954346352
2785455184 2925719136
2821528624 2937380416
2822922136 2974978604
2776645920 2947666548
2815952572 2952316900
2801048740 2947366984
2851462672 2946469004
With 16 mbufs allocated, we could still observe obvious performance
difference, though only 1%-2%
inline non-inline
5519987084 5669902680
5538416096 5737646840
5578934064 5590165532
5548131972 5767926840
5625585696 5831345628
5558282876 5662223764
5445587768 5641003924
5559096320 5775258444
5656437988 5743969272
5440939404 5664882412
5498875968 5785138532
5561652808 5737123940
5515211716 5627775604
5550567140 5630790628
5665964280 5589568164
5591295900 5702697308
With 32/64 mbufs allocated, the deviation of the data itself would hide
the performance difference.
So we prefer using inline for performance.
>> Also, it would be nice to have a simple test function in
>> app/test/test_mbuf.c. For instance, you could update
>> test_one_pktmbuf() to take a mbuf pointer as a parameter and remove
>> the mbuf allocation from the function. Then it could be called with
>> a mbuf allocated with rte_pktmbuf_alloc() (like before) and with
>> all the mbufs of rte_pktmbuf_alloc_bulk().
Don't quite get you. Is it that we write two cases, one case allocate
mbuf through rte_pktmbuf_alloc_bulk and one use rte_pktmbuf_alloc? It is
good to have. I could do this after this patch.
>>
>> Regards,
>> Olivier
>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] config: remove duplicate configuration information
2016-02-22 15:09 0% ` Trahe, Fiona
@ 2016-02-22 16:02 0% ` Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-02-22 16:02 UTC (permalink / raw)
To: Trahe, Fiona, dev
>Hi Keith,
>
>What makes a param common?
>
>e.g. cryptodev QAT PMD is supported in linux, but currently not supported in bsd.
>So typically I disable it in the bsd file and enable it in the linux file.
>
>Couldn't the same apply to any other parameter, i.e. there may be users who want to have differences in config for different OSs?
>
>So why not just leave as is and give users the option to choose?
The problem is the major configs are all common, in this design we have the common_base all configs are placed then as you stated they are disable in the common_OS files. Plus some are enabled/disabled in the deconfig_XXX files as well.
The goal is to move all of the configs into one file then we do not have to keep updating all of the common_OS files, but only enable/disable that option.
I have common_osxapp that I want to add later to build and run DPDK on OS X, which is another place to have these same configs. Later we may add another OS too, which means more copies :-)
>
>Regards,
>Fiona
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
>> Sent: Monday, February 22, 2016 1:54 PM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] [PATCH] config: remove duplicate configuration information
>>
>> In order to cleanup the configuration files some and reduce the number of
>> duplicate configuration information. Add a new file called common_base which
>> contains just about all of the configuration lines in one place. Then have the
>> common_bsdapp, common_linuxapp files include this one file. Then in those OS
>> specific files add the delta configuration lines.
>>
>> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
>> ---
>> config/common_base | 498 ++++++++++++++++++++++++++++
>> config/common_bsdapp | 436 +-----------------------
>> config/common_linuxapp | 491 +--------------------------
>> config/defconfig_x86_64-native-bsdapp-clang | 1 +
>> config/defconfig_x86_64-native-bsdapp-gcc | 1 +
>> 5 files changed, 518 insertions(+), 909 deletions(-) create mode 100644
>> config/common_base
>>
>> diff --git a/config/common_base b/config/common_base new file mode 100644
>> index 0000000..91a12eb
>> --- /dev/null
>> +++ b/config/common_base
>> @@ -0,0 +1,498 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright(c) 2010-2016 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.
>> +#
>> +
>> +#
>> +# Use intrinsics or assembly code for key routines #
>> +CONFIG_RTE_FORCE_INTRINSICS=n
>> +
>> +#
>> +# Machine forces strict alignment constraints.
>> +#
>> +CONFIG_RTE_ARCH_STRICT_ALIGN=n
>> +
>> +#
>> +# Compile to share library
>> +#
>> +CONFIG_RTE_BUILD_SHARED_LIB=n
>> +
>> +#
>> +# Combine to one single library
>> +#
>> +CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> +
>> +#
>> +# Use newest code breaking previous ABI # CONFIG_RTE_NEXT_ABI=y
>> +
>> +#
>> +# Machine's cache line size
>> +#
>> +CONFIG_RTE_CACHE_LINE_SIZE=64
>> +
>> +#
>> +# Compile Environment Abstraction Layer # CONFIG_RTE_LIBRTE_EAL=y
>> +CONFIG_RTE_MAX_LCORE=128
>> +CONFIG_RTE_MAX_NUMA_NODES=8
>> +CONFIG_RTE_MAX_MEMSEG=256
>> +CONFIG_RTE_MAX_MEMZONE=2560
>> +CONFIG_RTE_MAX_TAILQ=32
>> +CONFIG_RTE_LOG_LEVEL=8
>> +CONFIG_RTE_LOG_HISTORY=256
>> +CONFIG_RTE_LIBEAL_USE_HPET=n
>> +CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
>> +CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
>> +CONFIG_RTE_EAL_IGB_UIO=y
>> +CONFIG_RTE_EAL_VFIO=y
>> +CONFIG_RTE_MALLOC_DEBUG=n
>> +
>> +# Default driver path (or "" to disable) CONFIG_RTE_EAL_PMD_PATH=""
>> +
>> +#
>> +# Special configurations in PCI Config Space for high performance #
>> +CONFIG_RTE_PCI_CONFIG=n CONFIG_RTE_PCI_EXTENDED_TAG=""
>> +CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
>> +
>> +#
>> +# Compile Environment Abstraction Layer to support Vmware TSC map #
>> +CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
>> +
>> +#
>> +# Compile the argument parser library
>> +#
>> +CONFIG_RTE_LIBRTE_KVARGS=y
>> +
>> +#
>> +# Compile generic ethernet library
>> +#
>> +CONFIG_RTE_LIBRTE_ETHER=y
>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>> +CONFIG_RTE_MAX_ETHPORTS=32
>> +CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>> +CONFIG_RTE_LIBRTE_IEEE1588=n
>> +CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
>> +CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
>> +
>> +#
>> +# Support NIC bypass logic
>> +#
>> +CONFIG_RTE_NIC_BYPASS=n
>> +
>> +#
>> +# Compile burst-oriented IGB & EM PMD drivers #
>> +CONFIG_RTE_LIBRTE_EM_PMD=y CONFIG_RTE_LIBRTE_IGB_PMD=y
>> +CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
>> +CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
>> +CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
>> +
>> +#
>> +# Compile burst-oriented IXGBE PMD driver #
>> +CONFIG_RTE_LIBRTE_IXGBE_PMD=y
>> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
>> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>> +CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>> +CONFIG_RTE_IXGBE_INC_VECTOR=y
>> +CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>> +
>> +#
>> +# Compile burst-oriented I40E PMD driver # CONFIG_RTE_LIBRTE_I40E_PMD=y
>> +CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
>> +CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
>> +CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
>> +CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>> +CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
>> +CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
>> +CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
>> +CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
>> +CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>> +# interval up to 8160 us, aligned to 2 (or default value)
>> +CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>> +
>> +#
>> +# Compile burst-oriented FM10K PMD
>> +#
>> +CONFIG_RTE_LIBRTE_FM10K_PMD=y
>> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>> +CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>> +CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
>> +
>> +#
>> +# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD #
>> +CONFIG_RTE_LIBRTE_MLX4_PMD=n CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
>> +CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
>> +CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
>> +CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
>> +CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
>> +
>> +#
>> +# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD #
>> +CONFIG_RTE_LIBRTE_MLX5_PMD=n CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
>> +CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
>> +CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
>> +CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
>> +
>> +#
>> +# Compile burst-oriented Broadcom PMD driver #
>> +CONFIG_RTE_LIBRTE_BNX2X_PMD=n CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
>> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>> +
>> +#
>> +# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD #
>> +CONFIG_RTE_LIBRTE_CXGBE_PMD=y CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
>> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
>> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
>> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>> +
>> +#
>> +# Compile burst-oriented Cisco ENIC PMD driver #
>> +CONFIG_RTE_LIBRTE_ENIC_PMD=y CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>> +
>> +#
>> +# Compile burst-oriented Netronome NFP PMD driver #
>> +CONFIG_RTE_LIBRTE_NFP_PMD=n CONFIG_RTE_LIBRTE_NFP_DEBUG=n
>> +
>> +#
>> +# Compile software PMD backed by SZEDATA2 device #
>> +CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
>> +
>> +#
>> +# Compile burst-oriented VIRTIO PMD driver #
>> +CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
>> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>> +
>> +#
>> +# Compile burst-oriented VMXNET3 PMD driver #
>> +CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
>> CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
>> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
>> +
>> +#
>> +# Compile example software rings based PMD #
>> +CONFIG_RTE_LIBRTE_PMD_RING=y
>> +CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
>> +CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>> +
>> +#
>> +# Compile software PMD backed by PCAP files #
>> +CONFIG_RTE_LIBRTE_PMD_PCAP=n
>> +
>> +#
>> +# Compile link bonding PMD library
>> +#
>> +CONFIG_RTE_LIBRTE_PMD_BOND=y
>> +CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>> +CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>> +
>> +#
>> +# Compile software PMD backed by AF_PACKET sockets (Linux only) #
>> +CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>> +
>> +#
>> +# Compile Xen PMD
>> +#
>> +CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
>> +
>> +#
>> +# Compile null PMD
>> +#
>> +CONFIG_RTE_LIBRTE_PMD_NULL=y
>> +
>> +#
>> +# Do prefetch of packet data within PMD driver receive function #
>> +CONFIG_RTE_PMD_PACKET_PREFETCH=y
>> +
>> +#
>> +# Compile generic crypto device library # EXPERIMENTAL: API may change
>> +without prior notice # CONFIG_RTE_LIBRTE_CRYPTODEV=y
>> +CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>> +CONFIG_RTE_CRYPTO_MAX_DEVS=64
>> +CONFIG_RTE_CRYPTODEV_NAME_LEN=64
>> +
>> +#
>> +# Compile PMD for QuickAssist based devices #
>> +CONFIG_RTE_LIBRTE_PMD_QAT=n
>> CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
>> +CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
>> +CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
>> +CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
>> +#
>> +# Number of sessions to create in the session memory pool # on a single
>> +QuickAssist device.
>> +#
>> +CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
>> +
>> +#
>> +# Compile PMD for AESNI backed device
>> +#
>> +CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
>> +CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
>> +CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
>> +CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
>> +
>> +#
>> +# Compile librte_ring
>> +#
>> +CONFIG_RTE_LIBRTE_RING=y
>> +CONFIG_RTE_LIBRTE_RING_DEBUG=n
>> +CONFIG_RTE_RING_SPLIT_PROD_CONS=n
>> +CONFIG_RTE_RING_PAUSE_REP_COUNT=0
>> +
>> +#
>> +# Compile librte_mempool
>> +#
>> +CONFIG_RTE_LIBRTE_MEMPOOL=y
>> +CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
>> +CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
>> +
>> +#
>> +# Compile librte_mbuf
>> +#
>> +CONFIG_RTE_LIBRTE_MBUF=y
>> +CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>> +CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>> +CONFIG_RTE_PKTMBUF_HEADROOM=128
>> +
>> +#
>> +# Compile librte_mbuf_offload
>> +# EXPERIMENTAL: API may change without prior notice #
>> +CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
>> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
>> +
>> +#
>> +# Compile librte_timer
>> +#
>> +CONFIG_RTE_LIBRTE_TIMER=y
>> +CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
>> +
>> +#
>> +# Compile librte_cfgfile
>> +#
>> +CONFIG_RTE_LIBRTE_CFGFILE=y
>> +
>> +#
>> +# Compile librte_cmdline
>> +#
>> +CONFIG_RTE_LIBRTE_CMDLINE=y
>> +CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
>> +
>> +#
>> +# Compile librte_hash
>> +#
>> +CONFIG_RTE_LIBRTE_HASH=y
>> +CONFIG_RTE_LIBRTE_HASH_DEBUG=n
>> +
>> +#
>> +# Compile librte_jobstats
>> +#
>> +CONFIG_RTE_LIBRTE_JOBSTATS=y
>> +
>> +#
>> +# Compile librte_lpm
>> +#
>> +CONFIG_RTE_LIBRTE_LPM=y
>> +CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>> +
>> +#
>> +# Compile librte_acl
>> +#
>> +CONFIG_RTE_LIBRTE_ACL=y
>> +CONFIG_RTE_LIBRTE_ACL_DEBUG=n
>> +
>> +#
>> +# Compile librte_power
>> +#
>> +CONFIG_RTE_LIBRTE_POWER=y
>> +CONFIG_RTE_LIBRTE_POWER_DEBUG=n
>> +CONFIG_RTE_MAX_LCORE_FREQS=64
>> +
>> +#
>> +# Compile librte_net
>> +#
>> +CONFIG_RTE_LIBRTE_NET=y
>> +
>> +#
>> +# Compile librte_ip_frag
>> +#
>> +CONFIG_RTE_LIBRTE_IP_FRAG=y
>> +CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
>> +CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
>> +CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
>> +
>> +#
>> +# Compile librte_meter
>> +#
>> +CONFIG_RTE_LIBRTE_METER=y
>> +
>> +#
>> +# Compile librte_sched
>> +#
>> +CONFIG_RTE_LIBRTE_SCHED=y
>> +CONFIG_RTE_SCHED_DEBUG=n
>> +CONFIG_RTE_SCHED_RED=n
>> +CONFIG_RTE_SCHED_COLLECT_STATS=n
>> +CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
>> +CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
>> +CONFIG_RTE_SCHED_VECTOR=n
>> +
>> +#
>> +# Compile the distributor library
>> +#
>> +CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
>> +
>> +#
>> +# Compile the reorder library
>> +#
>> +CONFIG_RTE_LIBRTE_REORDER=y
>> +
>> +#
>> +# Compile librte_port
>> +#
>> +CONFIG_RTE_LIBRTE_PORT=y
>> +CONFIG_RTE_PORT_STATS_COLLECT=n
>> +
>> +#
>> +# Compile librte_table
>> +#
>> +CONFIG_RTE_LIBRTE_TABLE=y
>> +CONFIG_RTE_TABLE_STATS_COLLECT=n
>> +
>> +#
>> +# Compile librte_pipeline
>> +#
>> +CONFIG_RTE_LIBRTE_PIPELINE=y
>> +CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>> +
>> +#
>> +# Compile librte_kni
>> +#
>> +CONFIG_RTE_LIBRTE_KNI=y
>> +CONFIG_RTE_KNI_KMOD=y
>> +CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
>> +CONFIG_RTE_KNI_KO_DEBUG=n
>> +CONFIG_RTE_KNI_VHOST=n
>> +CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
>> +CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
>> +CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
>> +CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
>> +
>> +#
>> +# Compile vhost library
>> +# fuse-devel is needed to run vhost-cuse.
>> +# fuse-devel enables user space char driver development # vhost-user is
>> +turned on by default.
>> +#
>> +CONFIG_RTE_LIBRTE_VHOST=y
>> +CONFIG_RTE_LIBRTE_VHOST_USER=y
>> +CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>> +CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
>> +
>> +#
>> +#Compile Xen domain0 support
>> +#
>> +CONFIG_RTE_LIBRTE_XEN_DOM0=n
>> +
>> +#
>> +# Enable warning directives
>> +#
>> +CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
>> +
>> +#
>> +# Compile the test application
>> +#
>> +CONFIG_RTE_APP_TEST=y
>> +
>> +#
>> +# Compile the PMD test application
>> +#
>> +CONFIG_RTE_TEST_PMD=y
>> +CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>> +CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>> diff --git a/config/common_bsdapp b/config/common_bsdapp index
>> 696382c..de0ca7d 100644
>> --- a/config/common_bsdapp
>> +++ b/config/common_bsdapp
>> @@ -1,6 +1,6 @@
>> # BSD LICENSE
>> #
>> -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>> +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>> # All rights reserved.
>> #
>> # Redistribution and use in source and binary forms, with or without
>> @@ -37,74 +37,38 @@
>> CONFIG_RTE_EXEC_ENV="bsdapp"
>> CONFIG_RTE_EXEC_ENV_BSDAPP=y
>>
>> -##
>> -## machine can define specific variables or action for a specific board -##
>> RTE_MACHINE values are the directories in mk/machine/ -## -
>> #CONFIG_RTE_MACHINE="native"
>> -#
>> -##
>> -## define the architecture we compile for.
>> -## RTE_ARCH values are the directories in mk/arch/ -## -
>> #CONFIG_RTE_ARCH="x86_64"
>> -#CONFIG_RTE_ARCH_X86_64=y
>> -#CONFIG_RTE_ARCH_X86=y
>> -#
>> -##
>> -## The compiler we use.
>> -## RTE_TOOLCHAIN values are the directories in mk/toolchain/ -## -
>> #CONFIG_RTE_TOOLCHAIN="gcc"
>> -#CONFIG_RTE_TOOLCHAIN_GCC=y
>> -
>> -#
>> -# Use intrinsics or assembly code for key routines -# -
>> CONFIG_RTE_FORCE_INTRINSICS=n
>> +#include "common_base"
>>
>> #
>> -# Machine forces strict alignment constraints.
>> +# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
>> #
>> -CONFIG_RTE_ARCH_STRICT_ALIGN=n
>> +CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
>>
>> #
>> -# Compile to share library
>> +# Compile Environment Abstraction Layer
>> #
>> -CONFIG_RTE_BUILD_SHARED_LIB=n
>> +CONFIG_RTE_EAL_IGB_UIO=n
>> +CONFIG_RTE_EAL_VFIO=n
>>
>> #
>> -# Combine to one single library
>> +# Compile software PMD backed by AF_PACKET sockets (Linux only)
>> #
>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> +CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n
>>
>> #
>> -# Use newest code breaking previous ABI
>> +# Compile librte_power
>> #
>> -CONFIG_RTE_NEXT_ABI=y
>> +CONFIG_RTE_LIBRTE_POWER=n
>>
>> #
>> -# Machine's cache line size
>> +# Compile librte_kni
>> #
>> -CONFIG_RTE_CACHE_LINE_SIZE=64
>> +CONFIG_RTE_LIBRTE_KNI=n
>>
>> #
>> -# Compile Environment Abstraction Layer
>> +# Compile vhost library
>> #
>> -CONFIG_RTE_LIBRTE_EAL=y
>> -CONFIG_RTE_MAX_LCORE=128
>> -CONFIG_RTE_MAX_NUMA_NODES=8
>> -CONFIG_RTE_MAX_MEMSEG=256
>> -CONFIG_RTE_MAX_MEMZONE=2560
>> -CONFIG_RTE_MAX_TAILQ=32
>> -CONFIG_RTE_LOG_LEVEL=8
>> -CONFIG_RTE_LOG_HISTORY=256
>> -CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
>> -CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
>> -CONFIG_RTE_MALLOC_DEBUG=n
>> -
>> -# Default driver path (or "" to disable) -CONFIG_RTE_EAL_PMD_PATH=""
>> +CONFIG_RTE_LIBRTE_VHOST=n
>>
>> #
>> # FreeBSD contiguous memory driver settings @@ -113,373 +77,3 @@
>> CONFIG_RTE_CONTIGMEM_MAX_NUM_BUFS=64
>> CONFIG_RTE_CONTIGMEM_DEFAULT_NUM_BUFS=2
>> CONFIG_RTE_CONTIGMEM_DEFAULT_BUF_SIZE=1024*1024*1024
>>
>> -#
>> -# Compile Environment Abstraction Layer for BSD -# -
>> CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
>> -
>> -#
>> -# Compile Environment Abstraction Layer for linux -# -
>> CONFIG_RTE_LIBRTE_EAL_LINUXAPP=n
>> -
>> -#
>> -# Compile Environment Abstraction Layer to support Vmware TSC map -# -
>> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
>> -
>> -#
>> -# Compile the argument parser library
>> -#
>> -CONFIG_RTE_LIBRTE_KVARGS=y
>> -
>> -#
>> -# Compile generic ethernet library
>> -#
>> -CONFIG_RTE_LIBRTE_ETHER=y
>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>> -CONFIG_RTE_MAX_ETHPORTS=32
>> -CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>> -CONFIG_RTE_LIBRTE_IEEE1588=n
>> -CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
>> -CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
>> -
>> -#
>> -# Support NIC bypass logic
>> -#
>> -CONFIG_RTE_NIC_BYPASS=n
>> -
>> -#
>> -# Compile burst-oriented IGB & EM PMD drivers -# -
>> CONFIG_RTE_LIBRTE_EM_PMD=y -CONFIG_RTE_LIBRTE_IGB_PMD=y -
>> CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
>> -
>> -#
>> -# Compile burst-oriented IXGBE PMD driver -# -
>> CONFIG_RTE_LIBRTE_IXGBE_PMD=y -
>> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>> -CONFIG_RTE_IXGBE_INC_VECTOR=y
>> -CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>> -
>> -#
>> -# Compile burst-oriented I40E PMD driver -# -
>> CONFIG_RTE_LIBRTE_I40E_PMD=y -CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
>> -CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>> -CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
>> -CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
>> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
>> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
>> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>> -# interval up to 8160 us, aligned to 2 (or default value)
>> -CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>> -
>> -#
>> -# Compile burst-oriented FM10K PMD
>> -#
>> -CONFIG_RTE_LIBRTE_FM10K_PMD=y
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>> -
>> -#
>> -# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD -# -
>> CONFIG_RTE_LIBRTE_MLX4_PMD=n -CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
>> -CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
>> -CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
>> -CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
>> -CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
>> -
>> -#
>> -# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD -# -
>> CONFIG_RTE_LIBRTE_MLX5_PMD=n -CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
>> -CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
>> -CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
>> -CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
>> -
>> -#
>> -# Compile burst-oriented Broadcom PMD driver -# -
>> CONFIG_RTE_LIBRTE_BNX2X_PMD=n -CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n -
>> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>> -
>> -#
>> -# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD -# -
>> CONFIG_RTE_LIBRTE_CXGBE_PMD=y -CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n -
>> CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
>> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
>> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>> -
>> -#
>> -# Compile burst-oriented Cisco ENIC PMD driver -# -
>> CONFIG_RTE_LIBRTE_ENIC_PMD=y -CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>> -
>> -#
>> -# Compile software PMD backed by SZEDATA2 device -# -
>> CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
>> -
>> -#
>> -# Compile burst-oriented VIRTIO PMD driver -# -
>> CONFIG_RTE_LIBRTE_VIRTIO_PMD=y -
>> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>> -
>> -#
>> -# Compile burst-oriented VMXNET3 PMD driver -# -
>> CONFIG_RTE_LIBRTE_VMXNET3_PMD=y -
>> CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
>> -
>> -#
>> -# Compile example software rings based PMD -# -
>> CONFIG_RTE_LIBRTE_PMD_RING=y
>> -CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
>> -CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>> -
>> -#
>> -# Compile software PMD backed by PCAP files -# -
>> CONFIG_RTE_LIBRTE_PMD_PCAP=y
>> -
>> -#
>> -# Compile link bonding PMD library
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_BOND=y
>> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>> -
>> -#
>> -# Compile null PMD
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_NULL=y
>> -
>> -#
>> -# Do prefetch of packet data within PMD driver receive function -# -
>> CONFIG_RTE_PMD_PACKET_PREFETCH=y
>> -
>> -#
>> -# Compile generic crypto device library -# EXPERIMENTAL: API may change
>> without prior notice -# -CONFIG_RTE_LIBRTE_CRYPTODEV=y -
>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>> -CONFIG_RTE_CRYPTO_MAX_DEVS=64
>> -CONFIG_RTE_CRYPTODEV_NAME_LEN=64
>> -
>> -#
>> -# Compile PMD for QuickAssist based devices -# -
>> CONFIG_RTE_LIBRTE_PMD_QAT=n -CONFIG_RTE_LIBRTE_QAT_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_QAT_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_QAT_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_QAT_DEBUG_DRIVER=n
>> -#
>> -# Number of sessions to create in the session memory pool -# on a single
>> QuickAssist device.
>> -#
>> -CONFIG_RTE_MAX_QAT_SESSIONS=200
>> -
>> -#
>> -# Compile PMD for AESNI backed device
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
>> -CONFIG_RTE_LIBRTE_AESNI_MB_DEBUG=n
>> -
>> -#
>> -# Compile librte_ring
>> -#
>> -CONFIG_RTE_LIBRTE_RING=y
>> -CONFIG_RTE_LIBRTE_RING_DEBUG=n
>> -CONFIG_RTE_RING_SPLIT_PROD_CONS=n
>> -CONFIG_RTE_RING_PAUSE_REP_COUNT=0
>> -
>> -#
>> -# Compile librte_mempool
>> -#
>> -CONFIG_RTE_LIBRTE_MEMPOOL=y
>> -CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
>> -CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
>> -
>> -#
>> -# Compile librte_mbuf
>> -#
>> -CONFIG_RTE_LIBRTE_MBUF=y
>> -CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>> -CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>> -CONFIG_RTE_PKTMBUF_HEADROOM=128
>> -
>> -#
>> -# Compile librte_mbuf_offload
>> -# EXPERIMENTAL: API may change without prior notice -# -
>> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y -
>> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
>> -
>> -#
>> -# Compile librte_timer
>> -#
>> -CONFIG_RTE_LIBRTE_TIMER=y
>> -CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
>> -
>> -#
>> -# Compile librte_cfgfile
>> -#
>> -CONFIG_RTE_LIBRTE_CFGFILE=y
>> -
>> -#
>> -# Compile librte_cmdline
>> -#
>> -CONFIG_RTE_LIBRTE_CMDLINE=y
>> -CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
>> -
>> -#
>> -# Compile librte_hash
>> -#
>> -CONFIG_RTE_LIBRTE_HASH=y
>> -CONFIG_RTE_LIBRTE_HASH_DEBUG=n
>> -
>> -#
>> -# Compile librte_jobstats
>> -#
>> -CONFIG_RTE_LIBRTE_JOBSTATS=y
>> -
>> -#
>> -# Compile librte_lpm
>> -#
>> -CONFIG_RTE_LIBRTE_LPM=y
>> -CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>> -
>> -#
>> -# Compile librte_acl
>> -#
>> -CONFIG_RTE_LIBRTE_ACL=y
>> -CONFIG_RTE_LIBRTE_ACL_DEBUG=n
>> -
>> -#
>> -# Compile librte_power
>> -#
>> -CONFIG_RTE_LIBRTE_POWER=n
>> -CONFIG_RTE_LIBRTE_POWER_DEBUG=n
>> -CONFIG_RTE_MAX_LCORE_FREQS=64
>> -
>> -#
>> -# Compile librte_net
>> -#
>> -CONFIG_RTE_LIBRTE_NET=y
>> -
>> -#
>> -# Compile librte_ip_frag
>> -#
>> -CONFIG_RTE_LIBRTE_IP_FRAG=y
>> -CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
>> -CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
>> -CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
>> -
>> -#
>> -# Compile librte_meter
>> -#
>> -CONFIG_RTE_LIBRTE_METER=y
>> -
>> -#
>> -# Compile librte_sched
>> -#
>> -CONFIG_RTE_LIBRTE_SCHED=y
>> -CONFIG_RTE_SCHED_DEBUG=n
>> -CONFIG_RTE_SCHED_RED=n
>> -CONFIG_RTE_SCHED_COLLECT_STATS=n
>> -CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
>> -CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
>> -CONFIG_RTE_SCHED_VECTOR=n
>> -
>> -#
>> -# Compile the distributor library
>> -#
>> -CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
>> -
>> -#
>> -# Compile the reorder library
>> -#
>> -CONFIG_RTE_LIBRTE_REORDER=y
>> -
>> -#
>> -# Compile librte_port
>> -#
>> -CONFIG_RTE_LIBRTE_PORT=y
>> -CONFIG_RTE_PORT_STATS_COLLECT=n
>> -
>> -#
>> -# Compile librte_table
>> -#
>> -CONFIG_RTE_LIBRTE_TABLE=y
>> -CONFIG_RTE_TABLE_STATS_COLLECT=n
>> -
>> -#
>> -# Compile librte_pipeline
>> -#
>> -CONFIG_RTE_LIBRTE_PIPELINE=y
>> -CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>> -
>> -#
>> -# Enable warning directives
>> -#
>> -CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
>> -
>> -#
>> -# Compile the test application
>> -#
>> -CONFIG_RTE_APP_TEST=y
>> -
>> -#
>> -# Compile the PMD test application
>> -#
>> -CONFIG_RTE_TEST_PMD=y
>> -CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>> -CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>> diff --git a/config/common_linuxapp b/config/common_linuxapp index
>> f1638db..64ddbe9 100644
>> --- a/config/common_linuxapp
>> +++ b/config/common_linuxapp
>> @@ -1,6 +1,6 @@
>> # BSD LICENSE
>> #
>> -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>> +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>> # All rights reserved.
>> #
>> # Redistribution and use in source and binary forms, with or without
>> @@ -37,494 +37,9 @@
>> CONFIG_RTE_EXEC_ENV="linuxapp"
>> CONFIG_RTE_EXEC_ENV_LINUXAPP=y
>>
>> -##
>> -## machine can define specific variables or action for a specific board -##
>> RTE_MACHINE values are the directories in mk/machine/ -## -
>> #CONFIG_RTE_MACHINE="native"
>> -#
>> -##
>> -## define the architecture we compile for.
>> -## RTE_ARCH values are the directories in mk/arch/ -## -
>> #CONFIG_RTE_ARCH="x86_64"
>> -#CONFIG_RTE_ARCH_X86_64=y
>> -#CONFIG_RTE_ARCH_X86=y
>> -#
>> -##
>> -## The compiler we use.
>> -## RTE_TOOLCHAIN values are the directories in mk/toolchain/ -## -
>> #CONFIG_RTE_TOOLCHAIN="gcc"
>> -#CONFIG_RTE_TOOLCHAIN_GCC=y
>> -
>> -#
>> -# Use intrinsics or assembly code for key routines -# -
>> CONFIG_RTE_FORCE_INTRINSICS=n
>> -
>> -#
>> -# Machine forces strict alignment constraints.
>> -#
>> -CONFIG_RTE_ARCH_STRICT_ALIGN=n
>> -
>> -#
>> -# Compile to share library
>> -#
>> -CONFIG_RTE_BUILD_SHARED_LIB=n
>> -
>> -#
>> -# Combine to one single library
>> -#
>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> -
>> -#
>> -# Use newest code breaking previous ABI -# -CONFIG_RTE_NEXT_ABI=y
>> -
>> -#
>> -# Machine's cache line size
>> -#
>> -CONFIG_RTE_CACHE_LINE_SIZE=64
>> -
>> -#
>> -# Compile Environment Abstraction Layer -# -CONFIG_RTE_LIBRTE_EAL=y
>> -CONFIG_RTE_MAX_LCORE=128
>> -CONFIG_RTE_MAX_NUMA_NODES=8
>> -CONFIG_RTE_MAX_MEMSEG=256
>> -CONFIG_RTE_MAX_MEMZONE=2560
>> -CONFIG_RTE_MAX_TAILQ=32
>> -CONFIG_RTE_LOG_LEVEL=8
>> -CONFIG_RTE_LOG_HISTORY=256
>> -CONFIG_RTE_LIBEAL_USE_HPET=n
>> -CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
>> -CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
>> -CONFIG_RTE_EAL_IGB_UIO=y
>> -CONFIG_RTE_EAL_VFIO=y
>> -CONFIG_RTE_MALLOC_DEBUG=n
>> -# Default driver path (or "" to disable) -CONFIG_RTE_EAL_PMD_PATH=""
>> -
>> -#
>> -# Special configurations in PCI Config Space for high performance -# -
>> CONFIG_RTE_PCI_CONFIG=n -CONFIG_RTE_PCI_EXTENDED_TAG=""
>> -CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
>> +#include "common_base"
>>
>> #
>> -# Compile Environment Abstraction Layer for linux
>> +# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
>> #
>> CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y
>> -
>> -#
>> -# Compile Environment Abstraction Layer to support Vmware TSC map -# -
>> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
>> -
>> -#
>> -# Compile the argument parser library
>> -#
>> -CONFIG_RTE_LIBRTE_KVARGS=y
>> -
>> -#
>> -# Compile generic ethernet library
>> -#
>> -CONFIG_RTE_LIBRTE_ETHER=y
>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>> -CONFIG_RTE_MAX_ETHPORTS=32
>> -CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>> -CONFIG_RTE_LIBRTE_IEEE1588=n
>> -CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
>> -CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
>> -
>> -#
>> -# Support NIC bypass logic
>> -#
>> -CONFIG_RTE_NIC_BYPASS=n
>> -
>> -#
>> -# Compile burst-oriented IGB & EM PMD drivers -# -
>> CONFIG_RTE_LIBRTE_EM_PMD=y -CONFIG_RTE_LIBRTE_IGB_PMD=y -
>> CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
>> -
>> -#
>> -# Compile burst-oriented IXGBE PMD driver -# -
>> CONFIG_RTE_LIBRTE_IXGBE_PMD=y -
>> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>> -CONFIG_RTE_IXGBE_INC_VECTOR=y
>> -CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>> -
>> -#
>> -# Compile burst-oriented I40E PMD driver -# -
>> CONFIG_RTE_LIBRTE_I40E_PMD=y -CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
>> -CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>> -CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
>> -CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
>> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
>> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
>> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>> -# interval up to 8160 us, aligned to 2 (or default value)
>> -CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>> -
>> -#
>> -# Compile burst-oriented FM10K PMD
>> -#
>> -CONFIG_RTE_LIBRTE_FM10K_PMD=y
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>> -CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
>> -
>> -#
>> -# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD -# -
>> CONFIG_RTE_LIBRTE_MLX4_PMD=n -CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
>> -CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
>> -CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
>> -CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
>> -CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
>> -
>> -#
>> -# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD -# -
>> CONFIG_RTE_LIBRTE_MLX5_PMD=n -CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
>> -CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
>> -CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
>> -CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
>> -
>> -#
>> -# Compile burst-oriented Broadcom PMD driver -# -
>> CONFIG_RTE_LIBRTE_BNX2X_PMD=n -CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n -
>> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
>> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>> -
>> -#
>> -# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD -# -
>> CONFIG_RTE_LIBRTE_CXGBE_PMD=y -CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n -
>> CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
>> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
>> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
>> -
>> -#
>> -# Compile burst-oriented Cisco ENIC PMD driver -# -
>> CONFIG_RTE_LIBRTE_ENIC_PMD=y -CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>> -
>> -#
>> -# Compile burst-oriented Netronome NFP PMD driver -# -
>> CONFIG_RTE_LIBRTE_NFP_PMD=n -CONFIG_RTE_LIBRTE_NFP_DEBUG=n
>> -
>> -#
>> -# Compile software PMD backed by SZEDATA2 device -# -
>> CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
>> -
>> -#
>> -# Compile burst-oriented VIRTIO PMD driver -# -
>> CONFIG_RTE_LIBRTE_VIRTIO_PMD=y -
>> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>> -
>> -#
>> -# Compile burst-oriented VMXNET3 PMD driver -# -
>> CONFIG_RTE_LIBRTE_VMXNET3_PMD=y -
>> CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
>> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
>> -
>> -#
>> -# Compile example software rings based PMD -# -
>> CONFIG_RTE_LIBRTE_PMD_RING=y
>> -CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
>> -CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
>> -
>> -#
>> -# Compile software PMD backed by PCAP files -# -
>> CONFIG_RTE_LIBRTE_PMD_PCAP=n
>> -
>> -#
>> -# Compile link bonding PMD library
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_BOND=y
>> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>> -
>> -#
>> -# Compile software PMD backed by AF_PACKET sockets (Linux only) -# -
>> CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
>> -
>> -#
>> -# Compile Xen PMD
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
>> -
>> -#
>> -# Compile null PMD
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_NULL=y
>> -
>> -#
>> -# Do prefetch of packet data within PMD driver receive function -# -
>> CONFIG_RTE_PMD_PACKET_PREFETCH=y
>> -
>> -#
>> -# Compile generic crypto device library -# EXPERIMENTAL: API may change
>> without prior notice -# -CONFIG_RTE_LIBRTE_CRYPTODEV=y -
>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>> -CONFIG_RTE_CRYPTO_MAX_DEVS=64
>> -CONFIG_RTE_CRYPTODEV_NAME_LEN=64
>> -
>> -#
>> -# Compile PMD for QuickAssist based devices -# -
>> CONFIG_RTE_LIBRTE_PMD_QAT=n -
>> CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
>> -CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
>> -CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
>> -CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
>> -#
>> -# Number of sessions to create in the session memory pool -# on a single
>> QuickAssist device.
>> -#
>> -CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
>> -
>> -#
>> -# Compile PMD for AESNI backed device
>> -#
>> -CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
>> -CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
>> -CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
>> -CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
>> -
>> -#
>> -# Compile librte_ring
>> -#
>> -CONFIG_RTE_LIBRTE_RING=y
>> -CONFIG_RTE_LIBRTE_RING_DEBUG=n
>> -CONFIG_RTE_RING_SPLIT_PROD_CONS=n
>> -CONFIG_RTE_RING_PAUSE_REP_COUNT=0
>> -
>> -#
>> -# Compile librte_mempool
>> -#
>> -CONFIG_RTE_LIBRTE_MEMPOOL=y
>> -CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
>> -CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
>> -
>> -#
>> -# Compile librte_mbuf
>> -#
>> -CONFIG_RTE_LIBRTE_MBUF=y
>> -CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>> -CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>> -CONFIG_RTE_PKTMBUF_HEADROOM=128
>> -
>> -#
>> -# Compile librte_mbuf_offload
>> -# EXPERIMENTAL: API may change without prior notice -# -
>> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y -
>> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
>> -
>> -#
>> -# Compile librte_timer
>> -#
>> -CONFIG_RTE_LIBRTE_TIMER=y
>> -CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
>> -
>> -#
>> -# Compile librte_cfgfile
>> -#
>> -CONFIG_RTE_LIBRTE_CFGFILE=y
>> -
>> -#
>> -# Compile librte_cmdline
>> -#
>> -CONFIG_RTE_LIBRTE_CMDLINE=y
>> -CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
>> -
>> -#
>> -# Compile librte_hash
>> -#
>> -CONFIG_RTE_LIBRTE_HASH=y
>> -CONFIG_RTE_LIBRTE_HASH_DEBUG=n
>> -
>> -#
>> -# Compile librte_jobstats
>> -#
>> -CONFIG_RTE_LIBRTE_JOBSTATS=y
>> -
>> -#
>> -# Compile librte_lpm
>> -#
>> -CONFIG_RTE_LIBRTE_LPM=y
>> -CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>> -
>> -#
>> -# Compile librte_acl
>> -#
>> -CONFIG_RTE_LIBRTE_ACL=y
>> -CONFIG_RTE_LIBRTE_ACL_DEBUG=n
>> -
>> -#
>> -# Compile librte_power
>> -#
>> -CONFIG_RTE_LIBRTE_POWER=y
>> -CONFIG_RTE_LIBRTE_POWER_DEBUG=n
>> -CONFIG_RTE_MAX_LCORE_FREQS=64
>> -
>> -#
>> -# Compile librte_net
>> -#
>> -CONFIG_RTE_LIBRTE_NET=y
>> -
>> -#
>> -# Compile librte_ip_frag
>> -#
>> -CONFIG_RTE_LIBRTE_IP_FRAG=y
>> -CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
>> -CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
>> -CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
>> -
>> -#
>> -# Compile librte_meter
>> -#
>> -CONFIG_RTE_LIBRTE_METER=y
>> -
>> -#
>> -# Compile librte_sched
>> -#
>> -CONFIG_RTE_LIBRTE_SCHED=y
>> -CONFIG_RTE_SCHED_DEBUG=n
>> -CONFIG_RTE_SCHED_RED=n
>> -CONFIG_RTE_SCHED_COLLECT_STATS=n
>> -CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
>> -CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
>> -CONFIG_RTE_SCHED_VECTOR=n
>> -
>> -#
>> -# Compile the distributor library
>> -#
>> -CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
>> -
>> -#
>> -# Compile the reorder library
>> -#
>> -CONFIG_RTE_LIBRTE_REORDER=y
>> -
>> -#
>> -# Compile librte_port
>> -#
>> -CONFIG_RTE_LIBRTE_PORT=y
>> -CONFIG_RTE_PORT_STATS_COLLECT=n
>> -
>> -#
>> -# Compile librte_table
>> -#
>> -CONFIG_RTE_LIBRTE_TABLE=y
>> -CONFIG_RTE_TABLE_STATS_COLLECT=n
>> -
>> -#
>> -# Compile librte_pipeline
>> -#
>> -CONFIG_RTE_LIBRTE_PIPELINE=y
>> -CONFIG_RTE_PIPELINE_STATS_COLLECT=n
>> -
>> -#
>> -# Compile librte_kni
>> -#
>> -CONFIG_RTE_LIBRTE_KNI=y
>> -CONFIG_RTE_KNI_KMOD=y
>> -CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
>> -CONFIG_RTE_KNI_KO_DEBUG=n
>> -CONFIG_RTE_KNI_VHOST=n
>> -CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
>> -CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
>> -CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
>> -CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
>> -
>> -#
>> -# Compile vhost library
>> -# fuse-devel is needed to run vhost-cuse.
>> -# fuse-devel enables user space char driver development -# vhost-user is turned
>> on by default.
>> -#
>> -CONFIG_RTE_LIBRTE_VHOST=y
>> -CONFIG_RTE_LIBRTE_VHOST_USER=y
>> -CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>> -CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
>> -
>> -#
>> -#Compile Xen domain0 support
>> -#
>> -CONFIG_RTE_LIBRTE_XEN_DOM0=n
>> -
>> -#
>> -# Enable warning directives
>> -#
>> -CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
>> -
>> -#
>> -# Compile the test application
>> -#
>> -CONFIG_RTE_APP_TEST=y
>> -
>> -#
>> -# Compile the PMD test application
>> -#
>> -CONFIG_RTE_TEST_PMD=y
>> -CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>> -CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>> diff --git a/config/defconfig_x86_64-native-bsdapp-clang
>> b/config/defconfig_x86_64-native-bsdapp-clang
>> index d2baf2c..8b870b3 100644
>> --- a/config/defconfig_x86_64-native-bsdapp-clang
>> +++ b/config/defconfig_x86_64-native-bsdapp-clang
>> @@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
>> CONFIG_RTE_ARCH="x86_64"
>> CONFIG_RTE_ARCH_X86_64=y
>> CONFIG_RTE_ARCH_X86=y
>> +CONFIG_RTE_ARCH_64=y
>>
>> CONFIG_RTE_TOOLCHAIN="clang"
>> CONFIG_RTE_TOOLCHAIN_CLANG=y
>> diff --git a/config/defconfig_x86_64-native-bsdapp-gcc
>> b/config/defconfig_x86_64-native-bsdapp-gcc
>> index 5a6a4e8..4ea4433 100644
>> --- a/config/defconfig_x86_64-native-bsdapp-gcc
>> +++ b/config/defconfig_x86_64-native-bsdapp-gcc
>> @@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
>> CONFIG_RTE_ARCH="x86_64"
>> CONFIG_RTE_ARCH_X86_64=y
>> CONFIG_RTE_ARCH_X86=y
>> +CONFIG_RTE_ARCH_64=y
>>
>> CONFIG_RTE_TOOLCHAIN="gcc"
>> CONFIG_RTE_TOOLCHAIN_GCC=y
>> --
>> 2.7.0
>
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] config: remove duplicate configuration information
2016-02-22 13:53 6% [dpdk-dev] [PATCH] config: remove duplicate configuration information Keith Wiles
@ 2016-02-22 15:09 0% ` Trahe, Fiona
2016-02-22 16:02 0% ` Wiles, Keith
2016-02-24 13:58 0% ` Wiles, Keith
1 sibling, 1 reply; 200+ results
From: Trahe, Fiona @ 2016-02-22 15:09 UTC (permalink / raw)
To: Wiles, Keith, dev
Hi Keith,
What makes a param common?
e.g. cryptodev QAT PMD is supported in linux, but currently not supported in bsd.
So typically I disable it in the bsd file and enable it in the linux file.
Couldn't the same apply to any other parameter, i.e. there may be users who want to have differences in config for different OSs?
So why not just leave as is and give users the option to choose?
Regards,
Fiona
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
> Sent: Monday, February 22, 2016 1:54 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] config: remove duplicate configuration information
>
> In order to cleanup the configuration files some and reduce the number of
> duplicate configuration information. Add a new file called common_base which
> contains just about all of the configuration lines in one place. Then have the
> common_bsdapp, common_linuxapp files include this one file. Then in those OS
> specific files add the delta configuration lines.
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> ---
> config/common_base | 498 ++++++++++++++++++++++++++++
> config/common_bsdapp | 436 +-----------------------
> config/common_linuxapp | 491 +--------------------------
> config/defconfig_x86_64-native-bsdapp-clang | 1 +
> config/defconfig_x86_64-native-bsdapp-gcc | 1 +
> 5 files changed, 518 insertions(+), 909 deletions(-) create mode 100644
> config/common_base
>
> diff --git a/config/common_base b/config/common_base new file mode 100644
> index 0000000..91a12eb
> --- /dev/null
> +++ b/config/common_base
> @@ -0,0 +1,498 @@
> +# BSD LICENSE
> +#
> +# Copyright(c) 2010-2016 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.
> +#
> +
> +#
> +# Use intrinsics or assembly code for key routines #
> +CONFIG_RTE_FORCE_INTRINSICS=n
> +
> +#
> +# Machine forces strict alignment constraints.
> +#
> +CONFIG_RTE_ARCH_STRICT_ALIGN=n
> +
> +#
> +# Compile to share library
> +#
> +CONFIG_RTE_BUILD_SHARED_LIB=n
> +
> +#
> +# Combine to one single library
> +#
> +CONFIG_RTE_BUILD_COMBINE_LIBS=n
> +
> +#
> +# Use newest code breaking previous ABI # CONFIG_RTE_NEXT_ABI=y
> +
> +#
> +# Machine's cache line size
> +#
> +CONFIG_RTE_CACHE_LINE_SIZE=64
> +
> +#
> +# Compile Environment Abstraction Layer # CONFIG_RTE_LIBRTE_EAL=y
> +CONFIG_RTE_MAX_LCORE=128
> +CONFIG_RTE_MAX_NUMA_NODES=8
> +CONFIG_RTE_MAX_MEMSEG=256
> +CONFIG_RTE_MAX_MEMZONE=2560
> +CONFIG_RTE_MAX_TAILQ=32
> +CONFIG_RTE_LOG_LEVEL=8
> +CONFIG_RTE_LOG_HISTORY=256
> +CONFIG_RTE_LIBEAL_USE_HPET=n
> +CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
> +CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
> +CONFIG_RTE_EAL_IGB_UIO=y
> +CONFIG_RTE_EAL_VFIO=y
> +CONFIG_RTE_MALLOC_DEBUG=n
> +
> +# Default driver path (or "" to disable) CONFIG_RTE_EAL_PMD_PATH=""
> +
> +#
> +# Special configurations in PCI Config Space for high performance #
> +CONFIG_RTE_PCI_CONFIG=n CONFIG_RTE_PCI_EXTENDED_TAG=""
> +CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
> +
> +#
> +# Compile Environment Abstraction Layer to support Vmware TSC map #
> +CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
> +
> +#
> +# Compile the argument parser library
> +#
> +CONFIG_RTE_LIBRTE_KVARGS=y
> +
> +#
> +# Compile generic ethernet library
> +#
> +CONFIG_RTE_LIBRTE_ETHER=y
> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
> +CONFIG_RTE_MAX_ETHPORTS=32
> +CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
> +CONFIG_RTE_LIBRTE_IEEE1588=n
> +CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
> +CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
> +
> +#
> +# Support NIC bypass logic
> +#
> +CONFIG_RTE_NIC_BYPASS=n
> +
> +#
> +# Compile burst-oriented IGB & EM PMD drivers #
> +CONFIG_RTE_LIBRTE_EM_PMD=y CONFIG_RTE_LIBRTE_IGB_PMD=y
> +CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
> +CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
> +CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
> +
> +#
> +# Compile burst-oriented IXGBE PMD driver #
> +CONFIG_RTE_LIBRTE_IXGBE_PMD=y
> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
> +CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
> +CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
> +CONFIG_RTE_IXGBE_INC_VECTOR=y
> +CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
> +
> +#
> +# Compile burst-oriented I40E PMD driver # CONFIG_RTE_LIBRTE_I40E_PMD=y
> +CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
> +CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
> +CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
> +CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
> +CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
> +CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
> +CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
> +CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> +CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
> +# interval up to 8160 us, aligned to 2 (or default value)
> +CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
> +
> +#
> +# Compile burst-oriented FM10K PMD
> +#
> +CONFIG_RTE_LIBRTE_FM10K_PMD=y
> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> +CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> +CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> +CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> +
> +#
> +# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD #
> +CONFIG_RTE_LIBRTE_MLX4_PMD=n CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
> +CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
> +CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
> +CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
> +CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> +
> +#
> +# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD #
> +CONFIG_RTE_LIBRTE_MLX5_PMD=n CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
> +CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
> +CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
> +CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
> +
> +#
> +# Compile burst-oriented Broadcom PMD driver #
> +CONFIG_RTE_LIBRTE_BNX2X_PMD=n CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
> +CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
> +
> +#
> +# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD #
> +CONFIG_RTE_LIBRTE_CXGBE_PMD=y CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
> +
> +#
> +# Compile burst-oriented Cisco ENIC PMD driver #
> +CONFIG_RTE_LIBRTE_ENIC_PMD=y CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
> +
> +#
> +# Compile burst-oriented Netronome NFP PMD driver #
> +CONFIG_RTE_LIBRTE_NFP_PMD=n CONFIG_RTE_LIBRTE_NFP_DEBUG=n
> +
> +#
> +# Compile software PMD backed by SZEDATA2 device #
> +CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
> +
> +#
> +# Compile burst-oriented VIRTIO PMD driver #
> +CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
> +CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
> +
> +#
> +# Compile burst-oriented VMXNET3 PMD driver #
> +CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
> CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
> +CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
> +
> +#
> +# Compile example software rings based PMD #
> +CONFIG_RTE_LIBRTE_PMD_RING=y
> +CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
> +CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
> +
> +#
> +# Compile software PMD backed by PCAP files #
> +CONFIG_RTE_LIBRTE_PMD_PCAP=n
> +
> +#
> +# Compile link bonding PMD library
> +#
> +CONFIG_RTE_LIBRTE_PMD_BOND=y
> +CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
> +CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
> +
> +#
> +# Compile software PMD backed by AF_PACKET sockets (Linux only) #
> +CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
> +
> +#
> +# Compile Xen PMD
> +#
> +CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
> +
> +#
> +# Compile null PMD
> +#
> +CONFIG_RTE_LIBRTE_PMD_NULL=y
> +
> +#
> +# Do prefetch of packet data within PMD driver receive function #
> +CONFIG_RTE_PMD_PACKET_PREFETCH=y
> +
> +#
> +# Compile generic crypto device library # EXPERIMENTAL: API may change
> +without prior notice # CONFIG_RTE_LIBRTE_CRYPTODEV=y
> +CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> +CONFIG_RTE_CRYPTO_MAX_DEVS=64
> +CONFIG_RTE_CRYPTODEV_NAME_LEN=64
> +
> +#
> +# Compile PMD for QuickAssist based devices #
> +CONFIG_RTE_LIBRTE_PMD_QAT=n
> CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
> +#
> +# Number of sessions to create in the session memory pool # on a single
> +QuickAssist device.
> +#
> +CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
> +
> +#
> +# Compile PMD for AESNI backed device
> +#
> +CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
> +CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
> +CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
> +CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
> +
> +#
> +# Compile librte_ring
> +#
> +CONFIG_RTE_LIBRTE_RING=y
> +CONFIG_RTE_LIBRTE_RING_DEBUG=n
> +CONFIG_RTE_RING_SPLIT_PROD_CONS=n
> +CONFIG_RTE_RING_PAUSE_REP_COUNT=0
> +
> +#
> +# Compile librte_mempool
> +#
> +CONFIG_RTE_LIBRTE_MEMPOOL=y
> +CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
> +CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
> +
> +#
> +# Compile librte_mbuf
> +#
> +CONFIG_RTE_LIBRTE_MBUF=y
> +CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
> +CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
> +CONFIG_RTE_PKTMBUF_HEADROOM=128
> +
> +#
> +# Compile librte_mbuf_offload
> +# EXPERIMENTAL: API may change without prior notice #
> +CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
> +
> +#
> +# Compile librte_timer
> +#
> +CONFIG_RTE_LIBRTE_TIMER=y
> +CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
> +
> +#
> +# Compile librte_cfgfile
> +#
> +CONFIG_RTE_LIBRTE_CFGFILE=y
> +
> +#
> +# Compile librte_cmdline
> +#
> +CONFIG_RTE_LIBRTE_CMDLINE=y
> +CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
> +
> +#
> +# Compile librte_hash
> +#
> +CONFIG_RTE_LIBRTE_HASH=y
> +CONFIG_RTE_LIBRTE_HASH_DEBUG=n
> +
> +#
> +# Compile librte_jobstats
> +#
> +CONFIG_RTE_LIBRTE_JOBSTATS=y
> +
> +#
> +# Compile librte_lpm
> +#
> +CONFIG_RTE_LIBRTE_LPM=y
> +CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> +
> +#
> +# Compile librte_acl
> +#
> +CONFIG_RTE_LIBRTE_ACL=y
> +CONFIG_RTE_LIBRTE_ACL_DEBUG=n
> +
> +#
> +# Compile librte_power
> +#
> +CONFIG_RTE_LIBRTE_POWER=y
> +CONFIG_RTE_LIBRTE_POWER_DEBUG=n
> +CONFIG_RTE_MAX_LCORE_FREQS=64
> +
> +#
> +# Compile librte_net
> +#
> +CONFIG_RTE_LIBRTE_NET=y
> +
> +#
> +# Compile librte_ip_frag
> +#
> +CONFIG_RTE_LIBRTE_IP_FRAG=y
> +CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
> +CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
> +CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
> +
> +#
> +# Compile librte_meter
> +#
> +CONFIG_RTE_LIBRTE_METER=y
> +
> +#
> +# Compile librte_sched
> +#
> +CONFIG_RTE_LIBRTE_SCHED=y
> +CONFIG_RTE_SCHED_DEBUG=n
> +CONFIG_RTE_SCHED_RED=n
> +CONFIG_RTE_SCHED_COLLECT_STATS=n
> +CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
> +CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
> +CONFIG_RTE_SCHED_VECTOR=n
> +
> +#
> +# Compile the distributor library
> +#
> +CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
> +
> +#
> +# Compile the reorder library
> +#
> +CONFIG_RTE_LIBRTE_REORDER=y
> +
> +#
> +# Compile librte_port
> +#
> +CONFIG_RTE_LIBRTE_PORT=y
> +CONFIG_RTE_PORT_STATS_COLLECT=n
> +
> +#
> +# Compile librte_table
> +#
> +CONFIG_RTE_LIBRTE_TABLE=y
> +CONFIG_RTE_TABLE_STATS_COLLECT=n
> +
> +#
> +# Compile librte_pipeline
> +#
> +CONFIG_RTE_LIBRTE_PIPELINE=y
> +CONFIG_RTE_PIPELINE_STATS_COLLECT=n
> +
> +#
> +# Compile librte_kni
> +#
> +CONFIG_RTE_LIBRTE_KNI=y
> +CONFIG_RTE_KNI_KMOD=y
> +CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
> +CONFIG_RTE_KNI_KO_DEBUG=n
> +CONFIG_RTE_KNI_VHOST=n
> +CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
> +CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
> +CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
> +CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
> +
> +#
> +# Compile vhost library
> +# fuse-devel is needed to run vhost-cuse.
> +# fuse-devel enables user space char driver development # vhost-user is
> +turned on by default.
> +#
> +CONFIG_RTE_LIBRTE_VHOST=y
> +CONFIG_RTE_LIBRTE_VHOST_USER=y
> +CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> +CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
> +
> +#
> +#Compile Xen domain0 support
> +#
> +CONFIG_RTE_LIBRTE_XEN_DOM0=n
> +
> +#
> +# Enable warning directives
> +#
> +CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
> +
> +#
> +# Compile the test application
> +#
> +CONFIG_RTE_APP_TEST=y
> +
> +#
> +# Compile the PMD test application
> +#
> +CONFIG_RTE_TEST_PMD=y
> +CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
> +CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> diff --git a/config/common_bsdapp b/config/common_bsdapp index
> 696382c..de0ca7d 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -1,6 +1,6 @@
> # BSD LICENSE
> #
> -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> # All rights reserved.
> #
> # Redistribution and use in source and binary forms, with or without
> @@ -37,74 +37,38 @@
> CONFIG_RTE_EXEC_ENV="bsdapp"
> CONFIG_RTE_EXEC_ENV_BSDAPP=y
>
> -##
> -## machine can define specific variables or action for a specific board -##
> RTE_MACHINE values are the directories in mk/machine/ -## -
> #CONFIG_RTE_MACHINE="native"
> -#
> -##
> -## define the architecture we compile for.
> -## RTE_ARCH values are the directories in mk/arch/ -## -
> #CONFIG_RTE_ARCH="x86_64"
> -#CONFIG_RTE_ARCH_X86_64=y
> -#CONFIG_RTE_ARCH_X86=y
> -#
> -##
> -## The compiler we use.
> -## RTE_TOOLCHAIN values are the directories in mk/toolchain/ -## -
> #CONFIG_RTE_TOOLCHAIN="gcc"
> -#CONFIG_RTE_TOOLCHAIN_GCC=y
> -
> -#
> -# Use intrinsics or assembly code for key routines -# -
> CONFIG_RTE_FORCE_INTRINSICS=n
> +#include "common_base"
>
> #
> -# Machine forces strict alignment constraints.
> +# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
> #
> -CONFIG_RTE_ARCH_STRICT_ALIGN=n
> +CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
>
> #
> -# Compile to share library
> +# Compile Environment Abstraction Layer
> #
> -CONFIG_RTE_BUILD_SHARED_LIB=n
> +CONFIG_RTE_EAL_IGB_UIO=n
> +CONFIG_RTE_EAL_VFIO=n
>
> #
> -# Combine to one single library
> +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> #
> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
> +CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n
>
> #
> -# Use newest code breaking previous ABI
> +# Compile librte_power
> #
> -CONFIG_RTE_NEXT_ABI=y
> +CONFIG_RTE_LIBRTE_POWER=n
>
> #
> -# Machine's cache line size
> +# Compile librte_kni
> #
> -CONFIG_RTE_CACHE_LINE_SIZE=64
> +CONFIG_RTE_LIBRTE_KNI=n
>
> #
> -# Compile Environment Abstraction Layer
> +# Compile vhost library
> #
> -CONFIG_RTE_LIBRTE_EAL=y
> -CONFIG_RTE_MAX_LCORE=128
> -CONFIG_RTE_MAX_NUMA_NODES=8
> -CONFIG_RTE_MAX_MEMSEG=256
> -CONFIG_RTE_MAX_MEMZONE=2560
> -CONFIG_RTE_MAX_TAILQ=32
> -CONFIG_RTE_LOG_LEVEL=8
> -CONFIG_RTE_LOG_HISTORY=256
> -CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
> -CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
> -CONFIG_RTE_MALLOC_DEBUG=n
> -
> -# Default driver path (or "" to disable) -CONFIG_RTE_EAL_PMD_PATH=""
> +CONFIG_RTE_LIBRTE_VHOST=n
>
> #
> # FreeBSD contiguous memory driver settings @@ -113,373 +77,3 @@
> CONFIG_RTE_CONTIGMEM_MAX_NUM_BUFS=64
> CONFIG_RTE_CONTIGMEM_DEFAULT_NUM_BUFS=2
> CONFIG_RTE_CONTIGMEM_DEFAULT_BUF_SIZE=1024*1024*1024
>
> -#
> -# Compile Environment Abstraction Layer for BSD -# -
> CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
> -
> -#
> -# Compile Environment Abstraction Layer for linux -# -
> CONFIG_RTE_LIBRTE_EAL_LINUXAPP=n
> -
> -#
> -# Compile Environment Abstraction Layer to support Vmware TSC map -# -
> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
> -
> -#
> -# Compile the argument parser library
> -#
> -CONFIG_RTE_LIBRTE_KVARGS=y
> -
> -#
> -# Compile generic ethernet library
> -#
> -CONFIG_RTE_LIBRTE_ETHER=y
> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
> -CONFIG_RTE_MAX_ETHPORTS=32
> -CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
> -CONFIG_RTE_LIBRTE_IEEE1588=n
> -CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
> -CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
> -
> -#
> -# Support NIC bypass logic
> -#
> -CONFIG_RTE_NIC_BYPASS=n
> -
> -#
> -# Compile burst-oriented IGB & EM PMD drivers -# -
> CONFIG_RTE_LIBRTE_EM_PMD=y -CONFIG_RTE_LIBRTE_IGB_PMD=y -
> CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
> -
> -#
> -# Compile burst-oriented IXGBE PMD driver -# -
> CONFIG_RTE_LIBRTE_IXGBE_PMD=y -
> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
> -CONFIG_RTE_IXGBE_INC_VECTOR=y
> -CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
> -
> -#
> -# Compile burst-oriented I40E PMD driver -# -
> CONFIG_RTE_LIBRTE_I40E_PMD=y -CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
> -CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
> -CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
> -CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
> -# interval up to 8160 us, aligned to 2 (or default value)
> -CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
> -
> -#
> -# Compile burst-oriented FM10K PMD
> -#
> -CONFIG_RTE_LIBRTE_FM10K_PMD=y
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> -
> -#
> -# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD -# -
> CONFIG_RTE_LIBRTE_MLX4_PMD=n -CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
> -CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
> -CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
> -CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
> -CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> -
> -#
> -# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD -# -
> CONFIG_RTE_LIBRTE_MLX5_PMD=n -CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
> -CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
> -CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
> -CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
> -
> -#
> -# Compile burst-oriented Broadcom PMD driver -# -
> CONFIG_RTE_LIBRTE_BNX2X_PMD=n -CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n -
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
> -
> -#
> -# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD -# -
> CONFIG_RTE_LIBRTE_CXGBE_PMD=y -CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n -
> CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
> -
> -#
> -# Compile burst-oriented Cisco ENIC PMD driver -# -
> CONFIG_RTE_LIBRTE_ENIC_PMD=y -CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
> -
> -#
> -# Compile software PMD backed by SZEDATA2 device -# -
> CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
> -
> -#
> -# Compile burst-oriented VIRTIO PMD driver -# -
> CONFIG_RTE_LIBRTE_VIRTIO_PMD=y -
> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
> -
> -#
> -# Compile burst-oriented VMXNET3 PMD driver -# -
> CONFIG_RTE_LIBRTE_VMXNET3_PMD=y -
> CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
> -
> -#
> -# Compile example software rings based PMD -# -
> CONFIG_RTE_LIBRTE_PMD_RING=y
> -CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
> -CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
> -
> -#
> -# Compile software PMD backed by PCAP files -# -
> CONFIG_RTE_LIBRTE_PMD_PCAP=y
> -
> -#
> -# Compile link bonding PMD library
> -#
> -CONFIG_RTE_LIBRTE_PMD_BOND=y
> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
> -
> -#
> -# Compile null PMD
> -#
> -CONFIG_RTE_LIBRTE_PMD_NULL=y
> -
> -#
> -# Do prefetch of packet data within PMD driver receive function -# -
> CONFIG_RTE_PMD_PACKET_PREFETCH=y
> -
> -#
> -# Compile generic crypto device library -# EXPERIMENTAL: API may change
> without prior notice -# -CONFIG_RTE_LIBRTE_CRYPTODEV=y -
> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> -CONFIG_RTE_CRYPTO_MAX_DEVS=64
> -CONFIG_RTE_CRYPTODEV_NAME_LEN=64
> -
> -#
> -# Compile PMD for QuickAssist based devices -# -
> CONFIG_RTE_LIBRTE_PMD_QAT=n -CONFIG_RTE_LIBRTE_QAT_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_QAT_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_QAT_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_QAT_DEBUG_DRIVER=n
> -#
> -# Number of sessions to create in the session memory pool -# on a single
> QuickAssist device.
> -#
> -CONFIG_RTE_MAX_QAT_SESSIONS=200
> -
> -#
> -# Compile PMD for AESNI backed device
> -#
> -CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
> -CONFIG_RTE_LIBRTE_AESNI_MB_DEBUG=n
> -
> -#
> -# Compile librte_ring
> -#
> -CONFIG_RTE_LIBRTE_RING=y
> -CONFIG_RTE_LIBRTE_RING_DEBUG=n
> -CONFIG_RTE_RING_SPLIT_PROD_CONS=n
> -CONFIG_RTE_RING_PAUSE_REP_COUNT=0
> -
> -#
> -# Compile librte_mempool
> -#
> -CONFIG_RTE_LIBRTE_MEMPOOL=y
> -CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
> -CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
> -
> -#
> -# Compile librte_mbuf
> -#
> -CONFIG_RTE_LIBRTE_MBUF=y
> -CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
> -CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
> -CONFIG_RTE_PKTMBUF_HEADROOM=128
> -
> -#
> -# Compile librte_mbuf_offload
> -# EXPERIMENTAL: API may change without prior notice -# -
> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y -
> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
> -
> -#
> -# Compile librte_timer
> -#
> -CONFIG_RTE_LIBRTE_TIMER=y
> -CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
> -
> -#
> -# Compile librte_cfgfile
> -#
> -CONFIG_RTE_LIBRTE_CFGFILE=y
> -
> -#
> -# Compile librte_cmdline
> -#
> -CONFIG_RTE_LIBRTE_CMDLINE=y
> -CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
> -
> -#
> -# Compile librte_hash
> -#
> -CONFIG_RTE_LIBRTE_HASH=y
> -CONFIG_RTE_LIBRTE_HASH_DEBUG=n
> -
> -#
> -# Compile librte_jobstats
> -#
> -CONFIG_RTE_LIBRTE_JOBSTATS=y
> -
> -#
> -# Compile librte_lpm
> -#
> -CONFIG_RTE_LIBRTE_LPM=y
> -CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> -
> -#
> -# Compile librte_acl
> -#
> -CONFIG_RTE_LIBRTE_ACL=y
> -CONFIG_RTE_LIBRTE_ACL_DEBUG=n
> -
> -#
> -# Compile librte_power
> -#
> -CONFIG_RTE_LIBRTE_POWER=n
> -CONFIG_RTE_LIBRTE_POWER_DEBUG=n
> -CONFIG_RTE_MAX_LCORE_FREQS=64
> -
> -#
> -# Compile librte_net
> -#
> -CONFIG_RTE_LIBRTE_NET=y
> -
> -#
> -# Compile librte_ip_frag
> -#
> -CONFIG_RTE_LIBRTE_IP_FRAG=y
> -CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
> -CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
> -CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
> -
> -#
> -# Compile librte_meter
> -#
> -CONFIG_RTE_LIBRTE_METER=y
> -
> -#
> -# Compile librte_sched
> -#
> -CONFIG_RTE_LIBRTE_SCHED=y
> -CONFIG_RTE_SCHED_DEBUG=n
> -CONFIG_RTE_SCHED_RED=n
> -CONFIG_RTE_SCHED_COLLECT_STATS=n
> -CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
> -CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
> -CONFIG_RTE_SCHED_VECTOR=n
> -
> -#
> -# Compile the distributor library
> -#
> -CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
> -
> -#
> -# Compile the reorder library
> -#
> -CONFIG_RTE_LIBRTE_REORDER=y
> -
> -#
> -# Compile librte_port
> -#
> -CONFIG_RTE_LIBRTE_PORT=y
> -CONFIG_RTE_PORT_STATS_COLLECT=n
> -
> -#
> -# Compile librte_table
> -#
> -CONFIG_RTE_LIBRTE_TABLE=y
> -CONFIG_RTE_TABLE_STATS_COLLECT=n
> -
> -#
> -# Compile librte_pipeline
> -#
> -CONFIG_RTE_LIBRTE_PIPELINE=y
> -CONFIG_RTE_PIPELINE_STATS_COLLECT=n
> -
> -#
> -# Enable warning directives
> -#
> -CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
> -
> -#
> -# Compile the test application
> -#
> -CONFIG_RTE_APP_TEST=y
> -
> -#
> -# Compile the PMD test application
> -#
> -CONFIG_RTE_TEST_PMD=y
> -CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
> -CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp index
> f1638db..64ddbe9 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -1,6 +1,6 @@
> # BSD LICENSE
> #
> -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> # All rights reserved.
> #
> # Redistribution and use in source and binary forms, with or without
> @@ -37,494 +37,9 @@
> CONFIG_RTE_EXEC_ENV="linuxapp"
> CONFIG_RTE_EXEC_ENV_LINUXAPP=y
>
> -##
> -## machine can define specific variables or action for a specific board -##
> RTE_MACHINE values are the directories in mk/machine/ -## -
> #CONFIG_RTE_MACHINE="native"
> -#
> -##
> -## define the architecture we compile for.
> -## RTE_ARCH values are the directories in mk/arch/ -## -
> #CONFIG_RTE_ARCH="x86_64"
> -#CONFIG_RTE_ARCH_X86_64=y
> -#CONFIG_RTE_ARCH_X86=y
> -#
> -##
> -## The compiler we use.
> -## RTE_TOOLCHAIN values are the directories in mk/toolchain/ -## -
> #CONFIG_RTE_TOOLCHAIN="gcc"
> -#CONFIG_RTE_TOOLCHAIN_GCC=y
> -
> -#
> -# Use intrinsics or assembly code for key routines -# -
> CONFIG_RTE_FORCE_INTRINSICS=n
> -
> -#
> -# Machine forces strict alignment constraints.
> -#
> -CONFIG_RTE_ARCH_STRICT_ALIGN=n
> -
> -#
> -# Compile to share library
> -#
> -CONFIG_RTE_BUILD_SHARED_LIB=n
> -
> -#
> -# Combine to one single library
> -#
> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
> -
> -#
> -# Use newest code breaking previous ABI -# -CONFIG_RTE_NEXT_ABI=y
> -
> -#
> -# Machine's cache line size
> -#
> -CONFIG_RTE_CACHE_LINE_SIZE=64
> -
> -#
> -# Compile Environment Abstraction Layer -# -CONFIG_RTE_LIBRTE_EAL=y
> -CONFIG_RTE_MAX_LCORE=128
> -CONFIG_RTE_MAX_NUMA_NODES=8
> -CONFIG_RTE_MAX_MEMSEG=256
> -CONFIG_RTE_MAX_MEMZONE=2560
> -CONFIG_RTE_MAX_TAILQ=32
> -CONFIG_RTE_LOG_LEVEL=8
> -CONFIG_RTE_LOG_HISTORY=256
> -CONFIG_RTE_LIBEAL_USE_HPET=n
> -CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
> -CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
> -CONFIG_RTE_EAL_IGB_UIO=y
> -CONFIG_RTE_EAL_VFIO=y
> -CONFIG_RTE_MALLOC_DEBUG=n
> -# Default driver path (or "" to disable) -CONFIG_RTE_EAL_PMD_PATH=""
> -
> -#
> -# Special configurations in PCI Config Space for high performance -# -
> CONFIG_RTE_PCI_CONFIG=n -CONFIG_RTE_PCI_EXTENDED_TAG=""
> -CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
> +#include "common_base"
>
> #
> -# Compile Environment Abstraction Layer for linux
> +# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
> #
> CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y
> -
> -#
> -# Compile Environment Abstraction Layer to support Vmware TSC map -# -
> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
> -
> -#
> -# Compile the argument parser library
> -#
> -CONFIG_RTE_LIBRTE_KVARGS=y
> -
> -#
> -# Compile generic ethernet library
> -#
> -CONFIG_RTE_LIBRTE_ETHER=y
> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
> -CONFIG_RTE_MAX_ETHPORTS=32
> -CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
> -CONFIG_RTE_LIBRTE_IEEE1588=n
> -CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
> -CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
> -
> -#
> -# Support NIC bypass logic
> -#
> -CONFIG_RTE_NIC_BYPASS=n
> -
> -#
> -# Compile burst-oriented IGB & EM PMD drivers -# -
> CONFIG_RTE_LIBRTE_EM_PMD=y -CONFIG_RTE_LIBRTE_IGB_PMD=y -
> CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
> -
> -#
> -# Compile burst-oriented IXGBE PMD driver -# -
> CONFIG_RTE_LIBRTE_IXGBE_PMD=y -
> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
> -CONFIG_RTE_IXGBE_INC_VECTOR=y
> -CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
> -
> -#
> -# Compile burst-oriented I40E PMD driver -# -
> CONFIG_RTE_LIBRTE_I40E_PMD=y -CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
> -CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
> -CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
> -CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
> -# interval up to 8160 us, aligned to 2 (or default value)
> -CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
> -
> -#
> -# Compile burst-oriented FM10K PMD
> -#
> -CONFIG_RTE_LIBRTE_FM10K_PMD=y
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> -CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> -
> -#
> -# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD -# -
> CONFIG_RTE_LIBRTE_MLX4_PMD=n -CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
> -CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
> -CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
> -CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
> -CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> -
> -#
> -# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD -# -
> CONFIG_RTE_LIBRTE_MLX5_PMD=n -CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
> -CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
> -CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
> -CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
> -
> -#
> -# Compile burst-oriented Broadcom PMD driver -# -
> CONFIG_RTE_LIBRTE_BNX2X_PMD=n -CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n -
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
> -CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
> -
> -#
> -# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD -# -
> CONFIG_RTE_LIBRTE_CXGBE_PMD=y -CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n -
> CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
> -
> -#
> -# Compile burst-oriented Cisco ENIC PMD driver -# -
> CONFIG_RTE_LIBRTE_ENIC_PMD=y -CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
> -
> -#
> -# Compile burst-oriented Netronome NFP PMD driver -# -
> CONFIG_RTE_LIBRTE_NFP_PMD=n -CONFIG_RTE_LIBRTE_NFP_DEBUG=n
> -
> -#
> -# Compile software PMD backed by SZEDATA2 device -# -
> CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
> -
> -#
> -# Compile burst-oriented VIRTIO PMD driver -# -
> CONFIG_RTE_LIBRTE_VIRTIO_PMD=y -
> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
> -CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
> -
> -#
> -# Compile burst-oriented VMXNET3 PMD driver -# -
> CONFIG_RTE_LIBRTE_VMXNET3_PMD=y -
> CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
> -CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
> -
> -#
> -# Compile example software rings based PMD -# -
> CONFIG_RTE_LIBRTE_PMD_RING=y
> -CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
> -CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
> -
> -#
> -# Compile software PMD backed by PCAP files -# -
> CONFIG_RTE_LIBRTE_PMD_PCAP=n
> -
> -#
> -# Compile link bonding PMD library
> -#
> -CONFIG_RTE_LIBRTE_PMD_BOND=y
> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
> -CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
> -
> -#
> -# Compile software PMD backed by AF_PACKET sockets (Linux only) -# -
> CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
> -
> -#
> -# Compile Xen PMD
> -#
> -CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
> -
> -#
> -# Compile null PMD
> -#
> -CONFIG_RTE_LIBRTE_PMD_NULL=y
> -
> -#
> -# Do prefetch of packet data within PMD driver receive function -# -
> CONFIG_RTE_PMD_PACKET_PREFETCH=y
> -
> -#
> -# Compile generic crypto device library -# EXPERIMENTAL: API may change
> without prior notice -# -CONFIG_RTE_LIBRTE_CRYPTODEV=y -
> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> -CONFIG_RTE_CRYPTO_MAX_DEVS=64
> -CONFIG_RTE_CRYPTODEV_NAME_LEN=64
> -
> -#
> -# Compile PMD for QuickAssist based devices -# -
> CONFIG_RTE_LIBRTE_PMD_QAT=n -
> CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
> -CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
> -CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
> -CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
> -#
> -# Number of sessions to create in the session memory pool -# on a single
> QuickAssist device.
> -#
> -CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
> -
> -#
> -# Compile PMD for AESNI backed device
> -#
> -CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
> -CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
> -CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
> -CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
> -
> -#
> -# Compile librte_ring
> -#
> -CONFIG_RTE_LIBRTE_RING=y
> -CONFIG_RTE_LIBRTE_RING_DEBUG=n
> -CONFIG_RTE_RING_SPLIT_PROD_CONS=n
> -CONFIG_RTE_RING_PAUSE_REP_COUNT=0
> -
> -#
> -# Compile librte_mempool
> -#
> -CONFIG_RTE_LIBRTE_MEMPOOL=y
> -CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
> -CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
> -
> -#
> -# Compile librte_mbuf
> -#
> -CONFIG_RTE_LIBRTE_MBUF=y
> -CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
> -CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
> -CONFIG_RTE_PKTMBUF_HEADROOM=128
> -
> -#
> -# Compile librte_mbuf_offload
> -# EXPERIMENTAL: API may change without prior notice -# -
> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y -
> CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
> -
> -#
> -# Compile librte_timer
> -#
> -CONFIG_RTE_LIBRTE_TIMER=y
> -CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
> -
> -#
> -# Compile librte_cfgfile
> -#
> -CONFIG_RTE_LIBRTE_CFGFILE=y
> -
> -#
> -# Compile librte_cmdline
> -#
> -CONFIG_RTE_LIBRTE_CMDLINE=y
> -CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
> -
> -#
> -# Compile librte_hash
> -#
> -CONFIG_RTE_LIBRTE_HASH=y
> -CONFIG_RTE_LIBRTE_HASH_DEBUG=n
> -
> -#
> -# Compile librte_jobstats
> -#
> -CONFIG_RTE_LIBRTE_JOBSTATS=y
> -
> -#
> -# Compile librte_lpm
> -#
> -CONFIG_RTE_LIBRTE_LPM=y
> -CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> -
> -#
> -# Compile librte_acl
> -#
> -CONFIG_RTE_LIBRTE_ACL=y
> -CONFIG_RTE_LIBRTE_ACL_DEBUG=n
> -
> -#
> -# Compile librte_power
> -#
> -CONFIG_RTE_LIBRTE_POWER=y
> -CONFIG_RTE_LIBRTE_POWER_DEBUG=n
> -CONFIG_RTE_MAX_LCORE_FREQS=64
> -
> -#
> -# Compile librte_net
> -#
> -CONFIG_RTE_LIBRTE_NET=y
> -
> -#
> -# Compile librte_ip_frag
> -#
> -CONFIG_RTE_LIBRTE_IP_FRAG=y
> -CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
> -CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
> -CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
> -
> -#
> -# Compile librte_meter
> -#
> -CONFIG_RTE_LIBRTE_METER=y
> -
> -#
> -# Compile librte_sched
> -#
> -CONFIG_RTE_LIBRTE_SCHED=y
> -CONFIG_RTE_SCHED_DEBUG=n
> -CONFIG_RTE_SCHED_RED=n
> -CONFIG_RTE_SCHED_COLLECT_STATS=n
> -CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
> -CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
> -CONFIG_RTE_SCHED_VECTOR=n
> -
> -#
> -# Compile the distributor library
> -#
> -CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
> -
> -#
> -# Compile the reorder library
> -#
> -CONFIG_RTE_LIBRTE_REORDER=y
> -
> -#
> -# Compile librte_port
> -#
> -CONFIG_RTE_LIBRTE_PORT=y
> -CONFIG_RTE_PORT_STATS_COLLECT=n
> -
> -#
> -# Compile librte_table
> -#
> -CONFIG_RTE_LIBRTE_TABLE=y
> -CONFIG_RTE_TABLE_STATS_COLLECT=n
> -
> -#
> -# Compile librte_pipeline
> -#
> -CONFIG_RTE_LIBRTE_PIPELINE=y
> -CONFIG_RTE_PIPELINE_STATS_COLLECT=n
> -
> -#
> -# Compile librte_kni
> -#
> -CONFIG_RTE_LIBRTE_KNI=y
> -CONFIG_RTE_KNI_KMOD=y
> -CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
> -CONFIG_RTE_KNI_KO_DEBUG=n
> -CONFIG_RTE_KNI_VHOST=n
> -CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
> -CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
> -CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
> -CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
> -
> -#
> -# Compile vhost library
> -# fuse-devel is needed to run vhost-cuse.
> -# fuse-devel enables user space char driver development -# vhost-user is turned
> on by default.
> -#
> -CONFIG_RTE_LIBRTE_VHOST=y
> -CONFIG_RTE_LIBRTE_VHOST_USER=y
> -CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> -CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
> -
> -#
> -#Compile Xen domain0 support
> -#
> -CONFIG_RTE_LIBRTE_XEN_DOM0=n
> -
> -#
> -# Enable warning directives
> -#
> -CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
> -
> -#
> -# Compile the test application
> -#
> -CONFIG_RTE_APP_TEST=y
> -
> -#
> -# Compile the PMD test application
> -#
> -CONFIG_RTE_TEST_PMD=y
> -CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
> -CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> diff --git a/config/defconfig_x86_64-native-bsdapp-clang
> b/config/defconfig_x86_64-native-bsdapp-clang
> index d2baf2c..8b870b3 100644
> --- a/config/defconfig_x86_64-native-bsdapp-clang
> +++ b/config/defconfig_x86_64-native-bsdapp-clang
> @@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
> CONFIG_RTE_ARCH="x86_64"
> CONFIG_RTE_ARCH_X86_64=y
> CONFIG_RTE_ARCH_X86=y
> +CONFIG_RTE_ARCH_64=y
>
> CONFIG_RTE_TOOLCHAIN="clang"
> CONFIG_RTE_TOOLCHAIN_CLANG=y
> diff --git a/config/defconfig_x86_64-native-bsdapp-gcc
> b/config/defconfig_x86_64-native-bsdapp-gcc
> index 5a6a4e8..4ea4433 100644
> --- a/config/defconfig_x86_64-native-bsdapp-gcc
> +++ b/config/defconfig_x86_64-native-bsdapp-gcc
> @@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
> CONFIG_RTE_ARCH="x86_64"
> CONFIG_RTE_ARCH_X86_64=y
> CONFIG_RTE_ARCH_X86=y
> +CONFIG_RTE_ARCH_64=y
>
> CONFIG_RTE_TOOLCHAIN="gcc"
> CONFIG_RTE_TOOLCHAIN_GCC=y
> --
> 2.7.0
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
2016-02-03 17:23 0% ` Olivier MATZ
@ 2016-02-22 14:49 0% ` Xie, Huawei
2016-02-23 5:35 0% ` Xie, Huawei
0 siblings, 1 reply; 200+ results
From: Xie, Huawei @ 2016-02-22 14:49 UTC (permalink / raw)
To: Olivier MATZ, Panu Matilainen, dev; +Cc: dprovan
On 2/4/2016 1:24 AM, Olivier MATZ wrote:
> Hi,
>
> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>>
>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
>> the library ABI and should not be listed in the version map.
>>
>> I assume its inline for performance reasons, but then you lose the
>> benefits of dynamic linking such as ability to fix bugs and/or improve
>> itby just updating the library. Since the point of having a bulk API is
>> to improve performance by reducing the number of calls required, does it
>> really have to be inline? As in, have you actually measured the
>> difference between inline and non-inline and decided its worth all the
>> downsides?
>
> Agree with Panu. It would be interesting to compare the performance
> between inline and non inline to decide whether inlining it or not.
Will update after i gathered more data. inline could show obvious
performance difference in some cases.
>
> Also, it would be nice to have a simple test function in
> app/test/test_mbuf.c. For instance, you could update
> test_one_pktmbuf() to take a mbuf pointer as a parameter and remove
> the mbuf allocation from the function. Then it could be called with
> a mbuf allocated with rte_pktmbuf_alloc() (like before) and with
> all the mbufs of rte_pktmbuf_alloc_bulk().
>
> Regards,
> Olivier
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] config: remove duplicate configuration information
@ 2016-02-22 13:53 6% Keith Wiles
2016-02-22 15:09 0% ` Trahe, Fiona
2016-02-24 13:58 0% ` Wiles, Keith
0 siblings, 2 replies; 200+ results
From: Keith Wiles @ 2016-02-22 13:53 UTC (permalink / raw)
To: dev
In order to cleanup the configuration files some and reduce
the number of duplicate configuration information. Add a new
file called common_base which contains just about all of the
configuration lines in one place. Then have the common_bsdapp,
common_linuxapp files include this one file. Then in those OS
specific files add the delta configuration lines.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
config/common_base | 498 ++++++++++++++++++++++++++++
config/common_bsdapp | 436 +-----------------------
config/common_linuxapp | 491 +--------------------------
config/defconfig_x86_64-native-bsdapp-clang | 1 +
config/defconfig_x86_64-native-bsdapp-gcc | 1 +
5 files changed, 518 insertions(+), 909 deletions(-)
create mode 100644 config/common_base
diff --git a/config/common_base b/config/common_base
new file mode 100644
index 0000000..91a12eb
--- /dev/null
+++ b/config/common_base
@@ -0,0 +1,498 @@
+# BSD LICENSE
+#
+# Copyright(c) 2010-2016 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.
+#
+
+#
+# Use intrinsics or assembly code for key routines
+#
+CONFIG_RTE_FORCE_INTRINSICS=n
+
+#
+# Machine forces strict alignment constraints.
+#
+CONFIG_RTE_ARCH_STRICT_ALIGN=n
+
+#
+# Compile to share library
+#
+CONFIG_RTE_BUILD_SHARED_LIB=n
+
+#
+# Combine to one single library
+#
+CONFIG_RTE_BUILD_COMBINE_LIBS=n
+
+#
+# Use newest code breaking previous ABI
+#
+CONFIG_RTE_NEXT_ABI=y
+
+#
+# Machine's cache line size
+#
+CONFIG_RTE_CACHE_LINE_SIZE=64
+
+#
+# Compile Environment Abstraction Layer
+#
+CONFIG_RTE_LIBRTE_EAL=y
+CONFIG_RTE_MAX_LCORE=128
+CONFIG_RTE_MAX_NUMA_NODES=8
+CONFIG_RTE_MAX_MEMSEG=256
+CONFIG_RTE_MAX_MEMZONE=2560
+CONFIG_RTE_MAX_TAILQ=32
+CONFIG_RTE_LOG_LEVEL=8
+CONFIG_RTE_LOG_HISTORY=256
+CONFIG_RTE_LIBEAL_USE_HPET=n
+CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
+CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
+CONFIG_RTE_EAL_IGB_UIO=y
+CONFIG_RTE_EAL_VFIO=y
+CONFIG_RTE_MALLOC_DEBUG=n
+
+# Default driver path (or "" to disable)
+CONFIG_RTE_EAL_PMD_PATH=""
+
+#
+# Special configurations in PCI Config Space for high performance
+#
+CONFIG_RTE_PCI_CONFIG=n
+CONFIG_RTE_PCI_EXTENDED_TAG=""
+CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
+
+#
+# Compile Environment Abstraction Layer to support Vmware TSC map
+#
+CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
+
+#
+# Compile the argument parser library
+#
+CONFIG_RTE_LIBRTE_KVARGS=y
+
+#
+# Compile generic ethernet library
+#
+CONFIG_RTE_LIBRTE_ETHER=y
+CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
+CONFIG_RTE_MAX_ETHPORTS=32
+CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
+CONFIG_RTE_LIBRTE_IEEE1588=n
+CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
+CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
+
+#
+# Support NIC bypass logic
+#
+CONFIG_RTE_NIC_BYPASS=n
+
+#
+# Compile burst-oriented IGB & EM PMD drivers
+#
+CONFIG_RTE_LIBRTE_EM_PMD=y
+CONFIG_RTE_LIBRTE_IGB_PMD=y
+CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
+CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
+
+#
+# Compile burst-oriented IXGBE PMD driver
+#
+CONFIG_RTE_LIBRTE_IXGBE_PMD=y
+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
+CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
+CONFIG_RTE_IXGBE_INC_VECTOR=y
+CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
+
+#
+# Compile burst-oriented I40E PMD driver
+#
+CONFIG_RTE_LIBRTE_I40E_PMD=y
+CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
+CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
+CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
+CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
+CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
+# interval up to 8160 us, aligned to 2 (or default value)
+CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
+
+#
+# Compile burst-oriented FM10K PMD
+#
+CONFIG_RTE_LIBRTE_FM10K_PMD=y
+CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
+CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
+CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
+
+#
+# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
+#
+CONFIG_RTE_LIBRTE_MLX4_PMD=n
+CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
+CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
+CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
+CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
+CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
+
+#
+# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
+#
+CONFIG_RTE_LIBRTE_MLX5_PMD=n
+CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
+CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
+CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
+CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
+
+#
+# Compile burst-oriented Broadcom PMD driver
+#
+CONFIG_RTE_LIBRTE_BNX2X_PMD=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
+
+#
+# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
+#
+CONFIG_RTE_LIBRTE_CXGBE_PMD=y
+CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
+
+#
+# Compile burst-oriented Cisco ENIC PMD driver
+#
+CONFIG_RTE_LIBRTE_ENIC_PMD=y
+CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
+
+#
+# Compile burst-oriented Netronome NFP PMD driver
+#
+CONFIG_RTE_LIBRTE_NFP_PMD=n
+CONFIG_RTE_LIBRTE_NFP_DEBUG=n
+
+#
+# Compile software PMD backed by SZEDATA2 device
+#
+CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
+
+#
+# Compile burst-oriented VIRTIO PMD driver
+#
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
+
+#
+# Compile burst-oriented VMXNET3 PMD driver
+#
+CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
+CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
+
+#
+# Compile example software rings based PMD
+#
+CONFIG_RTE_LIBRTE_PMD_RING=y
+CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
+CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
+
+#
+# Compile software PMD backed by PCAP files
+#
+CONFIG_RTE_LIBRTE_PMD_PCAP=n
+
+#
+# Compile link bonding PMD library
+#
+CONFIG_RTE_LIBRTE_PMD_BOND=y
+CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
+CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
+
+#
+# Compile software PMD backed by AF_PACKET sockets (Linux only)
+#
+CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
+
+#
+# Compile Xen PMD
+#
+CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
+
+#
+# Compile null PMD
+#
+CONFIG_RTE_LIBRTE_PMD_NULL=y
+
+#
+# Do prefetch of packet data within PMD driver receive function
+#
+CONFIG_RTE_PMD_PACKET_PREFETCH=y
+
+#
+# Compile generic crypto device library
+# EXPERIMENTAL: API may change without prior notice
+#
+CONFIG_RTE_LIBRTE_CRYPTODEV=y
+CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
+CONFIG_RTE_CRYPTO_MAX_DEVS=64
+CONFIG_RTE_CRYPTODEV_NAME_LEN=64
+
+#
+# Compile PMD for QuickAssist based devices
+#
+CONFIG_RTE_LIBRTE_PMD_QAT=n
+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
+#
+# Number of sessions to create in the session memory pool
+# on a single QuickAssist device.
+#
+CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
+
+#
+# Compile PMD for AESNI backed device
+#
+CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
+CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
+CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
+CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
+
+#
+# Compile librte_ring
+#
+CONFIG_RTE_LIBRTE_RING=y
+CONFIG_RTE_LIBRTE_RING_DEBUG=n
+CONFIG_RTE_RING_SPLIT_PROD_CONS=n
+CONFIG_RTE_RING_PAUSE_REP_COUNT=0
+
+#
+# Compile librte_mempool
+#
+CONFIG_RTE_LIBRTE_MEMPOOL=y
+CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
+CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
+
+#
+# Compile librte_mbuf
+#
+CONFIG_RTE_LIBRTE_MBUF=y
+CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
+CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
+CONFIG_RTE_PKTMBUF_HEADROOM=128
+
+#
+# Compile librte_mbuf_offload
+# EXPERIMENTAL: API may change without prior notice
+#
+CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
+CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
+
+#
+# Compile librte_timer
+#
+CONFIG_RTE_LIBRTE_TIMER=y
+CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
+
+#
+# Compile librte_cfgfile
+#
+CONFIG_RTE_LIBRTE_CFGFILE=y
+
+#
+# Compile librte_cmdline
+#
+CONFIG_RTE_LIBRTE_CMDLINE=y
+CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
+
+#
+# Compile librte_hash
+#
+CONFIG_RTE_LIBRTE_HASH=y
+CONFIG_RTE_LIBRTE_HASH_DEBUG=n
+
+#
+# Compile librte_jobstats
+#
+CONFIG_RTE_LIBRTE_JOBSTATS=y
+
+#
+# Compile librte_lpm
+#
+CONFIG_RTE_LIBRTE_LPM=y
+CONFIG_RTE_LIBRTE_LPM_DEBUG=n
+
+#
+# Compile librte_acl
+#
+CONFIG_RTE_LIBRTE_ACL=y
+CONFIG_RTE_LIBRTE_ACL_DEBUG=n
+
+#
+# Compile librte_power
+#
+CONFIG_RTE_LIBRTE_POWER=y
+CONFIG_RTE_LIBRTE_POWER_DEBUG=n
+CONFIG_RTE_MAX_LCORE_FREQS=64
+
+#
+# Compile librte_net
+#
+CONFIG_RTE_LIBRTE_NET=y
+
+#
+# Compile librte_ip_frag
+#
+CONFIG_RTE_LIBRTE_IP_FRAG=y
+CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
+CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
+CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
+
+#
+# Compile librte_meter
+#
+CONFIG_RTE_LIBRTE_METER=y
+
+#
+# Compile librte_sched
+#
+CONFIG_RTE_LIBRTE_SCHED=y
+CONFIG_RTE_SCHED_DEBUG=n
+CONFIG_RTE_SCHED_RED=n
+CONFIG_RTE_SCHED_COLLECT_STATS=n
+CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
+CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
+CONFIG_RTE_SCHED_VECTOR=n
+
+#
+# Compile the distributor library
+#
+CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
+
+#
+# Compile the reorder library
+#
+CONFIG_RTE_LIBRTE_REORDER=y
+
+#
+# Compile librte_port
+#
+CONFIG_RTE_LIBRTE_PORT=y
+CONFIG_RTE_PORT_STATS_COLLECT=n
+
+#
+# Compile librte_table
+#
+CONFIG_RTE_LIBRTE_TABLE=y
+CONFIG_RTE_TABLE_STATS_COLLECT=n
+
+#
+# Compile librte_pipeline
+#
+CONFIG_RTE_LIBRTE_PIPELINE=y
+CONFIG_RTE_PIPELINE_STATS_COLLECT=n
+
+#
+# Compile librte_kni
+#
+CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_KNI_KMOD=y
+CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
+CONFIG_RTE_KNI_KO_DEBUG=n
+CONFIG_RTE_KNI_VHOST=n
+CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
+CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
+CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
+CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
+
+#
+# Compile vhost library
+# fuse-devel is needed to run vhost-cuse.
+# fuse-devel enables user space char driver development
+# vhost-user is turned on by default.
+#
+CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_VHOST_USER=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
+CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
+
+#
+#Compile Xen domain0 support
+#
+CONFIG_RTE_LIBRTE_XEN_DOM0=n
+
+#
+# Enable warning directives
+#
+CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
+
+#
+# Compile the test application
+#
+CONFIG_RTE_APP_TEST=y
+
+#
+# Compile the PMD test application
+#
+CONFIG_RTE_TEST_PMD=y
+CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
+CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 696382c..de0ca7d 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -37,74 +37,38 @@
CONFIG_RTE_EXEC_ENV="bsdapp"
CONFIG_RTE_EXEC_ENV_BSDAPP=y
-##
-## machine can define specific variables or action for a specific board
-## RTE_MACHINE values are the directories in mk/machine/
-##
-#CONFIG_RTE_MACHINE="native"
-#
-##
-## define the architecture we compile for.
-## RTE_ARCH values are the directories in mk/arch/
-##
-#CONFIG_RTE_ARCH="x86_64"
-#CONFIG_RTE_ARCH_X86_64=y
-#CONFIG_RTE_ARCH_X86=y
-#
-##
-## The compiler we use.
-## RTE_TOOLCHAIN values are the directories in mk/toolchain/
-##
-#CONFIG_RTE_TOOLCHAIN="gcc"
-#CONFIG_RTE_TOOLCHAIN_GCC=y
-
-#
-# Use intrinsics or assembly code for key routines
-#
-CONFIG_RTE_FORCE_INTRINSICS=n
+#include "common_base"
#
-# Machine forces strict alignment constraints.
+# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
#
-CONFIG_RTE_ARCH_STRICT_ALIGN=n
+CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
#
-# Compile to share library
+# Compile Environment Abstraction Layer
#
-CONFIG_RTE_BUILD_SHARED_LIB=n
+CONFIG_RTE_EAL_IGB_UIO=n
+CONFIG_RTE_EAL_VFIO=n
#
-# Combine to one single library
+# Compile software PMD backed by AF_PACKET sockets (Linux only)
#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
+CONFIG_RTE_LIBRTE_PMD_AF_PACKET=n
#
-# Use newest code breaking previous ABI
+# Compile librte_power
#
-CONFIG_RTE_NEXT_ABI=y
+CONFIG_RTE_LIBRTE_POWER=n
#
-# Machine's cache line size
+# Compile librte_kni
#
-CONFIG_RTE_CACHE_LINE_SIZE=64
+CONFIG_RTE_LIBRTE_KNI=n
#
-# Compile Environment Abstraction Layer
+# Compile vhost library
#
-CONFIG_RTE_LIBRTE_EAL=y
-CONFIG_RTE_MAX_LCORE=128
-CONFIG_RTE_MAX_NUMA_NODES=8
-CONFIG_RTE_MAX_MEMSEG=256
-CONFIG_RTE_MAX_MEMZONE=2560
-CONFIG_RTE_MAX_TAILQ=32
-CONFIG_RTE_LOG_LEVEL=8
-CONFIG_RTE_LOG_HISTORY=256
-CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
-CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
-CONFIG_RTE_MALLOC_DEBUG=n
-
-# Default driver path (or "" to disable)
-CONFIG_RTE_EAL_PMD_PATH=""
+CONFIG_RTE_LIBRTE_VHOST=n
#
# FreeBSD contiguous memory driver settings
@@ -113,373 +77,3 @@ CONFIG_RTE_CONTIGMEM_MAX_NUM_BUFS=64
CONFIG_RTE_CONTIGMEM_DEFAULT_NUM_BUFS=2
CONFIG_RTE_CONTIGMEM_DEFAULT_BUF_SIZE=1024*1024*1024
-#
-# Compile Environment Abstraction Layer for BSD
-#
-CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
-
-#
-# Compile Environment Abstraction Layer for linux
-#
-CONFIG_RTE_LIBRTE_EAL_LINUXAPP=n
-
-#
-# Compile Environment Abstraction Layer to support Vmware TSC map
-#
-CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
-
-#
-# Compile the argument parser library
-#
-CONFIG_RTE_LIBRTE_KVARGS=y
-
-#
-# Compile generic ethernet library
-#
-CONFIG_RTE_LIBRTE_ETHER=y
-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
-CONFIG_RTE_MAX_ETHPORTS=32
-CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
-CONFIG_RTE_LIBRTE_IEEE1588=n
-CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
-CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
-
-#
-# Support NIC bypass logic
-#
-CONFIG_RTE_NIC_BYPASS=n
-
-#
-# Compile burst-oriented IGB & EM PMD drivers
-#
-CONFIG_RTE_LIBRTE_EM_PMD=y
-CONFIG_RTE_LIBRTE_IGB_PMD=y
-CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
-
-#
-# Compile burst-oriented IXGBE PMD driver
-#
-CONFIG_RTE_LIBRTE_IXGBE_PMD=y
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
-CONFIG_RTE_IXGBE_INC_VECTOR=y
-CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
-
-#
-# Compile burst-oriented I40E PMD driver
-#
-CONFIG_RTE_LIBRTE_I40E_PMD=y
-CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
-CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
-CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
-# interval up to 8160 us, aligned to 2 (or default value)
-CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
-
-#
-# Compile burst-oriented FM10K PMD
-#
-CONFIG_RTE_LIBRTE_FM10K_PMD=y
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
-
-#
-# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
-#
-CONFIG_RTE_LIBRTE_MLX4_PMD=n
-CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
-CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
-CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
-CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
-CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
-
-#
-# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
-#
-CONFIG_RTE_LIBRTE_MLX5_PMD=n
-CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
-CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
-CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
-CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
-
-#
-# Compile burst-oriented Broadcom PMD driver
-#
-CONFIG_RTE_LIBRTE_BNX2X_PMD=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
-
-#
-# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
-#
-CONFIG_RTE_LIBRTE_CXGBE_PMD=y
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
-
-#
-# Compile burst-oriented Cisco ENIC PMD driver
-#
-CONFIG_RTE_LIBRTE_ENIC_PMD=y
-CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
-
-#
-# Compile software PMD backed by SZEDATA2 device
-#
-CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
-
-#
-# Compile burst-oriented VIRTIO PMD driver
-#
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
-
-#
-# Compile burst-oriented VMXNET3 PMD driver
-#
-CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
-
-#
-# Compile example software rings based PMD
-#
-CONFIG_RTE_LIBRTE_PMD_RING=y
-CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
-CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
-
-#
-# Compile software PMD backed by PCAP files
-#
-CONFIG_RTE_LIBRTE_PMD_PCAP=y
-
-#
-# Compile link bonding PMD library
-#
-CONFIG_RTE_LIBRTE_PMD_BOND=y
-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
-
-#
-# Compile null PMD
-#
-CONFIG_RTE_LIBRTE_PMD_NULL=y
-
-#
-# Do prefetch of packet data within PMD driver receive function
-#
-CONFIG_RTE_PMD_PACKET_PREFETCH=y
-
-#
-# Compile generic crypto device library
-# EXPERIMENTAL: API may change without prior notice
-#
-CONFIG_RTE_LIBRTE_CRYPTODEV=y
-CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
-CONFIG_RTE_CRYPTO_MAX_DEVS=64
-CONFIG_RTE_CRYPTODEV_NAME_LEN=64
-
-#
-# Compile PMD for QuickAssist based devices
-#
-CONFIG_RTE_LIBRTE_PMD_QAT=n
-CONFIG_RTE_LIBRTE_QAT_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_QAT_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_QAT_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_QAT_DEBUG_DRIVER=n
-#
-# Number of sessions to create in the session memory pool
-# on a single QuickAssist device.
-#
-CONFIG_RTE_MAX_QAT_SESSIONS=200
-
-#
-# Compile PMD for AESNI backed device
-#
-CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
-CONFIG_RTE_LIBRTE_AESNI_MB_DEBUG=n
-
-#
-# Compile librte_ring
-#
-CONFIG_RTE_LIBRTE_RING=y
-CONFIG_RTE_LIBRTE_RING_DEBUG=n
-CONFIG_RTE_RING_SPLIT_PROD_CONS=n
-CONFIG_RTE_RING_PAUSE_REP_COUNT=0
-
-#
-# Compile librte_mempool
-#
-CONFIG_RTE_LIBRTE_MEMPOOL=y
-CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
-CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
-
-#
-# Compile librte_mbuf
-#
-CONFIG_RTE_LIBRTE_MBUF=y
-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
-CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
-CONFIG_RTE_PKTMBUF_HEADROOM=128
-
-#
-# Compile librte_mbuf_offload
-# EXPERIMENTAL: API may change without prior notice
-#
-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
-
-#
-# Compile librte_timer
-#
-CONFIG_RTE_LIBRTE_TIMER=y
-CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
-
-#
-# Compile librte_cfgfile
-#
-CONFIG_RTE_LIBRTE_CFGFILE=y
-
-#
-# Compile librte_cmdline
-#
-CONFIG_RTE_LIBRTE_CMDLINE=y
-CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
-
-#
-# Compile librte_hash
-#
-CONFIG_RTE_LIBRTE_HASH=y
-CONFIG_RTE_LIBRTE_HASH_DEBUG=n
-
-#
-# Compile librte_jobstats
-#
-CONFIG_RTE_LIBRTE_JOBSTATS=y
-
-#
-# Compile librte_lpm
-#
-CONFIG_RTE_LIBRTE_LPM=y
-CONFIG_RTE_LIBRTE_LPM_DEBUG=n
-
-#
-# Compile librte_acl
-#
-CONFIG_RTE_LIBRTE_ACL=y
-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
-
-#
-# Compile librte_power
-#
-CONFIG_RTE_LIBRTE_POWER=n
-CONFIG_RTE_LIBRTE_POWER_DEBUG=n
-CONFIG_RTE_MAX_LCORE_FREQS=64
-
-#
-# Compile librte_net
-#
-CONFIG_RTE_LIBRTE_NET=y
-
-#
-# Compile librte_ip_frag
-#
-CONFIG_RTE_LIBRTE_IP_FRAG=y
-CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
-CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
-CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
-
-#
-# Compile librte_meter
-#
-CONFIG_RTE_LIBRTE_METER=y
-
-#
-# Compile librte_sched
-#
-CONFIG_RTE_LIBRTE_SCHED=y
-CONFIG_RTE_SCHED_DEBUG=n
-CONFIG_RTE_SCHED_RED=n
-CONFIG_RTE_SCHED_COLLECT_STATS=n
-CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
-CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
-CONFIG_RTE_SCHED_VECTOR=n
-
-#
-# Compile the distributor library
-#
-CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
-
-#
-# Compile the reorder library
-#
-CONFIG_RTE_LIBRTE_REORDER=y
-
-#
-# Compile librte_port
-#
-CONFIG_RTE_LIBRTE_PORT=y
-CONFIG_RTE_PORT_STATS_COLLECT=n
-
-#
-# Compile librte_table
-#
-CONFIG_RTE_LIBRTE_TABLE=y
-CONFIG_RTE_TABLE_STATS_COLLECT=n
-
-#
-# Compile librte_pipeline
-#
-CONFIG_RTE_LIBRTE_PIPELINE=y
-CONFIG_RTE_PIPELINE_STATS_COLLECT=n
-
-#
-# Enable warning directives
-#
-CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
-
-#
-# Compile the test application
-#
-CONFIG_RTE_APP_TEST=y
-
-#
-# Compile the PMD test application
-#
-CONFIG_RTE_TEST_PMD=y
-CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
-CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index f1638db..64ddbe9 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -37,494 +37,9 @@
CONFIG_RTE_EXEC_ENV="linuxapp"
CONFIG_RTE_EXEC_ENV_LINUXAPP=y
-##
-## machine can define specific variables or action for a specific board
-## RTE_MACHINE values are the directories in mk/machine/
-##
-#CONFIG_RTE_MACHINE="native"
-#
-##
-## define the architecture we compile for.
-## RTE_ARCH values are the directories in mk/arch/
-##
-#CONFIG_RTE_ARCH="x86_64"
-#CONFIG_RTE_ARCH_X86_64=y
-#CONFIG_RTE_ARCH_X86=y
-#
-##
-## The compiler we use.
-## RTE_TOOLCHAIN values are the directories in mk/toolchain/
-##
-#CONFIG_RTE_TOOLCHAIN="gcc"
-#CONFIG_RTE_TOOLCHAIN_GCC=y
-
-#
-# Use intrinsics or assembly code for key routines
-#
-CONFIG_RTE_FORCE_INTRINSICS=n
-
-#
-# Machine forces strict alignment constraints.
-#
-CONFIG_RTE_ARCH_STRICT_ALIGN=n
-
-#
-# Compile to share library
-#
-CONFIG_RTE_BUILD_SHARED_LIB=n
-
-#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
-# Use newest code breaking previous ABI
-#
-CONFIG_RTE_NEXT_ABI=y
-
-#
-# Machine's cache line size
-#
-CONFIG_RTE_CACHE_LINE_SIZE=64
-
-#
-# Compile Environment Abstraction Layer
-#
-CONFIG_RTE_LIBRTE_EAL=y
-CONFIG_RTE_MAX_LCORE=128
-CONFIG_RTE_MAX_NUMA_NODES=8
-CONFIG_RTE_MAX_MEMSEG=256
-CONFIG_RTE_MAX_MEMZONE=2560
-CONFIG_RTE_MAX_TAILQ=32
-CONFIG_RTE_LOG_LEVEL=8
-CONFIG_RTE_LOG_HISTORY=256
-CONFIG_RTE_LIBEAL_USE_HPET=n
-CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
-CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
-CONFIG_RTE_EAL_IGB_UIO=y
-CONFIG_RTE_EAL_VFIO=y
-CONFIG_RTE_MALLOC_DEBUG=n
-# Default driver path (or "" to disable)
-CONFIG_RTE_EAL_PMD_PATH=""
-
-#
-# Special configurations in PCI Config Space for high performance
-#
-CONFIG_RTE_PCI_CONFIG=n
-CONFIG_RTE_PCI_EXTENDED_TAG=""
-CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
+#include "common_base"
#
-# Compile Environment Abstraction Layer for linux
+# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ...
#
CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y
-
-#
-# Compile Environment Abstraction Layer to support Vmware TSC map
-#
-CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
-
-#
-# Compile the argument parser library
-#
-CONFIG_RTE_LIBRTE_KVARGS=y
-
-#
-# Compile generic ethernet library
-#
-CONFIG_RTE_LIBRTE_ETHER=y
-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
-CONFIG_RTE_MAX_ETHPORTS=32
-CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
-CONFIG_RTE_LIBRTE_IEEE1588=n
-CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
-CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
-
-#
-# Support NIC bypass logic
-#
-CONFIG_RTE_NIC_BYPASS=n
-
-#
-# Compile burst-oriented IGB & EM PMD drivers
-#
-CONFIG_RTE_LIBRTE_EM_PMD=y
-CONFIG_RTE_LIBRTE_IGB_PMD=y
-CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n
-
-#
-# Compile burst-oriented IXGBE PMD driver
-#
-CONFIG_RTE_LIBRTE_IXGBE_PMD=y
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
-CONFIG_RTE_IXGBE_INC_VECTOR=y
-CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
-
-#
-# Compile burst-oriented I40E PMD driver
-#
-CONFIG_RTE_LIBRTE_I40E_PMD=y
-CONFIG_RTE_LIBRTE_I40E_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
-CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
-CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
-# interval up to 8160 us, aligned to 2 (or default value)
-CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
-
-#
-# Compile burst-oriented FM10K PMD
-#
-CONFIG_RTE_LIBRTE_FM10K_PMD=y
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
-CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
-
-#
-# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
-#
-CONFIG_RTE_LIBRTE_MLX4_PMD=n
-CONFIG_RTE_LIBRTE_MLX4_DEBUG=n
-CONFIG_RTE_LIBRTE_MLX4_SGE_WR_N=4
-CONFIG_RTE_LIBRTE_MLX4_MAX_INLINE=0
-CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
-CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
-
-#
-# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
-#
-CONFIG_RTE_LIBRTE_MLX5_PMD=n
-CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
-CONFIG_RTE_LIBRTE_MLX5_SGE_WR_N=4
-CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE=0
-CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
-
-#
-# Compile burst-oriented Broadcom PMD driver
-#
-CONFIG_RTE_LIBRTE_BNX2X_PMD=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
-CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
-
-#
-# Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
-#
-CONFIG_RTE_LIBRTE_CXGBE_PMD=y
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_REG=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_MBOX=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_CXGBE_DEBUG_RX=n
-
-#
-# Compile burst-oriented Cisco ENIC PMD driver
-#
-CONFIG_RTE_LIBRTE_ENIC_PMD=y
-CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
-
-#
-# Compile burst-oriented Netronome NFP PMD driver
-#
-CONFIG_RTE_LIBRTE_NFP_PMD=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG=n
-
-#
-# Compile software PMD backed by SZEDATA2 device
-#
-CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
-
-#
-# Compile burst-oriented VIRTIO PMD driver
-#
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
-
-#
-# Compile burst-oriented VMXNET3 PMD driver
-#
-CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n
-
-#
-# Compile example software rings based PMD
-#
-CONFIG_RTE_LIBRTE_PMD_RING=y
-CONFIG_RTE_PMD_RING_MAX_RX_RINGS=16
-CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
-
-#
-# Compile software PMD backed by PCAP files
-#
-CONFIG_RTE_LIBRTE_PMD_PCAP=n
-
-#
-# Compile link bonding PMD library
-#
-CONFIG_RTE_LIBRTE_PMD_BOND=y
-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
-CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
-
-#
-# Compile software PMD backed by AF_PACKET sockets (Linux only)
-#
-CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
-
-#
-# Compile Xen PMD
-#
-CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
-
-#
-# Compile null PMD
-#
-CONFIG_RTE_LIBRTE_PMD_NULL=y
-
-#
-# Do prefetch of packet data within PMD driver receive function
-#
-CONFIG_RTE_PMD_PACKET_PREFETCH=y
-
-#
-# Compile generic crypto device library
-# EXPERIMENTAL: API may change without prior notice
-#
-CONFIG_RTE_LIBRTE_CRYPTODEV=y
-CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
-CONFIG_RTE_CRYPTO_MAX_DEVS=64
-CONFIG_RTE_CRYPTODEV_NAME_LEN=64
-
-#
-# Compile PMD for QuickAssist based devices
-#
-CONFIG_RTE_LIBRTE_PMD_QAT=n
-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
-#
-# Number of sessions to create in the session memory pool
-# on a single QuickAssist device.
-#
-CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
-
-#
-# Compile PMD for AESNI backed device
-#
-CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
-CONFIG_RTE_LIBRTE_PMD_AESNI_MB_DEBUG=n
-CONFIG_RTE_AESNI_MB_PMD_MAX_NB_QUEUE_PAIRS=8
-CONFIG_RTE_AESNI_MB_PMD_MAX_NB_SESSIONS=2048
-
-#
-# Compile librte_ring
-#
-CONFIG_RTE_LIBRTE_RING=y
-CONFIG_RTE_LIBRTE_RING_DEBUG=n
-CONFIG_RTE_RING_SPLIT_PROD_CONS=n
-CONFIG_RTE_RING_PAUSE_REP_COUNT=0
-
-#
-# Compile librte_mempool
-#
-CONFIG_RTE_LIBRTE_MEMPOOL=y
-CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
-CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
-
-#
-# Compile librte_mbuf
-#
-CONFIG_RTE_LIBRTE_MBUF=y
-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
-CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
-CONFIG_RTE_PKTMBUF_HEADROOM=128
-
-#
-# Compile librte_mbuf_offload
-# EXPERIMENTAL: API may change without prior notice
-#
-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
-CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
-
-#
-# Compile librte_timer
-#
-CONFIG_RTE_LIBRTE_TIMER=y
-CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
-
-#
-# Compile librte_cfgfile
-#
-CONFIG_RTE_LIBRTE_CFGFILE=y
-
-#
-# Compile librte_cmdline
-#
-CONFIG_RTE_LIBRTE_CMDLINE=y
-CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
-
-#
-# Compile librte_hash
-#
-CONFIG_RTE_LIBRTE_HASH=y
-CONFIG_RTE_LIBRTE_HASH_DEBUG=n
-
-#
-# Compile librte_jobstats
-#
-CONFIG_RTE_LIBRTE_JOBSTATS=y
-
-#
-# Compile librte_lpm
-#
-CONFIG_RTE_LIBRTE_LPM=y
-CONFIG_RTE_LIBRTE_LPM_DEBUG=n
-
-#
-# Compile librte_acl
-#
-CONFIG_RTE_LIBRTE_ACL=y
-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
-
-#
-# Compile librte_power
-#
-CONFIG_RTE_LIBRTE_POWER=y
-CONFIG_RTE_LIBRTE_POWER_DEBUG=n
-CONFIG_RTE_MAX_LCORE_FREQS=64
-
-#
-# Compile librte_net
-#
-CONFIG_RTE_LIBRTE_NET=y
-
-#
-# Compile librte_ip_frag
-#
-CONFIG_RTE_LIBRTE_IP_FRAG=y
-CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
-CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
-CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
-
-#
-# Compile librte_meter
-#
-CONFIG_RTE_LIBRTE_METER=y
-
-#
-# Compile librte_sched
-#
-CONFIG_RTE_LIBRTE_SCHED=y
-CONFIG_RTE_SCHED_DEBUG=n
-CONFIG_RTE_SCHED_RED=n
-CONFIG_RTE_SCHED_COLLECT_STATS=n
-CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
-CONFIG_RTE_SCHED_PORT_N_GRINDERS=8
-CONFIG_RTE_SCHED_VECTOR=n
-
-#
-# Compile the distributor library
-#
-CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
-
-#
-# Compile the reorder library
-#
-CONFIG_RTE_LIBRTE_REORDER=y
-
-#
-# Compile librte_port
-#
-CONFIG_RTE_LIBRTE_PORT=y
-CONFIG_RTE_PORT_STATS_COLLECT=n
-
-#
-# Compile librte_table
-#
-CONFIG_RTE_LIBRTE_TABLE=y
-CONFIG_RTE_TABLE_STATS_COLLECT=n
-
-#
-# Compile librte_pipeline
-#
-CONFIG_RTE_LIBRTE_PIPELINE=y
-CONFIG_RTE_PIPELINE_STATS_COLLECT=n
-
-#
-# Compile librte_kni
-#
-CONFIG_RTE_LIBRTE_KNI=y
-CONFIG_RTE_KNI_KMOD=y
-CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
-CONFIG_RTE_KNI_KO_DEBUG=n
-CONFIG_RTE_KNI_VHOST=n
-CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024
-CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n
-CONFIG_RTE_KNI_VHOST_DEBUG_RX=n
-CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
-
-#
-# Compile vhost library
-# fuse-devel is needed to run vhost-cuse.
-# fuse-devel enables user space char driver development
-# vhost-user is turned on by default.
-#
-CONFIG_RTE_LIBRTE_VHOST=y
-CONFIG_RTE_LIBRTE_VHOST_USER=y
-CONFIG_RTE_LIBRTE_VHOST_NUMA=n
-CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
-
-#
-#Compile Xen domain0 support
-#
-CONFIG_RTE_LIBRTE_XEN_DOM0=n
-
-#
-# Enable warning directives
-#
-CONFIG_RTE_INSECURE_FUNCTION_WARNING=n
-
-#
-# Compile the test application
-#
-CONFIG_RTE_APP_TEST=y
-
-#
-# Compile the PMD test application
-#
-CONFIG_RTE_TEST_PMD=y
-CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
-CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
diff --git a/config/defconfig_x86_64-native-bsdapp-clang b/config/defconfig_x86_64-native-bsdapp-clang
index d2baf2c..8b870b3 100644
--- a/config/defconfig_x86_64-native-bsdapp-clang
+++ b/config/defconfig_x86_64-native-bsdapp-clang
@@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
CONFIG_RTE_ARCH="x86_64"
CONFIG_RTE_ARCH_X86_64=y
CONFIG_RTE_ARCH_X86=y
+CONFIG_RTE_ARCH_64=y
CONFIG_RTE_TOOLCHAIN="clang"
CONFIG_RTE_TOOLCHAIN_CLANG=y
diff --git a/config/defconfig_x86_64-native-bsdapp-gcc b/config/defconfig_x86_64-native-bsdapp-gcc
index 5a6a4e8..4ea4433 100644
--- a/config/defconfig_x86_64-native-bsdapp-gcc
+++ b/config/defconfig_x86_64-native-bsdapp-gcc
@@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native"
CONFIG_RTE_ARCH="x86_64"
CONFIG_RTE_ARCH_X86_64=y
CONFIG_RTE_ARCH_X86=y
+CONFIG_RTE_ARCH_64=y
CONFIG_RTE_TOOLCHAIN="gcc"
CONFIG_RTE_TOOLCHAIN_GCC=y
--
2.7.0
^ permalink raw reply [relevance 6%]
* Re: [dpdk-dev] [PATCH v2 4/6] bond mode 4: allow external state machine
@ 2016-02-22 13:03 4% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-02-22 13:03 UTC (permalink / raw)
To: Eric Kinzie, dev; +Cc: Eric Kinzie
On 02/19/2016 09:17 PM, Eric Kinzie wrote:
> From: Eric Kinzie <ekinzie@brocade.com>
>
> Provide functions to allow an external 802.3ad state machine to transmit
> and recieve LACPDUs and to set the collection/distribution flags on
> slave interfaces.
>
> Signed-off-by: Eric Kinzie <ehkinzie@gmail.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Declan Doherty <declan.doherty@intel.com>
[...]
> diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.h b/drivers/net/bonding/rte_eth_bond_8023ad.h
> index ebd0e93..8cfa3d3 100644
> --- a/drivers/net/bonding/rte_eth_bond_8023ad.h
> +++ b/drivers/net/bonding/rte_eth_bond_8023ad.h
> @@ -64,6 +64,8 @@ extern "C" {
> #define MARKER_TLV_TYPE_INFO 0x01
> #define MARKER_TLV_TYPE_RESP 0x02
>
> +typedef void (*rte_eth_bond_8023ad_ext_slowrx_fn)(uint8_t slave_id, struct rte_mbuf *lacp_pkt);
> +
> enum rte_bond_8023ad_selection {
> UNSELECTED,
> STANDBY,
> @@ -157,6 +159,7 @@ struct rte_eth_bond_8023ad_conf {
> uint32_t tx_period_ms;
> uint32_t rx_marker_period_ms;
> uint32_t update_timeout_ms;
> + rte_eth_bond_8023ad_ext_slowrx_fn slowrx_cb;
> };
This still is a likely an ABI break, previously discussed around here:
http://dpdk.org/ml/archives/dev/2015-November/027321.html
It might not be embedded anywhere in DPDK codebase, but there's no
telling what others might have done with it (have an array of them,
embed in other structs etc).
Also ultimately ABI compatibility goes both ways: when the library
soname does not change then an application is free to assume both
downgrading and upgrading are safe. In this case, upgrading *might* be
okay, downgrading certainly is not. So by that measure it definitely is
an ABI break.
[...]
> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> index 22bd920..33d73ff 100644
> --- a/drivers/net/bonding/rte_eth_bond_version.map
> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> @@ -27,3 +27,9 @@ DPDK_2.1 {
> rte_eth_bond_free;
>
> } DPDK_2.0;
> +
> +DPDK_2.2 {
> + rte_eth_bond_8023ad_ext_collect;
> + rte_eth_bond_8023ad_ext_distrib;
> + rte_eth_bond_8023ad_ext_slowtx;
> +} DPDK_2.1;
>
These symbols are not part of DPDK 2.2, the version here is wrong.
Technically it would not actually matter much but better not to confuse
things unnecessarily.
- Panu -
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files
2016-02-22 6:31 3% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Helin Zhang
@ 2016-02-22 6:31 6% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2016-02-22 6:31 UTC (permalink / raw)
To: dev
It deprecated sys files of 'extended_tag' and
'max_read_request_size', and announced the planned ABI changes of
them.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/linux_gsg/enable_func.rst | 47 -------------------
doc/guides/nics/i40e.rst | 76 +++++++++++++++++++++++++++++++
doc/guides/rel_notes/deprecation.rst | 6 +++
lib/librte_eal/common/include/rte_pci.h | 2 +-
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 72 ++++-------------------------
5 files changed, 91 insertions(+), 112 deletions(-)
create mode 100644 doc/guides/nics/i40e.rst
v2:
- Kept the sys files as they were, and added ABI change announcement for them.
- Moved high performance part of i40e from 'GSG' to a new for .nics'.
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index c3fa6d3..f59f25c 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -176,50 +176,3 @@ Also, if ``INTEL_IOMMU_DEFAULT_ON`` is not set in the kernel, the ``intel_iommu=
This ensures that the Intel IOMMU is being initialized as expected.
Please note that while using ``iommu=pt`` is compulsory for ``igb_uio driver``, the ``vfio-pci`` driver can actually work with both ``iommu=pt`` and ``iommu=on``.
-
-High Performance of Small Packets on 40G NIC
---------------------------------------------
-
-As there might be firmware fixes for performance enhancement in latest version
-of firmware image, the firmware update might be needed for getting high performance.
-Check with the local Intel's Network Division application engineers for firmware updates.
-The base driver to support firmware version of FVL3E will be integrated in the next
-DPDK release, so currently the validated firmware version is 4.2.6.
-
-Enabling Extended Tag and Setting Max Read Request Size
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-PCI configurations of ``extended_tag`` and max _read_requ st_size have big impacts on performance of small packets on 40G NIC.
-Enabling extended_tag and setting ``max_read_request_size`` to small size such as 128 bytes provide great helps to high performance of small packets.
-
-* These can be done in some BIOS implementations.
-
-* For other BIOS implementations, PCI configurations can be changed by using command of ``setpci``, or special configurations in DPDK config file of ``common_linux``.
-
- * Bits 7:5 at address of 0xA8 of each PCI device is used for setting the max_read_request_size,
- and bit 8 of 0xA8 of each PCI device is used for enabling/disabling the extended_tag.
- lspci and setpci can be used to read the values of 0xA8 and then write it back after being changed.
-
- * In config file of common_linux, below three configurations can be changed for the same purpose.
-
- ``CONFIG_RTE_PCI_CONFIG``
-
- ``CONFIG_RTE_PCI_EXTENDED_TAG``
-
- ``CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE``
-
-Use 16 Bytes RX Descriptor Size
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes size can provide helps to high performance of small packets.
-Configuration of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can be changed to use 16 bytes size RX descriptors.
-
-High Performance and per Packet Latency Tradeoff
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Due to the hardware design, the interrupt signal inside NIC is needed for per
-packet descriptor write-back. The minimum interval of interrupts could be set
-at compile time by ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` in configuration files.
-Though there is a default configuration, the interval could be tuned by the
-users with that configuration item depends on what the user cares about more,
-performance or per packet latency.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
new file mode 100644
index 0000000..b6f089f
--- /dev/null
+++ b/doc/guides/nics/i40e.rst
@@ -0,0 +1,76 @@
+.. BSD LICENSE
+ Copyright(c) 2010-2016 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.
+
+I40E Poll Mode Driver
+=====================
+
+The I40E PMD (**librte_pmd_i40e**) provides poll mode driver support
+for **Intel X710/XL710/X722** 10/40 Gbps family of adapters.
+
+High performance of small packets
+---------------------------------
+
+As there might be firmware fixes or enhancements for performance in newer
+version of firmware images, firmware update might be necessary for getting
+high performance. In addition, host driver version is also important for
+DPDK VF performance if kernel PF driver is being used. Check with the local
+Intel Network Division application engineers for helps on firmware upgrade
+and kernel driver upgrade. Release 16.04 will be validated with NVM 5.xx.
+
+Extended Tag
+~~~~~~~~~~~~
+
+PCI configuration of ``extended_tag`` has big impact on small packet size
+performance of 40G ports. Enabling ``extended_tag`` can help 40G port to
+achieve the best performance, especially for small packet size.
+
+- Disabling/enabling ``extended_tag`` can be done in some BIOS implementations.
+- If BIOS does not enable it, and does not support changing it, tools
+ (e.g. ``setpci`` on Linux) can be used to enable or disable ``extended_tag``.
+- From release 16.04, ``extended_tag`` is enabled by default during port
+ initialization, users don't need to care about that anymore.
+
+Use 16 bytes RX descriptor size
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes
+size may help a bit for high performance of small packet size. Configuration
+of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can be changed
+to use 16 bytes size RX descriptors.
+
+High performance and per packet latency tradeoff
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the hardware design, the interrupt signal inside NIC is needed for per
+packet descriptor write-back. The minimum interval of interrupts could be set
+at compile time by ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` in configuration
+files. Though there is a default configuration, the interval could be tuned by
+the users with that configuration item depends on what the user cares about
+more, performance or per packet latency.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..b7e0a4f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,9 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for release 16.07. The eal function of
+ pci_config_space_set is deprecated in release 16.04, and will be removed
+ from 16.07. Macros of CONFIG_RTE_PCI_CONFIG, CONFIG_RTE_PCI_EXTENDED_TAG and
+ CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE will be removed. sysfile of extended_tag
+ and max_read_request_size created by kernel module igb_uio will be removed.
diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
index 189d509..e4fb82d 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -587,7 +587,7 @@ void rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
* A pointer to a rte_pci_device structure describing the device
* to use
*/
-void pci_config_space_set(struct rte_pci_device *dev) __rte_deprecated;
+void pci_config_space_set(struct rte_pci_device *dev);
#endif /* RTE_PCI_CONFIG */
#ifdef __cplusplus
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index f5617d2..01b4ca6 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -40,15 +40,6 @@
#include "compat.h"
-#ifdef RTE_PCI_CONFIG
-#define PCI_SYS_FILE_BUF_SIZE 10
-#define PCI_DEV_CAP_REG 0xA4
-#define PCI_DEV_CTRL_REG 0xA8
-#define PCI_DEV_CAP_EXT_TAG_MASK 0x20
-#define PCI_DEV_CTRL_EXT_TAG_SHIFT 8
-#define PCI_DEV_CTRL_EXT_TAG_MASK (1 << PCI_DEV_CTRL_EXT_TAG_SHIFT)
-#endif
-
/**
* A structure describing the private information for a uio device.
*/
@@ -94,19 +85,9 @@ store_max_vfs(struct device *dev, struct device_attribute *attr,
static ssize_t
show_extended_tag(struct device *dev, struct device_attribute *attr, char *buf)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- uint32_t val = 0;
+ dev_info(dev, "Deprecated\n");
- pci_read_config_dword(pci_dev, PCI_DEV_CAP_REG, &val);
- if (!(val & PCI_DEV_CAP_EXT_TAG_MASK)) /* Not supported */
- return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%s\n", "invalid");
-
- val = 0;
- pci_bus_read_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CTRL_REG, &val);
-
- return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%s\n",
- (val & PCI_DEV_CTRL_EXT_TAG_MASK) ? "on" : "off");
+ return 0;
}
static ssize_t
@@ -115,36 +96,9 @@ store_extended_tag(struct device *dev,
const char *buf,
size_t count)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- uint32_t val = 0, enable;
-
- if (strncmp(buf, "on", 2) == 0)
- enable = 1;
- else if (strncmp(buf, "off", 3) == 0)
- enable = 0;
- else
- return -EINVAL;
-
- pci_cfg_access_lock(pci_dev);
- pci_bus_read_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CAP_REG, &val);
- if (!(val & PCI_DEV_CAP_EXT_TAG_MASK)) { /* Not supported */
- pci_cfg_access_unlock(pci_dev);
- return -EPERM;
- }
+ dev_info(dev, "Deprecated\n");
- val = 0;
- pci_bus_read_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CTRL_REG, &val);
- if (enable)
- val |= PCI_DEV_CTRL_EXT_TAG_MASK;
- else
- val &= ~PCI_DEV_CTRL_EXT_TAG_MASK;
- pci_bus_write_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CTRL_REG, val);
- pci_cfg_access_unlock(pci_dev);
-
- return count;
+ return 0;
}
static ssize_t
@@ -152,10 +106,9 @@ show_max_read_request_size(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- int val = pcie_get_readrq(pci_dev);
+ dev_info(dev, "Deprecated\n");
- return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%d\n", val);
+ return 0;
}
static ssize_t
@@ -164,18 +117,9 @@ store_max_read_request_size(struct device *dev,
const char *buf,
size_t count)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- unsigned long size = 0;
- int ret;
+ dev_info(dev, "Deprecated\n");
- if (0 != kstrtoul(buf, 0, &size))
- return -EINVAL;
-
- ret = pcie_set_readrq(pci_dev, (int)size);
- if (ret < 0)
- return ret;
-
- return count;
+ return 0;
}
#endif
--
1.9.3
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e
@ 2016-02-22 6:31 3% ` Helin Zhang
2016-02-22 6:31 6% ` [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files Helin Zhang
0 siblings, 1 reply; 200+ results
From: Helin Zhang @ 2016-02-22 6:31 UTC (permalink / raw)
To: dev
It enables 'extended tag' for i40e devices only during its port
initialization, which is key for 40G performance. It also deprecates
the similar in igb_uio, and eal lib.
v2:
- Changed the type of return value of i40e_enable_extended_tag() to 'void'.
- Fixed the compile warnings.
- Kept the sys files as they were, and added ABI change announcement for them.
- Moved high performance part of i40e from 'GSG' to a new for .nics'.
Helin Zhang (3):
i40e: enable extended tag
eal: remove pci config of extended tag
igb_uio: deprecate sys files
config/common_linuxapp | 1 +
doc/guides/linux_gsg/enable_func.rst | 47 ----------------
doc/guides/nics/i40e.rst | 76 ++++++++++++++++++++++++++
doc/guides/rel_notes/deprecation.rst | 6 +++
doc/guides/rel_notes/release_16_04.rst | 6 +++
drivers/net/i40e/i40e_ethdev.c | 65 ++++++++++++++++++++--
lib/librte_eal/common/eal_common_pci.c | 7 ---
lib/librte_eal/common/include/rte_pci.h | 2 +
lib/librte_eal/linuxapp/eal/eal_pci.c | 90 +++----------------------------
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 72 +++----------------------
10 files changed, 167 insertions(+), 205 deletions(-)
create mode 100644 doc/guides/nics/i40e.rst
--
1.9.3
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e
2016-02-22 3:59 3% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Helin Zhang
2016-02-22 3:59 6% ` [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files Helin Zhang
@ 2016-02-22 5:52 0% ` Wu, Jingjing
1 sibling, 0 replies; 200+ results
From: Wu, Jingjing @ 2016-02-22 5:52 UTC (permalink / raw)
To: Zhang, Helin, dev; +Cc: zhe.tag
> -----Original Message-----
> From: Zhang, Helin
> Sent: Monday, February 22, 2016 12:00 PM
> To: dev@dpdk.org
> Cc: thomas.monjalon@6wind.com; Wu, Jingjing; zhe.tag@intel.com; Zhang,
> Helin
> Subject: [PATCH v2 0/3] enable extended tag for i40e
>
> It enables 'extended tag' for i40e devices only during its port initialization,
> which is key for 40G performance. It also deprecates the similar in igb_uio,
> and eal lib.
>
> v2:
> - Changed the type of return value of i40e_enable_extended_tag() to 'void'.
> - Fixed the compile warnings.
> - Kept the sys files as they were, and added ABI change announcement for
> them.
> - Moved high performance part of i40e from 'GSG' to a new for .nics'.
>
> Helin Zhang (3):
> i40e: enable extended tag
> eal: remove pci config of extended tag
> igb_uio: deprecate sys files
Agree to add a doc i40e.rst to record i40e specific stuff.
I also sent a patch http://dpdk.org/dev/patchwork/patch/10173/, it will be great if they can be merged. :)
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
>
> --
> 1.9.3
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files
2016-02-22 3:59 3% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Helin Zhang
@ 2016-02-22 3:59 6% ` Helin Zhang
2016-02-22 5:52 0% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Wu, Jingjing
1 sibling, 0 replies; 200+ results
From: Helin Zhang @ 2016-02-22 3:59 UTC (permalink / raw)
To: dev; +Cc: zhe.tag
It deprecated sys files of 'extended_tag' and
'max_read_request_size', and announced the planned ABI changes of
them.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
doc/guides/linux_gsg/enable_func.rst | 47 -------------------
doc/guides/nics/i40e.rst | 76 +++++++++++++++++++++++++++++++
doc/guides/rel_notes/deprecation.rst | 6 +++
lib/librte_eal/common/include/rte_pci.h | 2 +-
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 72 ++++-------------------------
5 files changed, 91 insertions(+), 112 deletions(-)
create mode 100644 doc/guides/nics/i40e.rst
v2:
- Kept the sys files as they were, and added ABI change announcement for them.
- Moved high performance part of i40e from 'GSG' to a new for .nics'.
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index c3fa6d3..f59f25c 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -176,50 +176,3 @@ Also, if ``INTEL_IOMMU_DEFAULT_ON`` is not set in the kernel, the ``intel_iommu=
This ensures that the Intel IOMMU is being initialized as expected.
Please note that while using ``iommu=pt`` is compulsory for ``igb_uio driver``, the ``vfio-pci`` driver can actually work with both ``iommu=pt`` and ``iommu=on``.
-
-High Performance of Small Packets on 40G NIC
---------------------------------------------
-
-As there might be firmware fixes for performance enhancement in latest version
-of firmware image, the firmware update might be needed for getting high performance.
-Check with the local Intel's Network Division application engineers for firmware updates.
-The base driver to support firmware version of FVL3E will be integrated in the next
-DPDK release, so currently the validated firmware version is 4.2.6.
-
-Enabling Extended Tag and Setting Max Read Request Size
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-PCI configurations of ``extended_tag`` and max _read_requ st_size have big impacts on performance of small packets on 40G NIC.
-Enabling extended_tag and setting ``max_read_request_size`` to small size such as 128 bytes provide great helps to high performance of small packets.
-
-* These can be done in some BIOS implementations.
-
-* For other BIOS implementations, PCI configurations can be changed by using command of ``setpci``, or special configurations in DPDK config file of ``common_linux``.
-
- * Bits 7:5 at address of 0xA8 of each PCI device is used for setting the max_read_request_size,
- and bit 8 of 0xA8 of each PCI device is used for enabling/disabling the extended_tag.
- lspci and setpci can be used to read the values of 0xA8 and then write it back after being changed.
-
- * In config file of common_linux, below three configurations can be changed for the same purpose.
-
- ``CONFIG_RTE_PCI_CONFIG``
-
- ``CONFIG_RTE_PCI_EXTENDED_TAG``
-
- ``CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE``
-
-Use 16 Bytes RX Descriptor Size
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes size can provide helps to high performance of small packets.
-Configuration of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can be changed to use 16 bytes size RX descriptors.
-
-High Performance and per Packet Latency Tradeoff
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Due to the hardware design, the interrupt signal inside NIC is needed for per
-packet descriptor write-back. The minimum interval of interrupts could be set
-at compile time by ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` in configuration files.
-Though there is a default configuration, the interval could be tuned by the
-users with that configuration item depends on what the user cares about more,
-performance or per packet latency.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
new file mode 100644
index 0000000..b6f089f
--- /dev/null
+++ b/doc/guides/nics/i40e.rst
@@ -0,0 +1,76 @@
+.. BSD LICENSE
+ Copyright(c) 2010-2016 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.
+
+I40E Poll Mode Driver
+=====================
+
+The I40E PMD (**librte_pmd_i40e**) provides poll mode driver support
+for **Intel X710/XL710/X722** 10/40 Gbps family of adapters.
+
+High performance of small packets
+---------------------------------
+
+As there might be firmware fixes or enhancements for performance in newer
+version of firmware images, firmware update might be necessary for getting
+high performance. In addition, host driver version is also important for
+DPDK VF performance if kernel PF driver is being used. Check with the local
+Intel Network Division application engineers for helps on firmware upgrade
+and kernel driver upgrade. Release 16.04 will be validated with NVM 5.xx.
+
+Extended Tag
+~~~~~~~~~~~~
+
+PCI configuration of ``extended_tag`` has big impact on small packet size
+performance of 40G ports. Enabling ``extended_tag`` can help 40G port to
+achieve the best performance, especially for small packet size.
+
+- Disabling/enabling ``extended_tag`` can be done in some BIOS implementations.
+- If BIOS does not enable it, and does not support changing it, tools
+ (e.g. ``setpci`` on Linux) can be used to enable or disable ``extended_tag``.
+- From release 16.04, ``extended_tag`` is enabled by default during port
+ initialization, users don't need to care about that anymore.
+
+Use 16 bytes RX descriptor size
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes
+size may help a bit for high performance of small packet size. Configuration
+of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can be changed
+to use 16 bytes size RX descriptors.
+
+High performance and per packet latency tradeoff
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the hardware design, the interrupt signal inside NIC is needed for per
+packet descriptor write-back. The minimum interval of interrupts could be set
+at compile time by ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` in configuration
+files. Though there is a default configuration, the interval could be tuned by
+the users with that configuration item depends on what the user cares about
+more, performance or per packet latency.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..b7e0a4f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,9 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for release 16.07. The eal function of
+ pci_config_space_set is deprecated in release 16.04, and will be removed
+ from 16.07. Macros of CONFIG_RTE_PCI_CONFIG, CONFIG_RTE_PCI_EXTENDED_TAG and
+ CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE will be removed. sysfile of extended_tag
+ and max_read_request_size created by kernel module igb_uio will be removed.
diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
index 189d509..e4fb82d 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -587,7 +587,7 @@ void rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
* A pointer to a rte_pci_device structure describing the device
* to use
*/
-void pci_config_space_set(struct rte_pci_device *dev) __rte_deprecated;
+void pci_config_space_set(struct rte_pci_device *dev);
#endif /* RTE_PCI_CONFIG */
#ifdef __cplusplus
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index f5617d2..01b4ca6 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -40,15 +40,6 @@
#include "compat.h"
-#ifdef RTE_PCI_CONFIG
-#define PCI_SYS_FILE_BUF_SIZE 10
-#define PCI_DEV_CAP_REG 0xA4
-#define PCI_DEV_CTRL_REG 0xA8
-#define PCI_DEV_CAP_EXT_TAG_MASK 0x20
-#define PCI_DEV_CTRL_EXT_TAG_SHIFT 8
-#define PCI_DEV_CTRL_EXT_TAG_MASK (1 << PCI_DEV_CTRL_EXT_TAG_SHIFT)
-#endif
-
/**
* A structure describing the private information for a uio device.
*/
@@ -94,19 +85,9 @@ store_max_vfs(struct device *dev, struct device_attribute *attr,
static ssize_t
show_extended_tag(struct device *dev, struct device_attribute *attr, char *buf)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- uint32_t val = 0;
+ dev_info(dev, "Deprecated\n");
- pci_read_config_dword(pci_dev, PCI_DEV_CAP_REG, &val);
- if (!(val & PCI_DEV_CAP_EXT_TAG_MASK)) /* Not supported */
- return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%s\n", "invalid");
-
- val = 0;
- pci_bus_read_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CTRL_REG, &val);
-
- return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%s\n",
- (val & PCI_DEV_CTRL_EXT_TAG_MASK) ? "on" : "off");
+ return 0;
}
static ssize_t
@@ -115,36 +96,9 @@ store_extended_tag(struct device *dev,
const char *buf,
size_t count)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- uint32_t val = 0, enable;
-
- if (strncmp(buf, "on", 2) == 0)
- enable = 1;
- else if (strncmp(buf, "off", 3) == 0)
- enable = 0;
- else
- return -EINVAL;
-
- pci_cfg_access_lock(pci_dev);
- pci_bus_read_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CAP_REG, &val);
- if (!(val & PCI_DEV_CAP_EXT_TAG_MASK)) { /* Not supported */
- pci_cfg_access_unlock(pci_dev);
- return -EPERM;
- }
+ dev_info(dev, "Deprecated\n");
- val = 0;
- pci_bus_read_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CTRL_REG, &val);
- if (enable)
- val |= PCI_DEV_CTRL_EXT_TAG_MASK;
- else
- val &= ~PCI_DEV_CTRL_EXT_TAG_MASK;
- pci_bus_write_config_dword(pci_dev->bus, pci_dev->devfn,
- PCI_DEV_CTRL_REG, val);
- pci_cfg_access_unlock(pci_dev);
-
- return count;
+ return 0;
}
static ssize_t
@@ -152,10 +106,9 @@ show_max_read_request_size(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- int val = pcie_get_readrq(pci_dev);
+ dev_info(dev, "Deprecated\n");
- return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%d\n", val);
+ return 0;
}
static ssize_t
@@ -164,18 +117,9 @@ store_max_read_request_size(struct device *dev,
const char *buf,
size_t count)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- unsigned long size = 0;
- int ret;
+ dev_info(dev, "Deprecated\n");
- if (0 != kstrtoul(buf, 0, &size))
- return -EINVAL;
-
- ret = pcie_set_readrq(pci_dev, (int)size);
- if (ret < 0)
- return ret;
-
- return count;
+ return 0;
}
#endif
--
1.9.3
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e
@ 2016-02-22 3:59 3% ` Helin Zhang
2016-02-22 3:59 6% ` [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files Helin Zhang
2016-02-22 5:52 0% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Wu, Jingjing
0 siblings, 2 replies; 200+ results
From: Helin Zhang @ 2016-02-22 3:59 UTC (permalink / raw)
To: dev; +Cc: zhe.tag
It enables 'extended tag' for i40e devices only during its port
initialization, which is key for 40G performance. It also deprecates
the similar in igb_uio, and eal lib.
v2:
- Changed the type of return value of i40e_enable_extended_tag() to 'void'.
- Fixed the compile warnings.
- Kept the sys files as they were, and added ABI change announcement for them.
- Moved high performance part of i40e from 'GSG' to a new for .nics'.
Helin Zhang (3):
i40e: enable extended tag
eal: remove pci config of extended tag
igb_uio: deprecate sys files
config/common_linuxapp | 1 +
doc/guides/linux_gsg/enable_func.rst | 47 ----------------
doc/guides/nics/i40e.rst | 76 ++++++++++++++++++++++++++
doc/guides/rel_notes/deprecation.rst | 6 +++
doc/guides/rel_notes/release_16_04.rst | 6 +++
drivers/net/i40e/i40e_ethdev.c | 65 ++++++++++++++++++++--
lib/librte_eal/common/eal_common_pci.c | 7 ---
lib/librte_eal/common/include/rte_pci.h | 2 +
lib/librte_eal/linuxapp/eal/eal_pci.c | 90 +++----------------------------
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 72 +++----------------------
10 files changed, 167 insertions(+), 205 deletions(-)
create mode 100644 doc/guides/nics/i40e.rst
--
1.9.3
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages
2016-02-16 14:48 4% ` [dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages David Hunt
@ 2016-02-19 13:33 7% ` Olivier MATZ
0 siblings, 0 replies; 200+ results
From: Olivier MATZ @ 2016-02-19 13:33 UTC (permalink / raw)
To: David Hunt, dev
Hi David,
On 02/16/2016 03:48 PM, David Hunt wrote:
> v2: Kept all the NEXT_ABI defs to this patch so as to make the
> previous patches easier to read, and also to imake it clear what
> code is necessary to keep ABI compatibility when NEXT_ABI is
> disabled.
>
> Signed-off-by: David Hunt <david.hunt@intel.com>
> ---
> app/test/Makefile | 2 +
> app/test/test_mempool_perf.c | 3 +
> lib/librte_mbuf/rte_mbuf.c | 7 ++
> lib/librte_mempool/Makefile | 2 +
> lib/librte_mempool/rte_mempool.c | 240 ++++++++++++++++++++++++++++++++++++++-
> lib/librte_mempool/rte_mempool.h | 68 ++++++++++-
> 6 files changed, 320 insertions(+), 2 deletions(-)
Given the size of this patch, I don't think it's worth adding the
NEXT ABI in that case.
Regards,
Olivier
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH RFC v2 2/3] vhost: make buf vector for scatter RX local.
@ 2016-02-19 10:56 4% ` Ilya Maximets
0 siblings, 0 replies; 200+ results
From: Ilya Maximets @ 2016-02-19 10:56 UTC (permalink / raw)
To: dev, Huawei Xie, Yuanhan Liu; +Cc: Ilya Maximets, Dyasly Sergey
Array of buf_vector's is just an array for temporary storing information
about available descriptors. It used only locally in virtio_dev_merge_rx()
and there is no reason for that array to be shared.
Fix that by allocating local buf_vec inside virtio_dev_merge_rx().
buf_vec field of struct vhost_virtqueue marked as deprecated.
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
---
doc/guides/rel_notes/deprecation.rst | 1 +
lib/librte_vhost/rte_virtio_net.h | 2 +-
lib/librte_vhost/vhost_rxtx.c | 45 ++++++++++++++++++------------------
3 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..40f350d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -7,6 +7,7 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* Field buf_vec of struct vhost_virtqueue have been deprecated.
* The following fields have been deprecated in rte_eth_stats:
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
index 10dcb90..db05d68 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -91,7 +91,7 @@ struct vhost_virtqueue {
int kickfd; /**< Currently unused as polling mode is enabled. */
int enabled;
uint64_t reserved[16]; /**< Reserve some spaces for future extension. */
- struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
+ struct buf_vector buf_vec[BUF_VECTOR_MAX] __rte_deprecated; /**< @deprecated Buffer for scatter RX. */
} __rte_cache_aligned;
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 411dd95..9095fb1 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -295,7 +295,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
static inline uint32_t __attribute__((always_inline))
copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
uint16_t res_base_idx, uint16_t res_end_idx,
- struct rte_mbuf *pkt)
+ struct rte_mbuf *pkt, struct buf_vector *buf_vec)
{
uint32_t vec_idx = 0;
uint32_t entry_success = 0;
@@ -325,7 +325,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
*/
vq = dev->virtqueue[queue_id];
- vb_addr = gpa_to_vva(dev, vq->buf_vec[vec_idx].buf_addr);
+ vb_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
vb_hdr_addr = vb_addr;
/* Prefetch buffer address. */
@@ -345,19 +345,19 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
seg_avail = rte_pktmbuf_data_len(pkt);
vb_offset = vq->vhost_hlen;
- vb_avail = vq->buf_vec[vec_idx].buf_len - vq->vhost_hlen;
+ vb_avail = buf_vec[vec_idx].buf_len - vq->vhost_hlen;
entry_len = vq->vhost_hlen;
if (vb_avail == 0) {
uint32_t desc_idx =
- vq->buf_vec[vec_idx].desc_idx;
+ buf_vec[vec_idx].desc_idx;
if ((vq->desc[desc_idx].flags
& VRING_DESC_F_NEXT) == 0) {
/* Update used ring with desc information */
vq->used->ring[cur_idx & (vq->size - 1)].id
- = vq->buf_vec[vec_idx].desc_idx;
+ = buf_vec[vec_idx].desc_idx;
vq->used->ring[cur_idx & (vq->size - 1)].len
= entry_len;
@@ -367,12 +367,12 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
}
vec_idx++;
- vb_addr = gpa_to_vva(dev, vq->buf_vec[vec_idx].buf_addr);
+ vb_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
/* Prefetch buffer address. */
rte_prefetch0((void *)(uintptr_t)vb_addr);
vb_offset = 0;
- vb_avail = vq->buf_vec[vec_idx].buf_len;
+ vb_avail = buf_vec[vec_idx].buf_len;
}
cpy_len = RTE_MIN(vb_avail, seg_avail);
@@ -399,11 +399,11 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
* entry reach to its end.
* But the segment doesn't complete.
*/
- if ((vq->desc[vq->buf_vec[vec_idx].desc_idx].flags &
+ if ((vq->desc[buf_vec[vec_idx].desc_idx].flags &
VRING_DESC_F_NEXT) == 0) {
/* Update used ring with desc information */
vq->used->ring[cur_idx & (vq->size - 1)].id
- = vq->buf_vec[vec_idx].desc_idx;
+ = buf_vec[vec_idx].desc_idx;
vq->used->ring[cur_idx & (vq->size - 1)].len
= entry_len;
entry_len = 0;
@@ -413,9 +413,9 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
vec_idx++;
vb_addr = gpa_to_vva(dev,
- vq->buf_vec[vec_idx].buf_addr);
+ buf_vec[vec_idx].buf_addr);
vb_offset = 0;
- vb_avail = vq->buf_vec[vec_idx].buf_len;
+ vb_avail = buf_vec[vec_idx].buf_len;
cpy_len = RTE_MIN(vb_avail, seg_avail);
} else {
/*
@@ -434,7 +434,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
* from buf_vec.
*/
uint32_t desc_idx =
- vq->buf_vec[vec_idx].desc_idx;
+ buf_vec[vec_idx].desc_idx;
if ((vq->desc[desc_idx].flags &
VRING_DESC_F_NEXT) == 0) {
@@ -456,9 +456,9 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
/* Get next buffer from buf_vec. */
vec_idx++;
vb_addr = gpa_to_vva(dev,
- vq->buf_vec[vec_idx].buf_addr);
+ buf_vec[vec_idx].buf_addr);
vb_avail =
- vq->buf_vec[vec_idx].buf_len;
+ buf_vec[vec_idx].buf_len;
vb_offset = 0;
}
@@ -471,7 +471,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
*/
/* Update used ring with desc information */
vq->used->ring[cur_idx & (vq->size - 1)].id
- = vq->buf_vec[vec_idx].desc_idx;
+ = buf_vec[vec_idx].desc_idx;
vq->used->ring[cur_idx & (vq->size - 1)].len
= entry_len;
entry_success++;
@@ -485,7 +485,7 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
static inline void __attribute__((always_inline))
update_secure_len(struct vhost_virtqueue *vq, uint32_t id,
- uint32_t *secure_len, uint32_t *vec_idx)
+ uint32_t *secure_len, uint32_t *vec_idx, struct buf_vector *buf_vec)
{
uint16_t wrapped_idx = id & (vq->size - 1);
uint32_t idx = vq->avail->ring[wrapped_idx];
@@ -496,9 +496,9 @@ update_secure_len(struct vhost_virtqueue *vq, uint32_t id,
do {
next_desc = 0;
len += vq->desc[idx].len;
- vq->buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
- vq->buf_vec[vec_id].buf_len = vq->desc[idx].len;
- vq->buf_vec[vec_id].desc_idx = idx;
+ buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
+ buf_vec[vec_id].buf_len = vq->desc[idx].len;
+ buf_vec[vec_id].desc_idx = idx;
vec_id++;
if (vq->desc[idx].flags & VRING_DESC_F_NEXT) {
@@ -523,6 +523,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
uint16_t avail_idx;
uint16_t res_base_idx, res_cur_idx;
uint8_t success = 0;
+ struct buf_vector buf_vec[BUF_VECTOR_MAX];
LOG_DEBUG(VHOST_DATA, "(%"PRIu64") virtio_dev_merge_rx()\n",
dev->device_fh);
@@ -561,8 +562,8 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
if (unlikely(res_cur_idx == avail_idx))
goto merge_rx_exit;
- update_secure_len(vq, res_cur_idx,
- &secure_len, &vec_idx);
+ update_secure_len(vq, res_cur_idx, &secure_len,
+ &vec_idx, buf_vec);
res_cur_idx++;
} while (pkt_len > secure_len);
@@ -573,7 +574,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
} while (success == 0);
entry_success = copy_from_mbuf_to_vring(dev, queue_id,
- res_base_idx, res_cur_idx, pkts[pkt_idx]);
+ res_base_idx, res_cur_idx, pkts[pkt_idx], buf_vec);
rte_smp_wmb();
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH RFC 2/4] vhost: make buf vector for scatter RX local.
2016-02-19 7:30 0% ` Ilya Maximets
@ 2016-02-19 8:10 3% ` Xie, Huawei
0 siblings, 0 replies; 200+ results
From: Xie, Huawei @ 2016-02-19 8:10 UTC (permalink / raw)
To: Ilya Maximets, Yuanhan Liu; +Cc: dev, Dyasly Sergey
On 2/19/2016 3:31 PM, Ilya Maximets wrote:
> On 19.02.2016 10:06, Yuanhan Liu wrote:
>> On Fri, Feb 19, 2016 at 09:32:41AM +0300, Ilya Maximets wrote:
>>> Array of buf_vector's is just an array for temporary storing information
>>> about available descriptors. It used only locally in virtio_dev_merge_rx()
>>> and there is no reason for that array to be shared.
>>>
>>> Fix that by allocating local buf_vec inside virtio_dev_merge_rx().
>>>
>>> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
>>> ---
>>> lib/librte_vhost/rte_virtio_net.h | 1 -
>>> lib/librte_vhost/vhost_rxtx.c | 45 ++++++++++++++++++++-------------------
>>> 2 files changed, 23 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>>> index 10dcb90..ae1e4fb 100644
>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>> @@ -91,7 +91,6 @@ struct vhost_virtqueue {
>>> int kickfd; /**< Currently unused as polling mode is enabled. */
>>> int enabled;
>>> uint64_t reserved[16]; /**< Reserve some spaces for future extension. */
>>> - struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
>>> } __rte_cache_aligned;
>> I like this kind of cleanup, however, it breaks ABI.
> Should I prepare version of this patch with field above marked as
> deprecated and add note to doc/guides/rel_notes/release_16_04.rst
> about future deletion?
Ilya, you could follow the ABI process:
http://dpdk.org/doc/guides/contributing/versioning.html
>
> Best regards, Ilya Maximets.
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure
@ 2016-02-19 7:31 15% ` Xutao Sun
0 siblings, 0 replies; 200+ results
From: Xutao Sun @ 2016-02-19 7:31 UTC (permalink / raw)
To: dev
Change the fields of outer_mac and inner_mac from pointer to struct in order to keep the code's readability.
Signed-off-by: Xutao Sun <xutao.sun@intel.com>
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
app/test-pmd/cmdline.c | 6 +++--
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_16_04.rst | 2 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 35 +++++++++++++++++++++++++++--
drivers/net/i40e/i40e_ethdev.c | 12 +++++-----
lib/librte_ether/rte_eth_ctrl.h | 4 ++--
6 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 52e9f5f..c707318 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6640,8 +6640,10 @@ cmd_tunnel_filter_parsed(void *parsed_result,
struct rte_eth_tunnel_filter_conf tunnel_filter_conf;
int ret = 0;
- tunnel_filter_conf.outer_mac = &res->outer_mac;
- tunnel_filter_conf.inner_mac = &res->inner_mac;
+ rte_memcpy(&tunnel_filter_conf.outer_mac, &res->outer_mac,
+ ETHER_ADDR_LEN);
+ rte_memcpy(&tunnel_filter_conf.inner_mac, &res->inner_mac,
+ ETHER_ADDR_LEN);
tunnel_filter_conf.inner_vlan = res->inner_vlan;
if (res->ip_value.family == AF_INET) {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..a895364 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,11 +32,6 @@ Deprecation Notices
RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
but release 2.3 will.
-* ABI changes are planned for rte_eth_tunnel_filter_conf. Change the fields
- of outer_mac and inner_mac from pointer to struct in order to keep the
- code's readability. The release 2.2 does not contain these ABI changes, but
- release 2.3 will, and no backwards compatibility is planned.
-
* The scheduler statistics structure will change to allow keeping track of
RED actions.
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index eb1b3b2..2588225 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -104,6 +104,8 @@ ABI Changes
the previous releases and made in this release. Use fixed width quotes for
``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* The fields of outer_mac and inner_mac were changed from pointer
+ to struct in order to keep the code's readability.
Shared Library Versions
-----------------------
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a520cc5..3ee629a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -553,7 +553,37 @@ tunnel_filter add
Add a tunnel filter on a port::
testpmd> tunnel_filter add (port_id) (outer_mac) (inner_mac) (ip_addr) \
- (inner_vlan) (tunnel_type) (filter_type) (tenant_id) (queue_id)
+ (inner_vlan) (vxlan|nvgre|ipingre) (imac-ivlan|imac-ivlan-tenid|\
+ imac-tenid|imac|omac-imac-tenid|oip|iip) (tenant_id) (queue_id)
+
+The available information categories are:
+
+* ``vxlan``: Set tunnel type as VXLAN.
+
+* ``nvgre``: Set tunnel type as NVGRE.
+
+* ``ipingre``: Set tunnel type as IP-in-GRE.
+
+* ``imac-ivlan``: Set filter type as Inner MAC and VLAN.
+
+* ``imac-ivlan-tenid``: Set filter type as Inner MAC, VLAN and tenant ID.
+
+* ``imac-tenid``: Set filter type as Inner MAC and tenant ID.
+
+* ``imac``: Set filter type as Inner MAC.
+
+* ``omac-imac-tenid``: Set filter type as Outer MAC, Inner MAC and tenant ID.
+
+* ``oip``: Set filter type as Outer IP.
+
+* ``iip``: Set filter type as Inner IP.
+
+Example::
+
+ testpmd> tunnel_filter add 0 68:05:CA:28:09:82 00:00:00:00:00:00 \
+ 192.168.2.2 0 ipingre oip 1 1
+
+ Set an IP-in-GRE tunnel on port 0, and the filter type is Outer IP.
tunnel_filter remove
~~~~~~~~~~~~~~~~~~~~
@@ -561,7 +591,8 @@ tunnel_filter remove
Remove a tunnel filter on a port::
testpmd> tunnel_filter rm (port_id) (outer_mac) (inner_mac) (ip_addr) \
- (inner_vlan) (tunnel_type) (filter_type) (tenant_id) (queue_id)
+ (inner_vlan) (vxlan|nvgre|ipingre) (imac-ivlan|imac-ivlan-tenid|\
+ imac-tenid|imac|omac-imac-tenid|oip|iip) (tenant_id) (queue_id)
rx_vxlan_port add
~~~~~~~~~~~~~~~~~
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..7c22358 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5828,10 +5828,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
}
pfilter = cld_filter;
- (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac,
- sizeof(struct ether_addr));
- (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac,
- sizeof(struct ether_addr));
+ (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac,
+ ETHER_ADDR_LEN);
+ (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
+ ETHER_ADDR_LEN);
pfilter->inner_vlan = tunnel_filter->inner_vlan;
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
@@ -6131,13 +6131,13 @@ i40e_tunnel_filter_param_check(struct i40e_pf *pf,
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_OMAC) &&
- (is_zero_ether_addr(filter->outer_mac))) {
+ (is_zero_ether_addr(&filter->outer_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL outer MAC address");
return -EINVAL;
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_IMAC) &&
- (is_zero_ether_addr(filter->inner_mac))) {
+ (is_zero_ether_addr(&filter->inner_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL inner MAC address");
return -EINVAL;
}
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..30cbde7 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
* Tunneling Packet filter configuration.
*/
struct rte_eth_tunnel_filter_conf {
- struct ether_addr *outer_mac; /**< Outer MAC address filter. */
- struct ether_addr *inner_mac; /**< Inner MAC address filter. */
+ struct ether_addr outer_mac; /**< Outer MAC address filter. */
+ struct ether_addr inner_mac; /**< Inner MAC address filter. */
uint16_t inner_vlan; /**< Inner VLAN filter. */
enum rte_tunnel_iptype ip_type; /**< IP address type. */
union {
--
1.9.3
^ permalink raw reply [relevance 15%]
* Re: [dpdk-dev] [PATCH RFC 2/4] vhost: make buf vector for scatter RX local.
2016-02-19 7:06 3% ` Yuanhan Liu
@ 2016-02-19 7:30 0% ` Ilya Maximets
2016-02-19 8:10 3% ` Xie, Huawei
0 siblings, 1 reply; 200+ results
From: Ilya Maximets @ 2016-02-19 7:30 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Dyasly Sergey
On 19.02.2016 10:06, Yuanhan Liu wrote:
> On Fri, Feb 19, 2016 at 09:32:41AM +0300, Ilya Maximets wrote:
>> Array of buf_vector's is just an array for temporary storing information
>> about available descriptors. It used only locally in virtio_dev_merge_rx()
>> and there is no reason for that array to be shared.
>>
>> Fix that by allocating local buf_vec inside virtio_dev_merge_rx().
>>
>> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
>> ---
>> lib/librte_vhost/rte_virtio_net.h | 1 -
>> lib/librte_vhost/vhost_rxtx.c | 45 ++++++++++++++++++++-------------------
>> 2 files changed, 23 insertions(+), 23 deletions(-)
>>
>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>> index 10dcb90..ae1e4fb 100644
>> --- a/lib/librte_vhost/rte_virtio_net.h
>> +++ b/lib/librte_vhost/rte_virtio_net.h
>> @@ -91,7 +91,6 @@ struct vhost_virtqueue {
>> int kickfd; /**< Currently unused as polling mode is enabled. */
>> int enabled;
>> uint64_t reserved[16]; /**< Reserve some spaces for future extension. */
>> - struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
>> } __rte_cache_aligned;
>
> I like this kind of cleanup, however, it breaks ABI.
Should I prepare version of this patch with field above marked as
deprecated and add note to doc/guides/rel_notes/release_16_04.rst
about future deletion?
Best regards, Ilya Maximets.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH RFC 2/4] vhost: make buf vector for scatter RX local.
@ 2016-02-19 7:06 3% ` Yuanhan Liu
2016-02-19 7:30 0% ` Ilya Maximets
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2016-02-19 7:06 UTC (permalink / raw)
To: Ilya Maximets; +Cc: dev, Dyasly Sergey
On Fri, Feb 19, 2016 at 09:32:41AM +0300, Ilya Maximets wrote:
> Array of buf_vector's is just an array for temporary storing information
> about available descriptors. It used only locally in virtio_dev_merge_rx()
> and there is no reason for that array to be shared.
>
> Fix that by allocating local buf_vec inside virtio_dev_merge_rx().
>
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> ---
> lib/librte_vhost/rte_virtio_net.h | 1 -
> lib/librte_vhost/vhost_rxtx.c | 45 ++++++++++++++++++++-------------------
> 2 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> index 10dcb90..ae1e4fb 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -91,7 +91,6 @@ struct vhost_virtqueue {
> int kickfd; /**< Currently unused as polling mode is enabled. */
> int enabled;
> uint64_t reserved[16]; /**< Reserve some spaces for future extension. */
> - struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
> } __rte_cache_aligned;
I like this kind of cleanup, however, it breaks ABI.
--yliu
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 4/4] doc: update with link changes
2016-02-14 22:17 8% ` [dpdk-dev] [PATCH v8 4/4] doc: update with link changes Marc Sune
@ 2016-02-18 18:14 0% ` Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2016-02-18 18:14 UTC (permalink / raw)
To: Marc Sune, dev, Lu, Wenzhuo, Zhang, Helin, Harish Patil, Chen, Jing D
Hi,
Some minor comments below in order to get a consistent set of release notes.
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marc Sune
> Sent: Sunday, February 14, 2016 10:18 PM
> To: dev@dpdk.org; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; Harish Patil <harish.patil@qlogic.com>; Chen,
> Jing D <jing.d.chen@intel.com>
> Subject: [dpdk-dev] [PATCH v8 4/4] doc: update with link changes
>
> Add new features, ABI changes and resolved issues notice for the
> refactored link patch.
>
> Signed-off-by: Marc Sune <marcdevel@gmail.com>
> ---
> doc/guides/rel_notes/release_2_3.rst | 102
This should be rebased and the notes added to doc/guides/rel_notes/release_16_04.rst.
> +
> +* **ethdev: define a set of advertised link speeds.**
The title and the text should be in the past tense.
See the hints/guidelines in the updated release notes:
http://dpdk.org/browse/dpdk/tree/doc/guides/rel_notes/release_16_04.rst
> +
> + Allowing to define a set of advertised speeds for auto-negociation,
Maybe something like: Added functionality to allow the definition of advertised speeds for ...
> +* **ethdev: add speed_cap bitmap to recover eth device link speed
> +capabilities
> + define a set of advertised link speeds.**
The title is a little long. Just give a brief overview here and more the detail
to the text sections.
> +
> + ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows
> + the application to recover the supported speeds for that ethernet
> device.
It would be good to use ```` quotes on speed_cap as well for consistency.
+
> +Examples
> +~~~~~~~~
> +
> +* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical
> +speeds to bitmap fields.
I don't think this should be in the "Examples" section. Maybe as a sub-item
in the "New Featrues" or in "API Changes" if it is a change.
> +
> +ABI Changes
> +-----------
> +
> +* The ethdev rte_eth_link and rte_eth_conf structures were changed to
> + support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
> +
> +* The ethdev rte_eth_dev_info was changed to support device speed
> capabilities.
Better to put the struct names and variables in ```` quotes.
Thanks,
John.
-
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library
2016-02-17 19:58 0% ` Ananyev, Konstantin
@ 2016-02-18 10:43 0% ` Yigit, Ferruh
0 siblings, 0 replies; 200+ results
From: Yigit, Ferruh @ 2016-02-18 10:43 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Wed, Feb 17, 2016 at 07:58:16PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> > Sent: Friday, February 12, 2016 1:46 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library
> >
> > This library gets control messages form kernelspace and forwards them to
> > librte_ether and returns response back to the kernelspace.
> >
> > Library does:
> > 1) Trigger Linux virtual interface creation
> > 2) Initialize the netlink socket communication
> > 3) Provides process() API to the application that does processing the
> > received messages
> >
> > This library requires corresponding kernel module to be inserted.
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >
> > ---
> >
> > v2:
> > * User rtnetlink to create interfaces.
> > * Add more ethtool support: get/set ringparam, set pauseparam.
> > * return defined error instead of hardcoded value
> > ---
> > MAINTAINERS | 1 +
> > config/common_linuxapp | 3 +-
> > doc/api/doxy-api-index.md | 3 +-
> > doc/api/doxy-api.conf | 1 +
> > doc/guides/rel_notes/release_16_04.rst | 9 +
> > lib/Makefile | 3 +-
> > lib/librte_ctrl_if/Makefile | 58 ++++
> > lib/librte_ctrl_if/rte_ctrl_if.c | 385 ++++++++++++++++++++++++
> > lib/librte_ctrl_if/rte_ctrl_if.h | 115 ++++++++
> > lib/librte_ctrl_if/rte_ctrl_if_version.map | 9 +
> > lib/librte_ctrl_if/rte_ethtool.c | 450 +++++++++++++++++++++++++++++
> > lib/librte_ctrl_if/rte_ethtool.h | 54 ++++
> > lib/librte_ctrl_if/rte_nl.c | 274 ++++++++++++++++++
> > lib/librte_ctrl_if/rte_nl.h | 49 ++++
> > lib/librte_eal/common/include/rte_log.h | 3 +-
> > mk/rte.app.mk | 3 +-
> > 16 files changed, 1415 insertions(+), 5 deletions(-)
> > create mode 100644 lib/librte_ctrl_if/Makefile
> > create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c
> > create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h
> > create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map
> > create mode 100644 lib/librte_ctrl_if/rte_ethtool.c
> > create mode 100644 lib/librte_ctrl_if/rte_ethtool.h
> > create mode 100644 lib/librte_ctrl_if/rte_nl.c
> > create mode 100644 lib/librte_ctrl_if/rte_nl.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 09c56c7..91c98bc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -256,6 +256,7 @@ F: doc/guides/sample_app_ug/kernel_nic_interface.rst
> > Linux KCP
> > M: Ferruh Yigit <ferruh.yigit@intel.com>
> > F: lib/librte_eal/linuxapp/kcp/
> > +F: lib/librte_ctrl_if/
> >
> > Linux AF_PACKET
> > M: John W. Linville <linville@tuxdriver.com>
> > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > index 2f4eb1d..4bcd508 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -1,6 +1,6 @@
> > # BSD LICENSE
> > #
> > -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> > +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> > # All rights reserved.
> > #
> > # Redistribution and use in source and binary forms, with or without
> > @@ -501,6 +501,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
> > #
> > CONFIG_RTE_KCP_KMOD=y
> > CONFIG_RTE_KCP_KO_DEBUG=n
> > +CONFIG_RTE_LIBRTE_CTRL_IF=y
> >
> > #
> > # Compile vhost library
> > diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> > index 7a91001..214d16e 100644
> > --- a/doc/api/doxy-api-index.md
> > +++ b/doc/api/doxy-api-index.md
> > @@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped by topics:
> > [common] (@ref rte_common.h),
> > [ABI compat] (@ref rte_compat.h),
> > [keepalive] (@ref rte_keepalive.h),
> > - [version] (@ref rte_version.h)
> > + [version] (@ref rte_version.h),
> > + [control interface] (@ref rte_ctrl_if.h)
> > diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> > index 57e8b5d..fd69bf1 100644
> > --- a/doc/api/doxy-api.conf
> > +++ b/doc/api/doxy-api.conf
> > @@ -39,6 +39,7 @@ INPUT = doc/api/doxy-api-index.md \
> > lib/librte_cmdline \
> > lib/librte_compat \
> > lib/librte_cryptodev \
> > + lib/librte_ctrl_if \
> > lib/librte_distributor \
> > lib/librte_ether \
> > lib/librte_hash \
> > diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
> > index 27fc624..1b1d34c 100644
> > --- a/doc/guides/rel_notes/release_16_04.rst
> > +++ b/doc/guides/rel_notes/release_16_04.rst
> > @@ -39,6 +39,14 @@ This section should contain new features added in this release. Sample format:
> >
> > Enabled virtio 1.0 support for virtio pmd driver.
> >
> > +* **Control interface support added.**
> > +
> > + To enable controlling DPDK ports by common Linux tools.
> > + Following modules added to DPDK:
> > +
> > + * librte_ctrl_if library
> > + * librte_eal/linuxapp/kcp kernel module
> > +
> >
> > Resolved Issues
> > ---------------
> > @@ -113,6 +121,7 @@ The libraries prepended with a plus sign were incremented in this version.
> > librte_acl.so.2
> > librte_cfgfile.so.2
> > librte_cmdline.so.1
> > + + librte_ctrl_if.so.1
> > librte_distributor.so.1
> > librte_eal.so.2
> > librte_hash.so.2
> > diff --git a/lib/Makefile b/lib/Makefile
> > index ef172ea..a50bc1e 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -1,6 +1,6 @@
> > # BSD LICENSE
> > #
> > -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> > +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> > # All rights reserved.
> > #
> > # Redistribution and use in source and binary forms, with or without
> > @@ -58,6 +58,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port
> > DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
> > DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
> > DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
> > +DIRS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += librte_ctrl_if
> >
> > ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> > DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
> > diff --git a/lib/librte_ctrl_if/Makefile b/lib/librte_ctrl_if/Makefile
> > new file mode 100644
> > index 0000000..4e82966
> > --- /dev/null
> > +++ b/lib/librte_ctrl_if/Makefile
> > @@ -0,0 +1,58 @@
> > +# BSD LICENSE
> > +#
> > +# Copyright(c) 2016 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.
> > +
> > +include $(RTE_SDK)/mk/rte.vars.mk
> > +
> > +#
> > +# library name
> > +#
> > +LIB = librte_ctrl_if.a
> > +
> > +CFLAGS += -O3
> > +CFLAGS += $(WERROR_FLAGS)
> > +
> > +EXPORT_MAP := rte_ctrl_if_version.map
> > +
> > +LIBABIVER := 1
> > +
> > +SRCS-y += rte_ctrl_if.c
> > +SRCS-y += rte_nl.c
> > +SRCS-y += rte_ethtool.c
> > +
> > +#
> > +# Export include files
> > +#
> > +SYMLINK-y-include += rte_ctrl_if.h
> > +
> > +# this lib depends upon:
> > +DEPDIRS-y += lib/librte_ether
> > +
> > +include $(RTE_SDK)/mk/rte.lib.mk
> > diff --git a/lib/librte_ctrl_if/rte_ctrl_if.c b/lib/librte_ctrl_if/rte_ctrl_if.c
> > new file mode 100644
> > index 0000000..d16398f
> > --- /dev/null
> > +++ b/lib/librte_ctrl_if/rte_ctrl_if.c
> > @@ -0,0 +1,385 @@
> > +/*-
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2016 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.
> > + */
> > +
> > +#include <fcntl.h>
> > +#include <unistd.h>
> > +#include <time.h>
> > +
> > +#include <sys/ioctl.h>
> > +#include <sys/socket.h>
> > +#include <linux/netlink.h>
> > +#include <linux/rtnetlink.h>
> > +
> > +#include <rte_ethdev.h>
> > +#include "rte_ctrl_if.h"
> > +#include "rte_nl.h"
> > +
> > +#define NAMESZ 32
> > +#define IFNAME "dpdk"
> > +#define BUFSZ 1024
> > +
> > +static int kcp_rtnl_fd = -1;
> > +static int kcp_fd_ref;
> > +
> > +struct kcp_request {
> > + struct nlmsghdr nlmsg;
> > + char buf[BUFSZ];
> > +};
> > +
> > +static int
> > +conrol_interface_rtnl_init(void)
> > +{
> > + struct sockaddr_nl src;
> > + int ret;
> > +
> > + kcp_rtnl_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
> > + if (kcp_rtnl_fd < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "socket for create failed.\n");
> > + return -1;
> > + }
> > +
> > + memset(&src, 0, sizeof(struct sockaddr_nl));
> > +
> > + src.nl_family = AF_NETLINK;
> > + src.nl_pid = getpid();
> > +
> > + ret = bind(kcp_rtnl_fd, (struct sockaddr *)&src,
> > + sizeof(struct sockaddr_nl));
> > + if (ret < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "Bind for create failed.\n");
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +control_interface_init(void)
> > +{
> > + int ret;
> > +
> > + ret = conrol_interface_rtnl_init();
> > + if (ret < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "Failed to initialize rtnetlink.\n");
> > + return -1;
> > + }
> > +
> > + ret = control_interface_nl_init();
> > + if (ret < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "Failed to initialize netlink.\n");
> > + close(kcp_rtnl_fd);
> > + kcp_rtnl_fd = -1;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int
> > +control_interface_ref_get(void)
> > +{
> > + int ret = 0;
> > +
> > + if (kcp_fd_ref == 0)
> > + ret = control_interface_init();
> > +
> > + if (ret == 0)
> > + kcp_fd_ref++;
> > + else
> > + RTE_LOG(ERR, CTRL_IF,
> > + "Failed to initialize control interface.\n");
> > +
> > + return kcp_fd_ref;
> > +}
> > +
> > +static void
> > +control_interface_release(void)
> > +{
> > + close(kcp_rtnl_fd);
> > + control_interface_nl_release();
> > +}
> > +
> > +static int
> > +control_interface_ref_put(void)
> > +{
> > + if (kcp_fd_ref == 0)
> > + return 0;
> > +
> > + kcp_fd_ref--;
> > +
> > + if (kcp_fd_ref == 0)
> > + control_interface_release();
> > +
> > + return kcp_fd_ref;
> > +}
> > +
> > +static int
> > +add_attr(struct kcp_request *req, unsigned short type, void *buf, size_t len)
> > +{
> > + struct rtattr *rta;
> > + int nlmsg_len;
> > +
> > + nlmsg_len = NLMSG_ALIGN(req->nlmsg.nlmsg_len);
> > + rta = (struct rtattr *)((char *)&req->nlmsg + nlmsg_len);
> > + if (nlmsg_len + RTA_LENGTH(len) > sizeof(struct kcp_request))
> > + return -1;
> > + rta->rta_type = type;
> > + rta->rta_len = RTA_LENGTH(len);
> > + memcpy(RTA_DATA(rta), buf, len);
> > + req->nlmsg.nlmsg_len = nlmsg_len + RTA_LENGTH(len);
> > +
> > + return 0;
> > +}
> > +
> > +static struct
> > +rtattr *add_attr_nested(struct kcp_request *req, unsigned short type)
> > +{
> > + struct rtattr *rta;
> > + int nlmsg_len;
> > +
> > + nlmsg_len = NLMSG_ALIGN(req->nlmsg.nlmsg_len);
> > + rta = (struct rtattr *)((char *)&req->nlmsg + nlmsg_len);
> > + if (nlmsg_len + RTA_LENGTH(0) > sizeof(struct kcp_request))
> > + return NULL;
> > + rta->rta_type = type;
> > + rta->rta_len = nlmsg_len;
> > + req->nlmsg.nlmsg_len = nlmsg_len + RTA_LENGTH(0);
> > +
> > + return rta;
> > +}
> > +
> > +static void
> > +end_attr_nested(struct kcp_request *req, struct rtattr *rta)
> > +{
> > + rta->rta_len = req->nlmsg.nlmsg_len - rta->rta_len;
> > +}
> > +
> > +static int
> > +rte_eth_rtnl_create(uint8_t port_id)
> > +{
> > + struct kcp_request req;
> > + struct ifinfomsg *info;
> > + struct rtattr *rta1;
> > + struct rtattr *rta2;
> > + unsigned int pid = getpid();
> > + char name[NAMESZ];
> > + char type[NAMESZ];
> > + struct iovec iov;
> > + struct msghdr msg;
> > + struct sockaddr_nl nladdr;
> > + int ret;
> > + char buf[BUFSZ];
> > +
> > + memset(&req, 0, sizeof(struct kcp_request));
> > +
> > + req.nlmsg.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
> > + req.nlmsg.nlmsg_flags = NLM_F_REQUEST | NLM_F_CREATE | NLM_F_EXCL;
> > + req.nlmsg.nlmsg_flags |= NLM_F_ACK;
> > + req.nlmsg.nlmsg_type = RTM_NEWLINK;
> > +
> > + info = NLMSG_DATA(&req.nlmsg);
> > +
> > + info->ifi_family = AF_UNSPEC;
> > + info->ifi_index = 0;
> > +
> > + snprintf(name, NAMESZ, IFNAME"%u", port_id);
> > + ret = add_attr(&req, IFLA_IFNAME, name, strlen(name) + 1);
> > + if (ret < 0)
> > + return -1;
> > +
> > + rta1 = add_attr_nested(&req, IFLA_LINKINFO);
> > + if (rta1 == NULL)
> > + return -1;
> > +
> > + snprintf(type, NAMESZ, KCP_DEVICE);
> > + ret = add_attr(&req, IFLA_INFO_KIND, type, strlen(type) + 1);
> > + if (ret < 0)
> > + return -1;
> > +
> > + rta2 = add_attr_nested(&req, IFLA_INFO_DATA);
> > + if (rta2 == NULL)
> > + return -1;
> > +
> > + ret = add_attr(&req, IFLA_KCP_PORTID, &port_id, sizeof(uint8_t));
> > + if (ret < 0)
> > + return -1;
> > +
> > + ret = add_attr(&req, IFLA_KCP_PID, &pid, sizeof(unsigned int));
> > + if (ret < 0)
> > + return -1;
> > +
> > + end_attr_nested(&req, rta2);
> > + end_attr_nested(&req, rta1);
> > +
> > + memset(&nladdr, 0, sizeof(nladdr));
> > + nladdr.nl_family = AF_NETLINK;
> > +
> > + iov.iov_base = (void *)&req.nlmsg;
> > + iov.iov_len = req.nlmsg.nlmsg_len;
> > +
> > + memset(&msg, 0, sizeof(struct msghdr));
> > + msg.msg_name = &nladdr;
> > + msg.msg_namelen = sizeof(nladdr);
> > + msg.msg_iov = &iov;
> > + msg.msg_iovlen = 1;
> > +
> > + ret = sendmsg(kcp_rtnl_fd, &msg, 0);
> > + if (ret < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "Send for create failed %d.\n", errno);
> > + return -1;
> > + }
> > +
> > + memset(buf, 0, sizeof(buf));
> > + iov.iov_base = buf;
> > + iov.iov_len = sizeof(buf);
> > +
> > + ret = recvmsg(kcp_rtnl_fd, &msg, 0);
> > + if (ret < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "Recv for create failed.\n");
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> It is probably would be good to make
> rte_eth_control_interface_create_one()/rte_eth_control_interface_destroy_one()
> a public API, so the user can decide which ports to expose to KCP, which not.
> If that is not possible by some reason - then seems no reason to keep
> control_interface_ref_get/ control_interface_ref_put.
>
It is easy to make them public, they are already as seperate functions,
but my concern is to make it more complex, right now this lib has only three APIs: create, destroy, process; simple.
and there is no overhead of having all interface instead of one.
When they are added as API, it is hard to remove them, is it OK if we kept as it is, and add those APIs if there is any demand?
> > +static int
> > +rte_eth_control_interface_create_one(uint8_t port_id)
> > +{
> > + int ret;
> > +
> > + if (control_interface_ref_get() != 0) {
> > + ret = rte_eth_rtnl_create(port_id);
> > + RTE_LOG(DEBUG, CTRL_IF,
> > + "Control interface %s for port:%u\n",
> > + ret < 0 ? "failed" : "created", port_id);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +int
> > +rte_eth_control_interface_create(void)
> > +{
> > + int i;
> > + int ret = 0;
> > +
> > + for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
> > + if (rte_eth_dev_is_valid_port(i)) {
> > + ret = rte_eth_control_interface_create_one(i);
> > + if (ret < 0)
> > + return ret;
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int
> > +rte_eth_rtnl_destroy(uint8_t port_id)
> > +{
> > + struct kcp_request req;
> > + struct ifinfomsg *info;
> > + char name[NAMESZ];
> > + struct iovec iov;
> > + struct msghdr msg;
> > + struct sockaddr_nl nladdr;
> > + int ret;
> > +
> > + memset(&req, 0, sizeof(struct kcp_request));
> > +
> > + req.nlmsg.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
> > + req.nlmsg.nlmsg_flags = NLM_F_REQUEST;
> > + req.nlmsg.nlmsg_type = RTM_DELLINK;
> > +
> > + info = NLMSG_DATA(&req.nlmsg);
> > +
> > + info->ifi_family = AF_UNSPEC;
> > + info->ifi_index = 0;
> > +
> > + snprintf(name, NAMESZ, IFNAME"%u", port_id);
> > + ret = add_attr(&req, IFLA_IFNAME, name, strlen(name) + 1);
> > + if (ret < 0)
> > + return -1;
> > +
> > + memset(&nladdr, 0, sizeof(nladdr));
> > + nladdr.nl_family = AF_NETLINK;
> > +
> > + iov.iov_base = (void *)&req.nlmsg;
> > + iov.iov_len = req.nlmsg.nlmsg_len;
> > +
> > + memset(&msg, 0, sizeof(struct msghdr));
> > + msg.msg_name = &nladdr;
> > + msg.msg_namelen = sizeof(nladdr);
> > + msg.msg_iov = &iov;
> > + msg.msg_iovlen = 1;
> > +
> > + ret = sendmsg(kcp_rtnl_fd, &msg, 0);
> > + if (ret < 0) {
> > + RTE_LOG(ERR, CTRL_IF, "Send for destroy failed.\n");
> > + return -1;
> > + }
> > + return 0;
> > +}
> > +
> > +static int
> > +rte_eth_control_interface_destroy_one(uint8_t port_id)
> > +{
> > + rte_eth_rtnl_destroy(port_id);
> > + control_interface_ref_put();
> > + RTE_LOG(DEBUG, CTRL_IF, "Control interface destroyed for port:%u\n",
> > + port_id);
> > +
> > + return 0;
> > +}
> > +
> > +int
> > +rte_eth_control_interface_destroy(void)
> > +{
> > + int i;
> > + int ret = 0;
> > +
> > + for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
> > + if (rte_eth_dev_is_valid_port(i)) {
> > + ret = rte_eth_control_interface_destroy_one(i);
> > + if (ret < 0)
> > + return ret;
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +int
> > +rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec)
> > +{
> > + return control_interface_process_msg(flag, timeout_sec);
> > +}
> > +};
> ....
>
> > diff --git a/lib/librte_ctrl_if/rte_nl.c b/lib/librte_ctrl_if/rte_nl.c
> > new file mode 100644
> > index 0000000..adc5fa8
> > --- /dev/null
> > +++ b/lib/librte_ctrl_if/rte_nl.c
> > @@ -0,0 +1,274 @@
> > +/*-
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2016 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.
> > + */
> > +
> > +#include <unistd.h>
> > +
> > +#include <sys/socket.h>
> > +#include <linux/netlink.h>
> > +
> > +#include <rte_spinlock.h>
> > +#include <rte_ethdev.h>
> > +#include "rte_ethtool.h"
> > +#include "rte_nl.h"
> > +#include "rte_ctrl_if.h"
> > +
> > +#define MAX_PAYLOAD sizeof(struct kcp_ethtool_msg)
> > +
> > +struct ctrl_if_nl {
> > + union {
> > + struct nlmsghdr nlh;
> > + uint8_t nlmsg[NLMSG_SPACE(MAX_PAYLOAD)];
> > + };
> > + struct msghdr msg;
> > + struct iovec iov;
> > +};
> > +
> > +static int sock_fd = -1;
> > +pthread_t thread_id;
> > +
> > +struct sockaddr_nl dest_addr;
> > +
> > +pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
> > +pthread_mutex_t msg_lock = PTHREAD_MUTEX_INITIALIZER;
>
> Could you group related global variables into some struct.
> Then at least people would realise what lock and cond are supposed to synchronise.
OK
> Another good thing to do - make them static, if possible.
>
Right, I will make them static.
> > +
> > +static struct ctrl_if_nl nl_s;
> > +static struct ctrl_if_nl nl_r;
> > +
> > +static int kcp_ethtool_msg_count;
> > +static struct kcp_ethtool_msg msg_storage;
> > +
> > +static int
> > +nl_send(void *buf, size_t len)
> > +{
> > + int ret;
> > +
> > + if (nl_s.nlh.nlmsg_len < len) {
> > + RTE_LOG(ERR, CTRL_IF, "Message is too big, len:%zu\n", len);
> > + return -1;
> > + }
> > +
> > + if (!NLMSG_OK(&nl_s.nlh, NLMSG_SPACE(MAX_PAYLOAD))) {
> > + RTE_LOG(ERR, CTRL_IF, "Message is not OK\n");
> > + return -1;
> > + }
> > +
> > + /* Fill in the netlink message payload */
> > + memcpy(NLMSG_DATA(nl_s.nlmsg), buf, len);
> > +
> > + ret = sendmsg(sock_fd, &nl_s.msg, 0);
> > +
> > + if (ret < 0)
> > + RTE_LOG(ERR, CTRL_IF, "Failed nl msg send. ret:%d, err:%d\n",
> > + ret, errno);
> > + return ret;
> > +}
> > +
> > +static int
> > +nl_ethtool_msg_send(struct kcp_ethtool_msg *msg)
> > +{
> > + return nl_send((void *)msg, sizeof(struct kcp_ethtool_msg));
> > +}
> > +
> > +static void
> > +process_msg(struct kcp_ethtool_msg *msg)
> > +{
> > + if (msg->cmd_id > RTE_KCP_REQ_UNKNOWN) {
> > + msg->err = rte_eth_dev_control_process(msg->cmd_id,
> > + msg->port_id, msg->input_buffer,
> > + msg->output_buffer, &msg->output_buffer_len);
> > + } else {
> > + msg->err = rte_eth_dev_ethtool_process(msg->cmd_id,
> > + msg->port_id, msg->input_buffer,
> > + msg->output_buffer, &msg->output_buffer_len);
> > + }
> > +
> > + if (msg->err)
> > + memset(msg->output_buffer, 0, msg->output_buffer_len);
> > +
> > + nl_ethtool_msg_send(msg);
> > +}
> > +
> > +int
> > +control_interface_process_msg(int flag, unsigned int timeout_sec)
> > +{
> > + int ret = 0;
> > + struct timespec ts;
> > +
> > + pthread_mutex_lock(&msg_lock);
> > +
> > + clock_gettime(CLOCK_REALTIME, &ts);
> > + ts.tv_sec += timeout_sec;
> > + while (timeout_sec && !kcp_ethtool_msg_count && !ret)
> > + ret = pthread_cond_timedwait(&cond, &msg_lock, &ts);
>
>
> Better to avoid holding lock while calling process_msg().
> That is a good programming practice, as msg_lock protects only contents of the msg_storage.
> Again if by some reason process() would take a while, wouldn't stop your control thread.
> lock(); copy_message_into_local_buffer; unlock(); process();
>
OK
> > +
> > + switch (flag) {
> > + case RTE_ETHTOOL_CTRL_IF_PROCESS_MSG:
> > + if (kcp_ethtool_msg_count) {
> > + process_msg(&msg_storage);
> > + kcp_ethtool_msg_count = 0;
> > + }
> > + ret = 0;
> > + break;
> > +
> > + case RTE_ETHTOOL_CTRL_IF_DISCARD_MSG:
> > + if (kcp_ethtool_msg_count) {
> > + msg_storage.err = -1;
> > + nl_ethtool_msg_send(&msg_storage);
> > + kcp_ethtool_msg_count = 0;
> > + }
> > + ret = 0;
> > + break;
> > +
> > + default:
> > + ret = -1;
> > + break;
> > + }
> > + pthread_mutex_unlock(&msg_lock);
> > +
> > + return ret;
> > +}
> > +
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure
@ 2016-02-18 9:58 17% ` Xutao Sun
1 sibling, 0 replies; 200+ results
From: Xutao Sun @ 2016-02-18 9:58 UTC (permalink / raw)
To: dev
Change the fields of outer_mac and inner_mac from pointer to struct in order to keep the code's readability.
Signed-off-by: Xutao Sun <xutao.sun@intel.com>
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
app/test-pmd/cmdline.c | 6 ++++--
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_16_04.rst | 2 ++
drivers/net/i40e/i40e_ethdev.c | 12 ++++++------
lib/librte_ether/rte_eth_ctrl.h | 4 ++--
5 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 52e9f5f..c707318 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6640,8 +6640,10 @@ cmd_tunnel_filter_parsed(void *parsed_result,
struct rte_eth_tunnel_filter_conf tunnel_filter_conf;
int ret = 0;
- tunnel_filter_conf.outer_mac = &res->outer_mac;
- tunnel_filter_conf.inner_mac = &res->inner_mac;
+ rte_memcpy(&tunnel_filter_conf.outer_mac, &res->outer_mac,
+ ETHER_ADDR_LEN);
+ rte_memcpy(&tunnel_filter_conf.inner_mac, &res->inner_mac,
+ ETHER_ADDR_LEN);
tunnel_filter_conf.inner_vlan = res->inner_vlan;
if (res->ip_value.family == AF_INET) {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..a895364 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,11 +32,6 @@ Deprecation Notices
RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
but release 2.3 will.
-* ABI changes are planned for rte_eth_tunnel_filter_conf. Change the fields
- of outer_mac and inner_mac from pointer to struct in order to keep the
- code's readability. The release 2.2 does not contain these ABI changes, but
- release 2.3 will, and no backwards compatibility is planned.
-
* The scheduler statistics structure will change to allow keeping track of
RED actions.
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index eb1b3b2..2588225 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -104,6 +104,8 @@ ABI Changes
the previous releases and made in this release. Use fixed width quotes for
``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* The fields of outer_mac and inner_mac were changed from pointer
+ to struct in order to keep the code's readability.
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..7c22358 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5828,10 +5828,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
}
pfilter = cld_filter;
- (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac,
- sizeof(struct ether_addr));
- (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac,
- sizeof(struct ether_addr));
+ (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac,
+ ETHER_ADDR_LEN);
+ (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
+ ETHER_ADDR_LEN);
pfilter->inner_vlan = tunnel_filter->inner_vlan;
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
@@ -6131,13 +6131,13 @@ i40e_tunnel_filter_param_check(struct i40e_pf *pf,
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_OMAC) &&
- (is_zero_ether_addr(filter->outer_mac))) {
+ (is_zero_ether_addr(&filter->outer_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL outer MAC address");
return -EINVAL;
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_IMAC) &&
- (is_zero_ether_addr(filter->inner_mac))) {
+ (is_zero_ether_addr(&filter->inner_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL inner MAC address");
return -EINVAL;
}
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..30cbde7 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
* Tunneling Packet filter configuration.
*/
struct rte_eth_tunnel_filter_conf {
- struct ether_addr *outer_mac; /**< Outer MAC address filter. */
- struct ether_addr *inner_mac; /**< Inner MAC address filter. */
+ struct ether_addr outer_mac; /**< Outer MAC address filter. */
+ struct ether_addr inner_mac; /**< Inner MAC address filter. */
uint16_t inner_vlan; /**< Inner VLAN filter. */
enum rte_tunnel_iptype ip_type; /**< IP address type. */
union {
--
1.9.3
^ permalink raw reply [relevance 17%]
* [dpdk-dev] [PATCH v2 28/30] i40e: add/remove new device IDs
@ 2016-02-18 6:30 4% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2016-02-18 6:30 UTC (permalink / raw)
To: dev
It adds several new device IDs, and also removed one which is
not used at all.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 91 +++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 2 +-
drivers/net/i40e/i40e_rxtx.c | 8 +--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 8 ++-
4 files changed, 102 insertions(+), 7 deletions(-)
create mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
new file mode 100644
index 0000000..fec5e4d
--- /dev/null
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -0,0 +1,91 @@
+DPDK Release 2.3
+================
+
+New Features
+------------
+
+**Updated the i40e base driver.**
+
+ The i40e base driver was updated with changes including the
+ following:
+
+ * Use rx control AQ commands to read/write rx control registers.
+ * Add new X722 device IDs, and removed X710 one was never used.
+ * Expose registers for HASH/FD input set configuring.
+
+
+Resolved Issues
+---------------
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+* **i40e: Fixed failure of reading/writing rx control registers.**
+
+ Fixed i40e issue failing to read/write rx control registers when
+ under stress small traffic, which will result in application launch
+ failure.
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 6edd7dd..a5207fc 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -599,7 +599,7 @@ i40e_get_vsi_from_adapter(struct i40e_adapter *adapter)
return NULL;
hw = I40E_DEV_PRIVATE_TO_HW(adapter);
- if (hw->mac.type == I40E_MAC_VF) {
+ if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(adapter);
return &vf->vsi;
} else {
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 40cffc1..90ca819 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2113,7 +2113,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t base, bsf, tc_mapping;
int use_def_burst_func = 1;
- if (hw->mac.type == I40E_MAC_VF) {
+ if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
struct i40e_vf *vf =
I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
vsi = &vf->vsi;
@@ -2153,7 +2153,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->nb_rx_desc = nb_desc;
rxq->rx_free_thresh = rx_conf->rx_free_thresh;
rxq->queue_id = queue_idx;
- if (hw->mac.type == I40E_MAC_VF)
+ if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF)
rxq->reg_idx = queue_idx;
else /* PF device */
rxq->reg_idx = vsi->base_queue +
@@ -2330,7 +2330,7 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t tx_rs_thresh, tx_free_thresh;
uint16_t i, base, bsf, tc_mapping;
- if (hw->mac.type == I40E_MAC_VF) {
+ if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
struct i40e_vf *vf =
I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
vsi = &vf->vsi;
@@ -2458,7 +2458,7 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->hthresh = tx_conf->tx_thresh.hthresh;
txq->wthresh = tx_conf->tx_thresh.wthresh;
txq->queue_id = queue_idx;
- if (hw->mac.type == I40E_MAC_VF)
+ if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF)
txq->reg_idx = queue_idx;
else /* PF device */
txq->reg_idx = vsi->base_queue +
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index d088191..40ba98c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -496,7 +496,6 @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_82599_BYPASS)
#define I40E_DEV_ID_SFP_XL710 0x1572
#define I40E_DEV_ID_QEMU 0x1574
-#define I40E_DEV_ID_KX_A 0x157F
#define I40E_DEV_ID_KX_B 0x1580
#define I40E_DEV_ID_KX_C 0x1581
#define I40E_DEV_ID_QSFP_A 0x1583
@@ -507,13 +506,14 @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_82599_BYPASS)
#define I40E_DEV_ID_20G_KR2_A 0x1588
#define I40E_DEV_ID_10G_BASE_T4 0x1589
#define I40E_DEV_ID_X722_A0 0x374C
+#define I40E_DEV_ID_KX_X722 0x37CE
+#define I40E_DEV_ID_QSFP_X722 0x37CF
#define I40E_DEV_ID_SFP_X722 0x37D0
#define I40E_DEV_ID_1G_BASE_T_X722 0x37D1
#define I40E_DEV_ID_10G_BASE_T_X722 0x37D2
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_SFP_XL710)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_QEMU)
-RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_KX_A)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_KX_B)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_KX_C)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_QSFP_A)
@@ -524,6 +524,8 @@ RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_20G_KR2)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_20G_KR2_A)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_BASE_T4)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_X722_A0)
+RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_KX_X722)
+RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_QSFP_X722)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_SFP_X722)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_1G_BASE_T_X722)
RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_BASE_T_X722)
@@ -572,11 +574,13 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
#define I40E_DEV_ID_VF 0x154C
#define I40E_DEV_ID_VF_HV 0x1571
+#define I40E_DEV_ID_X722_A0_VF 0x374D
#define I40E_DEV_ID_X722_VF 0x37CD
#define I40E_DEV_ID_X722_VF_HV 0x37D9
RTE_PCI_DEV_ID_DECL_I40EVF(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_VF)
RTE_PCI_DEV_ID_DECL_I40EVF(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_VF_HV)
+RTE_PCI_DEV_ID_DECL_I40EVF(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_X722_A0_VF)
RTE_PCI_DEV_ID_DECL_I40EVF(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_X722_VF)
RTE_PCI_DEV_ID_DECL_I40EVF(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_X722_VF_HV)
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3 1/5] lib/librte_ether: change function name of tunnel port config
@ 2016-02-18 3:17 4% ` Wenzhuo Lu
0 siblings, 0 replies; 200+ results
From: Wenzhuo Lu @ 2016-02-18 3:17 UTC (permalink / raw)
To: dev
The names of function for tunnel port configuration are not
accurate. They're tunnel_add/del, better change them to
tunnel_port_add/del.
As it may be an ABI change if change the names directly, the
new functions are added but not remove the old ones. The old
ones will be removed in the next release after an ABI change
announcement.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
app/test-pmd/cmdline.c | 6 +++--
examples/tep_termination/vxlan_setup.c | 2 +-
lib/librte_ether/rte_ethdev.c | 45 ++++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 18 ++++++++++++++
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..4e71e90 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6780,9 +6780,11 @@ cmd_tunnel_udp_config_parsed(void *parsed_result,
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
if (!strcmp(res->what, "add"))
- ret = rte_eth_dev_udp_tunnel_add(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_add(res->port_id,
+ &tunnel_udp);
else
- ret = rte_eth_dev_udp_tunnel_delete(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_delete(res->port_id,
+ &tunnel_udp);
if (ret < 0)
printf("udp tunneling add error: (%s)\n", strerror(-ret));
diff --git a/examples/tep_termination/vxlan_setup.c b/examples/tep_termination/vxlan_setup.c
index 51ad133..8836603 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -191,7 +191,7 @@ vxlan_port_init(uint8_t port, struct rte_mempool *mbuf_pool)
/* Configure UDP port for UDP tunneling */
tunnel_udp.udp_port = udp_port;
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
- retval = rte_eth_dev_udp_tunnel_add(port, &tunnel_udp);
+ retval = rte_eth_dev_udp_tunnel_port_add(port, &tunnel_udp);
if (retval < 0)
return retval;
rte_eth_macaddr_get(port, &ports_eth_addr[port]);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..74428f4 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1987,6 +1987,28 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_add, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_add)(dev, udp_tunnel);
+}
+
+int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *udp_tunnel)
{
@@ -2010,6 +2032,29 @@ rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_del, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_del)(dev, udp_tunnel);
+}
+
+int
rte_eth_led_on(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..2e064f4 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1261,6 +1261,14 @@ typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
/**< @internal Program eeprom data */
+typedef int (*eth_udp_tunnel_port_add_t)(struct rte_eth_dev *dev,
+ struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Add tunneling UDP port */
+
+typedef int (*eth_udp_tunnel_port_del_t)(struct rte_eth_dev *dev,
+ struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Delete tunneling UDP port */
+
#ifdef RTE_NIC_BYPASS
enum {
@@ -1443,6 +1451,10 @@ struct eth_dev_ops {
eth_timesync_read_time timesync_read_time;
/** Set the device clock time. */
eth_timesync_write_time timesync_write_time;
+ /** Add UDP tunnel port. */
+ eth_udp_tunnel_port_add_t udp_tunnel_port_add;
+ /** Del UDP tunnel port. */
+ eth_udp_tunnel_port_del_t udp_tunnel_port_del;
};
/**
@@ -3408,6 +3420,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t port_id,
int
rte_eth_dev_udp_tunnel_add(uint8_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
+int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* Detete UDP tunneling port configuration of Ethernet device
@@ -3425,6 +3440,9 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
+int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* Check whether the filter type is supported on an Ethernet device.
--
1.9.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-17 1:54 11% ` [dpdk-dev] [PATCH v3] " Ziye Yang
2016-02-17 10:14 4% ` Bruce Richardson
2016-02-18 1:57 4% ` Zhang, Helin
@ 2016-02-18 2:46 4% ` Liang, Cunming
2 siblings, 0 replies; 200+ results
From: Liang, Cunming @ 2016-02-18 2:46 UTC (permalink / raw)
To: Yang, Ziye, dev; +Cc: Yang, Ziye
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ziye Yang
> Sent: Wednesday, February 17, 2016 9:55 AM
> To: dev@dpdk.org
> Cc: Yang, Ziye
> Subject: [dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in
> rte_pci_id structure
>
> From: Ziye <ziye.yang@intel.com>
>
> The purpose of this patch is used to add a new field
> "class" in rte_pci_id structure. The new class field includes
> class_id, subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info,
> which can be more flexible instead of probing the device by
> vendor_id OR device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which
> can be quite convenient.
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
It's better to use "doc:" as subject prefix, the others are good to go.
Acked-by: Cunming Liang <cunming.liang@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-17 1:54 11% ` [dpdk-dev] [PATCH v3] " Ziye Yang
2016-02-17 10:14 4% ` Bruce Richardson
@ 2016-02-18 1:57 4% ` Zhang, Helin
2016-02-18 2:46 4% ` Liang, Cunming
2 siblings, 0 replies; 200+ results
From: Zhang, Helin @ 2016-02-18 1:57 UTC (permalink / raw)
To: Yang, Ziye, dev; +Cc: Yang, Ziye
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ziye Yang
> Sent: Wednesday, February 17, 2016 9:55 AM
> To: dev@dpdk.org
> Cc: Yang, Ziye
> Subject: [dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field
> in rte_pci_id structure
>
> From: Ziye <ziye.yang@intel.com>
>
> The purpose of this patch is used to add a new field "class" in rte_pci_id
> structure. The new class field includes class_id, subcalss_id, programming
> interface of a pci device.
> With this field, we can identify pci device by its class info, which can be more
> flexible instead of probing the device by vendor_id OR device_id OR
> subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which can be quite
> convenient.
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library
2016-02-12 13:45 1% ` [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library Ferruh Yigit
@ 2016-02-17 19:58 0% ` Ananyev, Konstantin
2016-02-18 10:43 0% ` Yigit, Ferruh
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-02-17 19:58 UTC (permalink / raw)
To: Yigit, Ferruh, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, February 12, 2016 1:46 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library
>
> This library gets control messages form kernelspace and forwards them to
> librte_ether and returns response back to the kernelspace.
>
> Library does:
> 1) Trigger Linux virtual interface creation
> 2) Initialize the netlink socket communication
> 3) Provides process() API to the application that does processing the
> received messages
>
> This library requires corresponding kernel module to be inserted.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> ---
>
> v2:
> * User rtnetlink to create interfaces.
> * Add more ethtool support: get/set ringparam, set pauseparam.
> * return defined error instead of hardcoded value
> ---
> MAINTAINERS | 1 +
> config/common_linuxapp | 3 +-
> doc/api/doxy-api-index.md | 3 +-
> doc/api/doxy-api.conf | 1 +
> doc/guides/rel_notes/release_16_04.rst | 9 +
> lib/Makefile | 3 +-
> lib/librte_ctrl_if/Makefile | 58 ++++
> lib/librte_ctrl_if/rte_ctrl_if.c | 385 ++++++++++++++++++++++++
> lib/librte_ctrl_if/rte_ctrl_if.h | 115 ++++++++
> lib/librte_ctrl_if/rte_ctrl_if_version.map | 9 +
> lib/librte_ctrl_if/rte_ethtool.c | 450 +++++++++++++++++++++++++++++
> lib/librte_ctrl_if/rte_ethtool.h | 54 ++++
> lib/librte_ctrl_if/rte_nl.c | 274 ++++++++++++++++++
> lib/librte_ctrl_if/rte_nl.h | 49 ++++
> lib/librte_eal/common/include/rte_log.h | 3 +-
> mk/rte.app.mk | 3 +-
> 16 files changed, 1415 insertions(+), 5 deletions(-)
> create mode 100644 lib/librte_ctrl_if/Makefile
> create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c
> create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h
> create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map
> create mode 100644 lib/librte_ctrl_if/rte_ethtool.c
> create mode 100644 lib/librte_ctrl_if/rte_ethtool.h
> create mode 100644 lib/librte_ctrl_if/rte_nl.c
> create mode 100644 lib/librte_ctrl_if/rte_nl.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 09c56c7..91c98bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -256,6 +256,7 @@ F: doc/guides/sample_app_ug/kernel_nic_interface.rst
> Linux KCP
> M: Ferruh Yigit <ferruh.yigit@intel.com>
> F: lib/librte_eal/linuxapp/kcp/
> +F: lib/librte_ctrl_if/
>
> Linux AF_PACKET
> M: John W. Linville <linville@tuxdriver.com>
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 2f4eb1d..4bcd508 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -1,6 +1,6 @@
> # BSD LICENSE
> #
> -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> # All rights reserved.
> #
> # Redistribution and use in source and binary forms, with or without
> @@ -501,6 +501,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
> #
> CONFIG_RTE_KCP_KMOD=y
> CONFIG_RTE_KCP_KO_DEBUG=n
> +CONFIG_RTE_LIBRTE_CTRL_IF=y
>
> #
> # Compile vhost library
> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> index 7a91001..214d16e 100644
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped by topics:
> [common] (@ref rte_common.h),
> [ABI compat] (@ref rte_compat.h),
> [keepalive] (@ref rte_keepalive.h),
> - [version] (@ref rte_version.h)
> + [version] (@ref rte_version.h),
> + [control interface] (@ref rte_ctrl_if.h)
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> index 57e8b5d..fd69bf1 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -39,6 +39,7 @@ INPUT = doc/api/doxy-api-index.md \
> lib/librte_cmdline \
> lib/librte_compat \
> lib/librte_cryptodev \
> + lib/librte_ctrl_if \
> lib/librte_distributor \
> lib/librte_ether \
> lib/librte_hash \
> diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..1b1d34c 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -39,6 +39,14 @@ This section should contain new features added in this release. Sample format:
>
> Enabled virtio 1.0 support for virtio pmd driver.
>
> +* **Control interface support added.**
> +
> + To enable controlling DPDK ports by common Linux tools.
> + Following modules added to DPDK:
> +
> + * librte_ctrl_if library
> + * librte_eal/linuxapp/kcp kernel module
> +
>
> Resolved Issues
> ---------------
> @@ -113,6 +121,7 @@ The libraries prepended with a plus sign were incremented in this version.
> librte_acl.so.2
> librte_cfgfile.so.2
> librte_cmdline.so.1
> + + librte_ctrl_if.so.1
> librte_distributor.so.1
> librte_eal.so.2
> librte_hash.so.2
> diff --git a/lib/Makefile b/lib/Makefile
> index ef172ea..a50bc1e 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -1,6 +1,6 @@
> # BSD LICENSE
> #
> -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> # All rights reserved.
> #
> # Redistribution and use in source and binary forms, with or without
> @@ -58,6 +58,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port
> DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
> DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
> DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
> +DIRS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += librte_ctrl_if
>
> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
> diff --git a/lib/librte_ctrl_if/Makefile b/lib/librte_ctrl_if/Makefile
> new file mode 100644
> index 0000000..4e82966
> --- /dev/null
> +++ b/lib/librte_ctrl_if/Makefile
> @@ -0,0 +1,58 @@
> +# BSD LICENSE
> +#
> +# Copyright(c) 2016 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.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +#
> +# library name
> +#
> +LIB = librte_ctrl_if.a
> +
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS)
> +
> +EXPORT_MAP := rte_ctrl_if_version.map
> +
> +LIBABIVER := 1
> +
> +SRCS-y += rte_ctrl_if.c
> +SRCS-y += rte_nl.c
> +SRCS-y += rte_ethtool.c
> +
> +#
> +# Export include files
> +#
> +SYMLINK-y-include += rte_ctrl_if.h
> +
> +# this lib depends upon:
> +DEPDIRS-y += lib/librte_ether
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_ctrl_if/rte_ctrl_if.c b/lib/librte_ctrl_if/rte_ctrl_if.c
> new file mode 100644
> index 0000000..d16398f
> --- /dev/null
> +++ b/lib/librte_ctrl_if/rte_ctrl_if.c
> @@ -0,0 +1,385 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 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.
> + */
> +
> +#include <fcntl.h>
> +#include <unistd.h>
> +#include <time.h>
> +
> +#include <sys/ioctl.h>
> +#include <sys/socket.h>
> +#include <linux/netlink.h>
> +#include <linux/rtnetlink.h>
> +
> +#include <rte_ethdev.h>
> +#include "rte_ctrl_if.h"
> +#include "rte_nl.h"
> +
> +#define NAMESZ 32
> +#define IFNAME "dpdk"
> +#define BUFSZ 1024
> +
> +static int kcp_rtnl_fd = -1;
> +static int kcp_fd_ref;
> +
> +struct kcp_request {
> + struct nlmsghdr nlmsg;
> + char buf[BUFSZ];
> +};
> +
> +static int
> +conrol_interface_rtnl_init(void)
> +{
> + struct sockaddr_nl src;
> + int ret;
> +
> + kcp_rtnl_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
> + if (kcp_rtnl_fd < 0) {
> + RTE_LOG(ERR, CTRL_IF, "socket for create failed.\n");
> + return -1;
> + }
> +
> + memset(&src, 0, sizeof(struct sockaddr_nl));
> +
> + src.nl_family = AF_NETLINK;
> + src.nl_pid = getpid();
> +
> + ret = bind(kcp_rtnl_fd, (struct sockaddr *)&src,
> + sizeof(struct sockaddr_nl));
> + if (ret < 0) {
> + RTE_LOG(ERR, CTRL_IF, "Bind for create failed.\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +control_interface_init(void)
> +{
> + int ret;
> +
> + ret = conrol_interface_rtnl_init();
> + if (ret < 0) {
> + RTE_LOG(ERR, CTRL_IF, "Failed to initialize rtnetlink.\n");
> + return -1;
> + }
> +
> + ret = control_interface_nl_init();
> + if (ret < 0) {
> + RTE_LOG(ERR, CTRL_IF, "Failed to initialize netlink.\n");
> + close(kcp_rtnl_fd);
> + kcp_rtnl_fd = -1;
> + }
> +
> + return ret;
> +}
> +
> +static int
> +control_interface_ref_get(void)
> +{
> + int ret = 0;
> +
> + if (kcp_fd_ref == 0)
> + ret = control_interface_init();
> +
> + if (ret == 0)
> + kcp_fd_ref++;
> + else
> + RTE_LOG(ERR, CTRL_IF,
> + "Failed to initialize control interface.\n");
> +
> + return kcp_fd_ref;
> +}
> +
> +static void
> +control_interface_release(void)
> +{
> + close(kcp_rtnl_fd);
> + control_interface_nl_release();
> +}
> +
> +static int
> +control_interface_ref_put(void)
> +{
> + if (kcp_fd_ref == 0)
> + return 0;
> +
> + kcp_fd_ref--;
> +
> + if (kcp_fd_ref == 0)
> + control_interface_release();
> +
> + return kcp_fd_ref;
> +}
> +
> +static int
> +add_attr(struct kcp_request *req, unsigned short type, void *buf, size_t len)
> +{
> + struct rtattr *rta;
> + int nlmsg_len;
> +
> + nlmsg_len = NLMSG_ALIGN(req->nlmsg.nlmsg_len);
> + rta = (struct rtattr *)((char *)&req->nlmsg + nlmsg_len);
> + if (nlmsg_len + RTA_LENGTH(len) > sizeof(struct kcp_request))
> + return -1;
> + rta->rta_type = type;
> + rta->rta_len = RTA_LENGTH(len);
> + memcpy(RTA_DATA(rta), buf, len);
> + req->nlmsg.nlmsg_len = nlmsg_len + RTA_LENGTH(len);
> +
> + return 0;
> +}
> +
> +static struct
> +rtattr *add_attr_nested(struct kcp_request *req, unsigned short type)
> +{
> + struct rtattr *rta;
> + int nlmsg_len;
> +
> + nlmsg_len = NLMSG_ALIGN(req->nlmsg.nlmsg_len);
> + rta = (struct rtattr *)((char *)&req->nlmsg + nlmsg_len);
> + if (nlmsg_len + RTA_LENGTH(0) > sizeof(struct kcp_request))
> + return NULL;
> + rta->rta_type = type;
> + rta->rta_len = nlmsg_len;
> + req->nlmsg.nlmsg_len = nlmsg_len + RTA_LENGTH(0);
> +
> + return rta;
> +}
> +
> +static void
> +end_attr_nested(struct kcp_request *req, struct rtattr *rta)
> +{
> + rta->rta_len = req->nlmsg.nlmsg_len - rta->rta_len;
> +}
> +
> +static int
> +rte_eth_rtnl_create(uint8_t port_id)
> +{
> + struct kcp_request req;
> + struct ifinfomsg *info;
> + struct rtattr *rta1;
> + struct rtattr *rta2;
> + unsigned int pid = getpid();
> + char name[NAMESZ];
> + char type[NAMESZ];
> + struct iovec iov;
> + struct msghdr msg;
> + struct sockaddr_nl nladdr;
> + int ret;
> + char buf[BUFSZ];
> +
> + memset(&req, 0, sizeof(struct kcp_request));
> +
> + req.nlmsg.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
> + req.nlmsg.nlmsg_flags = NLM_F_REQUEST | NLM_F_CREATE | NLM_F_EXCL;
> + req.nlmsg.nlmsg_flags |= NLM_F_ACK;
> + req.nlmsg.nlmsg_type = RTM_NEWLINK;
> +
> + info = NLMSG_DATA(&req.nlmsg);
> +
> + info->ifi_family = AF_UNSPEC;
> + info->ifi_index = 0;
> +
> + snprintf(name, NAMESZ, IFNAME"%u", port_id);
> + ret = add_attr(&req, IFLA_IFNAME, name, strlen(name) + 1);
> + if (ret < 0)
> + return -1;
> +
> + rta1 = add_attr_nested(&req, IFLA_LINKINFO);
> + if (rta1 == NULL)
> + return -1;
> +
> + snprintf(type, NAMESZ, KCP_DEVICE);
> + ret = add_attr(&req, IFLA_INFO_KIND, type, strlen(type) + 1);
> + if (ret < 0)
> + return -1;
> +
> + rta2 = add_attr_nested(&req, IFLA_INFO_DATA);
> + if (rta2 == NULL)
> + return -1;
> +
> + ret = add_attr(&req, IFLA_KCP_PORTID, &port_id, sizeof(uint8_t));
> + if (ret < 0)
> + return -1;
> +
> + ret = add_attr(&req, IFLA_KCP_PID, &pid, sizeof(unsigned int));
> + if (ret < 0)
> + return -1;
> +
> + end_attr_nested(&req, rta2);
> + end_attr_nested(&req, rta1);
> +
> + memset(&nladdr, 0, sizeof(nladdr));
> + nladdr.nl_family = AF_NETLINK;
> +
> + iov.iov_base = (void *)&req.nlmsg;
> + iov.iov_len = req.nlmsg.nlmsg_len;
> +
> + memset(&msg, 0, sizeof(struct msghdr));
> + msg.msg_name = &nladdr;
> + msg.msg_namelen = sizeof(nladdr);
> + msg.msg_iov = &iov;
> + msg.msg_iovlen = 1;
> +
> + ret = sendmsg(kcp_rtnl_fd, &msg, 0);
> + if (ret < 0) {
> + RTE_LOG(ERR, CTRL_IF, "Send for create failed %d.\n", errno);
> + return -1;
> + }
> +
> + memset(buf, 0, sizeof(buf));
> + iov.iov_base = buf;
> + iov.iov_len = sizeof(buf);
> +
> + ret = recvmsg(kcp_rtnl_fd, &msg, 0);
> + if (ret < 0) {
> + RTE_LOG(ERR, CTRL_IF, "Recv for create failed.\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
It is probably would be good to make
rte_eth_control_interface_create_one()/rte_eth_control_interface_destroy_one()
a public API, so the user can decide which ports to expose to KCP, which not.
If that is not possible by some reason - then seems no reason to keep
control_interface_ref_get/ control_interface_ref_put.
> +static int
> +rte_eth_control_interface_create_one(uint8_t port_id)
> +{
> + int ret;
> +
> + if (control_interface_ref_get() != 0) {
> + ret = rte_eth_rtnl_create(port_id);
> + RTE_LOG(DEBUG, CTRL_IF,
> + "Control interface %s for port:%u\n",
> + ret < 0 ? "failed" : "created", port_id);
> + }
> +
> + return 0;
> +}
> +
> +int
> +rte_eth_control_interface_create(void)
> +{
> + int i;
> + int ret = 0;
> +
> + for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
> + if (rte_eth_dev_is_valid_port(i)) {
> + ret = rte_eth_control_interface_create_one(i);
> + if (ret < 0)
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +
> +static int
> +rte_eth_rtnl_destroy(uint8_t port_id)
> +{
> + struct kcp_request req;
> + struct ifinfomsg *info;
> + char name[NAMESZ];
> + struct iovec iov;
> + struct msghdr msg;
> + struct sockaddr_nl nladdr;
> + int ret;
> +
> + memset(&req, 0, sizeof(struct kcp_request));
> +
> + req.nlmsg.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
> + req.nlmsg.nlmsg_flags = NLM_F_REQUEST;
> + req.nlmsg.nlmsg_type = RTM_DELLINK;
> +
> + info = NLMSG_DATA(&req.nlmsg);
> +
> + info->ifi_family = AF_UNSPEC;
> + info->ifi_index = 0;
> +
> + snprintf(name, NAMESZ, IFNAME"%u", port_id);
> + ret = add_attr(&req, IFLA_IFNAME, name, strlen(name) + 1);
> + if (ret < 0)
> + return -1;
> +
> + memset(&nladdr, 0, sizeof(nladdr));
> + nladdr.nl_family = AF_NETLINK;
> +
> + iov.iov_base = (void *)&req.nlmsg;
> + iov.iov_len = req.nlmsg.nlmsg_len;
> +
> + memset(&msg, 0, sizeof(struct msghdr));
> + msg.msg_name = &nladdr;
> + msg.msg_namelen = sizeof(nladdr);
> + msg.msg_iov = &iov;
> + msg.msg_iovlen = 1;
> +
> + ret = sendmsg(kcp_rtnl_fd, &msg, 0);
> + if (ret < 0) {
> + RTE_LOG(ERR, CTRL_IF, "Send for destroy failed.\n");
> + return -1;
> + }
> + return 0;
> +}
> +
> +static int
> +rte_eth_control_interface_destroy_one(uint8_t port_id)
> +{
> + rte_eth_rtnl_destroy(port_id);
> + control_interface_ref_put();
> + RTE_LOG(DEBUG, CTRL_IF, "Control interface destroyed for port:%u\n",
> + port_id);
> +
> + return 0;
> +}
> +
> +int
> +rte_eth_control_interface_destroy(void)
> +{
> + int i;
> + int ret = 0;
> +
> + for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
> + if (rte_eth_dev_is_valid_port(i)) {
> + ret = rte_eth_control_interface_destroy_one(i);
> + if (ret < 0)
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +
> +int
> +rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec)
> +{
> + return control_interface_process_msg(flag, timeout_sec);
> +}
> +};
....
> diff --git a/lib/librte_ctrl_if/rte_nl.c b/lib/librte_ctrl_if/rte_nl.c
> new file mode 100644
> index 0000000..adc5fa8
> --- /dev/null
> +++ b/lib/librte_ctrl_if/rte_nl.c
> @@ -0,0 +1,274 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 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.
> + */
> +
> +#include <unistd.h>
> +
> +#include <sys/socket.h>
> +#include <linux/netlink.h>
> +
> +#include <rte_spinlock.h>
> +#include <rte_ethdev.h>
> +#include "rte_ethtool.h"
> +#include "rte_nl.h"
> +#include "rte_ctrl_if.h"
> +
> +#define MAX_PAYLOAD sizeof(struct kcp_ethtool_msg)
> +
> +struct ctrl_if_nl {
> + union {
> + struct nlmsghdr nlh;
> + uint8_t nlmsg[NLMSG_SPACE(MAX_PAYLOAD)];
> + };
> + struct msghdr msg;
> + struct iovec iov;
> +};
> +
> +static int sock_fd = -1;
> +pthread_t thread_id;
> +
> +struct sockaddr_nl dest_addr;
> +
> +pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
> +pthread_mutex_t msg_lock = PTHREAD_MUTEX_INITIALIZER;
Could you group related global variables into some struct.
Then at least people would realise what lock and cond are supposed to synchronise.
Another good thing to do - make them static, if possible.
> +
> +static struct ctrl_if_nl nl_s;
> +static struct ctrl_if_nl nl_r;
> +
> +static int kcp_ethtool_msg_count;
> +static struct kcp_ethtool_msg msg_storage;
> +
> +static int
> +nl_send(void *buf, size_t len)
> +{
> + int ret;
> +
> + if (nl_s.nlh.nlmsg_len < len) {
> + RTE_LOG(ERR, CTRL_IF, "Message is too big, len:%zu\n", len);
> + return -1;
> + }
> +
> + if (!NLMSG_OK(&nl_s.nlh, NLMSG_SPACE(MAX_PAYLOAD))) {
> + RTE_LOG(ERR, CTRL_IF, "Message is not OK\n");
> + return -1;
> + }
> +
> + /* Fill in the netlink message payload */
> + memcpy(NLMSG_DATA(nl_s.nlmsg), buf, len);
> +
> + ret = sendmsg(sock_fd, &nl_s.msg, 0);
> +
> + if (ret < 0)
> + RTE_LOG(ERR, CTRL_IF, "Failed nl msg send. ret:%d, err:%d\n",
> + ret, errno);
> + return ret;
> +}
> +
> +static int
> +nl_ethtool_msg_send(struct kcp_ethtool_msg *msg)
> +{
> + return nl_send((void *)msg, sizeof(struct kcp_ethtool_msg));
> +}
> +
> +static void
> +process_msg(struct kcp_ethtool_msg *msg)
> +{
> + if (msg->cmd_id > RTE_KCP_REQ_UNKNOWN) {
> + msg->err = rte_eth_dev_control_process(msg->cmd_id,
> + msg->port_id, msg->input_buffer,
> + msg->output_buffer, &msg->output_buffer_len);
> + } else {
> + msg->err = rte_eth_dev_ethtool_process(msg->cmd_id,
> + msg->port_id, msg->input_buffer,
> + msg->output_buffer, &msg->output_buffer_len);
> + }
> +
> + if (msg->err)
> + memset(msg->output_buffer, 0, msg->output_buffer_len);
> +
> + nl_ethtool_msg_send(msg);
> +}
> +
> +int
> +control_interface_process_msg(int flag, unsigned int timeout_sec)
> +{
> + int ret = 0;
> + struct timespec ts;
> +
> + pthread_mutex_lock(&msg_lock);
> +
> + clock_gettime(CLOCK_REALTIME, &ts);
> + ts.tv_sec += timeout_sec;
> + while (timeout_sec && !kcp_ethtool_msg_count && !ret)
> + ret = pthread_cond_timedwait(&cond, &msg_lock, &ts);
Better to avoid holding lock while calling process_msg().
That is a good programming practice, as msg_lock protects only contents of the msg_storage.
Again if by some reason process() would take a while, wouldn't stop your control thread.
lock(); copy_message_into_local_buffer; unlock(); process();
> +
> + switch (flag) {
> + case RTE_ETHTOOL_CTRL_IF_PROCESS_MSG:
> + if (kcp_ethtool_msg_count) {
> + process_msg(&msg_storage);
> + kcp_ethtool_msg_count = 0;
> + }
> + ret = 0;
> + break;
> +
> + case RTE_ETHTOOL_CTRL_IF_DISCARD_MSG:
> + if (kcp_ethtool_msg_count) {
> + msg_storage.err = -1;
> + nl_ethtool_msg_send(&msg_storage);
> + kcp_ethtool_msg_count = 0;
> + }
> + ret = 0;
> + break;
> +
> + default:
> + ret = -1;
> + break;
> + }
> + pthread_mutex_unlock(&msg_lock);
> +
> + return ret;
> +}
> +
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 1/3] ethdev: add helper functions to get eth_dev and dev private data
2016-02-17 14:20 3% [dpdk-dev] [PATCH 0/3] ethdev: add helper functions to get eth_dev and dev private data Ferruh Yigit
@ 2016-02-17 14:20 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2016-02-17 14:20 UTC (permalink / raw)
To: dev
This is to provide abstraction and reduce global variable access.
Global variable rte_eth_devices kept exported to not break ABI.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
lib/librte_ether/rte_ethdev.h | 44 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 6afb5a9..7209b83 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -3881,6 +3881,50 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *eth_dev, const char *name,
uint16_t queue_id, size_t size,
unsigned align, int socket_id);
+/**
+ * Return rte_eth_dev by port id
+ *
+ * This is to abstract device access and limit global variable access.
+ *
+ * @param port_id
+ * port_id of the device to return.
+ */
+static inline struct rte_eth_dev *
+rte_eth_by_port(uint16_t port_id)
+{
+ return &rte_eth_devices[port_id];
+}
+
+/**
+ * Return rte_eth_dev private data structure by port id
+ *
+ * This is to abstract device private data access and
+ * limit global variable access.
+ *
+ * @param port_id
+ * port_id of the device to return.
+ */
+static inline void *
+rte_eth_private_by_port(uint16_t port_id)
+{
+ return rte_eth_devices[port_id].data->dev_private;
+}
+
+/**
+ * Return rte_eth_dev private data structure by rte_eth_dev
+ *
+ * This is helper function to access device private data, also
+ * provides some abstraction on how private data kept.
+ *
+ * @param dev
+ * rte_eth_dev
+ */
+static inline void *
+rte_eth_private_by_dev(struct rte_eth_dev *dev)
+{
+ return dev->data->dev_private;
+}
+
#ifdef __cplusplus
}
#endif
--
2.5.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 0/3] ethdev: add helper functions to get eth_dev and dev private data
@ 2016-02-17 14:20 3% Ferruh Yigit
2016-02-17 14:20 3% ` [dpdk-dev] [PATCH 1/3] " Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2016-02-17 14:20 UTC (permalink / raw)
To: dev
This is to provide abstraction and reduce global variable access.
Global variable rte_eth_devices kept exported to not break ABI.
Bonding driver not selected on purpose, just it seems it is using
rte_eth_devices heavily.
There are a few more usage in drivers but they left as it is because they
are in fast path code.
Ferruh Yigit (3):
ethdev: add helper functions to get eth_dev and dev private data
app/test: use ethdev helper functions
bonding: use ethdev helper functions
app/test/test_link_bonding.c | 35 ++++++++------
app/test/virtual_pmd.c | 51 +++++++++------------
drivers/net/bonding/rte_eth_bond_8023ad.c | 10 ++--
drivers/net/bonding/rte_eth_bond_api.c | 76 +++++++++++++++----------------
drivers/net/bonding/rte_eth_bond_args.c | 13 ++++--
drivers/net/bonding/rte_eth_bond_pmd.c | 47 +++++++++++--------
lib/librte_ether/rte_ethdev.h | 44 ++++++++++++++++++
7 files changed, 167 insertions(+), 109 deletions(-)
--
2.5.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-17 1:54 11% ` [dpdk-dev] [PATCH v3] " Ziye Yang
@ 2016-02-17 10:14 4% ` Bruce Richardson
2016-02-18 1:57 4% ` Zhang, Helin
2016-02-18 2:46 4% ` Liang, Cunming
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2016-02-17 10:14 UTC (permalink / raw)
To: Ziye Yang; +Cc: dev
On Wed, Feb 17, 2016 at 09:54:33AM +0800, Ziye Yang wrote:
> From: Ziye <ziye.yang@intel.com>
>
> The purpose of this patch is used to add a new field
> "class" in rte_pci_id structure. The new class field includes
> class_id, subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info,
> which can be more flexible instead of probing the device by
> vendor_id OR device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which
> can be quite convenient.
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-16 4:15 15% ` [dpdk-dev] [PATCH v2] " Ziye Yang
2016-02-16 10:11 7% ` Bruce Richardson
@ 2016-02-17 1:54 11% ` Ziye Yang
2016-02-17 10:14 4% ` Bruce Richardson
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ziye Yang @ 2016-02-17 1:54 UTC (permalink / raw)
To: dev; +Cc: Ziye
From: Ziye <ziye.yang@intel.com>
The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..9fa2433 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,9 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for struct rte_pci_id, i.e., add new field ``class``.
+ This new added ``class`` field can be used to probe pci device by class
+ related info. This change should impact size of struct rte_pci_id and struct
+ rte_pci_device. The release 16.04 does not contain these ABI changes, but
+ release 16.07 will.
--
1.9.3
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages
2016-02-16 14:48 3% ` [dpdk-dev] [PATCH 0/6] external mempool manager David Hunt
@ 2016-02-16 14:48 4% ` David Hunt
2016-02-19 13:33 7% ` Olivier MATZ
0 siblings, 1 reply; 200+ results
From: David Hunt @ 2016-02-16 14:48 UTC (permalink / raw)
To: dev
v2: Kept all the NEXT_ABI defs to this patch so as to make the
previous patches easier to read, and also to imake it clear what
code is necessary to keep ABI compatibility when NEXT_ABI is
disabled.
Signed-off-by: David Hunt <david.hunt@intel.com>
---
app/test/Makefile | 2 +
app/test/test_mempool_perf.c | 3 +
lib/librte_mbuf/rte_mbuf.c | 7 ++
lib/librte_mempool/Makefile | 2 +
lib/librte_mempool/rte_mempool.c | 240 ++++++++++++++++++++++++++++++++++++++-
lib/librte_mempool/rte_mempool.h | 68 ++++++++++-
6 files changed, 320 insertions(+), 2 deletions(-)
diff --git a/app/test/Makefile b/app/test/Makefile
index 9a2f75f..8fcf0c2 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -74,7 +74,9 @@ SRCS-$(CONFIG_RTE_LIBRTE_TIMER) += test_timer_perf.c
SRCS-$(CONFIG_RTE_LIBRTE_TIMER) += test_timer_racecond.c
SRCS-y += test_mempool.c
+ifeq ($(CONFIG_RTE_NEXT_ABI),y)
SRCS-y += test_ext_mempool.c
+endif
SRCS-y += test_mempool_perf.c
SRCS-y += test_mbuf.c
diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index 091c1df..ca69e49 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -161,6 +161,9 @@ per_lcore_mempool_test(__attribute__((unused)) void *arg)
n_get_bulk);
if (unlikely(ret < 0)) {
rte_mempool_dump(stdout, mp);
+#ifndef RTE_NEXT_ABI
+ rte_ring_dump(stdout, mp->ring);
+#endif
/* in this case, objects are lost... */
return -1;
}
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 42b0cd1..967d987 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -167,6 +167,7 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
mbp_priv.mbuf_data_room_size = data_room_size;
mbp_priv.mbuf_priv_size = priv_size;
+#ifdef RTE_NEXT_ABI
#ifdef RTE_MEMPOOL_HANDLER_EXT
return rte_mempool_create_ext(name, n, elt_size,
cache_size, sizeof(struct rte_pktmbuf_pool_private),
@@ -179,6 +180,12 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
rte_pktmbuf_pool_init, &mbp_priv, rte_pktmbuf_init, NULL,
socket_id, 0);
#endif
+#else
+ return rte_mempool_create(name, n, elt_size,
+ cache_size, sizeof(struct rte_pktmbuf_pool_private),
+ rte_pktmbuf_pool_init, &mbp_priv, rte_pktmbuf_init, NULL,
+ socket_id, 0);
+#endif
}
/* do some sanity checks on a mbuf: panic if it fails */
diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index 4f72546..8038785 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -42,9 +42,11 @@ LIBABIVER := 1
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool.c
+ifeq ($(CONFIG_RTE_NEXT_ABI),y)
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool_default.c
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool_stack.c
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += custom_mempool.c
+endif
ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_dom0_mempool.c
endif
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 44bc92f..53e44ff 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -59,7 +59,9 @@
#include <rte_spinlock.h>
#include "rte_mempool.h"
+#ifdef RTE_NEXT_ABI
#include "rte_mempool_internal.h"
+#endif
TAILQ_HEAD(rte_mempool_list, rte_tailq_entry);
@@ -400,6 +402,7 @@ rte_mempool_create(const char *name, unsigned n, unsigned elt_size,
MEMPOOL_PG_SHIFT_MAX);
}
+#ifdef RTE_NEXT_ABI
/*
* Common mempool create function.
* Create the mempool over already allocated chunk of memory.
@@ -698,6 +701,229 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
return mp;
}
+#else
+/*
+ * Create the mempool over already allocated chunk of memory.
+ * That external memory buffer can consists of physically disjoint pages.
+ * Setting vaddr to NULL, makes mempool to fallback to original behaviour
+ * and allocate space for mempool and it's elements as one big chunk of
+ * physically continuos memory.
+ * */
+struct rte_mempool *
+rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
+ unsigned cache_size, unsigned private_data_size,
+ rte_mempool_ctor_t *mp_init, void *mp_init_arg,
+ rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
+ int socket_id, unsigned flags, void *vaddr,
+ const phys_addr_t paddr[], uint32_t pg_num, uint32_t pg_shift)
+{
+ char mz_name[RTE_MEMZONE_NAMESIZE];
+ char rg_name[RTE_RING_NAMESIZE];
+ struct rte_mempool_list *mempool_list;
+ struct rte_mempool *mp = NULL;
+ struct rte_tailq_entry *te;
+ struct rte_ring *r;
+ const struct rte_memzone *mz;
+ size_t mempool_size;
+ int mz_flags = RTE_MEMZONE_1GB|RTE_MEMZONE_SIZE_HINT_ONLY;
+ int rg_flags = 0;
+ void *obj;
+ struct rte_mempool_objsz objsz;
+ void *startaddr;
+ int page_size = getpagesize();
+
+ /* compilation-time checks */
+ RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
+ RTE_CACHE_LINE_MASK) != 0);
+#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+ RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
+ RTE_CACHE_LINE_MASK) != 0);
+ RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
+ RTE_CACHE_LINE_MASK) != 0);
+#endif
+#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+ RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
+ RTE_CACHE_LINE_MASK) != 0);
+ RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, stats) &
+ RTE_CACHE_LINE_MASK) != 0);
+#endif
+
+ mempool_list = RTE_TAILQ_CAST(rte_mempool_tailq.head, rte_mempool_list);
+
+ /* asked cache too big */
+ if (cache_size > RTE_MEMPOOL_CACHE_MAX_SIZE ||
+ CALC_CACHE_FLUSHTHRESH(cache_size) > n) {
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ /* check that we have both VA and PA */
+ if (vaddr != NULL && paddr == NULL) {
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ /* Check that pg_num and pg_shift parameters are valid. */
+ if (pg_num < RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ /* "no cache align" imply "no spread" */
+ if (flags & MEMPOOL_F_NO_CACHE_ALIGN)
+ flags |= MEMPOOL_F_NO_SPREAD;
+
+ /* ring flags */
+ if (flags & MEMPOOL_F_SP_PUT)
+ rg_flags |= RING_F_SP_ENQ;
+ if (flags & MEMPOOL_F_SC_GET)
+ rg_flags |= RING_F_SC_DEQ;
+
+ /* calculate mempool object sizes. */
+ if (!rte_mempool_calc_obj_size(elt_size, flags, &objsz)) {
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ rte_rwlock_write_lock(RTE_EAL_MEMPOOL_RWLOCK);
+
+ /* allocate the ring that will be used to store objects */
+ /* Ring functions will return appropriate errors if we are
+ * running as a secondary process etc., so no checks made
+ * in this function for that condition */
+ snprintf(rg_name, sizeof(rg_name), RTE_MEMPOOL_MZ_FORMAT, name);
+ r = rte_ring_create(rg_name, rte_align32pow2(n+1), socket_id, rg_flags);
+ if (r == NULL)
+ goto exit;
+
+ /*
+ * reserve a memory zone for this mempool: private data is
+ * cache-aligned
+ */
+ private_data_size = (private_data_size +
+ RTE_MEMPOOL_ALIGN_MASK) & (~RTE_MEMPOOL_ALIGN_MASK);
+
+ if (!rte_eal_has_hugepages()) {
+ /*
+ * expand private data size to a whole page, so that the
+ * first pool element will start on a new standard page
+ */
+ int head = sizeof(struct rte_mempool);
+ int new_size = (private_data_size + head) % page_size;
+
+ if (new_size)
+ private_data_size += page_size - new_size;
+ }
+
+ /* try to allocate tailq entry */
+ te = rte_zmalloc("MEMPOOL_TAILQ_ENTRY", sizeof(*te), 0);
+ if (te == NULL) {
+ RTE_LOG(ERR, MEMPOOL, "Cannot allocate tailq entry!\n");
+ goto exit;
+ }
+
+ /*
+ * If user provided an external memory buffer, then use it to
+ * store mempool objects. Otherwise reserve a memzone that is large
+ * enough to hold mempool header and metadata plus mempool objects.
+ */
+ mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+ mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
+ if (vaddr == NULL)
+ mempool_size += (size_t)objsz.total_size * n;
+
+ if (!rte_eal_has_hugepages()) {
+ /*
+ * we want the memory pool to start on a page boundary,
+ * because pool elements crossing page boundaries would
+ * result in discontiguous physical addresses
+ */
+ mempool_size += page_size;
+ }
+
+ snprintf(mz_name, sizeof(mz_name), RTE_MEMPOOL_MZ_FORMAT, name);
+
+ mz = rte_memzone_reserve(mz_name, mempool_size, socket_id, mz_flags);
+
+ /*
+ * no more memory: in this case we loose previously reserved
+ * space for the ring as we cannot free it
+ */
+ if (mz == NULL) {
+ rte_free(te);
+ goto exit;
+ }
+
+ if (rte_eal_has_hugepages()) {
+ startaddr = (void *)mz->addr;
+ } else {
+ /* align memory pool start address on a page boundary */
+ unsigned long addr = (unsigned long)mz->addr;
+
+ if (addr & (page_size - 1)) {
+ addr += page_size;
+ addr &= ~(page_size - 1);
+ }
+ startaddr = (void *)addr;
+ }
+
+ /* init the mempool structure */
+ mp = startaddr;
+ memset(mp, 0, sizeof(*mp));
+ snprintf(mp->name, sizeof(mp->name), "%s", name);
+ mp->phys_addr = mz->phys_addr;
+ mp->ring = r;
+ mp->size = n;
+ mp->flags = flags;
+ mp->elt_size = objsz.elt_size;
+ mp->header_size = objsz.header_size;
+ mp->trailer_size = objsz.trailer_size;
+ mp->cache_size = cache_size;
+ mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
+ mp->private_data_size = private_data_size;
+
+ /* calculate address of the first element for continuous mempool. */
+ obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
+ private_data_size;
+ obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
+
+ /* populate address translation fields. */
+ mp->pg_num = pg_num;
+ mp->pg_shift = pg_shift;
+ mp->pg_mask = RTE_LEN2MASK(mp->pg_shift, typeof(mp->pg_mask));
+
+ /* mempool elements allocated together with mempool */
+ if (vaddr == NULL) {
+ mp->elt_va_start = (uintptr_t)obj;
+ mp->elt_pa[0] = mp->phys_addr +
+ (mp->elt_va_start - (uintptr_t)mp);
+
+ /* mempool elements in a separate chunk of memory. */
+ } else {
+ mp->elt_va_start = (uintptr_t)vaddr;
+ memcpy(mp->elt_pa, paddr, sizeof(mp->elt_pa[0]) * pg_num);
+ }
+
+ mp->elt_va_end = mp->elt_va_start;
+
+ /* call the initializer */
+ if (mp_init)
+ mp_init(mp, mp_init_arg);
+
+ mempool_populate(mp, n, 1, obj_init, obj_init_arg);
+
+ te->data = (void *) mp;
+
+ rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
+ TAILQ_INSERT_TAIL(mempool_list, te, next);
+ rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
+
+exit:
+ rte_rwlock_write_unlock(RTE_EAL_MEMPOOL_RWLOCK);
+
+ return mp;
+}
+#endif
/* Return the number of entries in the mempool */
unsigned
@@ -705,7 +931,11 @@ rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
+#ifdef RTE_NEXT_ABI
count = rte_mempool_ext_get_count(mp);
+#else
+ count = rte_ring_count(mp->ring);
+#endif
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
{
@@ -861,6 +1091,9 @@ rte_mempool_dump(FILE *f, const struct rte_mempool *mp)
fprintf(f, "mempool <%s>@%p\n", mp->name, mp);
fprintf(f, " flags=%x\n", mp->flags);
+#ifndef RTE_NEXT_ABI
+ fprintf(f, " ring=<%s>@%p\n", mp->ring->name, mp->ring);
+#endif
fprintf(f, " phys_addr=0x%" PRIx64 "\n", mp->phys_addr);
fprintf(f, " size=%"PRIu32"\n", mp->size);
fprintf(f, " header_size=%"PRIu32"\n", mp->header_size);
@@ -883,7 +1116,11 @@ rte_mempool_dump(FILE *f, const struct rte_mempool *mp)
mp->size);
cache_count = rte_mempool_dump_cache(f, mp);
+#ifdef RTE_NEXT_ABI
common_count = rte_mempool_ext_get_count(mp);
+#else
+ common_count = rte_ring_count(mp->ring);
+#endif
if ((cache_count + common_count) > mp->size)
common_count = mp->size - cache_count;
fprintf(f, " common_pool_count=%u\n", common_count);
@@ -978,7 +1215,7 @@ void rte_mempool_walk(void (*func)(const struct rte_mempool *, void *),
rte_rwlock_read_unlock(RTE_EAL_MEMPOOL_RWLOCK);
}
-
+#ifdef RTE_NEXT_ABI
/* create the mempool using an external mempool manager */
struct rte_mempool *
rte_mempool_create_ext(const char *name, unsigned n, unsigned elt_size,
@@ -1004,3 +1241,4 @@ rte_mempool_create_ext(const char *name, unsigned n, unsigned elt_size,
}
+#endif
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 8d8201f..e676296 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -88,8 +88,10 @@ extern "C" {
struct rte_mempool_debug_stats {
uint64_t put_bulk; /**< Number of puts. */
uint64_t put_objs; /**< Number of objects successfully put. */
+#ifdef RTE_NEXT_ABI
uint64_t put_pool_bulk; /**< Number of puts into pool. */
uint64_t put_pool_objs; /**< Number of objects into pool. */
+#endif
uint64_t get_success_bulk; /**< Successful allocation number. */
uint64_t get_success_objs; /**< Objects successfully allocated. */
uint64_t get_fail_bulk; /**< Failed allocation number. */
@@ -177,6 +179,7 @@ struct rte_mempool_objtlr {
#endif
};
+#ifdef RTE_NEXT_ABI
/* Handler functions for external mempool support */
typedef void *(*rte_mempool_alloc_t)(struct rte_mempool *mp,
const char *name, unsigned n, int socket_id, unsigned flags);
@@ -250,12 +253,16 @@ rte_mempool_ext_get_count(const struct rte_mempool *mp);
*/
int
rte_mempool_ext_free(struct rte_mempool *mp);
+#endif
/**
* The RTE mempool structure.
*/
struct rte_mempool {
char name[RTE_MEMPOOL_NAMESIZE]; /**< Name of mempool. */
+#ifndef RTE_NEXT_ABI
+ struct rte_ring *ring; /**< Ring to store objects. */
+#endif
phys_addr_t phys_addr; /**< Phys. addr. of mempool struct. */
int flags; /**< Flags of the mempool. */
uint32_t size; /**< Size of the mempool. */
@@ -269,10 +276,12 @@ struct rte_mempool {
unsigned private_data_size; /**< Size of private data. */
+#ifdef RTE_NEXT_ABI
/* Common pool data structure pointer */
void *rt_pool;
int16_t handler_idx;
+#endif
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/** Per-lcore local cache. */
@@ -303,9 +312,10 @@ struct rte_mempool {
#define MEMPOOL_F_NO_CACHE_ALIGN 0x0002 /**< Do not align objs on cache lines.*/
#define MEMPOOL_F_SP_PUT 0x0004 /**< Default put is "single-producer".*/
#define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
+#ifdef RTE_NEXT_ABI
#define MEMPOOL_F_USE_STACK 0x0010 /**< Use a stack for the common pool. */
#define MEMPOOL_F_INT_HANDLER 0x0020 /**< Using internal mempool handler */
-
+#endif
/**
* @internal When debug is enabled, store some statistics.
@@ -836,7 +846,11 @@ void rte_mempool_dump(FILE *f, const struct rte_mempool *mp);
*/
static inline void __attribute__((always_inline))
__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
+#ifdef RTE_NEXT_ABI
unsigned n, __attribute__((unused)) int is_mp)
+#else
+ unsigned n, int is_mp)
+#endif
{
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
@@ -852,7 +866,12 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* cache is not enabled or single producer or non-EAL thread */
+#ifdef RTE_NEXT_ABI
if (unlikely(cache_size == 0 || lcore_id >= RTE_MAX_LCORE))
+#else
+ if (unlikely(cache_size == 0 || is_mp == 0 ||
+ lcore_id >= RTE_MAX_LCORE))
+#endif
goto ring_enqueue;
/* Go straight to ring if put would overflow mem allocated for cache */
@@ -875,9 +894,15 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
cache->len += n;
+#ifdef RTE_NEXT_ABI
if (unlikely(cache->len >= flushthresh)) {
rte_mempool_ext_put_bulk(mp, &cache->objs[cache_size],
cache->len - cache_size);
+#else
+ if (cache->len >= flushthresh) {
+ rte_ring_mp_enqueue_bulk(mp->ring, &cache->objs[cache_size],
+ cache->len - cache_size);
+#endif
cache->len = cache_size;
}
@@ -886,10 +911,28 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
ring_enqueue:
#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#ifdef RTE_NEXT_ABI
/* Increment stats counter to tell us how many pool puts happened */
__MEMPOOL_STAT_ADD(mp, put_pool, n);
rte_mempool_ext_put_bulk(mp, obj_table, n);
+#else
+ /* push remaining objects in ring */
+#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+ if (is_mp) {
+ if (rte_ring_mp_enqueue_bulk(mp->ring, obj_table, n) < 0)
+ rte_panic("cannot put objects in mempool\n");
+ } else {
+ if (rte_ring_sp_enqueue_bulk(mp->ring, obj_table, n) < 0)
+ rte_panic("cannot put objects in mempool\n");
+ }
+#else
+ if (is_mp)
+ rte_ring_mp_enqueue_bulk(mp->ring, obj_table, n);
+ else
+ rte_ring_sp_enqueue_bulk(mp->ring, obj_table, n);
+#endif
+#endif
}
@@ -1013,7 +1056,11 @@ rte_mempool_put(struct rte_mempool *mp, void *obj)
*/
static inline int __attribute__((always_inline))
__mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
+#ifdef RTE_NEXT_ABI
unsigned n, __attribute__((unused))int is_mc)
+#else
+ unsigned n, int is_mc)
+#endif
{
int ret;
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
@@ -1024,8 +1071,13 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
uint32_t cache_size = mp->cache_size;
/* cache is not enabled or single consumer */
+#ifdef RTE_NEXT_ABI
if (unlikely(cache_size == 0 || n >= cache_size ||
lcore_id >= RTE_MAX_LCORE))
+#else
+ if (unlikely(cache_size == 0 || is_mc == 0 ||
+ n >= cache_size || lcore_id >= RTE_MAX_LCORE))
+#endif
goto ring_dequeue;
cache = &mp->local_cache[lcore_id];
@@ -1037,8 +1089,13 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
uint32_t req = n + (cache_size - cache->len);
/* How many do we require i.e. number to fill the cache + the request */
+#ifdef RTE_NEXT_ABI
ret = rte_mempool_ext_get_bulk(mp,
&cache->objs[cache->len], req);
+#else
+ ret = rte_ring_mc_dequeue_bulk(mp->ring,
+ &cache->objs[cache->len], req);
+#endif
if (unlikely(ret < 0)) {
/*
* In the offchance that we are buffer constrained,
@@ -1066,7 +1123,14 @@ ring_dequeue:
#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* get remaining objects from ring */
+#ifdef RTE_NEXT_ABI
ret = rte_mempool_ext_get_bulk(mp, obj_table, n);
+#else
+ if (is_mc)
+ ret = rte_ring_mc_dequeue_bulk(mp->ring, obj_table, n);
+ else
+ ret = rte_ring_sc_dequeue_bulk(mp->ring, obj_table, n);
+#endif
if (ret < 0)
__MEMPOOL_STAT_ADD(mp, get_fail, n);
@@ -1468,6 +1532,7 @@ ssize_t rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, size_t elt_sz,
*/
void rte_mempool_walk(void (*func)(const struct rte_mempool *, void *arg),
void *arg);
+#ifdef RTE_NEXT_ABI
/**
* Function to get the name of a mempool handler
@@ -1541,6 +1606,7 @@ rte_mempool_create_ext(const char *name, unsigned n, unsigned elt_size,
rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
int socket_id, unsigned flags,
const char *handler_name);
+#endif
#ifdef __cplusplus
}
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 0/6] external mempool manager
@ 2016-02-16 14:48 3% ` David Hunt
2016-02-16 14:48 4% ` [dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages David Hunt
1 sibling, 1 reply; 200+ results
From: David Hunt @ 2016-02-16 14:48 UTC (permalink / raw)
To: dev
Hi list.
Here's the v2 version of a proposed patch for an external mempool manager
v2 changes:
* There was a lot of duplicate code between rte_mempool_xmem_create and
rte_mempool_create_ext. This has now been refactored and is now
hopefully cleaner.
* The RTE_NEXT_ABI define is now used to allow building of the library
in a format that is compatible with binaries built against previous
versions of DPDK.
* Changes out of code reviews. Hopefully I've got most of them included.
The External Mempool Manager is an extension to the mempool API that allows
users to add and use an external mempool manager, which allows external memory
subsystems such as external hardware memory management systems and software
based memory allocators to be used with DPDK.
The existing API to the internal DPDK mempool manager will remain unchanged
and will be backward compatible. However, there will be an ABI breakage, as
the mempool struct is changing. These changes are all contained withing
RTE_NEXT_ABI defs, and the current or next code can be changed with
the CONFIG_RTE_NEXT_ABI config setting
There are two aspects to external mempool manager.
1. Adding the code for your new mempool handler. This is achieved by adding a
new mempool handler source file into the librte_mempool library, and
using the REGISTER_MEMPOOL_HANDLER macro.
2. Using the new API to call rte_mempool_create_ext to create a new mempool
using the name parameter to identify which handler to use.
New API calls added
1. A new mempool 'create' function which accepts mempool handler name.
2. A new mempool 'rte_get_mempool_handler' function which accepts mempool
handler name, and returns the index to the relevant set of callbacks for
that mempool handler
Several external mempool managers may be used in the same application. A new
mempool can then be created by using the new 'create' function, providing the
mempool handler name to point the mempool to the relevant mempool manager
callback structure.
The old 'create' function can still be called by legacy programs, and will
internally work out the mempool handle based on the flags provided (single
producer, single consumer, etc). By default handles are created internally to
implement the built-in DPDK mempool manager and mempool types.
The external mempool manager needs to provide the following functions.
1. alloc - allocates the mempool memory, and adds each object onto a ring
2. put - puts an object back into the mempool once an application has
finished with it
3. get - gets an object from the mempool for use by the application
4. get_count - gets the number of available objects in the mempool
5. free - frees the mempool memory
Every time a get/put/get_count is called from the application/PMD, the
callback for that mempool is called. These functions are in the fastpath,
and any unoptimised handlers may limit performance.
The new APIs are as follows:
1. rte_mempool_create_ext
struct rte_mempool *
rte_mempool_create_ext(const char * name, unsigned n,
unsigned cache_size, unsigned private_data_size,
int socket_id, unsigned flags,
const char * handler_name);
2. rte_mempool_get_handler_name
char *
rte_mempool_get_handler_name(struct rte_mempool *mp);
Please see rte_mempool.h for further information on the parameters.
The important thing to note is that the mempool handler is passed by name
to rte_mempool_create_ext, and that in turn calls rte_get_mempool_handler to
get the handler index, which is stored in the rte_memool structure. This
allow multiple processes to use the same mempool, as the function pointers
are accessed via handler index.
The mempool handler structure contains callbacks to the implementation of
the handler, and is set up for registration as follows:
static struct rte_mempool_handler handler_sp_mc = {
.name = "ring_sp_mc",
.alloc = rte_mempool_common_ring_alloc,
.put = common_ring_sp_put,
.get = common_ring_mc_get,
.get_count = common_ring_get_count,
.free = common_ring_free,
};
And then the following macro will register the handler in the array of handlers
REGISTER_MEMPOOL_HANDLER(handler_mp_mc);
For and example of a simple malloc based mempool manager, see
lib/librte_mempool/custom_mempool.c
For an example of API usage, please see app/test/test_ext_mempool.c, which
implements a rudimentary mempool manager using simple mallocs for each
mempool object (custom_mempool.c).
David Hunt (6):
mempool: add external mempool manager support
mempool: add stack (lifo) based external mempool handler
mempool: adds a simple ring-based mempool handler using mallocs for
objects
mempool: add autotest for external mempool custom example
mempool: allow rte_pktmbuf_pool_create switch between memool handlers
mempool: add in the RTE_NEXT_ABI protection for ABI breakages
app/test/Makefile | 3 +
app/test/test_ext_mempool.c | 451 +++++++++++++++++++++++++++++
app/test/test_mempool_perf.c | 2 +
config/common_bsdapp | 2 +
config/common_linuxapp | 2 +
lib/librte_mbuf/rte_mbuf.c | 15 +
lib/librte_mempool/Makefile | 5 +
lib/librte_mempool/custom_mempool.c | 146 ++++++++++
lib/librte_mempool/rte_mempool.c | 383 ++++++++++++++++++++++--
lib/librte_mempool/rte_mempool.h | 213 +++++++++++++-
lib/librte_mempool/rte_mempool_default.c | 236 +++++++++++++++
lib/librte_mempool/rte_mempool_internal.h | 75 +++++
lib/librte_mempool/rte_mempool_stack.c | 164 +++++++++++
lib/librte_mempool/rte_mempool_version.map | 1 +
14 files changed, 1665 insertions(+), 33 deletions(-)
create mode 100644 app/test/test_ext_mempool.c
create mode 100644 lib/librte_mempool/custom_mempool.c
create mode 100644 lib/librte_mempool/rte_mempool_default.c
create mode 100644 lib/librte_mempool/rte_mempool_internal.h
create mode 100644 lib/librte_mempool/rte_mempool_stack.c
--
2.5.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-16 10:11 7% ` Bruce Richardson
@ 2016-02-16 10:34 7% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-16 10:34 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Ziye Yang, dev
2016-02-16 10:11, Bruce Richardson:
> Thomas, is there some reason why the deprecation notices are not called out in
> the release notes for a new release? Why are they kept separately?
No strong reason.
It is part of the release notes but not in the versioned section.
Probably because there is no interest in keeping the history of planned
deprecations in the release notes. When the API/ABI is changed, the deprecation
notice is replaced by an entry in the versioned section.
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-16 4:15 15% ` [dpdk-dev] [PATCH v2] " Ziye Yang
@ 2016-02-16 10:11 7% ` Bruce Richardson
2016-02-16 10:34 7% ` Thomas Monjalon
2016-02-17 1:54 11% ` [dpdk-dev] [PATCH v3] " Ziye Yang
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2016-02-16 10:11 UTC (permalink / raw)
To: Ziye Yang; +Cc: dev
On Tue, Feb 16, 2016 at 12:15:19PM +0800, Ziye Yang wrote:
> From: Ziye <ziye.yang@intel.com>
>
> The purpose of this patch is used to add a new field
> "class" in rte_pci_id structure. The new class field includes
> class_id, subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info,
> which can be more flexible instead of probing the device by
> vendor_id OR device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which
> can be quite convenient.
>
> As release_2_3.rst is replaced with release_16_04.rst.
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> ---
> doc/guides/rel_notes/release_16_04.rst | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..fe843a5 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
> ABI Changes
> -----------
>
> -* Add a short 1-2 sentence description of the ABI change that was announced in
> - the previous releases and made in this release. Use fixed width quotes for
> - ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
> +* New field ``class`` is added into ``rte_pci_id`` structure. This new
> + added ``class`` field can be used to probe pci devices by class related
> + info. With this new field, the size of structure ``rte_pci_device`` will
> + be increased.
>
>
> Shared Library Versions
> --
Hi,
since this is new ABI change announcement, and not one that was previously
announced and is now being applied, this announcement should go in the
deprecation.rst file, rather than release_16_04.rst.
Thomas, is there some reason why the deprecation notices are not called out in
the release notes for a new release? Why are they kept separately?
/Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-16 7:43 9% ` Yang, Ziye
@ 2016-02-16 7:55 7% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-02-16 7:55 UTC (permalink / raw)
To: Yang, Ziye, dev
On 02/16/2016 09:43 AM, Yang, Ziye wrote:
> Hi Panu,
>
> " ABI breakage announcements go into doc/guides/rel_notes/deprecation.rst,
> see the examples there. Also you can't break the ABI in the version under development but only the next one, so right now the earliest ABI breakage opportunity is in the release *after* 16.04, which is supposed to be 16.07 according to the roadmap."
>
> So I only need to do the ABI breakage announcements into doc/guides/rel_notes/deprecation.rst, right?
>
Yes.
The version-specific release notes ABI/API changes section is to be
updated along with the actual changes to the code.
If you haven't already done so, do read
http://dpdk.org/doc/guides/contributing/versioning.html
- Panu -
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-16 7:38 9% ` Panu Matilainen
@ 2016-02-16 7:43 9% ` Yang, Ziye
2016-02-16 7:55 7% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Yang, Ziye @ 2016-02-16 7:43 UTC (permalink / raw)
To: Panu Matilainen, dev
Hi Panu,
" ABI breakage announcements go into doc/guides/rel_notes/deprecation.rst,
see the examples there. Also you can't break the ABI in the version under development but only the next one, so right now the earliest ABI breakage opportunity is in the release *after* 16.04, which is supposed to be 16.07 according to the roadmap."
So I only need to do the ABI breakage announcements into doc/guides/rel_notes/deprecation.rst, right?
Thanks.
Best Regards,
Ziye Yang
-----Original Message-----
From: Panu Matilainen [mailto:pmatilai@redhat.com]
Sent: Tuesday, February 16, 2016 3:39 PM
To: Yang, Ziye <ziye.yang@intel.com>; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
On 02/16/2016 05:16 AM, Ziye Yang wrote:
> From: Ziye <ziye.yang@intel.com>
>
> The purpose of this patch is used to add a new field "class" in
> rte_pci_id structure. The new class field includes class_id,
> subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info, which
> can be more flexible instead of probing the device by vendor_id OR
> device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which can
> be quite convenient.
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> ---
> doc/guides/rel_notes/release_16_04.rst | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_16_04.rst
> b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..fe843a5 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
> ABI Changes
> -----------
>
> -* Add a short 1-2 sentence description of the ABI change that was
> announced in
> - the previous releases and made in this release. Use fixed width
> quotes for
> - ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
> +* New field ``class`` is added into ``rte_pci_id`` structure. This
> +new
> + added ``class`` field can be used to probe pci devices by class
> +related
> + info. With this new field, the size of structure ``rte_pci_device``
> +will
> + be increased.
>
>
> Shared Library Versions
>
ABI breakage announcements go into doc/guides/rel_notes/deprecation.rst,
see the examples there. Also you can't break the ABI in the version under development but only the next one, so right now the earliest ABI breakage opportunity is in the release *after* 16.04, which is supposed to be 16.07 according to the roadmap.
- Panu -
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
2016-02-16 3:16 15% [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure Ziye Yang
@ 2016-02-16 7:38 9% ` Panu Matilainen
2016-02-16 7:43 9% ` Yang, Ziye
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-02-16 7:38 UTC (permalink / raw)
To: Ziye Yang, dev
On 02/16/2016 05:16 AM, Ziye Yang wrote:
> From: Ziye <ziye.yang@intel.com>
>
> The purpose of this patch is used to add a new field
> "class" in rte_pci_id structure. The new class field includes
> class_id, subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info,
> which can be more flexible instead of probing the device by
> vendor_id OR device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which
> can be quite convenient.
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> ---
> doc/guides/rel_notes/release_16_04.rst | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..fe843a5 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
> ABI Changes
> -----------
>
> -* Add a short 1-2 sentence description of the ABI change that was announced in
> - the previous releases and made in this release. Use fixed width quotes for
> - ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
> +* New field ``class`` is added into ``rte_pci_id`` structure. This new
> + added ``class`` field can be used to probe pci devices by class related
> + info. With this new field, the size of structure ``rte_pci_device`` will
> + be increased.
>
>
> Shared Library Versions
>
ABI breakage announcements go into doc/guides/rel_notes/deprecation.rst,
see the examples there. Also you can't break the ABI in the version
under development but only the next one, so right now the earliest ABI
breakage opportunity is in the release *after* 16.04, which is supposed
to be 16.07 according to the roadmap.
- Panu -
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v2 0/5] clean-up cpuflags
2016-02-06 22:17 3% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2016-02-06 22:17 1% ` [dpdk-dev] [PATCH v2 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
@ 2016-02-16 7:30 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-16 7:30 UTC (permalink / raw)
To: david.marchand; +Cc: dev, viktorin
2016-02-06 23:17, Thomas Monjalon:
> Following the work of Ferruh, I suggest this cleanup to remove as much
> as possible of the code from the cpuflags headers.
> The goal is to un-inline these functions (not performance sensitive)
> and remove the CPU flags table from the ABI (just added recently).
> The bonus is to stop mimic x86 in ARM and PPC implementations.
>
> WARNING: it has not been tested nor compiled on Tilera and POWER8.
>
> v2 changes:
> - fix maintainers file
> - fix include from C++ app
> - fix missing REG_PLATFORM for ARM
> - suggested ARM refactor from Jerin
Applied
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
2016-01-25 2:36 9% [dpdk-dev] [PATCH] PCI: ABI change request for adding new field in rte_pci_id structure Ziye Yang
@ 2016-02-16 4:15 15% ` Ziye Yang
2016-02-16 10:11 7% ` Bruce Richardson
2016-02-17 1:54 11% ` [dpdk-dev] [PATCH v3] " Ziye Yang
0 siblings, 2 replies; 200+ results
From: Ziye Yang @ 2016-02-16 4:15 UTC (permalink / raw)
To: dev; +Cc: Ziye
From: Ziye <ziye.yang@intel.com>
The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.
As release_2_3.rst is replaced with release_16_04.rst.
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
---
doc/guides/rel_notes/release_16_04.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..fe843a5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
ABI Changes
-----------
-* Add a short 1-2 sentence description of the ABI change that was announced in
- the previous releases and made in this release. Use fixed width quotes for
- ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+ added ``class`` field can be used to probe pci devices by class related
+ info. With this new field, the size of structure ``rte_pci_device`` will
+ be increased.
Shared Library Versions
--
1.9.3
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
[not found] <1453689419-237252>
@ 2016-02-16 4:08 15% ` Ziye Yang
0 siblings, 0 replies; 200+ results
From: Ziye Yang @ 2016-02-16 4:08 UTC (permalink / raw)
To: dev; +Cc: Ziye
From: Ziye <ziye.yang@intel.com>
The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.
As release_2_3.rst is replaced with release_16_04.rst
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
---
doc/guides/rel_notes/release_16_04.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..fe843a5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
ABI Changes
-----------
-* Add a short 1-2 sentence description of the ABI change that was announced in
- the previous releases and made in this release. Use fixed width quotes for
- ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+ added ``class`` field can be used to probe pci devices by class related
+ info. With this new field, the size of structure ``rte_pci_device`` will
+ be increased.
Shared Library Versions
--
1.9.3
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure
@ 2016-02-16 3:16 15% Ziye Yang
2016-02-16 7:38 9% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Ziye Yang @ 2016-02-16 3:16 UTC (permalink / raw)
To: dev; +Cc: Ziye
From: Ziye <ziye.yang@intel.com>
The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
---
doc/guides/rel_notes/release_16_04.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..fe843a5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
ABI Changes
-----------
-* Add a short 1-2 sentence description of the ABI change that was announced in
- the previous releases and made in this release. Use fixed width quotes for
- ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+ added ``class`` field can be used to probe pci devices by class related
+ info. With this new field, the size of structure ``rte_pci_device`` will
+ be increased.
Shared Library Versions
--
1.9.3
^ permalink raw reply [relevance 15%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-15 10:21 0% ` Hunt, David
@ 2016-02-15 12:31 0% ` Olivier MATZ
0 siblings, 0 replies; 200+ results
From: Olivier MATZ @ 2016-02-15 12:31 UTC (permalink / raw)
To: Hunt, David, Thomas Monjalon, Wiles, Keith; +Cc: dev
Hi David,
On 02/15/2016 11:21 AM, Hunt, David wrote:
> On 15/02/2016 10:15, Olivier MATZ wrote:
>> On 02/15/2016 10:58 AM, Hunt, David wrote:
>>> I'm working on that at the moment with the external mempool handler
>>> code. However, it crossed my mind that we have a choice to use symbol
>>> versioning OR use NEXT_ABI. Would one method be preferred over the
>>> other?
>>
>> I think symbol versioning should always be preferred when possible.
>>
>> In your case, as far as I remember, your are updating the rte_mempool
>> structure, which is accessed by static inline functions. I don't think
>> it is easily manageable with symbol versioning. Moreover, the ABI will
>> already be broken by Keith's patch, so I think it's less problematic
>> to have other patches breaking the ABI at the same time.
>
> OK, Thanks for that. I'll use NEXT_ABI in this case so. :)
Just to let you know in case you missed it: Keith's patch (v3 [1] and
v4 [2]) finally does not have the NEXT_ABI ifdefs, because it was
too heavy.
So for your patches it will also depend on the complexity of the
changes. You can have a try with NEXT_ABI and see if the code is
still maintainable or not. If not, the process is to push a deprecation
notice for 16.04 and the code for 16.07.
Regards,
Olivier
[1] v3: http://dpdk.org/ml/archives/dev/2016-February/033004.html
[2] v4: http://dpdk.org/ml/archives/dev/2016-February/033102.html
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-15 10:15 4% ` Olivier MATZ
@ 2016-02-15 10:21 0% ` Hunt, David
2016-02-15 12:31 0% ` Olivier MATZ
0 siblings, 1 reply; 200+ results
From: Hunt, David @ 2016-02-15 10:21 UTC (permalink / raw)
To: Olivier MATZ, Thomas Monjalon, Wiles, Keith; +Cc: dev
On 15/02/2016 10:15, Olivier MATZ wrote:
> Hi David,
>
> On 02/15/2016 10:58 AM, Hunt, David wrote:
>> On 12/02/2016 15:50, Olivier MATZ wrote:
>>> - NEXT_ABI does make the code harder to read in this case, and I'm
>>> thinking about the patchset from David Hunt (external mempool handler)
>>> that will be in the same situation, and maybe also another patchset
>>> I'm working on.
>>
>> Olivier,
>> I'm working on that at the moment with the external mempool handler
>> code. However, it crossed my mind that we have a choice to use symbol
>> versioning OR use NEXT_ABI. Would one method be preferred over the other?
>
> I think symbol versioning should always be preferred when possible.
>
> In your case, as far as I remember, your are updating the rte_mempool
> structure, which is accessed by static inline functions. I don't think
> it is easily manageable with symbol versioning. Moreover, the ABI will
> already be broken by Keith's patch, so I think it's less problematic
> to have other patches breaking the ABI at the same time.
OK, Thanks for that. I'll use NEXT_ABI in this case so. :)
Regards,
David.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
@ 2016-02-15 10:15 4% ` Olivier MATZ
2016-02-15 10:21 0% ` Hunt, David
0 siblings, 1 reply; 200+ results
From: Olivier MATZ @ 2016-02-15 10:15 UTC (permalink / raw)
To: Hunt, David, Thomas Monjalon, Wiles, Keith; +Cc: dev
Hi David,
On 02/15/2016 10:58 AM, Hunt, David wrote:
> On 12/02/2016 15:50, Olivier MATZ wrote:
>> - NEXT_ABI does make the code harder to read in this case, and I'm
>> thinking about the patchset from David Hunt (external mempool handler)
>> that will be in the same situation, and maybe also another patchset
>> I'm working on.
>
> Olivier,
> I'm working on that at the moment with the external mempool handler
> code. However, it crossed my mind that we have a choice to use symbol
> versioning OR use NEXT_ABI. Would one method be preferred over the other?
I think symbol versioning should always be preferred when possible.
In your case, as far as I remember, your are updating the rte_mempool
structure, which is accessed by static inline functions. I don't think
it is easily manageable with symbol versioning. Moreover, the ABI will
already be broken by Keith's patch, so I think it's less problematic
to have other patches breaking the ABI at the same time.
Regards,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4] mempool: reduce rte_mempool structure size
2016-02-12 18:36 3% ` [dpdk-dev] [PATCH v4] " Keith Wiles
@ 2016-02-15 9:20 0% ` Olivier MATZ
0 siblings, 0 replies; 200+ results
From: Olivier MATZ @ 2016-02-15 9:20 UTC (permalink / raw)
To: Keith Wiles, dev
On 02/12/2016 07:36 PM, Keith Wiles wrote:
> The rte_mempool structure is changed, which will cause an ABI change
> for this structure. Providing backward compat is not reasonable
> here as this structure is used in multiple defines/inlines.
>
> Allow mempool cache support to be dynamic depending on if the
> mempool being created needs cache support. Saves about 1.5M of
> memory used by the rte_mempool structure.
>
> Allocating small mempools which do not require cache can consume
> larges amounts of memory if you have a number of these mempools.
>
> Change to be effective in release 16.07.
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
(for 16.07)
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v8 4/4] doc: update with link changes
@ 2016-02-14 22:17 8% ` Marc Sune
2016-02-18 18:14 0% ` Mcnamara, John
0 siblings, 1 reply; 200+ results
From: Marc Sune @ 2016-02-14 22:17 UTC (permalink / raw)
To: dev, Wenzhuo Lu, Helin Zhang, Harish Patil, Jing Chen
Add new features, ABI changes and resolved issues notice for
the refactored link patch.
Signed-off-by: Marc Sune <marcdevel@gmail.com>
---
doc/guides/rel_notes/release_2_3.rst | 102 +++++++++++++++++++++++++++++++++++
1 file changed, 102 insertions(+)
create mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
new file mode 100644
index 0000000..b10c3bb
--- /dev/null
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -0,0 +1,102 @@
+DPDK Release 2.3
+================
+
+New Features
+------------
+
+* **ethdev: define a set of advertised link speeds.**
+
+ Allowing to define a set of advertised speeds for auto-negociation,
+ explicitely disable link auto-negociation (single speed) and full
+ auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+ define a set of advertised link speeds.**
+
+ ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+ application to recover the supported speeds for that ethernet device.
+
+
+Resolved Issues
+---------------
+
+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+ 100Gbps in Mbps (100000) exceeds 16 bit max value of ``link_speed`` in
+ ``rte_eth_link``.
+
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical speeds
+ to bitmap fields.
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+* The ethdev rte_eth_link and rte_eth_conf structures were changed to
+ support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
--
2.1.4
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH] doc: deprecation notice in 16.04 for rte_mempool changes
@ 2016-02-12 18:38 5% Keith Wiles
0 siblings, 0 replies; 200+ results
From: Keith Wiles @ 2016-02-12 18:38 UTC (permalink / raw)
To: dev
Deprecation notice for 16.04 for changes to occur in
release 16.07 for rte_mempool memory reduction.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..748a48d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,13 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI change is planned for the rte_mempool structure to allow mempool
+ cache support to be dynamic depending on the mempool being created
+ needing cache support. Saves about 1.5M of memory per rte_mempool structure
+ by removing the per lcore cache memory. Change will occur in DPDK 16.07
+ release and will skip the define RTE_NEXT_ABI in DPDK 16.04 release. The
+ code effected is app/test/test_mempool.c and librte_mempool/rte_mempool.[ch].
+ The rte_mempool.local_cache will be converted from an array to a pointer to
+ allow for dynamic allocation of the per lcore cache memory.
+
--
2.5.4 (Apple Git-61)
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v4] mempool: reduce rte_mempool structure size
2016-02-09 17:30 2% ` [dpdk-dev] [PATCH v2] mempool: reduce " Keith Wiles
2016-02-10 21:18 7% ` [dpdk-dev] [PATCH v3] " Keith Wiles
@ 2016-02-12 18:36 3% ` Keith Wiles
2016-02-15 9:20 0% ` Olivier MATZ
2 siblings, 1 reply; 200+ results
From: Keith Wiles @ 2016-02-12 18:36 UTC (permalink / raw)
To: dev
The rte_mempool structure is changed, which will cause an ABI change
for this structure. Providing backward compat is not reasonable
here as this structure is used in multiple defines/inlines.
Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support. Saves about 1.5M of
memory used by the rte_mempool structure.
Allocating small mempools which do not require cache can consume
larges amounts of memory if you have a number of these mempools.
Change to be effective in release 16.07.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
* Patch v4 remove RTE_NEXT_ABI ifdefs for 16.07 integration, plus split
out the deprecation notice into another patch email for 16.04 release.
* Patch v3 fix up the ifdefs to correct some problems in removing ifdef
lines. Added the ABI deprecation notice to the document file.
* Patch v2 to add some comments and setup for RTE_NEXT_ABI changes.
app/test/test_mempool.c | 4 +--
lib/librte_mempool/rte_mempool.c | 55 ++++++++++++++++++----------------------
lib/librte_mempool/rte_mempool.h | 29 ++++++++++-----------
3 files changed, 40 insertions(+), 48 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index f0f823b..10e1fa4 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -122,8 +122,8 @@ test_mempool_basic(void)
return -1;
printf("get private data\n");
- if (rte_mempool_get_priv(mp) !=
- (char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
+ if (rte_mempool_get_priv(mp) != (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
return -1;
printf("get physical address of an object\n");
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..6f067f3 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -452,12 +452,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
/* compilation-time checks */
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
RTE_CACHE_LINE_MASK) != 0);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
RTE_CACHE_LINE_MASK) != 0);
- RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
- RTE_CACHE_LINE_MASK) != 0);
-#endif
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
RTE_CACHE_LINE_MASK) != 0);
@@ -527,9 +523,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
*/
int head = sizeof(struct rte_mempool);
int new_size = (private_data_size + head) % page_size;
- if (new_size) {
+ if (new_size)
private_data_size += page_size - new_size;
- }
}
/* try to allocate tailq entry */
@@ -544,7 +539,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
* store mempool objects. Otherwise reserve a memzone that is large
* enough to hold mempool header and metadata plus mempool objects.
*/
- mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+ mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
+ mempool_size += private_data_size;
mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
if (vaddr == NULL)
mempool_size += (size_t)objsz.total_size * n;
@@ -598,8 +594,15 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
mp->private_data_size = private_data_size;
+ /*
+ * local_cache pointer is set even if cache_size is zero.
+ * The local_cache points to just past the elt_pa[] array.
+ */
+ mp->local_cache = (struct rte_mempool_cache *)
+ ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
+
/* calculate address of the first element for continuous mempool. */
- obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
+ obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
private_data_size;
obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
@@ -613,9 +616,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->elt_va_start = (uintptr_t)obj;
mp->elt_pa[0] = mp->phys_addr +
(mp->elt_va_start - (uintptr_t)mp);
-
- /* mempool elements in a separate chunk of memory. */
} else {
+ /* mempool elements in a separate chunk of memory. */
mp->elt_va_start = (uintptr_t)vaddr;
memcpy(mp->elt_pa, paddr, sizeof (mp->elt_pa[0]) * pg_num);
}
@@ -645,19 +647,15 @@ unsigned
rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
+ unsigned lcore_id;
count = rte_ring_count(mp->ring);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
- {
- unsigned lcore_id;
- if (mp->cache_size == 0)
- return count;
+ if (mp->cache_size == 0)
+ return count;
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
- count += mp->local_cache[lcore_id].len;
- }
-#endif
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
+ count += mp->local_cache[lcore_id].len;
/*
* due to race condition (access to len is not locked), the
@@ -672,13 +670,16 @@ rte_mempool_count(const struct rte_mempool *mp)
static unsigned
rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
unsigned lcore_id;
unsigned count = 0;
unsigned cache_count;
fprintf(f, " cache infos:\n");
fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
+
+ if (mp->cache_size == 0)
+ return count;
+
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
cache_count = mp->local_cache[lcore_id].len;
fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
@@ -686,11 +687,6 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
}
fprintf(f, " total_cache_count=%u\n", count);
return count;
-#else
- RTE_SET_USED(mp);
- fprintf(f, " cache disabled\n");
- return 0;
-#endif
}
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -755,13 +751,16 @@ mempool_audit_cookies(const struct rte_mempool *mp)
#define mempool_audit_cookies(mp) do {} while(0)
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* check cookies before and after objects */
static void
mempool_audit_cache(const struct rte_mempool *mp)
{
/* check cache size consistency */
unsigned lcore_id;
+
+ if (mp->cache_size == 0)
+ return;
+
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
@@ -770,10 +769,6 @@ mempool_audit_cache(const struct rte_mempool *mp)
}
}
}
-#else
-#define mempool_audit_cache(mp) do {} while(0)
-#endif
-
/* check the consistency of mempool (size, cookies, ...) */
void
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 9745bf0..8595e77 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -95,7 +95,6 @@ struct rte_mempool_debug_stats {
} __rte_cache_aligned;
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/**
* A structure that stores a per-core object cache.
*/
@@ -107,7 +106,6 @@ struct rte_mempool_cache {
*/
void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
} __rte_cache_aligned;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/**
* A structure that stores the size of mempool elements.
@@ -194,10 +192,7 @@ struct rte_mempool {
unsigned private_data_size; /**< Size of private data. */
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
- /** Per-lcore local cache. */
- struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
-#endif
+ struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
/** Per-lcore statistics. */
@@ -247,6 +242,13 @@ struct rte_mempool {
#endif
/**
+ * Size of elt_pa array size based on number of pages. (Internal use)
+ */
+#define __PA_SIZE(mp, pgn) \
+ RTE_ALIGN_CEIL((((pgn) - RTE_DIM((mp)->elt_pa)) * \
+ sizeof((mp)->elt_pa[0])), RTE_CACHE_LINE_SIZE)
+
+/**
* Calculate the size of the mempool header.
*
* @param mp
@@ -254,9 +256,9 @@ struct rte_mempool {
* @param pgn
* Number of pages used to store mempool objects.
*/
-#define MEMPOOL_HEADER_SIZE(mp, pgn) (sizeof(*(mp)) + \
- RTE_ALIGN_CEIL(((pgn) - RTE_DIM((mp)->elt_pa)) * \
- sizeof ((mp)->elt_pa[0]), RTE_CACHE_LINE_SIZE))
+#define MEMPOOL_HEADER_SIZE(mp, pgn, cs) \
+ (sizeof(*(mp)) + __PA_SIZE(mp, pgn) + (((cs) == 0) ? 0 : \
+ (sizeof(struct rte_mempool_cache) * RTE_MAX_LCORE)))
/**
* Return true if the whole mempool is in contiguous memory.
@@ -755,19 +757,16 @@ static inline void __attribute__((always_inline))
__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n, int is_mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index;
void **cache_objs;
unsigned lcore_id = rte_lcore_id();
uint32_t cache_size = mp->cache_size;
uint32_t flushthresh = mp->cache_flushthresh;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* increment stat now, adding in mempool always success */
__MEMPOOL_STAT_ADD(mp, put, n);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* cache is not enabled or single producer or non-EAL thread */
if (unlikely(cache_size == 0 || is_mp == 0 ||
lcore_id >= RTE_MAX_LCORE))
@@ -802,7 +801,6 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
return;
ring_enqueue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* push remaining objects in ring */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -946,7 +944,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
unsigned n, int is_mc)
{
int ret;
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index, len;
void **cache_objs;
@@ -992,7 +989,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
return 0;
ring_dequeue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* get remaining objects from ring */
if (is_mc)
@@ -1293,7 +1289,8 @@ void rte_mempool_audit(const struct rte_mempool *mp);
*/
static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
{
- return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
+ return (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
}
/**
--
2.5.4 (Apple Git-61)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
2016-02-12 16:40 0% ` Ivan Boule
@ 2016-02-12 17:33 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2016-02-12 17:33 UTC (permalink / raw)
To: Ivan Boule; +Cc: dev
On Fri, Feb 12, 2016 at 05:40:02PM +0100, Ivan Boule wrote:
> On 02/12/2016 12:44 PM, Ananyev, Konstantin wrote:
> >
> >>
> >>>-----Original Message-----
> ...
> >>
> >>In that case we don't need to make any changes at rte_ethdev.[h,c] to alloc/free/maintain tx_buffer inside each queue...
> >>It all will be upper layer responsibility.
> >>So no need to modify existing rte_ethdev structures/code.
> >>Again, no need for error callback - caller would check return value and decide what to do with unsent packets in the tx_buffer.
> >>
> >
> >Just to summarise why I think it is better to have tx buffering managed on the app level:
> >
> >1. avoid any ABI change.
> >2. Avoid extra changes in rte_ethdev.c: tx_queue_setup/tx_queue_stop.
> >3. Provides much more flexibility to the user:
> > a) where to allocate space for tx_buffer (stack, heap, hugepages, etc).
> > b) user can mix and match plain tx_burst() and tx_buffer/tx_buffer_flush()
> > in any way he fills it appropriate.
> > c) user can change the size of tx_buffer without stop/re-config/start queue:
> > just allocate new larger(smaller) tx_buffer & copy contents to the new one.
> > d) user can preserve buffered packets through device restart circle:
> > i.e if let say TX hang happened, and user has to do dev_stop/dev_start -
> > contents of tx_buffer will stay unchanged and its contents could be
> > (re-)transmitted after device is up again, or through different port/queue if needed.
> >
> >As a drawbacks mentioned - tx error handling becomes less transparent...
> >But we can add error handling routine and it's user provided parameter
> >into struct rte_eth_dev_tx_buffer', something like that:
> >
> >+struct rte_eth_dev_tx_buffer {
> >+ buffer_tx_error_fn cbfn;
> >+ void *userdata;
> >+ unsigned nb_pkts;
> >+ uint64_t errors;
> >+ /**< Total number of queue packets to sent that are dropped. */
> >+ struct rte_mbuf *pkts[];
> >+};
> >
> >Konstantin
> >
>
> Just to enforce Konstantin's comments.
> As a very basic - not to say fundamental - rule, one should avoid adding in
> the PMD RX/TX API any extra processing that can be handled at a higher
> level.
> The only and self-sufficient reason is that we must avoid impacting
> performances on the critical path, in particular for those - usually the
> majority of - applications that do not need such extra operations, or better
> implement them at upper level.
>
> Maybe in a not so far future will come a proposal for forking a new open
> source fast-dpdk project aiming at providing API simplicity, zero-overhead,
> modular design, and all those nice properties that every one claims to seek
> :-)
>
> Ivan
>
Hi Ivan,
I completely agree with your comments. However, none of the proposals for TX
buffering would impact the existing fast-path processing paths. They simply add
an optional buffering layer above it - as is done by a very large number of our
sample apps. The point of this patchset is to reduce or eliminate this duplication
of code by centralising it in the libs.
Of the different ways of doing this proposed, my slight preference is for the
original one due to the simplicity of the APIs it provides, but the advantages
in flexibility provided by Konstantin's proposals may outway the additional
"ugliness" in the APIs.
Regards,
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
2016-02-12 11:44 3% ` Ananyev, Konstantin
@ 2016-02-12 16:40 0% ` Ivan Boule
2016-02-12 17:33 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Ivan Boule @ 2016-02-12 16:40 UTC (permalink / raw)
To: Ananyev, Konstantin, Kulasek, TomaszX, dev
On 02/12/2016 12:44 PM, Ananyev, Konstantin wrote:
>
>>
>>> -----Original Message-----
...
>>
>> In that case we don't need to make any changes at rte_ethdev.[h,c] to alloc/free/maintain tx_buffer inside each queue...
>> It all will be upper layer responsibility.
>> So no need to modify existing rte_ethdev structures/code.
>> Again, no need for error callback - caller would check return value and decide what to do with unsent packets in the tx_buffer.
>>
>
> Just to summarise why I think it is better to have tx buffering managed on the app level:
>
> 1. avoid any ABI change.
> 2. Avoid extra changes in rte_ethdev.c: tx_queue_setup/tx_queue_stop.
> 3. Provides much more flexibility to the user:
> a) where to allocate space for tx_buffer (stack, heap, hugepages, etc).
> b) user can mix and match plain tx_burst() and tx_buffer/tx_buffer_flush()
> in any way he fills it appropriate.
> c) user can change the size of tx_buffer without stop/re-config/start queue:
> just allocate new larger(smaller) tx_buffer & copy contents to the new one.
> d) user can preserve buffered packets through device restart circle:
> i.e if let say TX hang happened, and user has to do dev_stop/dev_start -
> contents of tx_buffer will stay unchanged and its contents could be
> (re-)transmitted after device is up again, or through different port/queue if needed.
>
> As a drawbacks mentioned - tx error handling becomes less transparent...
> But we can add error handling routine and it's user provided parameter
> into struct rte_eth_dev_tx_buffer', something like that:
>
> +struct rte_eth_dev_tx_buffer {
> + buffer_tx_error_fn cbfn;
> + void *userdata;
> + unsigned nb_pkts;
> + uint64_t errors;
> + /**< Total number of queue packets to sent that are dropped. */
> + struct rte_mbuf *pkts[];
> +};
>
> Konstantin
>
Just to enforce Konstantin's comments.
As a very basic - not to say fundamental - rule, one should avoid adding
in the PMD RX/TX API any extra processing that can be handled at a
higher level.
The only and self-sufficient reason is that we must avoid impacting
performances on the critical path, in particular for those - usually the
majority of - applications that do not need such extra operations, or
better implement them at upper level.
Maybe in a not so far future will come a proposal for forking a new open
source fast-dpdk project aiming at providing API simplicity,
zero-overhead, modular design, and all those nice properties that every
one claims to seek :-)
Ivan
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-12 15:50 0% ` Olivier MATZ
@ 2016-02-12 15:58 0% ` Wiles, Keith
1 sibling, 0 replies; 200+ results
From: Wiles, Keith @ 2016-02-12 15:58 UTC (permalink / raw)
To: Olivier MATZ, Thomas Monjalon; +Cc: dev
>Hi,
>
>On 02/12/2016 04:38 PM, Thomas Monjalon wrote:
>> OK, I'm going to sum it up with new words and let the conclusion comes
>> from Keith, Panu and Olivier.
>>
>> We agreed to allow ABI breaking if a notification was done in the
>> previous release.
>> Keith has sent a notification for 16.04 so the "official" ABI will be
>> changed in 16.07.
>> It is also encouraged to show how the ABI will be broken when sending
>> a notification. It allows to give an informed opinion before ack'ing.
>> The code snippet will also be useful to app developpers when preparing
>> a future upgrade.
>> Keith has sent the whole code change.
>> This code change may be submitted in the current release without waiting
>> the deprecation time if gated in the NEXT_ABI ifdefs.
>> It allows to provide the feature to app developpers who don't care about
>> versioning. But the price is a more complicated code to read and manage.
>>
>> To make it short, the rules to use NEXT_ABI are not strict and may change.
>> So now you have to decide if this change can be integrated in 16.04
>> as NEXT_ABI.
>
>Thank you Thomas for this summary. Then my vote would be in favor of
>only keep the deprecation notice for 16.04 and push the code without
>the NEXT_ABI ifdefs for 16.07 because:
>
>- although it's a valuable patch, there is no urgency in having if for
> the next release
>- NEXT_ABI does make the code harder to read in this case, and I'm
> thinking about the patchset from David Hunt (external mempool handler)
> that will be in the same situation, and maybe also another patchset
> I'm working on.
As I stated in my previous email, I can submit v4 patch. Do you need two patches one for the notice in 16.04 and then one for 16.07?
>
>Regards,
>Olivier
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-12 15:38 4% ` Thomas Monjalon
2016-02-12 15:50 0% ` Olivier MATZ
@ 2016-02-12 15:54 0% ` Wiles, Keith
1 sibling, 0 replies; 200+ results
From: Wiles, Keith @ 2016-02-12 15:54 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
>2016-02-12 15:07, Wiles, Keith:
>> >On 02/12/2016 03:57 PM, Thomas Monjalon wrote:
>> >> 2016-02-12 13:23, Panu Matilainen:
>> >>> On 02/10/2016 11:18 PM, Keith Wiles wrote:
>> >>>> static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
>> >>>> {
>> >>>> +#ifdef RTE_NEXT_ABI
>> >>>> + return (char *)mp +
>> >>>> + MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
>> >>>> +#else
>> >>>> return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
>> >>>> +#endif /* RTE_NEXT_ABI */
>> >>>> }
>> >>>
>> >>> This is not RTE_NEXT_ABI material IMO, the added ifdef clutter is just
>> >>> too much.
>> >>
>> >> The changes are restricted to the mempool files.
>> >> I think it is not so much. However I wonder how much the feature is important
>> >> to justify the use of NEXT_ABI.
>> >
>> >Well yes, to be precise: for the benefit of this patch, the ifdef
>> >clutter seems too much.
>> >
>> >Its not as if every change is expected to go through a NEXT_ABI phase,
>> >based on http://dpdk.org/ml/archives/dev/2016-February/032866.html there
>> >might be some confusion regarding that.
>>
>> I think the NEXT_ABI is reasonable in this case as it does change a structure everyone uses and the ifdef clutter is caused by having to remove old ifdefs, which is a good thing for DPDK. The NEXT_ABI ifdefs only exist for one release and then they will disappear, which I think is more then reasonable.
>
>OK, I'm going to sum it up with new words and let the conclusion comes
>from Keith, Panu and Olivier.
>
>We agreed to allow ABI breaking if a notification was done in the
>previous release.
>Keith has sent a notification for 16.04 so the "official" ABI will be
>changed in 16.07.
>It is also encouraged to show how the ABI will be broken when sending
>a notification. It allows to give an informed opinion before ack'ing.
>The code snippet will also be useful to app developpers when preparing
>a future upgrade.
>Keith has sent the whole code change.
>This code change may be submitted in the current release without waiting
>the deprecation time if gated in the NEXT_ABI ifdefs.
>It allows to provide the feature to app developpers who don't care about
>versioning. But the price is a more complicated code to read and manage.
>
>To make it short, the rules to use NEXT_ABI are not strict and may change.
>So now you have to decide if this change can be integrated in 16.04
>as NEXT_ABI.
I would personally go ahead with the NEXT_ABI in 16.04 as it seems more reasonable for developers. I do not know if we made this patch in 16.04 without NEXT_ABI what would break in a developers project, which to me means we need to error on the side of caution by using NEXT_ABI.
I am willing to submit a v4 patch without the NEXT_API ifdefs, but that is something everyone needs to agree on.
>
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-12 15:38 4% ` Thomas Monjalon
@ 2016-02-12 15:50 0% ` Olivier MATZ
2016-02-12 15:58 0% ` Wiles, Keith
2016-02-12 15:54 0% ` Wiles, Keith
1 sibling, 2 replies; 200+ results
From: Olivier MATZ @ 2016-02-12 15:50 UTC (permalink / raw)
To: Thomas Monjalon, Wiles, Keith; +Cc: dev
Hi,
On 02/12/2016 04:38 PM, Thomas Monjalon wrote:
> OK, I'm going to sum it up with new words and let the conclusion comes
> from Keith, Panu and Olivier.
>
> We agreed to allow ABI breaking if a notification was done in the
> previous release.
> Keith has sent a notification for 16.04 so the "official" ABI will be
> changed in 16.07.
> It is also encouraged to show how the ABI will be broken when sending
> a notification. It allows to give an informed opinion before ack'ing.
> The code snippet will also be useful to app developpers when preparing
> a future upgrade.
> Keith has sent the whole code change.
> This code change may be submitted in the current release without waiting
> the deprecation time if gated in the NEXT_ABI ifdefs.
> It allows to provide the feature to app developpers who don't care about
> versioning. But the price is a more complicated code to read and manage.
>
> To make it short, the rules to use NEXT_ABI are not strict and may change.
> So now you have to decide if this change can be integrated in 16.04
> as NEXT_ABI.
Thank you Thomas for this summary. Then my vote would be in favor of
only keep the deprecation notice for 16.04 and push the code without
the NEXT_ABI ifdefs for 16.07 because:
- although it's a valuable patch, there is no urgency in having if for
the next release
- NEXT_ABI does make the code harder to read in this case, and I'm
thinking about the patchset from David Hunt (external mempool handler)
that will be in the same situation, and maybe also another patchset
I'm working on.
Regards,
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
@ 2016-02-12 15:38 4% ` Thomas Monjalon
2016-02-12 15:50 0% ` Olivier MATZ
2016-02-12 15:54 0% ` Wiles, Keith
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2016-02-12 15:38 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dev
2016-02-12 15:07, Wiles, Keith:
> >On 02/12/2016 03:57 PM, Thomas Monjalon wrote:
> >> 2016-02-12 13:23, Panu Matilainen:
> >>> On 02/10/2016 11:18 PM, Keith Wiles wrote:
> >>>> static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
> >>>> {
> >>>> +#ifdef RTE_NEXT_ABI
> >>>> + return (char *)mp +
> >>>> + MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
> >>>> +#else
> >>>> return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
> >>>> +#endif /* RTE_NEXT_ABI */
> >>>> }
> >>>
> >>> This is not RTE_NEXT_ABI material IMO, the added ifdef clutter is just
> >>> too much.
> >>
> >> The changes are restricted to the mempool files.
> >> I think it is not so much. However I wonder how much the feature is important
> >> to justify the use of NEXT_ABI.
> >
> >Well yes, to be precise: for the benefit of this patch, the ifdef
> >clutter seems too much.
> >
> >Its not as if every change is expected to go through a NEXT_ABI phase,
> >based on http://dpdk.org/ml/archives/dev/2016-February/032866.html there
> >might be some confusion regarding that.
>
> I think the NEXT_ABI is reasonable in this case as it does change a structure everyone uses and the ifdef clutter is caused by having to remove old ifdefs, which is a good thing for DPDK. The NEXT_ABI ifdefs only exist for one release and then they will disappear, which I think is more then reasonable.
OK, I'm going to sum it up with new words and let the conclusion comes
from Keith, Panu and Olivier.
We agreed to allow ABI breaking if a notification was done in the
previous release.
Keith has sent a notification for 16.04 so the "official" ABI will be
changed in 16.07.
It is also encouraged to show how the ABI will be broken when sending
a notification. It allows to give an informed opinion before ack'ing.
The code snippet will also be useful to app developpers when preparing
a future upgrade.
Keith has sent the whole code change.
This code change may be submitted in the current release without waiting
the deprecation time if gated in the NEXT_ABI ifdefs.
It allows to provide the feature to app developpers who don't care about
versioning. But the price is a more complicated code to read and manage.
To make it short, the rules to use NEXT_ABI are not strict and may change.
So now you have to decide if this change can be integrated in 16.04
as NEXT_ABI.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library
@ 2016-02-12 13:45 1% ` Ferruh Yigit
2016-02-17 19:58 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2016-02-12 13:45 UTC (permalink / raw)
To: dev
This library gets control messages form kernelspace and forwards them to
librte_ether and returns response back to the kernelspace.
Library does:
1) Trigger Linux virtual interface creation
2) Initialize the netlink socket communication
3) Provides process() API to the application that does processing the
received messages
This library requires corresponding kernel module to be inserted.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
v2:
* User rtnetlink to create interfaces.
* Add more ethtool support: get/set ringparam, set pauseparam.
* return defined error instead of hardcoded value
---
MAINTAINERS | 1 +
config/common_linuxapp | 3 +-
doc/api/doxy-api-index.md | 3 +-
doc/api/doxy-api.conf | 1 +
doc/guides/rel_notes/release_16_04.rst | 9 +
lib/Makefile | 3 +-
lib/librte_ctrl_if/Makefile | 58 ++++
lib/librte_ctrl_if/rte_ctrl_if.c | 385 ++++++++++++++++++++++++
lib/librte_ctrl_if/rte_ctrl_if.h | 115 ++++++++
lib/librte_ctrl_if/rte_ctrl_if_version.map | 9 +
lib/librte_ctrl_if/rte_ethtool.c | 450 +++++++++++++++++++++++++++++
lib/librte_ctrl_if/rte_ethtool.h | 54 ++++
lib/librte_ctrl_if/rte_nl.c | 274 ++++++++++++++++++
lib/librte_ctrl_if/rte_nl.h | 49 ++++
lib/librte_eal/common/include/rte_log.h | 3 +-
mk/rte.app.mk | 3 +-
16 files changed, 1415 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_ctrl_if/Makefile
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map
create mode 100644 lib/librte_ctrl_if/rte_ethtool.c
create mode 100644 lib/librte_ctrl_if/rte_ethtool.h
create mode 100644 lib/librte_ctrl_if/rte_nl.c
create mode 100644 lib/librte_ctrl_if/rte_nl.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 09c56c7..91c98bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -256,6 +256,7 @@ F: doc/guides/sample_app_ug/kernel_nic_interface.rst
Linux KCP
M: Ferruh Yigit <ferruh.yigit@intel.com>
F: lib/librte_eal/linuxapp/kcp/
+F: lib/librte_ctrl_if/
Linux AF_PACKET
M: John W. Linville <linville@tuxdriver.com>
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2f4eb1d..4bcd508 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -501,6 +501,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
#
CONFIG_RTE_KCP_KMOD=y
CONFIG_RTE_KCP_KO_DEBUG=n
+CONFIG_RTE_LIBRTE_CTRL_IF=y
#
# Compile vhost library
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 7a91001..214d16e 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped by topics:
[common] (@ref rte_common.h),
[ABI compat] (@ref rte_compat.h),
[keepalive] (@ref rte_keepalive.h),
- [version] (@ref rte_version.h)
+ [version] (@ref rte_version.h),
+ [control interface] (@ref rte_ctrl_if.h)
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 57e8b5d..fd69bf1 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -39,6 +39,7 @@ INPUT = doc/api/doxy-api-index.md \
lib/librte_cmdline \
lib/librte_compat \
lib/librte_cryptodev \
+ lib/librte_ctrl_if \
lib/librte_distributor \
lib/librte_ether \
lib/librte_hash \
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..1b1d34c 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -39,6 +39,14 @@ This section should contain new features added in this release. Sample format:
Enabled virtio 1.0 support for virtio pmd driver.
+* **Control interface support added.**
+
+ To enable controlling DPDK ports by common Linux tools.
+ Following modules added to DPDK:
+
+ * librte_ctrl_if library
+ * librte_eal/linuxapp/kcp kernel module
+
Resolved Issues
---------------
@@ -113,6 +121,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.1
+ + librte_ctrl_if.so.1
librte_distributor.so.1
librte_eal.so.2
librte_hash.so.2
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..a50bc1e 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port
DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
+DIRS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += librte_ctrl_if
ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
diff --git a/lib/librte_ctrl_if/Makefile b/lib/librte_ctrl_if/Makefile
new file mode 100644
index 0000000..4e82966
--- /dev/null
+++ b/lib/librte_ctrl_if/Makefile
@@ -0,0 +1,58 @@
+# BSD LICENSE
+#
+# Copyright(c) 2016 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.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_ctrl_if.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+EXPORT_MAP := rte_ctrl_if_version.map
+
+LIBABIVER := 1
+
+SRCS-y += rte_ctrl_if.c
+SRCS-y += rte_nl.c
+SRCS-y += rte_ethtool.c
+
+#
+# Export include files
+#
+SYMLINK-y-include += rte_ctrl_if.h
+
+# this lib depends upon:
+DEPDIRS-y += lib/librte_ether
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ctrl_if/rte_ctrl_if.c b/lib/librte_ctrl_if/rte_ctrl_if.c
new file mode 100644
index 0000000..d16398f
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if.c
@@ -0,0 +1,385 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <fcntl.h>
+#include <unistd.h>
+#include <time.h>
+
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+#include <linux/netlink.h>
+#include <linux/rtnetlink.h>
+
+#include <rte_ethdev.h>
+#include "rte_ctrl_if.h"
+#include "rte_nl.h"
+
+#define NAMESZ 32
+#define IFNAME "dpdk"
+#define BUFSZ 1024
+
+static int kcp_rtnl_fd = -1;
+static int kcp_fd_ref;
+
+struct kcp_request {
+ struct nlmsghdr nlmsg;
+ char buf[BUFSZ];
+};
+
+static int
+conrol_interface_rtnl_init(void)
+{
+ struct sockaddr_nl src;
+ int ret;
+
+ kcp_rtnl_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
+ if (kcp_rtnl_fd < 0) {
+ RTE_LOG(ERR, CTRL_IF, "socket for create failed.\n");
+ return -1;
+ }
+
+ memset(&src, 0, sizeof(struct sockaddr_nl));
+
+ src.nl_family = AF_NETLINK;
+ src.nl_pid = getpid();
+
+ ret = bind(kcp_rtnl_fd, (struct sockaddr *)&src,
+ sizeof(struct sockaddr_nl));
+ if (ret < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Bind for create failed.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int
+control_interface_init(void)
+{
+ int ret;
+
+ ret = conrol_interface_rtnl_init();
+ if (ret < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Failed to initialize rtnetlink.\n");
+ return -1;
+ }
+
+ ret = control_interface_nl_init();
+ if (ret < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Failed to initialize netlink.\n");
+ close(kcp_rtnl_fd);
+ kcp_rtnl_fd = -1;
+ }
+
+ return ret;
+}
+
+static int
+control_interface_ref_get(void)
+{
+ int ret = 0;
+
+ if (kcp_fd_ref == 0)
+ ret = control_interface_init();
+
+ if (ret == 0)
+ kcp_fd_ref++;
+ else
+ RTE_LOG(ERR, CTRL_IF,
+ "Failed to initialize control interface.\n");
+
+ return kcp_fd_ref;
+}
+
+static void
+control_interface_release(void)
+{
+ close(kcp_rtnl_fd);
+ control_interface_nl_release();
+}
+
+static int
+control_interface_ref_put(void)
+{
+ if (kcp_fd_ref == 0)
+ return 0;
+
+ kcp_fd_ref--;
+
+ if (kcp_fd_ref == 0)
+ control_interface_release();
+
+ return kcp_fd_ref;
+}
+
+static int
+add_attr(struct kcp_request *req, unsigned short type, void *buf, size_t len)
+{
+ struct rtattr *rta;
+ int nlmsg_len;
+
+ nlmsg_len = NLMSG_ALIGN(req->nlmsg.nlmsg_len);
+ rta = (struct rtattr *)((char *)&req->nlmsg + nlmsg_len);
+ if (nlmsg_len + RTA_LENGTH(len) > sizeof(struct kcp_request))
+ return -1;
+ rta->rta_type = type;
+ rta->rta_len = RTA_LENGTH(len);
+ memcpy(RTA_DATA(rta), buf, len);
+ req->nlmsg.nlmsg_len = nlmsg_len + RTA_LENGTH(len);
+
+ return 0;
+}
+
+static struct
+rtattr *add_attr_nested(struct kcp_request *req, unsigned short type)
+{
+ struct rtattr *rta;
+ int nlmsg_len;
+
+ nlmsg_len = NLMSG_ALIGN(req->nlmsg.nlmsg_len);
+ rta = (struct rtattr *)((char *)&req->nlmsg + nlmsg_len);
+ if (nlmsg_len + RTA_LENGTH(0) > sizeof(struct kcp_request))
+ return NULL;
+ rta->rta_type = type;
+ rta->rta_len = nlmsg_len;
+ req->nlmsg.nlmsg_len = nlmsg_len + RTA_LENGTH(0);
+
+ return rta;
+}
+
+static void
+end_attr_nested(struct kcp_request *req, struct rtattr *rta)
+{
+ rta->rta_len = req->nlmsg.nlmsg_len - rta->rta_len;
+}
+
+static int
+rte_eth_rtnl_create(uint8_t port_id)
+{
+ struct kcp_request req;
+ struct ifinfomsg *info;
+ struct rtattr *rta1;
+ struct rtattr *rta2;
+ unsigned int pid = getpid();
+ char name[NAMESZ];
+ char type[NAMESZ];
+ struct iovec iov;
+ struct msghdr msg;
+ struct sockaddr_nl nladdr;
+ int ret;
+ char buf[BUFSZ];
+
+ memset(&req, 0, sizeof(struct kcp_request));
+
+ req.nlmsg.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.nlmsg.nlmsg_flags = NLM_F_REQUEST | NLM_F_CREATE | NLM_F_EXCL;
+ req.nlmsg.nlmsg_flags |= NLM_F_ACK;
+ req.nlmsg.nlmsg_type = RTM_NEWLINK;
+
+ info = NLMSG_DATA(&req.nlmsg);
+
+ info->ifi_family = AF_UNSPEC;
+ info->ifi_index = 0;
+
+ snprintf(name, NAMESZ, IFNAME"%u", port_id);
+ ret = add_attr(&req, IFLA_IFNAME, name, strlen(name) + 1);
+ if (ret < 0)
+ return -1;
+
+ rta1 = add_attr_nested(&req, IFLA_LINKINFO);
+ if (rta1 == NULL)
+ return -1;
+
+ snprintf(type, NAMESZ, KCP_DEVICE);
+ ret = add_attr(&req, IFLA_INFO_KIND, type, strlen(type) + 1);
+ if (ret < 0)
+ return -1;
+
+ rta2 = add_attr_nested(&req, IFLA_INFO_DATA);
+ if (rta2 == NULL)
+ return -1;
+
+ ret = add_attr(&req, IFLA_KCP_PORTID, &port_id, sizeof(uint8_t));
+ if (ret < 0)
+ return -1;
+
+ ret = add_attr(&req, IFLA_KCP_PID, &pid, sizeof(unsigned int));
+ if (ret < 0)
+ return -1;
+
+ end_attr_nested(&req, rta2);
+ end_attr_nested(&req, rta1);
+
+ memset(&nladdr, 0, sizeof(nladdr));
+ nladdr.nl_family = AF_NETLINK;
+
+ iov.iov_base = (void *)&req.nlmsg;
+ iov.iov_len = req.nlmsg.nlmsg_len;
+
+ memset(&msg, 0, sizeof(struct msghdr));
+ msg.msg_name = &nladdr;
+ msg.msg_namelen = sizeof(nladdr);
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+
+ ret = sendmsg(kcp_rtnl_fd, &msg, 0);
+ if (ret < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Send for create failed %d.\n", errno);
+ return -1;
+ }
+
+ memset(buf, 0, sizeof(buf));
+ iov.iov_base = buf;
+ iov.iov_len = sizeof(buf);
+
+ ret = recvmsg(kcp_rtnl_fd, &msg, 0);
+ if (ret < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Recv for create failed.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int
+rte_eth_control_interface_create_one(uint8_t port_id)
+{
+ int ret;
+
+ if (control_interface_ref_get() != 0) {
+ ret = rte_eth_rtnl_create(port_id);
+ RTE_LOG(DEBUG, CTRL_IF,
+ "Control interface %s for port:%u\n",
+ ret < 0 ? "failed" : "created", port_id);
+ }
+
+ return 0;
+}
+
+int
+rte_eth_control_interface_create(void)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+ if (rte_eth_dev_is_valid_port(i)) {
+ ret = rte_eth_control_interface_create_one(i);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+static int
+rte_eth_rtnl_destroy(uint8_t port_id)
+{
+ struct kcp_request req;
+ struct ifinfomsg *info;
+ char name[NAMESZ];
+ struct iovec iov;
+ struct msghdr msg;
+ struct sockaddr_nl nladdr;
+ int ret;
+
+ memset(&req, 0, sizeof(struct kcp_request));
+
+ req.nlmsg.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.nlmsg.nlmsg_flags = NLM_F_REQUEST;
+ req.nlmsg.nlmsg_type = RTM_DELLINK;
+
+ info = NLMSG_DATA(&req.nlmsg);
+
+ info->ifi_family = AF_UNSPEC;
+ info->ifi_index = 0;
+
+ snprintf(name, NAMESZ, IFNAME"%u", port_id);
+ ret = add_attr(&req, IFLA_IFNAME, name, strlen(name) + 1);
+ if (ret < 0)
+ return -1;
+
+ memset(&nladdr, 0, sizeof(nladdr));
+ nladdr.nl_family = AF_NETLINK;
+
+ iov.iov_base = (void *)&req.nlmsg;
+ iov.iov_len = req.nlmsg.nlmsg_len;
+
+ memset(&msg, 0, sizeof(struct msghdr));
+ msg.msg_name = &nladdr;
+ msg.msg_namelen = sizeof(nladdr);
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+
+ ret = sendmsg(kcp_rtnl_fd, &msg, 0);
+ if (ret < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Send for destroy failed.\n");
+ return -1;
+ }
+ return 0;
+}
+
+static int
+rte_eth_control_interface_destroy_one(uint8_t port_id)
+{
+ rte_eth_rtnl_destroy(port_id);
+ control_interface_ref_put();
+ RTE_LOG(DEBUG, CTRL_IF, "Control interface destroyed for port:%u\n",
+ port_id);
+
+ return 0;
+}
+
+int
+rte_eth_control_interface_destroy(void)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+ if (rte_eth_dev_is_valid_port(i)) {
+ ret = rte_eth_control_interface_destroy_one(i);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+int
+rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec)
+{
+ return control_interface_process_msg(flag, timeout_sec);
+}
diff --git a/lib/librte_ctrl_if/rte_ctrl_if.h b/lib/librte_ctrl_if/rte_ctrl_if.h
new file mode 100644
index 0000000..dcaf6dd
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if.h
@@ -0,0 +1,115 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#ifndef _RTE_CTRL_IF_H_
+#define _RTE_CTRL_IF_H_
+
+/**
+ * @file
+ *
+ * Control Interface Library for RTE
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <exec-env/rte_kcp_common.h>
+
+/**
+ * Flags values for rte_eth_control_interface_process_msg() API
+ */
+enum control_interface_process_flag {
+ /**< Process if msg available. */
+ RTE_ETHTOOL_CTRL_IF_PROCESS_MSG,
+
+ /**< Discard msg if available, respond with a error value. */
+ RTE_ETHTOOL_CTRL_IF_DISCARD_MSG,
+};
+
+/**
+ * Creates control interfaces (Linux virtual network interface)for
+ * each existing eal port.
+ *
+ * This API opens device created by supportive kernel module and initializes
+ * kernel communication interface.
+ *
+ * If supportive kernel module is not inserted this API will return
+ * an error.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_create(void);
+
+/**
+ * Destroys control interfaces.
+ *
+ * This API close device created by supportive kernel module and release
+ * underlying communication interface.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_destroy(void);
+
+/**
+ * Process if any received message is available.
+ *
+ * This function can be blocking or unblocking according timeout_sec
+ * parameter value. If function will be continuous loop, like can be
+ * called by any forwarding lcore, nonblocking mode should be preferred.
+ * If a separate thread created to handle control messages, blocking
+ * mode can be preferred to save CPU cycles.
+ *
+ * @param flag
+ * Defines what to do with message, can be process or discard.
+ *
+ * @param timeout_sec
+ * if 0, function is in nonblocking mode.
+ * if > 0, blocks for given time, if there is no message available,
+ * sleeps again same amount of time. Value is in seconds.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_CTRL_IF_H_ */
diff --git a/lib/librte_ctrl_if/rte_ctrl_if_version.map b/lib/librte_ctrl_if/rte_ctrl_if_version.map
new file mode 100644
index 0000000..8b27e26
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if_version.map
@@ -0,0 +1,9 @@
+DPDK_2.3 {
+ global:
+
+ rte_eth_control_interface_create;
+ rte_eth_control_interface_destroy;
+ rte_eth_control_interface_process_msg;
+
+ local: *;
+};
diff --git a/lib/librte_ctrl_if/rte_ethtool.c b/lib/librte_ctrl_if/rte_ethtool.c
new file mode 100644
index 0000000..def968a
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ethtool.c
@@ -0,0 +1,450 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <stdio.h>
+#include <error.h>
+
+#include <linux/if_link.h>
+
+#include <rte_version.h>
+#include <rte_ethdev.h>
+#include "rte_ethtool.h"
+
+#define ETHTOOL_GEEPROM_LEN 99
+#define ETHTOOL_GREGS_LEN 98
+#define ETHTOOL_GSSET_COUNT 97
+
+static int
+get_drvinfo(int port_id, void *data, int *data_len)
+{
+ struct ethtool_drvinfo *info = data;
+ struct rte_eth_dev_info dev_info;
+ int n;
+
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(port_id, &dev_info);
+
+ snprintf(info->driver, sizeof(info->driver), "%s",
+ dev_info.driver_name);
+ snprintf(info->version, sizeof(info->version), "%s",
+ rte_version());
+ snprintf(info->bus_info, sizeof(info->bus_info),
+ "%04x:%02x:%02x.%x",
+ dev_info.pci_dev->addr.domain, dev_info.pci_dev->addr.bus,
+ dev_info.pci_dev->addr.devid, dev_info.pci_dev->addr.function);
+
+ n = rte_eth_dev_get_reg_length(port_id);
+ info->regdump_len = n < 0 ? 0 : n;
+
+ n = rte_eth_dev_get_eeprom_length(port_id);
+ info->eedump_len = n < 0 ? 0 : n;
+
+ info->n_stats = sizeof(struct rte_eth_stats) / sizeof(uint64_t);
+ info->testinfo_len = 0;
+
+ *data_len = sizeof(struct ethtool_drvinfo);
+
+ return 0;
+}
+
+static int
+get_reg_len(int port_id, void *data, int *data_len)
+{
+ int reg_length = 0;
+
+ reg_length = rte_eth_dev_get_reg_length(port_id);
+ if (reg_length < 0)
+ return reg_length;
+
+ *(int *)data = reg_length * sizeof(uint32_t);
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_reg(int port_id, void *in_data, void *out_data, int *out_data_len)
+{
+ unsigned int reg_length;
+ int reg_length_out_len;
+ struct ethtool_regs *ethtool_regs = in_data;
+ struct rte_dev_reg_info regs = {
+ .data = out_data,
+ .length = ethtool_regs->len,
+ };
+ int ret;
+
+ ret = get_reg_len(port_id, ®_length, ®_length_out_len);
+ if (ret < 0 || reg_length > ethtool_regs->len)
+ return -1;
+
+ ret = rte_eth_dev_get_reg_info(port_id, ®s);
+ if (ret < 0)
+ return ret;
+
+ ethtool_regs->version = regs.version;
+ *out_data_len = reg_length;
+
+ return 0;
+}
+
+static int
+get_link(int port_id, void *data, int *data_len)
+{
+ struct rte_eth_link link;
+
+ rte_eth_link_get(port_id, &link);
+
+ *(int *)data = link.link_status;
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_eeprom_length(int port_id, void *data, int *data_len)
+{
+ int eeprom_length = 0;
+
+ eeprom_length = rte_eth_dev_get_eeprom_length(port_id);
+ if (eeprom_length < 0)
+ return eeprom_length;
+
+ *(int *)data = eeprom_length;
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_eeprom(int port_id, void *in_data, void *out_data, int *out_data_len)
+{
+ struct ethtool_eeprom *eeprom = in_data;
+ struct rte_dev_eeprom_info eeprom_info = {
+ .data = out_data,
+ .offset = eeprom->offset,
+ .length = eeprom->len,
+ };
+ int ret;
+
+ ret = rte_eth_dev_get_eeprom(port_id, &eeprom_info);
+ if (ret < 0)
+ return ret;
+
+ eeprom->magic = eeprom_info.magic;
+ *out_data_len = eeprom->len;
+
+ return 0;
+}
+
+static int
+set_eeprom(int port_id, void *in_data)
+{
+ struct ethtool_eeprom *eeprom = in_data;
+ struct rte_dev_eeprom_info eeprom_info = {
+ .data = eeprom->data,
+ .offset = eeprom->offset,
+ .length = eeprom->len,
+ };
+ int ret;
+
+ ret = rte_eth_dev_set_eeprom(port_id, &eeprom_info);
+ if (ret < 0)
+ return ret;
+
+ eeprom->magic = eeprom_info.magic;
+
+ return 0;
+}
+
+static int
+get_ringparam(int port_id, void *data, int *data_len)
+{
+ struct ethtool_ringparam *ringparam = data;
+ struct rte_eth_dev_info dev_info;
+ struct rte_eth_rxq_info rx_qinfo;
+ struct rte_eth_txq_info tx_qinfo;
+ int ret;
+
+ rte_eth_dev_info_get(port_id, &dev_info);
+
+ ret = rte_eth_rx_queue_info_get(port_id, 0, &rx_qinfo);
+ if (ret != 0)
+ return -1;
+
+ ret = rte_eth_tx_queue_info_get(port_id, 0, &tx_qinfo);
+ if (ret != 0)
+ return -1;
+
+ memset(ringparam, 0, sizeof(struct ethtool_ringparam));
+ ringparam->rx_pending = rx_qinfo.nb_desc;
+ ringparam->rx_max_pending = dev_info.rx_desc_lim.nb_max;
+ ringparam->tx_pending = tx_qinfo.nb_desc;
+ ringparam->tx_max_pending = dev_info.tx_desc_lim.nb_max;
+
+ *data_len = sizeof(struct ethtool_ringparam);
+
+ return 0;
+}
+
+static int
+set_ringparam(int port_id, void *data)
+{
+ struct ethtool_ringparam *ringparam = data;
+ struct rte_eth_rxq_info rx_qinfo;
+ int ret;
+
+ ret = rte_eth_rx_queue_info_get(port_id, 0, &rx_qinfo);
+ if (ret != 0)
+ return -1;
+
+ rte_eth_dev_stop(port_id);
+
+ ret = rte_eth_tx_queue_setup(port_id, 0, ringparam->tx_pending,
+ rte_socket_id(), NULL);
+ if (ret != 0)
+ return -1;
+
+ ret = rte_eth_rx_queue_setup(port_id, 0, ringparam->rx_pending,
+ rte_socket_id(), NULL, rx_qinfo.mp);
+ if (ret != 0)
+ return -1;
+
+ return rte_eth_dev_start(port_id);
+}
+
+static int
+get_pauseparam(int port_id, void *data, int *data_len)
+{
+ struct ethtool_pauseparam *pauseparam = data;
+ struct rte_eth_fc_conf fc_conf;
+ int ret;
+
+ ret = rte_eth_dev_flow_ctrl_get(port_id, &fc_conf);
+ if (ret)
+ return -1;
+
+ pauseparam->tx_pause = 0;
+ pauseparam->rx_pause = 0;
+
+ switch (fc_conf.mode) {
+ case RTE_FC_RX_PAUSE:
+ pauseparam->rx_pause = 1;
+ break;
+ case RTE_FC_TX_PAUSE:
+ pauseparam->tx_pause = 1;
+ break;
+ case RTE_FC_FULL:
+ pauseparam->rx_pause = 1;
+ pauseparam->tx_pause = 1;
+ default:
+ break;
+ }
+ pauseparam->autoneg = (uint32_t)fc_conf.autoneg;
+
+ *data_len = sizeof(struct ethtool_pauseparam);
+
+ return 0;
+}
+
+static int
+set_pauseparam(int port_id, void *data)
+{
+ struct ethtool_pauseparam *pauseparam = data;
+ struct rte_eth_fc_conf fc_conf;
+ int ret;
+
+ ret = rte_eth_dev_flow_ctrl_get(port_id, &fc_conf);
+ if (ret)
+ return -1;
+
+ fc_conf.autoneg = pauseparam->autoneg;
+
+ if (pauseparam->tx_pause) {
+ if (pauseparam->rx_pause)
+ fc_conf.mode = RTE_FC_FULL;
+ else
+ fc_conf.mode = RTE_FC_TX_PAUSE;
+ } else {
+ if (pauseparam->rx_pause)
+ fc_conf.mode = RTE_FC_RX_PAUSE;
+ else
+ fc_conf.mode = RTE_FC_NONE;
+ }
+
+ ret = rte_eth_dev_flow_ctrl_set(port_id, &fc_conf);
+ if (ret)
+ return -1;
+
+ return 0;
+}
+
+int
+rte_eth_dev_ethtool_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len)
+{
+ int ret = 0;
+
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -ENODEV;
+
+ switch (cmd_id) {
+ case ETHTOOL_GDRVINFO:
+ return get_drvinfo(port_id, out_data, out_data_len);
+ case ETHTOOL_GREGS_LEN:
+ return get_reg_len(port_id, out_data, out_data_len);
+ case ETHTOOL_GREGS:
+ return get_reg(port_id, in_data, out_data, out_data_len);
+ case ETHTOOL_GLINK:
+ return get_link(port_id, out_data, out_data_len);
+ case ETHTOOL_GEEPROM_LEN:
+ return get_eeprom_length(port_id, out_data, out_data_len);
+ case ETHTOOL_GEEPROM:
+ return get_eeprom(port_id, in_data, out_data, out_data_len);
+ case ETHTOOL_SEEPROM:
+ return set_eeprom(port_id, in_data);
+ case ETHTOOL_GRINGPARAM:
+ return get_ringparam(port_id, out_data, out_data_len);
+ case ETHTOOL_SRINGPARAM:
+ return set_ringparam(port_id, in_data);
+ case ETHTOOL_GPAUSEPARAM:
+ return get_pauseparam(port_id, out_data, out_data_len);
+ case ETHTOOL_SPAUSEPARAM:
+ return set_pauseparam(port_id, in_data);
+ default:
+ ret = EOPNOTSUPP;
+ break;
+ }
+
+ return ret;
+}
+
+static int
+set_mtu(int port_id, void *in_data)
+{
+ int *mtu = in_data;
+
+ return rte_eth_dev_set_mtu(port_id, *mtu);
+}
+
+static int
+get_stats(int port_id, void *data, int *data_len)
+{
+ struct rte_eth_stats stats;
+ struct rtnl_link_stats64 *if_stats = data;
+ int ret;
+
+ ret = rte_eth_stats_get(port_id, &stats);
+ if (ret < 0)
+ return -EOPNOTSUPP;
+
+ if_stats->rx_packets = stats.ipackets;
+ if_stats->tx_packets = stats.opackets;
+ if_stats->rx_bytes = stats.ibytes;
+ if_stats->tx_bytes = stats.obytes;
+ if_stats->rx_errors = stats.ierrors;
+ if_stats->tx_errors = stats.oerrors;
+ if_stats->rx_dropped = stats.imissed;
+ if_stats->multicast = stats.imcasts;
+
+ *data_len = sizeof(struct rtnl_link_stats64);
+
+ return 0;
+}
+
+static int
+get_mac(int port_id, void *data, int *data_len)
+{
+ struct ether_addr addr;
+
+ rte_eth_macaddr_get(port_id, &addr);
+ memcpy(data, &addr, sizeof(struct ether_addr));
+
+ *data_len = sizeof(struct ether_addr);
+
+ return 0;
+}
+
+static int
+set_mac(int port_id, void *in_data)
+{
+ struct ether_addr addr;
+
+ memcpy(&addr, in_data, ETHER_ADDR_LEN);
+
+ return rte_eth_dev_default_mac_addr_set(port_id, &addr);
+}
+
+static int
+start_port(int port_id)
+{
+ rte_eth_dev_stop(port_id);
+ return rte_eth_dev_start(port_id);
+}
+
+static int
+stop_port(int port_id)
+{
+ rte_eth_dev_stop(port_id);
+ return 0;
+}
+
+int
+rte_eth_dev_control_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len)
+{
+ int ret = 0;
+
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -ENODEV;
+
+ switch (cmd_id) {
+ case RTE_KCP_REQ_CHANGE_MTU:
+ return set_mtu(port_id, in_data);
+ case RTE_KCP_REQ_GET_STATS:
+ return get_stats(port_id, out_data, out_data_len);
+ case RTE_KCP_REQ_GET_MAC:
+ return get_mac(port_id, out_data, out_data_len);
+ case RTE_KCP_REQ_SET_MAC:
+ return set_mac(port_id, in_data);
+ case RTE_KCP_REQ_START_PORT:
+ return start_port(port_id);
+ case RTE_KCP_REQ_STOP_PORT:
+ return stop_port(port_id);
+ default:
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
+ return ret;
+}
diff --git a/lib/librte_ctrl_if/rte_ethtool.h b/lib/librte_ctrl_if/rte_ethtool.h
new file mode 100644
index 0000000..19f364f
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ethtool.h
@@ -0,0 +1,54 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#ifndef _RTE_ETHTOOL_H_
+#define _RTE_ETHTOOL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <linux/ethtool.h>
+
+#include <exec-env/rte_kcp_common.h>
+
+int rte_eth_dev_ethtool_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len);
+int rte_eth_dev_control_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_ETHTOOL_H_ */
diff --git a/lib/librte_ctrl_if/rte_nl.c b/lib/librte_ctrl_if/rte_nl.c
new file mode 100644
index 0000000..adc5fa8
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_nl.c
@@ -0,0 +1,274 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <unistd.h>
+
+#include <sys/socket.h>
+#include <linux/netlink.h>
+
+#include <rte_spinlock.h>
+#include <rte_ethdev.h>
+#include "rte_ethtool.h"
+#include "rte_nl.h"
+#include "rte_ctrl_if.h"
+
+#define MAX_PAYLOAD sizeof(struct kcp_ethtool_msg)
+
+struct ctrl_if_nl {
+ union {
+ struct nlmsghdr nlh;
+ uint8_t nlmsg[NLMSG_SPACE(MAX_PAYLOAD)];
+ };
+ struct msghdr msg;
+ struct iovec iov;
+};
+
+static int sock_fd = -1;
+pthread_t thread_id;
+
+struct sockaddr_nl dest_addr;
+
+pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
+pthread_mutex_t msg_lock = PTHREAD_MUTEX_INITIALIZER;
+
+static struct ctrl_if_nl nl_s;
+static struct ctrl_if_nl nl_r;
+
+static int kcp_ethtool_msg_count;
+static struct kcp_ethtool_msg msg_storage;
+
+static int
+nl_send(void *buf, size_t len)
+{
+ int ret;
+
+ if (nl_s.nlh.nlmsg_len < len) {
+ RTE_LOG(ERR, CTRL_IF, "Message is too big, len:%zu\n", len);
+ return -1;
+ }
+
+ if (!NLMSG_OK(&nl_s.nlh, NLMSG_SPACE(MAX_PAYLOAD))) {
+ RTE_LOG(ERR, CTRL_IF, "Message is not OK\n");
+ return -1;
+ }
+
+ /* Fill in the netlink message payload */
+ memcpy(NLMSG_DATA(nl_s.nlmsg), buf, len);
+
+ ret = sendmsg(sock_fd, &nl_s.msg, 0);
+
+ if (ret < 0)
+ RTE_LOG(ERR, CTRL_IF, "Failed nl msg send. ret:%d, err:%d\n",
+ ret, errno);
+ return ret;
+}
+
+static int
+nl_ethtool_msg_send(struct kcp_ethtool_msg *msg)
+{
+ return nl_send((void *)msg, sizeof(struct kcp_ethtool_msg));
+}
+
+static void
+process_msg(struct kcp_ethtool_msg *msg)
+{
+ if (msg->cmd_id > RTE_KCP_REQ_UNKNOWN) {
+ msg->err = rte_eth_dev_control_process(msg->cmd_id,
+ msg->port_id, msg->input_buffer,
+ msg->output_buffer, &msg->output_buffer_len);
+ } else {
+ msg->err = rte_eth_dev_ethtool_process(msg->cmd_id,
+ msg->port_id, msg->input_buffer,
+ msg->output_buffer, &msg->output_buffer_len);
+ }
+
+ if (msg->err)
+ memset(msg->output_buffer, 0, msg->output_buffer_len);
+
+ nl_ethtool_msg_send(msg);
+}
+
+int
+control_interface_process_msg(int flag, unsigned int timeout_sec)
+{
+ int ret = 0;
+ struct timespec ts;
+
+ pthread_mutex_lock(&msg_lock);
+
+ clock_gettime(CLOCK_REALTIME, &ts);
+ ts.tv_sec += timeout_sec;
+ while (timeout_sec && !kcp_ethtool_msg_count && !ret)
+ ret = pthread_cond_timedwait(&cond, &msg_lock, &ts);
+
+ switch (flag) {
+ case RTE_ETHTOOL_CTRL_IF_PROCESS_MSG:
+ if (kcp_ethtool_msg_count) {
+ process_msg(&msg_storage);
+ kcp_ethtool_msg_count = 0;
+ }
+ ret = 0;
+ break;
+
+ case RTE_ETHTOOL_CTRL_IF_DISCARD_MSG:
+ if (kcp_ethtool_msg_count) {
+ msg_storage.err = -1;
+ nl_ethtool_msg_send(&msg_storage);
+ kcp_ethtool_msg_count = 0;
+ }
+ ret = 0;
+ break;
+
+ default:
+ ret = -1;
+ break;
+ }
+ pthread_mutex_unlock(&msg_lock);
+
+ return ret;
+}
+
+static int
+msg_add_and_signal(struct nlmsghdr *nlh)
+{
+ pthread_mutex_lock(&msg_lock);
+
+ memcpy(&msg_storage, NLMSG_DATA(nlh), sizeof(struct kcp_ethtool_msg));
+ kcp_ethtool_msg_count = 1;
+ msg_storage.flag = KCP_MSG_FLAG_RESPONSE;
+
+ pthread_cond_signal(&cond);
+
+ pthread_mutex_unlock(&msg_lock);
+
+ return 0;
+}
+
+static void *
+nl_recv(void *arg)
+{
+ int ret;
+
+ for (;;) {
+ ret = recvmsg(sock_fd, &nl_r.msg, 0);
+ if (ret < 0)
+ continue;
+
+ if ((unsigned)ret < sizeof(struct kcp_ethtool_msg)) {
+ RTE_LOG(WARNING, CTRL_IF,
+ "Received %u bytes, payload %lu\n",
+ ret, sizeof(struct kcp_ethtool_msg));
+ continue;
+ }
+
+ msg_add_and_signal(&nl_r.nlh);
+ }
+
+ return arg;
+}
+
+static void
+nl_setup_header(struct ctrl_if_nl *nl)
+{
+ dest_addr.nl_family = AF_NETLINK;
+ dest_addr.nl_pid = 0; /* For Linux Kernel */
+ dest_addr.nl_groups = 0;
+
+ memset(nl->nlmsg, 0, NLMSG_SPACE(MAX_PAYLOAD));
+
+ /* Fill the netlink message header */
+ nl->nlh.nlmsg_len = NLMSG_LENGTH(MAX_PAYLOAD);
+ nl->nlh.nlmsg_pid = getpid(); /* self pid */
+ nl->nlh.nlmsg_flags = 0;
+
+ nl->iov.iov_base = (void *)nl->nlmsg;
+ nl->iov.iov_len = nl->nlh.nlmsg_len;
+ memset(&nl->msg, 0, sizeof(struct msghdr));
+ nl->msg.msg_name = (void *)&dest_addr;
+ nl->msg.msg_namelen = sizeof(struct sockaddr_nl);
+ nl->msg.msg_iov = &nl->iov;
+ nl->msg.msg_iovlen = 1;
+}
+
+static int
+nl_socket_init(void)
+{
+ struct sockaddr_nl src_addr;
+ int fd;
+ int ret;
+
+ fd = socket(PF_NETLINK, SOCK_RAW, KCP_NL_GRP);
+ if (fd < 0)
+ return -1;
+
+ src_addr.nl_family = AF_NETLINK;
+ src_addr.nl_pid = getpid();
+ ret = bind(fd, (struct sockaddr *)&src_addr, sizeof(src_addr));
+ if (ret) {
+ close(fd);
+ return -1;
+ }
+
+ nl_setup_header(&nl_s);
+ nl_setup_header(&nl_r);
+
+ return fd;
+}
+
+int
+control_interface_nl_init(void)
+{
+ int ret;
+
+ sock_fd = nl_socket_init();
+ if (sock_fd < 0) {
+ RTE_LOG(ERR, CTRL_IF, "Failed to initialize netlink socket\n");
+ return -1;
+ }
+
+ ret = pthread_create(&thread_id, NULL, nl_recv, NULL);
+ if (ret != 0) {
+ RTE_LOG(ERR, CTRL_IF, "Failed to create receive thread.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+void
+control_interface_nl_release(void)
+{
+ pthread_cancel(thread_id);
+ pthread_join(thread_id, NULL);
+ close(sock_fd);
+}
diff --git a/lib/librte_ctrl_if/rte_nl.h b/lib/librte_ctrl_if/rte_nl.h
new file mode 100644
index 0000000..ee06d90
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_nl.h
@@ -0,0 +1,49 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#ifndef _RTE_NL_H_
+#define _RTE_NL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+int control_interface_nl_init(void);
+void control_interface_nl_release(void);
+int control_interface_process_msg(int flag, unsigned int timeout_sec);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_NL_H_ */
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index 2e47e7f..a0a2c9f 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -79,6 +79,7 @@ extern struct rte_logs rte_logs;
#define RTE_LOGTYPE_PIPELINE 0x00008000 /**< Log related to pipeline. */
#define RTE_LOGTYPE_MBUF 0x00010000 /**< Log related to mbuf. */
#define RTE_LOGTYPE_CRYPTODEV 0x00020000 /**< Log related to cryptodev. */
+#define RTE_LOGTYPE_CTRL_IF 0x00040000 /**< Log related to control interface. */
/* these log types can be used in an application */
#define RTE_LOGTYPE_USER1 0x01000000 /**< User-defined log type 1. */
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 8ecab41..e1638f0 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# Copyright(c) 2014-2015 6WIND S.A.
# All rights reserved.
#
@@ -122,6 +122,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF) += -lrte_mbuf
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF_OFFLOAD) += -lrte_mbuf_offload
_LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += -lrte_ip_frag
_LDLIBS-$(CONFIG_RTE_LIBRTE_ETHER) += -lethdev
+_LDLIBS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += -lrte_ctrl_if
_LDLIBS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += -lrte_cryptodev
_LDLIBS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += -lrte_mempool
_LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -lrte_ring
--
2.5.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size
2016-02-10 18:02 3% ` Thomas Monjalon
@ 2016-02-12 11:52 3% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-02-12 11:52 UTC (permalink / raw)
To: Thomas Monjalon, Wiles, Keith; +Cc: dev, Neil Horman
On 02/10/2016 08:02 PM, Thomas Monjalon wrote:
> 2016-02-10 18:01, Wiles, Keith:
>>>>> --- a/config/defconfig_x86_64-native-linuxapp-gcc
>>>>> +++ b/config/defconfig_x86_64-native-linuxapp-gcc
>>>>> @@ -40,3 +40,8 @@ CONFIG_RTE_ARCH_64=y
>>>>>
>>>>> CONFIG_RTE_TOOLCHAIN="gcc"
>>>>> CONFIG_RTE_TOOLCHAIN_GCC=y
>>>>> +CONFIG_RTE_BUILD_SHARED_LIB=y
>>>>> +CONFIG_RTE_NEXT_ABI=n
>>>>> +CONFIG_RTE_EAL_IGB_UIO=n
>>>>> +CONFIG_RTE_LIBRTE_KNI=n
>>>>> +CONFIG_RTE_KNI_KMOD=n
>>>
>>> Hmm, not sure where this came from, but will remove it.
>>
>> I think this was from the ABI-Checker I ran and the tool should leave the repo in its original state.
>
> Yes you're right. The ABI checker modify the defconfig instead of modifying
> the generated .config file.
Its "by design" according to Neil (this was discussed when the abi
checker was introduced, see
http://dpdk.org/ml/archives/dev/2015-March/014636.html)
I actually agree with Neil that changing .config after make config seems
counter-intuitive compared to how this works in other projects, but that
doesn't make modifying the default templates the right thing to do in DPDK.
> Anyone for a patch?
I can add it to my TODO among a couple of other things - it should not
leave clutter like this behind no matter what. As to how exactly it
should be fixed, it could of course just change .config, or
alternatively create (and later clean up) a temporary defconfig file
with the necessary contents, which would be closer to the current
approach I guess.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
@ 2016-02-12 11:44 3% ` Ananyev, Konstantin
2016-02-12 16:40 0% ` Ivan Boule
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-02-12 11:44 UTC (permalink / raw)
To: Ananyev, Konstantin, Kulasek, TomaszX, dev
>
> > -----Original Message-----
> > From: Kulasek, TomaszX
> > Sent: Tuesday, February 09, 2016 5:03 PM
> > To: Ananyev, Konstantin; dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> >
> >
> >
> > > -----Original Message-----
> > > From: Ananyev, Konstantin
> > > Sent: Tuesday, February 2, 2016 14:50
> > > To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>; dev@dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> > >
> > > Hi Tomasz,
> > >
> > > > -----Original Message-----
> > > > From: Kulasek, TomaszX
> > > > Sent: Tuesday, February 02, 2016 10:01 AM
> > > > To: Ananyev, Konstantin; dev@dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> > > >
> > > > Hi Konstantin,
> > > >
> > > > > -----Original Message-----
> > > > > From: Ananyev, Konstantin
> > > > > Sent: Friday, January 15, 2016 19:45
> > > > > To: Kulasek, TomaszX; dev@dpdk.org
> > > > > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api
> > > > >
> > > > > Hi Tomasz,
> > > > >
> > > > > >
> > > > > > + /* get new buffer space first, but keep old space around
> > > */
> > > > > > + new_bufs = rte_zmalloc("ethdev->txq_bufs",
> > > > > > + sizeof(*dev->data->txq_bufs) * nb_queues, 0);
> > > > > > + if (new_bufs == NULL)
> > > > > > + return -(ENOMEM);
> > > > > > +
> > > > >
> > > > > Why not to allocate space for txq_bufs together with tx_queues (as
> > > > > one chunk for both)?
> > > > > As I understand there is always one to one mapping between them
> > > anyway.
> > > > > Would simplify things a bit.
> > > > > Or even introduce a new struct to group with all related tx queue
> > > > > info togetehr struct rte_eth_txq_data {
> > > > > void *queue; /*actual pmd queue*/
> > > > > struct rte_eth_dev_tx_buffer buf;
> > > > > uint8_t state;
> > > > > }
> > > > > And use it inside struct rte_eth_dev_data?
> > > > > Would probably give a better data locality.
> > > > >
> > > >
> > > > Introducing such a struct will require a huge rework of pmd drivers. I
> > > don't think it's worth only for this one feature.
> > >
> > > Why not?
> > > Things are getting more and more messy here: now we have a separate array
> > > of pointer to queues, Separate array of queue states, you are going to add
> > > separate array of tx buffers.
> > > For me it seems logical to unite all these 3 fields into one sub-struct.
> > >
> >
> > I agree with you, and probably such a work will be nice also for rx queues, but these two changes impacts on another part of dpdk.
> > While buffered tx API is more client application helper.
> >
> > For me these two thinks are different features and should be made separately because:
> > 1) They are independent and can be done separately,
> > 2) They can (and should) be reviewed, tested and approved separately,
> > 3) They are addressed to another type of people (tx buffering to application developers, rte_eth_dev_data to pmd developers), so
> > another people can be interested in having (or not) one or second feature
>
> Such division seems a bit artificial to me :)
> You are making changes in rte_ethdev.[c,h] - I think that filed regrouping would make code cleaner and easier to read/maintain.
>
> >
> > Even for bug tracking it will be cleaner to separate these two things. And yes, it is logical to unite it, maybe also for rx queues, but
> > should be discussed separately.
> >
> > I've made a prototype with this rework, and the impact on the code not related to this particular feature is too wide and strong to
> join
> > them. I would rather to provide it as independent patch for further discussion only on it, if needed.
>
> Sure, separate patch is fine.
> Why not to submit it as extra one is the series?
>
>
> >
> > > >
> > > >
> > > > > > +/**
> > > > > > + * @internal
> > > > > > + * Structure used to buffer packets for future TX
> > > > > > + * Used by APIs rte_eth_tx_buffer and rte_eth_tx_buffer_flush */
> > > > > > +struct rte_eth_dev_tx_buffer {
> > > > > > + struct rte_mbuf *pkts[RTE_ETHDEV_TX_BUFSIZE];
> > > > >
> > > > > I think it is better to make size of pkts[] configurable at runtime.
> > > > > There are a lot of different usage scenarios - hard to predict what
> > > > > would be an optimal buffer size for all cases.
> > > > >
> > > >
> > > > This buffer is allocated in eth_dev shared memory, so there are two
> > > scenarios:
> > > > 1) We have prealocated buffer with maximal size, and then we can set
> > > > threshold level without restarting device, or
> > > > 2) We need to set its size before starting device.
> > >
> > > >
> > > > Second one is better, I think.
> > >
> > > Yep, I was thinking about 2) too.
> > > Might be an extra parameter in struct rte_eth_txconf.
> > >
> >
> > Struct rte_eth_txconf is passed to ethdev after rte_eth_dev_tx_queue_config, so we don't know its value when buffers are
> > allocated.
>
> Ok, and why allocation of the tx buffer can't be done at rte_eth_tx_queue_setup()?
>
> Actually just thought why not to let rte_eth_tx_buffer() to accept struct rte_eth_dev_tx_buffer * as a parameter:
> +static inline int __attribute__((always_inline))
> +rte_eth_tx_buffer(uint8_t port_id, uint16_t queue_id, accept struct rte_eth_dev_tx_buffer * txb, struct rte_mbuf *tx_pkt)
> ?
>
> In that case we don't need to make any changes at rte_ethdev.[h,c] to alloc/free/maintain tx_buffer inside each queue...
> It all will be upper layer responsibility.
> So no need to modify existing rte_ethdev structures/code.
> Again, no need for error callback - caller would check return value and decide what to do with unsent packets in the tx_buffer.
>
Just to summarise why I think it is better to have tx buffering managed on the app level:
1. avoid any ABI change.
2. Avoid extra changes in rte_ethdev.c: tx_queue_setup/tx_queue_stop.
3. Provides much more flexibility to the user:
a) where to allocate space for tx_buffer (stack, heap, hugepages, etc).
b) user can mix and match plain tx_burst() and tx_buffer/tx_buffer_flush()
in any way he fills it appropriate.
c) user can change the size of tx_buffer without stop/re-config/start queue:
just allocate new larger(smaller) tx_buffer & copy contents to the new one.
d) user can preserve buffered packets through device restart circle:
i.e if let say TX hang happened, and user has to do dev_stop/dev_start -
contents of tx_buffer will stay unchanged and its contents could be
(re-)transmitted after device is up again, or through different port/queue if needed.
As a drawbacks mentioned - tx error handling becomes less transparent...
But we can add error handling routine and it's user provided parameter
into struct rte_eth_dev_tx_buffer', something like that:
+struct rte_eth_dev_tx_buffer {
+ buffer_tx_error_fn cbfn;
+ void *userdata;
+ unsigned nb_pkts;
+ uint64_t errors;
+ /**< Total number of queue packets to sent that are dropped. */
+ struct rte_mbuf *pkts[];
+};
Konstantin
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-10 21:18 7% ` [dpdk-dev] [PATCH v3] " Keith Wiles
@ 2016-02-12 11:23 0% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-02-12 11:23 UTC (permalink / raw)
To: Keith Wiles, dev
On 02/10/2016 11:18 PM, Keith Wiles wrote:
> The rte_mempool structure is changed, which will cause an ABI change
> for this structure. Providing backward compat is not reasonable
> here as this structure is used in multiple defines/inlines.
>
> Allow mempool cache support to be dynamic depending on if the
> mempool being created needs cache support. Saves about 1.5M of
> memory used by the rte_mempool structure.
>
> Allocating small mempools which do not require cache can consume
> larges amounts of memory if you have a number of these mempools.
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> ---
> * Patch v3 fix up the ifdefs to correct some problems in removing ifdef
> lines. Added the ABI deprecation notice to the document file.
> * Patch v2 to add some comments and setup for RTE_NEXT_ABI changes.
>
> app/test/test_mempool.c | 5 +++
> doc/guides/rel_notes/deprecation.rst | 7 +++
> lib/librte_mempool/rte_mempool.c | 82 +++++++++++++++++++++++++++++++++---
> lib/librte_mempool/rte_mempool.h | 46 ++++++++++++++++----
> 4 files changed, 127 insertions(+), 13 deletions(-)
>
> diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
> index f0f823b..f3fba50 100644
> --- a/app/test/test_mempool.c
> +++ b/app/test/test_mempool.c
> @@ -122,8 +122,13 @@ test_mempool_basic(void)
> return -1;
>
> printf("get private data\n");
> +#ifdef RTE_NEXT_ABI
> + if (rte_mempool_get_priv(mp) != (char *)mp +
> + MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
> +#else
> if (rte_mempool_get_priv(mp) !=
> (char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
> +#endif
> return -1;
>
> printf("get physical address of an object\n");
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index e94d4a2..1b9d25e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -49,3 +49,10 @@ Deprecation Notices
> commands (such as RETA update in testpmd). This should impact
> CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> It should be integrated in release 2.3.
> +
> +* ABI change is planned for the rte_mempool structure to allow mempool
> + cache support to be dynamic depending on the mempool being created
> + needing cache support. Saves about 1.5M of memory per rte_mempool structure
> + by removing the per lcore cache memory. Change will occur after DPDK 16.04
> + release.
> +
> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
> index aff5f6d..5f21eaa 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -452,12 +452,17 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
> /* compilation-time checks */
> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
> RTE_CACHE_LINE_MASK) != 0);
> +#ifdef RTE_NEXT_ABI
> + RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
> + RTE_CACHE_LINE_MASK) != 0);
> +#else
> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
> RTE_CACHE_LINE_MASK) != 0);
> RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
> RTE_CACHE_LINE_MASK) != 0);
> #endif
> +#endif /* RTE_NEXT_ABI */
> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
> RTE_CACHE_LINE_MASK) != 0);
> @@ -527,9 +532,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
> */
> int head = sizeof(struct rte_mempool);
> int new_size = (private_data_size + head) % page_size;
> - if (new_size) {
> + if (new_size)
> private_data_size += page_size - new_size;
> - }
> }
>
> /* try to allocate tailq entry */
> @@ -544,7 +548,12 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
> * store mempool objects. Otherwise reserve a memzone that is large
> * enough to hold mempool header and metadata plus mempool objects.
> */
> +#ifdef RTE_NEXT_ABI
> + mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
> + mempool_size += private_data_size;
> +#else
> mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
> +#endif /* RTE_NEXT_ABI */
> mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
> if (vaddr == NULL)
> mempool_size += (size_t)objsz.total_size * n;
> @@ -598,9 +607,22 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
> mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
> mp->private_data_size = private_data_size;
>
> +#ifdef RTE_NEXT_ABI
> + /*
> + * local_cache pointer is set even if cache_size is zero.
> + * The local_cache points to just past the elt_pa[] array.
> + */
> + mp->local_cache = (struct rte_mempool_cache *)
> + ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
> +
> + /* calculate address of the first element for continuous mempool. */
> + obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
> + private_data_size;
> +#else
> /* calculate address of the first element for continuous mempool. */
> obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
> private_data_size;
> +#endif /* RTE_NEXT_ABI */
> obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
>
> /* populate address translation fields. */
> @@ -613,9 +635,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
> mp->elt_va_start = (uintptr_t)obj;
> mp->elt_pa[0] = mp->phys_addr +
> (mp->elt_va_start - (uintptr_t)mp);
> -
> - /* mempool elements in a separate chunk of memory. */
> } else {
> + /* mempool elements in a separate chunk of memory. */
> mp->elt_va_start = (uintptr_t)vaddr;
> memcpy(mp->elt_pa, paddr, sizeof (mp->elt_pa[0]) * pg_num);
> }
> @@ -645,10 +666,21 @@ unsigned
> rte_mempool_count(const struct rte_mempool *mp)
> {
> unsigned count;
> +#ifdef RTE_NEXT_ABI
> + unsigned lcore_id;
>
> count = rte_ring_count(mp->ring);
>
> + if (mp->cache_size == 0)
> + return count;
> +
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
> + count += mp->local_cache[lcore_id].len;
> +#else
> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> +
> + count = rte_ring_count(mp->ring);
> +
> {
> unsigned lcore_id;
> if (mp->cache_size == 0)
> @@ -658,6 +690,7 @@ rte_mempool_count(const struct rte_mempool *mp)
> count += mp->local_cache[lcore_id].len;
> }
> #endif
> +#endif /* RTE_NEXT_ABI */
>
> /*
> * due to race condition (access to len is not locked), the
> @@ -672,6 +705,24 @@ rte_mempool_count(const struct rte_mempool *mp)
> static unsigned
> rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
> {
> +#ifdef RTE_NEXT_ABI
> + unsigned lcore_id;
> + unsigned count = 0;
> + unsigned cache_count;
> +
> + fprintf(f, " cache infos:\n");
> + fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
> + if (mp->cache_size == 0)
> + return count;
> +
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> + cache_count = mp->local_cache[lcore_id].len;
> + fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
> + count += cache_count;
> + }
> + fprintf(f, " total_cache_count=%u\n", count);
> + return count;
> +#else
> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> unsigned lcore_id;
> unsigned count = 0;
> @@ -691,6 +742,7 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
> fprintf(f, " cache disabled\n");
> return 0;
> #endif
> +#endif /* RTE_NEXT_ABI */
> }
>
> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> @@ -755,6 +807,26 @@ mempool_audit_cookies(const struct rte_mempool *mp)
> #define mempool_audit_cookies(mp) do {} while(0)
> #endif
>
> +#ifdef RTE_NEXT_ABI
> +/* check cookies before and after objects */
> +static void
> +mempool_audit_cache(const struct rte_mempool *mp)
> +{
> + /* check cache size consistency */
> + unsigned lcore_id;
> +
> + if (mp->cache_size == 0)
> + return;
> +
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> + if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
> + RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
> + lcore_id);
> + rte_panic("MEMPOOL: invalid cache len\n");
> + }
> + }
> +}
> +#else
> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> /* check cookies before and after objects */
> static void
> @@ -773,7 +845,7 @@ mempool_audit_cache(const struct rte_mempool *mp)
> #else
> #define mempool_audit_cache(mp) do {} while(0)
> #endif
> -
> +#endif /* RTE_NEXT_ABI */
>
> /* check the consistency of mempool (size, cookies, ...) */
> void
> diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
> index 9745bf0..b12d6a9 100644
> --- a/lib/librte_mempool/rte_mempool.h
> +++ b/lib/librte_mempool/rte_mempool.h
> @@ -95,7 +95,7 @@ struct rte_mempool_debug_stats {
> } __rte_cache_aligned;
> #endif
>
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
> /**
> * A structure that stores a per-core object cache.
> */
> @@ -107,7 +107,7 @@ struct rte_mempool_cache {
> */
> void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
> } __rte_cache_aligned;
> -#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
> +#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
>
> /**
> * A structure that stores the size of mempool elements.
> @@ -194,10 +194,14 @@ struct rte_mempool {
>
> unsigned private_data_size; /**< Size of private data. */
>
> +#ifdef RTE_NEXT_ABI
> + struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
> +#else
> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> /** Per-lcore local cache. */
> struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
> #endif
> +#endif /* RTE_NEXT_ABI */
>
> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> /** Per-lcore statistics. */
> @@ -246,6 +250,26 @@ struct rte_mempool {
> #define __MEMPOOL_STAT_ADD(mp, name, n) do {} while(0)
> #endif
>
> +#ifdef RTE_NEXT_ABI
> +/**
> + * Size of elt_pa array size based on number of pages. (Internal use)
> + */
> +#define __PA_SIZE(mp, pgn) \
> + RTE_ALIGN_CEIL((((pgn) - RTE_DIM((mp)->elt_pa)) * \
> + sizeof((mp)->elt_pa[0])), RTE_CACHE_LINE_SIZE)
> +
> +/**
> + * Calculate the size of the mempool header.
> + *
> + * @param mp
> + * Pointer to the memory pool.
> + * @param pgn
> + * Number of pages used to store mempool objects.
> + */
> +#define MEMPOOL_HEADER_SIZE(mp, pgn, cs) \
> + (sizeof(*(mp)) + __PA_SIZE(mp, pgn) + (((cs) == 0) ? 0 : \
> + (sizeof(struct rte_mempool_cache) * RTE_MAX_LCORE)))
> +#else
> /**
> * Calculate the size of the mempool header.
> *
> @@ -257,6 +281,7 @@ struct rte_mempool {
> #define MEMPOOL_HEADER_SIZE(mp, pgn) (sizeof(*(mp)) + \
> RTE_ALIGN_CEIL(((pgn) - RTE_DIM((mp)->elt_pa)) * \
> sizeof ((mp)->elt_pa[0]), RTE_CACHE_LINE_SIZE))
> +#endif /* RTE_NEXT_ABI */
>
> /**
> * Return true if the whole mempool is in contiguous memory.
> @@ -755,19 +780,19 @@ static inline void __attribute__((always_inline))
> __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
> unsigned n, int is_mp)
> {
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
> struct rte_mempool_cache *cache;
> uint32_t index;
> void **cache_objs;
> unsigned lcore_id = rte_lcore_id();
> uint32_t cache_size = mp->cache_size;
> uint32_t flushthresh = mp->cache_flushthresh;
> -#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
> +#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
>
> /* increment stat now, adding in mempool always success */
> __MEMPOOL_STAT_ADD(mp, put, n);
>
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
> /* cache is not enabled or single producer or non-EAL thread */
> if (unlikely(cache_size == 0 || is_mp == 0 ||
> lcore_id >= RTE_MAX_LCORE))
> @@ -802,7 +827,7 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
> return;
>
> ring_enqueue:
> -#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
> +#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
>
> /* push remaining objects in ring */
> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> @@ -946,7 +971,7 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
> unsigned n, int is_mc)
> {
> int ret;
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
> struct rte_mempool_cache *cache;
> uint32_t index, len;
> void **cache_objs;
> @@ -992,7 +1017,7 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
> return 0;
>
> ring_dequeue:
> -#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
> +#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
>
> /* get remaining objects from ring */
> if (is_mc)
> @@ -1293,7 +1318,12 @@ void rte_mempool_audit(const struct rte_mempool *mp);
> */
> static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
> {
> +#ifdef RTE_NEXT_ABI
> + return (char *)mp +
> + MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
> +#else
> return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
> +#endif /* RTE_NEXT_ABI */
> }
>
> /**
>
This is not RTE_NEXT_ABI material IMO, the added ifdef clutter is just
too much.
I'd suggest adding a deprecation notice for the change now and after
16.04 is released, just resend the patch without messing with RTE_NEXT_ABI.
- Pnau -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API
2016-02-11 15:27 3% ` Nélio Laranjeiro
@ 2016-02-11 23:23 0% ` Marc
0 siblings, 0 replies; 200+ results
From: Marc @ 2016-02-11 23:23 UTC (permalink / raw)
To: Nélio Laranjeiro; +Cc: dev
On 11 February 2016 at 16:27, Nélio Laranjeiro <nelio.laranjeiro@6wind.com>
wrote:
> On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote:
> > On 2 February 2016 at 03:20, Stephen Hemminger <
> stephen@networkplumber.org>
> > wrote:
> >
> > > On Thu, 28 Jan 2016 17:33:20 +0000
> > > Harish Patil <harish.patil@qlogic.com> wrote:
> > >
> > > > * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
> > > > values of all supported link speeds, in Mbps.
> > >
> > > I would prefer that there were no speed value macros.
> > > Linux used to have these, but people kept adding new hardware speeds
> > > and it soon gets out of date.
> > >
> >
> > I see what you mean, but I am not sure I agree. Link speeds are
> generally a
> > reduced amount of items (~20). Though it is true it can eventually grow,
> > but at small rate. Having numeric constants all over the source seems
> less
> > readable and less maintainable (e.g. less "grepable"/"sedable") to me.
> >
> >
> > >
> > > If you are going to redo it, then just increase speed to 64 bit, and
> allow
> > > any non-zero value.
> > >
> >
> > Value is now 32 bits, which I think is enough for future rates in mbps.
> > Since these constants were there, and before doing something to have to
> > revert it, can someone else give his/her opinion on this?
>
> For non 64bit architecture it is better to keep it on 32 bit but, if this
> field is only used on control plane we can afford 64 bit field and avoid
> another ABI breakage (in a far future).
>
> Even if this 32 bit field seems large enough you can already find on
> Internet some reports of transmission of petabit/s [1], we can imagine a
> NIC which provide this possibility by aggregating a lot of optical links
> and DPDK only will see it as single one.
>
OK, since it is not performance critical I will change it to 64 bit value.
>
> > If there is consensus, I've no problem on removing it for v8
>
Still the question about numeric speed MACROs is open.
best
marc
> >
> > Thanks
> > marc
>
> [1] http://optics.org/news/4/1/29
>
> --
> Nélio Laranjeiro
> 6WIND
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3] af_packet: make the device detachable
@ 2016-02-11 16:37 3% Wojciech Zmuda
2016-02-24 14:08 3% ` Iremonger, Bernard
0 siblings, 1 reply; 200+ results
From: Wojciech Zmuda @ 2016-02-11 16:37 UTC (permalink / raw)
To: dev
Allow dynamic deallocation of af_packet device through proper
API functions. To achieve this:
* set device flag to RTE_ETH_DEV_DETACHABLE
* implement rte_pmd_af_packet_devuninit() and expose it
through rte_driver.uninit()
* copy device name to ethdev->data to make discoverable with
rte_eth_dev_allocated()
Moreover, make af_packet init function static, as there is no
reason to keep it public.
Signed-off-by: Wojciech Zmuda <woz@semihalf.com>
---
v3:
* Rephrased feature note in release notes.
* Rephrased commit log.
* Added API change note in release notes.
* Made init function static.
* Removed af_packet header file, as it is not needed
after init function is not public anymore.
v2:
* Fixed typo and a comment.
* Added feature to the 2.3 release notes.
* Free memory allocated for rx and tx queues.
doc/guides/rel_notes/release_2_3.rst | 6 +++
drivers/net/af_packet/Makefile | 5 --
drivers/net/af_packet/rte_eth_af_packet.c | 43 ++++++++++++++++--
drivers/net/af_packet/rte_eth_af_packet.h | 53 ----------------------
.../net/af_packet/rte_pmd_af_packet_version.map | 3 --
5 files changed, 45 insertions(+), 65 deletions(-)
delete mode 100644 drivers/net/af_packet/rte_eth_af_packet.h
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 7945694..da4abc3 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,9 @@ This section should contain new features added in this release. Sample format:
Enabled virtio 1.0 support for virtio pmd driver.
+* **Added af_packet dynamic removal function.**
+
+ Af_packet device can now be detached using API, like other PMD devices.
Resolved Issues
---------------
@@ -91,6 +94,9 @@ This section should contain API changes. Sample format:
* Add a short 1-2 sentence description of the API change. Use fixed width
quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* Af_packet device init function is no longer public. Device should be attached
+ with API.
+
ABI Changes
-----------
diff --git a/drivers/net/af_packet/Makefile b/drivers/net/af_packet/Makefile
index ce5d239..cb1a7ae 100644
--- a/drivers/net/af_packet/Makefile
+++ b/drivers/net/af_packet/Makefile
@@ -50,11 +50,6 @@ CFLAGS += $(WERROR_FLAGS)
#
SRCS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += rte_eth_af_packet.c
-#
-# Export include files
-#
-SYMLINK-y-include += rte_eth_af_packet.h
-
# this lib depends upon:
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_mbuf
DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += lib/librte_ether
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index 767f36b..5544528 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -53,8 +53,6 @@
#include <unistd.h>
#include <poll.h>
-#include "rte_eth_af_packet.h"
-
#define ETH_AF_PACKET_IFACE_ARG "iface"
#define ETH_AF_PACKET_NUM_Q_ARG "qpairs"
#define ETH_AF_PACKET_BLOCKSIZE_ARG "blocksz"
@@ -65,6 +63,8 @@
#define DFLT_FRAME_SIZE (1 << 11)
#define DFLT_FRAME_COUNT (1 << 9)
+#define RTE_PMD_AF_PACKET_MAX_RINGS 16
+
struct pkt_rx_queue {
int sockfd;
@@ -667,11 +667,13 @@ rte_pmd_init_internals(const char *name,
data->nb_tx_queues = (uint16_t)nb_queues;
data->dev_link = pmd_link;
data->mac_addrs = &(*internals)->eth_addr;
+ strncpy(data->name,
+ (*eth_dev)->data->name, strlen((*eth_dev)->data->name));
(*eth_dev)->data = data;
(*eth_dev)->dev_ops = &ops;
(*eth_dev)->driver = NULL;
- (*eth_dev)->data->dev_flags = 0;
+ (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
(*eth_dev)->data->drv_name = drivername;
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
@@ -798,7 +800,7 @@ rte_eth_from_packet(const char *name,
return 0;
}
-int
+static int
rte_pmd_af_packet_devinit(const char *name, const char *params)
{
unsigned numa_node;
@@ -836,10 +838,43 @@ exit:
return ret;
}
+static int
+rte_pmd_af_packet_devuninit(const char *name)
+{
+ struct rte_eth_dev *eth_dev = NULL;
+ struct pmd_internals *internals;
+ unsigned q;
+
+ RTE_LOG(INFO, PMD, "Closing AF_PACKET ethdev on numa socket %u\n",
+ rte_socket_id());
+
+ if (name == NULL)
+ return -1;
+
+ /* find the ethdev entry */
+ eth_dev = rte_eth_dev_allocated(name);
+ if (eth_dev == NULL)
+ return -1;
+
+ internals = eth_dev->data->dev_private;
+ for (q = 0; q < internals->nb_queues; q++) {
+ rte_free(internals->rx_queue[q].rd);
+ rte_free(internals->tx_queue[q].rd);
+ }
+
+ rte_free(eth_dev->data->dev_private);
+ rte_free(eth_dev->data);
+
+ rte_eth_dev_release_port(eth_dev);
+
+ return 0;
+}
+
static struct rte_driver pmd_af_packet_drv = {
.name = "eth_af_packet",
.type = PMD_VDEV,
.init = rte_pmd_af_packet_devinit,
+ .uninit = rte_pmd_af_packet_devuninit,
};
PMD_REGISTER_DRIVER(pmd_af_packet_drv);
diff --git a/drivers/net/af_packet/rte_eth_af_packet.h b/drivers/net/af_packet/rte_eth_af_packet.h
deleted file mode 100644
index 5d1bc7e..0000000
--- a/drivers/net/af_packet/rte_eth_af_packet.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*-
- * 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.
- */
-
-#ifndef _RTE_ETH_AF_PACKET_H_
-#define _RTE_ETH_AF_PACKET_H_
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#define RTE_PMD_AF_PACKET_MAX_RINGS 16
-
-/**
- * For use by the EAL only. Called as part of EAL init to set up any dummy NICs
- * configured on command line.
- */
-int rte_pmd_af_packet_devinit(const char *name, const char *params);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif
diff --git a/drivers/net/af_packet/rte_pmd_af_packet_version.map b/drivers/net/af_packet/rte_pmd_af_packet_version.map
index de95169..ef35398 100644
--- a/drivers/net/af_packet/rte_pmd_af_packet_version.map
+++ b/drivers/net/af_packet/rte_pmd_af_packet_version.map
@@ -1,7 +1,4 @@
DPDK_2.0 {
- global:
-
- rte_pmd_af_packet_devinit;
local: *;
};
--
1.9.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API
@ 2016-02-11 15:27 3% ` Nélio Laranjeiro
2016-02-11 23:23 0% ` Marc
0 siblings, 1 reply; 200+ results
From: Nélio Laranjeiro @ 2016-02-11 15:27 UTC (permalink / raw)
To: Marc; +Cc: dev
On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote:
> On 2 February 2016 at 03:20, Stephen Hemminger <stephen@networkplumber.org>
> wrote:
>
> > On Thu, 28 Jan 2016 17:33:20 +0000
> > Harish Patil <harish.patil@qlogic.com> wrote:
> >
> > > * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
> > > values of all supported link speeds, in Mbps.
> >
> > I would prefer that there were no speed value macros.
> > Linux used to have these, but people kept adding new hardware speeds
> > and it soon gets out of date.
> >
>
> I see what you mean, but I am not sure I agree. Link speeds are generally a
> reduced amount of items (~20). Though it is true it can eventually grow,
> but at small rate. Having numeric constants all over the source seems less
> readable and less maintainable (e.g. less "grepable"/"sedable") to me.
>
>
> >
> > If you are going to redo it, then just increase speed to 64 bit, and allow
> > any non-zero value.
> >
>
> Value is now 32 bits, which I think is enough for future rates in mbps.
> Since these constants were there, and before doing something to have to
> revert it, can someone else give his/her opinion on this?
For non 64bit architecture it is better to keep it on 32 bit but, if this
field is only used on control plane we can afford 64 bit field and avoid
another ABI breakage (in a far future).
Even if this 32 bit field seems large enough you can already find on
Internet some reports of transmission of petabit/s [1], we can imagine a
NIC which provide this possibility by aggregating a lot of optical links
and DPDK only will see it as single one.
> If there is consensus, I've no problem on removing it for v8
>
> Thanks
> marc
[1] http://optics.org/news/4/1/29
--
Nélio Laranjeiro
6WIND
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3] mempool: reduce rte_mempool structure size
2016-02-09 17:30 2% ` [dpdk-dev] [PATCH v2] mempool: reduce " Keith Wiles
@ 2016-02-10 21:18 7% ` Keith Wiles
2016-02-12 11:23 0% ` Panu Matilainen
2016-02-12 18:36 3% ` [dpdk-dev] [PATCH v4] " Keith Wiles
2 siblings, 1 reply; 200+ results
From: Keith Wiles @ 2016-02-10 21:18 UTC (permalink / raw)
To: dev
The rte_mempool structure is changed, which will cause an ABI change
for this structure. Providing backward compat is not reasonable
here as this structure is used in multiple defines/inlines.
Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support. Saves about 1.5M of
memory used by the rte_mempool structure.
Allocating small mempools which do not require cache can consume
larges amounts of memory if you have a number of these mempools.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
* Patch v3 fix up the ifdefs to correct some problems in removing ifdef
lines. Added the ABI deprecation notice to the document file.
* Patch v2 to add some comments and setup for RTE_NEXT_ABI changes.
app/test/test_mempool.c | 5 +++
doc/guides/rel_notes/deprecation.rst | 7 +++
lib/librte_mempool/rte_mempool.c | 82 +++++++++++++++++++++++++++++++++---
lib/librte_mempool/rte_mempool.h | 46 ++++++++++++++++----
4 files changed, 127 insertions(+), 13 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index f0f823b..f3fba50 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -122,8 +122,13 @@ test_mempool_basic(void)
return -1;
printf("get private data\n");
+#ifdef RTE_NEXT_ABI
+ if (rte_mempool_get_priv(mp) != (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
+#else
if (rte_mempool_get_priv(mp) !=
(char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
+#endif
return -1;
printf("get physical address of an object\n");
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..1b9d25e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,10 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI change is planned for the rte_mempool structure to allow mempool
+ cache support to be dynamic depending on the mempool being created
+ needing cache support. Saves about 1.5M of memory per rte_mempool structure
+ by removing the per lcore cache memory. Change will occur after DPDK 16.04
+ release.
+
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..5f21eaa 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -452,12 +452,17 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
/* compilation-time checks */
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
RTE_CACHE_LINE_MASK) != 0);
+#ifdef RTE_NEXT_ABI
+ RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
+ RTE_CACHE_LINE_MASK) != 0);
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
RTE_CACHE_LINE_MASK) != 0);
RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
RTE_CACHE_LINE_MASK) != 0);
#endif
+#endif /* RTE_NEXT_ABI */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
RTE_CACHE_LINE_MASK) != 0);
@@ -527,9 +532,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
*/
int head = sizeof(struct rte_mempool);
int new_size = (private_data_size + head) % page_size;
- if (new_size) {
+ if (new_size)
private_data_size += page_size - new_size;
- }
}
/* try to allocate tailq entry */
@@ -544,7 +548,12 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
* store mempool objects. Otherwise reserve a memzone that is large
* enough to hold mempool header and metadata plus mempool objects.
*/
+#ifdef RTE_NEXT_ABI
+ mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
+ mempool_size += private_data_size;
+#else
mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+#endif /* RTE_NEXT_ABI */
mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
if (vaddr == NULL)
mempool_size += (size_t)objsz.total_size * n;
@@ -598,9 +607,22 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
mp->private_data_size = private_data_size;
+#ifdef RTE_NEXT_ABI
+ /*
+ * local_cache pointer is set even if cache_size is zero.
+ * The local_cache points to just past the elt_pa[] array.
+ */
+ mp->local_cache = (struct rte_mempool_cache *)
+ ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
+
+ /* calculate address of the first element for continuous mempool. */
+ obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
+ private_data_size;
+#else
/* calculate address of the first element for continuous mempool. */
obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
private_data_size;
+#endif /* RTE_NEXT_ABI */
obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
/* populate address translation fields. */
@@ -613,9 +635,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->elt_va_start = (uintptr_t)obj;
mp->elt_pa[0] = mp->phys_addr +
(mp->elt_va_start - (uintptr_t)mp);
-
- /* mempool elements in a separate chunk of memory. */
} else {
+ /* mempool elements in a separate chunk of memory. */
mp->elt_va_start = (uintptr_t)vaddr;
memcpy(mp->elt_pa, paddr, sizeof (mp->elt_pa[0]) * pg_num);
}
@@ -645,10 +666,21 @@ unsigned
rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
+#ifdef RTE_NEXT_ABI
+ unsigned lcore_id;
count = rte_ring_count(mp->ring);
+ if (mp->cache_size == 0)
+ return count;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
+ count += mp->local_cache[lcore_id].len;
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+
+ count = rte_ring_count(mp->ring);
+
{
unsigned lcore_id;
if (mp->cache_size == 0)
@@ -658,6 +690,7 @@ rte_mempool_count(const struct rte_mempool *mp)
count += mp->local_cache[lcore_id].len;
}
#endif
+#endif /* RTE_NEXT_ABI */
/*
* due to race condition (access to len is not locked), the
@@ -672,6 +705,24 @@ rte_mempool_count(const struct rte_mempool *mp)
static unsigned
rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
{
+#ifdef RTE_NEXT_ABI
+ unsigned lcore_id;
+ unsigned count = 0;
+ unsigned cache_count;
+
+ fprintf(f, " cache infos:\n");
+ fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
+ if (mp->cache_size == 0)
+ return count;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ cache_count = mp->local_cache[lcore_id].len;
+ fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
+ count += cache_count;
+ }
+ fprintf(f, " total_cache_count=%u\n", count);
+ return count;
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
unsigned lcore_id;
unsigned count = 0;
@@ -691,6 +742,7 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
fprintf(f, " cache disabled\n");
return 0;
#endif
+#endif /* RTE_NEXT_ABI */
}
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -755,6 +807,26 @@ mempool_audit_cookies(const struct rte_mempool *mp)
#define mempool_audit_cookies(mp) do {} while(0)
#endif
+#ifdef RTE_NEXT_ABI
+/* check cookies before and after objects */
+static void
+mempool_audit_cache(const struct rte_mempool *mp)
+{
+ /* check cache size consistency */
+ unsigned lcore_id;
+
+ if (mp->cache_size == 0)
+ return;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
+ RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
+ lcore_id);
+ rte_panic("MEMPOOL: invalid cache len\n");
+ }
+ }
+}
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* check cookies before and after objects */
static void
@@ -773,7 +845,7 @@ mempool_audit_cache(const struct rte_mempool *mp)
#else
#define mempool_audit_cache(mp) do {} while(0)
#endif
-
+#endif /* RTE_NEXT_ABI */
/* check the consistency of mempool (size, cookies, ...) */
void
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 9745bf0..b12d6a9 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -95,7 +95,7 @@ struct rte_mempool_debug_stats {
} __rte_cache_aligned;
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
/**
* A structure that stores a per-core object cache.
*/
@@ -107,7 +107,7 @@ struct rte_mempool_cache {
*/
void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
} __rte_cache_aligned;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
/**
* A structure that stores the size of mempool elements.
@@ -194,10 +194,14 @@ struct rte_mempool {
unsigned private_data_size; /**< Size of private data. */
+#ifdef RTE_NEXT_ABI
+ struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/** Per-lcore local cache. */
struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
#endif
+#endif /* RTE_NEXT_ABI */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
/** Per-lcore statistics. */
@@ -246,6 +250,26 @@ struct rte_mempool {
#define __MEMPOOL_STAT_ADD(mp, name, n) do {} while(0)
#endif
+#ifdef RTE_NEXT_ABI
+/**
+ * Size of elt_pa array size based on number of pages. (Internal use)
+ */
+#define __PA_SIZE(mp, pgn) \
+ RTE_ALIGN_CEIL((((pgn) - RTE_DIM((mp)->elt_pa)) * \
+ sizeof((mp)->elt_pa[0])), RTE_CACHE_LINE_SIZE)
+
+/**
+ * Calculate the size of the mempool header.
+ *
+ * @param mp
+ * Pointer to the memory pool.
+ * @param pgn
+ * Number of pages used to store mempool objects.
+ */
+#define MEMPOOL_HEADER_SIZE(mp, pgn, cs) \
+ (sizeof(*(mp)) + __PA_SIZE(mp, pgn) + (((cs) == 0) ? 0 : \
+ (sizeof(struct rte_mempool_cache) * RTE_MAX_LCORE)))
+#else
/**
* Calculate the size of the mempool header.
*
@@ -257,6 +281,7 @@ struct rte_mempool {
#define MEMPOOL_HEADER_SIZE(mp, pgn) (sizeof(*(mp)) + \
RTE_ALIGN_CEIL(((pgn) - RTE_DIM((mp)->elt_pa)) * \
sizeof ((mp)->elt_pa[0]), RTE_CACHE_LINE_SIZE))
+#endif /* RTE_NEXT_ABI */
/**
* Return true if the whole mempool is in contiguous memory.
@@ -755,19 +780,19 @@ static inline void __attribute__((always_inline))
__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n, int is_mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
struct rte_mempool_cache *cache;
uint32_t index;
void **cache_objs;
unsigned lcore_id = rte_lcore_id();
uint32_t cache_size = mp->cache_size;
uint32_t flushthresh = mp->cache_flushthresh;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
/* increment stat now, adding in mempool always success */
__MEMPOOL_STAT_ADD(mp, put, n);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
/* cache is not enabled or single producer or non-EAL thread */
if (unlikely(cache_size == 0 || is_mp == 0 ||
lcore_id >= RTE_MAX_LCORE))
@@ -802,7 +827,7 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
return;
ring_enqueue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
/* push remaining objects in ring */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -946,7 +971,7 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
unsigned n, int is_mc)
{
int ret;
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI) /* Remove line */
struct rte_mempool_cache *cache;
uint32_t index, len;
void **cache_objs;
@@ -992,7 +1017,7 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
return 0;
ring_dequeue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */ /* Remove line RTE_NEXT_ABI */
/* get remaining objects from ring */
if (is_mc)
@@ -1293,7 +1318,12 @@ void rte_mempool_audit(const struct rte_mempool *mp);
*/
static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
{
+#ifdef RTE_NEXT_ABI
+ return (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
+#else
return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
+#endif /* RTE_NEXT_ABI */
}
/**
--
2.5.4 (Apple Git-61)
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size
2016-02-10 18:01 3% [dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size Wiles, Keith
@ 2016-02-10 18:02 3% ` Thomas Monjalon
2016-02-12 11:52 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-02-10 18:02 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dev, Neil Horman
2016-02-10 18:01, Wiles, Keith:
> >>> --- a/config/defconfig_x86_64-native-linuxapp-gcc
> >>> +++ b/config/defconfig_x86_64-native-linuxapp-gcc
> >>> @@ -40,3 +40,8 @@ CONFIG_RTE_ARCH_64=y
> >>>
> >>> CONFIG_RTE_TOOLCHAIN="gcc"
> >>> CONFIG_RTE_TOOLCHAIN_GCC=y
> >>> +CONFIG_RTE_BUILD_SHARED_LIB=y
> >>> +CONFIG_RTE_NEXT_ABI=n
> >>> +CONFIG_RTE_EAL_IGB_UIO=n
> >>> +CONFIG_RTE_LIBRTE_KNI=n
> >>> +CONFIG_RTE_KNI_KMOD=n
> >
> >Hmm, not sure where this came from, but will remove it.
>
> I think this was from the ABI-Checker I ran and the tool should leave the repo in its original state.
Yes you're right. The ABI checker modify the defconfig instead of modifying
the generated .config file.
Anyone for a patch?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size
@ 2016-02-10 18:01 3% Wiles, Keith
2016-02-10 18:02 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Wiles, Keith @ 2016-02-10 18:01 UTC (permalink / raw)
To: Olivier MATZ, dev
>>Hi Keith,
>>
>>Thank you for adding the RTE_NEXT_ABI. I think this is the way
>>described in the process. Your changes will be available in next
>>version (16.4) for people compiling with RTE_NEXT_ABI=y, and in
>>16.7 without option (I'm just surprised that RTE_NEXT_ABI=y in
>>default configs...).
>>
>>I think a deprecation notice should also be added in this commit
>>in doc/guides/rel_notes/deprecation.rst.
>
>Will add the text.
>>
>>Please also find comments below.
>>
>>On 02/09/2016 06:30 PM, Keith Wiles wrote:
>>
>>> diff --git a/config/defconfig_x86_64-native-linuxapp-gcc b/config/defconfig_x86_64-native-linuxapp-gcc
>>> index 60baf5b..02e9ace 100644
>>> --- a/config/defconfig_x86_64-native-linuxapp-gcc
>>> +++ b/config/defconfig_x86_64-native-linuxapp-gcc
>>> @@ -40,3 +40,8 @@ CONFIG_RTE_ARCH_64=y
>>>
>>> CONFIG_RTE_TOOLCHAIN="gcc"
>>> CONFIG_RTE_TOOLCHAIN_GCC=y
>>> +CONFIG_RTE_BUILD_SHARED_LIB=y
>>> +CONFIG_RTE_NEXT_ABI=n
>>> +CONFIG_RTE_EAL_IGB_UIO=n
>>> +CONFIG_RTE_LIBRTE_KNI=n
>>> +CONFIG_RTE_KNI_KMOD=n
>
>Hmm, not sure where this came from, but will remove it.
I think this was from the ABI-Checker I ran and the tool should leave the repo in its original state.
>>
>>I think this should not be part of the patch.
>>
>>> @@ -672,6 +704,24 @@ rte_mempool_count(const struct rte_mempool *mp)
>>> static unsigned
>>> rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
>>> {
>>> +#ifdef RTE_NEXT_ABI
>>> + unsigned lcore_id;
>>> + unsigned count = 0;
>>> + unsigned cache_count;
>>> +
>>> + fprintf(f, " cache infos:\n");
>>> + fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
>>> + if (mp->cache_size == 0)
>>> + return count;
>>> +
>>> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
>>> + cache_count = mp->local_cache[lcore_id].len;
>>> + fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
>>> + count += cache_count;
>>> + }
>>> + fprintf(f, " total_cache_count=%u\n", count);
>>> + return count;
>>> +#else
>>> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>> unsigned lcore_id;
>>> unsigned count = 0;
>>
>>I think in this case we could avoid to duplicate the code without
>>beeing unclear by using the proper #ifdefs:
>
>I was struggling with how it should be done. I like to see clear ifdefs and be able to see the complete code for a given case. In these cases I wanted to make it simple to remove the code quickly by just deleting lines instead of editing lines. I will follow your suggestion.
>>
>>#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI)
>> /* common code */
>>#ifdef RTE_NEXT_ABI
>> if (mp->cache_size == 0)
>> return count;
>>#endif
>> /* common code */
>>#else
>>...
>>#endif
>>
>>
>>> @@ -755,6 +806,26 @@ mempool_audit_cookies(const struct rte_mempool *mp)
>>> #define mempool_audit_cookies(mp) do {} while(0)
>>> #endif
>>>
>>> +#ifdef RTE_NEXT_ABI
>>> +/* check cookies before and after objects */
>>> +static void
>>> +mempool_audit_cache(const struct rte_mempool *mp)
>>> +{
>>> + /* check cache size consistency */
>>> + unsigned lcore_id;
>>> +
>>> + if (mp->cache_size == 0)
>>> + return;
>>> +
>>> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
>>> + if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
>>> + RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
>>> + lcore_id);
>>> + rte_panic("MEMPOOL: invalid cache len\n");
>>> + }
>>> + }
>>> +}
>>> +#else
>>
>>same here
>>
>>> diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
>>> index 6e2390a..fc9b595 100644
>>> --- a/lib/librte_mempool/rte_mempool.h
>>> +++ b/lib/librte_mempool/rte_mempool.h
>>> @@ -95,6 +95,19 @@ struct rte_mempool_debug_stats {
>>> } __rte_cache_aligned;
>>> #endif
>>>
>>> +#ifdef RTE_NEXT_ABI
>>> +/**
>>> + * A structure that stores a per-core object cache.
>>> + */
>>> +struct rte_mempool_cache {
>>> + unsigned len; /**< Cache len */
>>> + /*
>>> + * Cache is allocated to this size to allow it to overflow in certain
>>> + * cases to avoid needless emptying of cache.
>>> + */
>>> + void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
>>> +} __rte_cache_aligned;
>>> +#else
>>
>>same here
>>
>>
>>
>>> @@ -755,19 +793,25 @@ static inline void __attribute__((always_inline))
>>> __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
>>> unsigned n, int is_mp)
>>> {
>>> +#ifndef RTE_NEXT_ABI /* Note: ifndef */
>>> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>> +#endif /* RTE_NEXT_ABI */
>>> struct rte_mempool_cache *cache;
>>> uint32_t index;
>>> void **cache_objs;
>>> unsigned lcore_id = rte_lcore_id();
>>> uint32_t cache_size = mp->cache_size;
>>> uint32_t flushthresh = mp->cache_flushthresh;
>>> +#ifndef RTE_NEXT_ABI /* Note: ifndef */
>>> #endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
>>> +#endif /* RTE_NEXT_ABI */
>>
>>this looks strange... I think it does not work properly.
>>Why not
>>#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0 || defined(RTE_NEXT_ABI)
>
>Yes, it is strange :-(
>>
>>> /* increment stat now, adding in mempool always success */
>>> __MEMPOOL_STAT_ADD(mp, put, n);
>>>
>>> +#ifndef RTE_NEXT_ABI /* Note: ifndef */
>>> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>> +#endif /* RTE_NEXT_ABI */
>>> /* cache is not enabled or single producer or non-EAL thread */
>>> if (unlikely(cache_size == 0 || is_mp == 0 ||
>>> lcore_id >= RTE_MAX_LCORE))
>>> @@ -802,7 +846,9 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
>>> return;
>>>
>>> ring_enqueue:
>>> +#ifndef RTE_NEXT_ABI /* Note: ifndef */
>>> #endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
>>> +#endif /* RTE_NEXT_ABI */
>>>
>>> /* push remaining objects in ring */
>>> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
>>> @@ -946,7 +992,9 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
>>> unsigned n, int is_mc)
>>> {
>>> int ret;
>>> +#ifndef RTE_NEXT_ABI /* Note: ifndef */
>>> #if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>> +#endif /* RTE_NEXT_ABI */
>>> struct rte_mempool_cache *cache;
>>> uint32_t index, len;
>>> void **cache_objs;
>>> @@ -992,7 +1040,9 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
>>> return 0;
>>>
>>> ring_dequeue:
>>> +#ifndef RTE_NEXT_ABI /* Note: ifndef */
>>> #endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
>>> +#endif /* RTE_NEXT_ABI */
>>>
>>> /* get remaining objects from ring */
>>> if (is_mc)
>>
>>Same in those cases.
>>
>>
>>
>>Regards,
>>Olivier
>>
>
>
>Regards,
>Keith
>
>
>
>
>
Regards,
Keith
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 2/2] doc: rename release notes 2.3 to 16.04
@ 2016-02-10 17:02 9% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2016-02-10 17:02 UTC (permalink / raw)
To: dev
From: "Richardson, Bruce" <bruce.richardson@intel.com>
Updated release documentation to reflect new numbering scheme.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/index.rst | 2 +-
doc/guides/rel_notes/release_16_04.rst | 138 +++++++++++++++++++++++++++++++++
doc/guides/rel_notes/release_2_3.rst | 138 ---------------------------------
3 files changed, 139 insertions(+), 139 deletions(-)
create mode 100644 doc/guides/rel_notes/release_16_04.rst
delete mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 29013cf..84317b8 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,7 +36,7 @@ Release Notes
:numbered:
rel_description
- release_2_3
+ release_16_04
release_2_2
release_2_1
release_2_0
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
new file mode 100644
index 0000000..27fc624
--- /dev/null
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -0,0 +1,138 @@
+DPDK Release 16.04
+==================
+
+
+**Read this first**
+
+The text below explains how to update the release notes.
+
+Use proper spelling, capitalization and punctuation in all sections.
+
+Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
+
+Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+
+ firefox build/doc/html/guides/rel_notes/release_16_04.html
+
+
+New Features
+------------
+
+This section should contain new features added in this release. Sample format:
+
+* **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense. The description
+ should be enough to allow someone scanning the release notes to understand
+ the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list like this.
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+* **Virtio 1.0.**
+
+ Enabled virtio 1.0 support for virtio pmd driver.
+
+
+Resolved Issues
+---------------
+
+This section should contain bug fixes added to the relevant sections. Sample format:
+
+* **code/section Fixed issue in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description of the resolved issue in the past tense.
+ The title should contain the code/lib section like a commit message.
+ Add the entries in alphabetic order in the relevant sections below.
+
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+This section should contain new known issues in this release. Sample format:
+
+* **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue in the present
+ tense. Add information on any known workarounds.
+
+
+API Changes
+-----------
+
+This section should contain API changes. Sample format:
+
+* Add a short 1-2 sentence description of the API change. Use fixed width
+ quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
+ABI Changes
+-----------
+
+* Add a short 1-2 sentence description of the ABI change that was announced in
+ the previous releases and made in this release. Use fixed width quotes for
+ ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
+Shared Library Versions
+-----------------------
+
+Update any library version updated in this release and prepend with a ``+`` sign.
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
deleted file mode 100644
index 7945694..0000000
--- a/doc/guides/rel_notes/release_2_3.rst
+++ /dev/null
@@ -1,138 +0,0 @@
-DPDK Release 2.3
-================
-
-
-**Read this first**
-
-The text below explains how to update the release notes.
-
-Use proper spelling, capitalization and punctuation in all sections.
-
-Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
-
-Build the docs and view the output file to ensure the changes are correct::
-
- make doc-guides-html
-
- firefox build/doc/html/guides/rel_notes/release_2_3.html
-
-
-New Features
-------------
-
-This section should contain new features added in this release. Sample format:
-
-* **Add a title in the past tense with a full stop.**
-
- Add a short 1-2 sentence description in the past tense. The description
- should be enough to allow someone scanning the release notes to understand
- the new feature.
-
- If the feature adds a lot of sub-features you can use a bullet list like this.
-
- * Added feature foo to do something.
- * Enhanced feature bar to do something else.
-
- Refer to the previous release notes for examples.
-
-* **Virtio 1.0.**
-
- Enabled virtio 1.0 support for virtio pmd driver.
-
-
-Resolved Issues
----------------
-
-This section should contain bug fixes added to the relevant sections. Sample format:
-
-* **code/section Fixed issue in the past tense with a full stop.**
-
- Add a short 1-2 sentence description of the resolved issue in the past tense.
- The title should contain the code/lib section like a commit message.
- Add the entries in alphabetic order in the relevant sections below.
-
-
-EAL
-~~~
-
-
-Drivers
-~~~~~~~
-
-
-Libraries
-~~~~~~~~~
-
-
-Examples
-~~~~~~~~
-
-
-Other
-~~~~~
-
-
-Known Issues
-------------
-
-This section should contain new known issues in this release. Sample format:
-
-* **Add title in present tense with full stop.**
-
- Add a short 1-2 sentence description of the known issue in the present
- tense. Add information on any known workarounds.
-
-
-API Changes
------------
-
-This section should contain API changes. Sample format:
-
-* Add a short 1-2 sentence description of the API change. Use fixed width
- quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
-
-
-ABI Changes
------------
-
-* Add a short 1-2 sentence description of the ABI change that was announced in
- the previous releases and made in this release. Use fixed width quotes for
- ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
-
-
-Shared Library Versions
------------------------
-
-Update any library version updated in this release and prepend with a ``+`` sign.
-
-The libraries prepended with a plus sign were incremented in this version.
-
-.. code-block:: diff
-
- libethdev.so.2
- librte_acl.so.2
- librte_cfgfile.so.2
- librte_cmdline.so.1
- librte_distributor.so.1
- librte_eal.so.2
- librte_hash.so.2
- librte_ip_frag.so.1
- librte_ivshmem.so.1
- librte_jobstats.so.1
- librte_kni.so.2
- librte_kvargs.so.1
- librte_lpm.so.2
- librte_mbuf.so.2
- librte_mempool.so.1
- librte_meter.so.1
- librte_pipeline.so.2
- librte_pmd_bond.so.1
- librte_pmd_ring.so.2
- librte_port.so.2
- librte_power.so.1
- librte_reorder.so.1
- librte_ring.so.1
- librte_sched.so.1
- librte_table.so.2
- librte_timer.so.1
- librte_vhost.so.2
--
2.5.0
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2 2/2] doc: rename release notes 2.3 to 16.04
@ 2016-02-10 14:33 9% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2016-02-10 14:33 UTC (permalink / raw)
To: dev
From: "Richardson, Bruce" <bruce.richardson@intel.com>
Updated release documentation to reflect new numbering scheme.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/index.rst | 2 +-
doc/guides/rel_notes/release_16_04.rst | 138 +++++++++++++++++++++++++++++++++
doc/guides/rel_notes/release_2_3.rst | 138 ---------------------------------
3 files changed, 139 insertions(+), 139 deletions(-)
create mode 100644 doc/guides/rel_notes/release_16_04.rst
delete mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 29013cf..84317b8 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,7 +36,7 @@ Release Notes
:numbered:
rel_description
- release_2_3
+ release_16_04
release_2_2
release_2_1
release_2_0
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
new file mode 100644
index 0000000..27fc624
--- /dev/null
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -0,0 +1,138 @@
+DPDK Release 16.04
+==================
+
+
+**Read this first**
+
+The text below explains how to update the release notes.
+
+Use proper spelling, capitalization and punctuation in all sections.
+
+Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
+
+Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+
+ firefox build/doc/html/guides/rel_notes/release_16_04.html
+
+
+New Features
+------------
+
+This section should contain new features added in this release. Sample format:
+
+* **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense. The description
+ should be enough to allow someone scanning the release notes to understand
+ the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list like this.
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+* **Virtio 1.0.**
+
+ Enabled virtio 1.0 support for virtio pmd driver.
+
+
+Resolved Issues
+---------------
+
+This section should contain bug fixes added to the relevant sections. Sample format:
+
+* **code/section Fixed issue in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description of the resolved issue in the past tense.
+ The title should contain the code/lib section like a commit message.
+ Add the entries in alphabetic order in the relevant sections below.
+
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+This section should contain new known issues in this release. Sample format:
+
+* **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue in the present
+ tense. Add information on any known workarounds.
+
+
+API Changes
+-----------
+
+This section should contain API changes. Sample format:
+
+* Add a short 1-2 sentence description of the API change. Use fixed width
+ quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
+ABI Changes
+-----------
+
+* Add a short 1-2 sentence description of the ABI change that was announced in
+ the previous releases and made in this release. Use fixed width quotes for
+ ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
+Shared Library Versions
+-----------------------
+
+Update any library version updated in this release and prepend with a ``+`` sign.
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
deleted file mode 100644
index 7945694..0000000
--- a/doc/guides/rel_notes/release_2_3.rst
+++ /dev/null
@@ -1,138 +0,0 @@
-DPDK Release 2.3
-================
-
-
-**Read this first**
-
-The text below explains how to update the release notes.
-
-Use proper spelling, capitalization and punctuation in all sections.
-
-Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
-
-Build the docs and view the output file to ensure the changes are correct::
-
- make doc-guides-html
-
- firefox build/doc/html/guides/rel_notes/release_2_3.html
-
-
-New Features
-------------
-
-This section should contain new features added in this release. Sample format:
-
-* **Add a title in the past tense with a full stop.**
-
- Add a short 1-2 sentence description in the past tense. The description
- should be enough to allow someone scanning the release notes to understand
- the new feature.
-
- If the feature adds a lot of sub-features you can use a bullet list like this.
-
- * Added feature foo to do something.
- * Enhanced feature bar to do something else.
-
- Refer to the previous release notes for examples.
-
-* **Virtio 1.0.**
-
- Enabled virtio 1.0 support for virtio pmd driver.
-
-
-Resolved Issues
----------------
-
-This section should contain bug fixes added to the relevant sections. Sample format:
-
-* **code/section Fixed issue in the past tense with a full stop.**
-
- Add a short 1-2 sentence description of the resolved issue in the past tense.
- The title should contain the code/lib section like a commit message.
- Add the entries in alphabetic order in the relevant sections below.
-
-
-EAL
-~~~
-
-
-Drivers
-~~~~~~~
-
-
-Libraries
-~~~~~~~~~
-
-
-Examples
-~~~~~~~~
-
-
-Other
-~~~~~
-
-
-Known Issues
-------------
-
-This section should contain new known issues in this release. Sample format:
-
-* **Add title in present tense with full stop.**
-
- Add a short 1-2 sentence description of the known issue in the present
- tense. Add information on any known workarounds.
-
-
-API Changes
------------
-
-This section should contain API changes. Sample format:
-
-* Add a short 1-2 sentence description of the API change. Use fixed width
- quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
-
-
-ABI Changes
------------
-
-* Add a short 1-2 sentence description of the ABI change that was announced in
- the previous releases and made in this release. Use fixed width quotes for
- ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
-
-
-Shared Library Versions
------------------------
-
-Update any library version updated in this release and prepend with a ``+`` sign.
-
-The libraries prepended with a plus sign were incremented in this version.
-
-.. code-block:: diff
-
- libethdev.so.2
- librte_acl.so.2
- librte_cfgfile.so.2
- librte_cmdline.so.1
- librte_distributor.so.1
- librte_eal.so.2
- librte_hash.so.2
- librte_ip_frag.so.1
- librte_ivshmem.so.1
- librte_jobstats.so.1
- librte_kni.so.2
- librte_kvargs.so.1
- librte_lpm.so.2
- librte_mbuf.so.2
- librte_mempool.so.1
- librte_meter.so.1
- librte_pipeline.so.2
- librte_pmd_bond.so.1
- librte_pmd_ring.so.2
- librte_port.so.2
- librte_power.so.1
- librte_reorder.so.1
- librte_ring.so.1
- librte_sched.so.1
- librte_table.so.2
- librte_timer.so.1
- librte_vhost.so.2
--
2.5.0
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size
2016-02-02 23:02 2% [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size Keith Wiles
2016-02-03 17:11 0% ` Ananyev, Konstantin
2016-02-08 11:02 4% ` Olivier MATZ
@ 2016-02-09 17:30 2% ` Keith Wiles
2016-02-10 21:18 7% ` [dpdk-dev] [PATCH v3] " Keith Wiles
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Keith Wiles @ 2016-02-09 17:30 UTC (permalink / raw)
To: dev
Patch v2 to add some comments and setup for RTE_NEXT_ABI changes.
The rte_mempool structure is changed, which will cause an ABI change
for this structure. Providing backward compat is not reasonable
here as this structure is used in multiple defines/inlines.
Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support. Saves about 1.5M of
memory used by the rte_mempool structure.
Allocating small mempools which do not require cache can consume
larges amounts of memory if you have a number of these mempools.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
app/test/test_mempool.c | 5 ++
config/defconfig_x86_64-native-linuxapp-gcc | 5 ++
lib/librte_mempool/rte_mempool.c | 83 ++++++++++++++++++++++++++---
lib/librte_mempool/rte_mempool.h | 57 +++++++++++++++++++-
4 files changed, 143 insertions(+), 7 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 72f8fb6..2829d40 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -122,8 +122,13 @@ test_mempool_basic(void)
return -1;
printf("get private data\n");
+#ifdef RTE_NEXT_ABI
+ if (rte_mempool_get_priv(mp) != (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
+#else
if (rte_mempool_get_priv(mp) !=
(char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
+#endif
return -1;
printf("get physical address of an object\n");
diff --git a/config/defconfig_x86_64-native-linuxapp-gcc b/config/defconfig_x86_64-native-linuxapp-gcc
index 60baf5b..02e9ace 100644
--- a/config/defconfig_x86_64-native-linuxapp-gcc
+++ b/config/defconfig_x86_64-native-linuxapp-gcc
@@ -40,3 +40,8 @@ CONFIG_RTE_ARCH_64=y
CONFIG_RTE_TOOLCHAIN="gcc"
CONFIG_RTE_TOOLCHAIN_GCC=y
+CONFIG_RTE_BUILD_SHARED_LIB=y
+CONFIG_RTE_NEXT_ABI=n
+CONFIG_RTE_EAL_IGB_UIO=n
+CONFIG_RTE_LIBRTE_KNI=n
+CONFIG_RTE_KNI_KMOD=n
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..c61dc44 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -452,12 +452,17 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
/* compilation-time checks */
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
RTE_CACHE_LINE_MASK) != 0);
+#ifdef RTE_NEXT_ABI
+ RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
+ RTE_CACHE_LINE_MASK) != 0);
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
RTE_CACHE_LINE_MASK) != 0);
RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
RTE_CACHE_LINE_MASK) != 0);
#endif
+#endif /* RTE_NEXT_ABI */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
RTE_CACHE_LINE_MASK) != 0);
@@ -527,9 +532,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
*/
int head = sizeof(struct rte_mempool);
int new_size = (private_data_size + head) % page_size;
- if (new_size) {
+ if (new_size)
private_data_size += page_size - new_size;
- }
}
/* try to allocate tailq entry */
@@ -544,7 +548,12 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
* store mempool objects. Otherwise reserve a memzone that is large
* enough to hold mempool header and metadata plus mempool objects.
*/
+#ifdef RTE_NEXT_ABI
+ mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
+ mempool_size += private_data_size;
+#else
mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+#endif /* RTE_NEXT_ABI */
mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
if (vaddr == NULL)
mempool_size += (size_t)objsz.total_size * n;
@@ -598,9 +607,22 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
mp->private_data_size = private_data_size;
+#ifdef RTE_NEXT_ABI
+ /*
+ * local_cache pointer is set even if cache_size is zero.
+ * The local_cache points to just past the elt_pa[] array.
+ */
+ mp->local_cache = (struct rte_mempool_cache *)
+ ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
+
+ /* calculate address of the first element for continuous mempool. */
+ obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
+ private_data_size;
+#else
/* calculate address of the first element for continuous mempool. */
obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
private_data_size;
+#endif /* RTE_NEXT_ABI */
obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
/* populate address translation fields. */
@@ -613,9 +635,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->elt_va_start = (uintptr_t)obj;
mp->elt_pa[0] = mp->phys_addr +
(mp->elt_va_start - (uintptr_t)mp);
-
- /* mempool elements in a separate chunk of memory. */
} else {
+ /* mempool elements in a separate chunk of memory. */
mp->elt_va_start = (uintptr_t)vaddr;
memcpy(mp->elt_pa, paddr, sizeof (mp->elt_pa[0]) * pg_num);
}
@@ -645,10 +666,21 @@ unsigned
rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
+#ifdef RTE_NEXT_ABI
+ unsigned lcore_id;
count = rte_ring_count(mp->ring);
+ if (mp->cache_size == 0)
+ return count;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
+ count += mp->local_cache[lcore_id].len;
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+
+ count = rte_ring_count(mp->ring);
+
{
unsigned lcore_id;
if (mp->cache_size == 0)
@@ -658,7 +690,7 @@ rte_mempool_count(const struct rte_mempool *mp)
count += mp->local_cache[lcore_id].len;
}
#endif
-
+#endif /* RTE_NEXT_ABI */
/*
* due to race condition (access to len is not locked), the
* total can be greater than size... so fix the result
@@ -672,6 +704,24 @@ rte_mempool_count(const struct rte_mempool *mp)
static unsigned
rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
{
+#ifdef RTE_NEXT_ABI
+ unsigned lcore_id;
+ unsigned count = 0;
+ unsigned cache_count;
+
+ fprintf(f, " cache infos:\n");
+ fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
+ if (mp->cache_size == 0)
+ return count;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ cache_count = mp->local_cache[lcore_id].len;
+ fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
+ count += cache_count;
+ }
+ fprintf(f, " total_cache_count=%u\n", count);
+ return count;
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
unsigned lcore_id;
unsigned count = 0;
@@ -691,6 +741,7 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
fprintf(f, " cache disabled\n");
return 0;
#endif
+#endif /* RTE_NEXT_ABI */
}
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -755,6 +806,26 @@ mempool_audit_cookies(const struct rte_mempool *mp)
#define mempool_audit_cookies(mp) do {} while(0)
#endif
+#ifdef RTE_NEXT_ABI
+/* check cookies before and after objects */
+static void
+mempool_audit_cache(const struct rte_mempool *mp)
+{
+ /* check cache size consistency */
+ unsigned lcore_id;
+
+ if (mp->cache_size == 0)
+ return;
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
+ RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
+ lcore_id);
+ rte_panic("MEMPOOL: invalid cache len\n");
+ }
+ }
+}
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* check cookies before and after objects */
static void
@@ -773,7 +844,7 @@ mempool_audit_cache(const struct rte_mempool *mp)
#else
#define mempool_audit_cache(mp) do {} while(0)
#endif
-
+#endif /* RTE_NEXT_ABI */
/* check the consistency of mempool (size, cookies, ...) */
void
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 6e2390a..fc9b595 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -95,6 +95,19 @@ struct rte_mempool_debug_stats {
} __rte_cache_aligned;
#endif
+#ifdef RTE_NEXT_ABI
+/**
+ * A structure that stores a per-core object cache.
+ */
+struct rte_mempool_cache {
+ unsigned len; /**< Cache len */
+ /*
+ * Cache is allocated to this size to allow it to overflow in certain
+ * cases to avoid needless emptying of cache.
+ */
+ void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
+} __rte_cache_aligned;
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/**
* A structure that stores a per-core object cache.
@@ -108,6 +121,7 @@ struct rte_mempool_cache {
void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
} __rte_cache_aligned;
#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_NEXT_ABI */
/**
* A structure that stores the size of mempool elements.
@@ -194,10 +208,14 @@ struct rte_mempool {
unsigned private_data_size; /**< Size of private data. */
+#ifdef RTE_NEXT_ABI
+ struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
+#else
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/** Per-lcore local cache. */
struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
#endif
+#endif /* RTE_NEXT_ABI */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
/** Per-lcore statistics. */
@@ -246,6 +264,26 @@ struct rte_mempool {
#define __MEMPOOL_STAT_ADD(mp, name, n) do {} while(0)
#endif
+#ifdef RTE_NEXT_ABI
+/**
+ * Size of elt_pa array size based on number of pages. (Internal use)
+ */
+#define __PA_SIZE(mp, pgn) \
+ RTE_ALIGN_CEIL((((pgn) - RTE_DIM((mp)->elt_pa)) * \
+ sizeof((mp)->elt_pa[0])), RTE_CACHE_LINE_SIZE)
+
+/**
+ * Calculate the size of the mempool header.
+ *
+ * @param mp
+ * Pointer to the memory pool.
+ * @param pgn
+ * Number of pages used to store mempool objects.
+ */
+#define MEMPOOL_HEADER_SIZE(mp, pgn, cs) \
+ (sizeof(*(mp)) + __PA_SIZE(mp, pgn) + (((cs) == 0) ? 0 : \
+ (sizeof(struct rte_mempool_cache) * RTE_MAX_LCORE)))
+#else
/**
* Calculate the size of the mempool header.
*
@@ -257,7 +295,7 @@ struct rte_mempool {
#define MEMPOOL_HEADER_SIZE(mp, pgn) (sizeof(*(mp)) + \
RTE_ALIGN_CEIL(((pgn) - RTE_DIM((mp)->elt_pa)) * \
sizeof ((mp)->elt_pa[0]), RTE_CACHE_LINE_SIZE))
-
+#endif /* RTE_NEXT_ABI */
/**
* Return true if the whole mempool is in contiguous memory.
*/
@@ -755,19 +793,25 @@ static inline void __attribute__((always_inline))
__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n, int is_mp)
{
+#ifndef RTE_NEXT_ABI /* Note: ifndef */
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#endif /* RTE_NEXT_ABI */
struct rte_mempool_cache *cache;
uint32_t index;
void **cache_objs;
unsigned lcore_id = rte_lcore_id();
uint32_t cache_size = mp->cache_size;
uint32_t flushthresh = mp->cache_flushthresh;
+#ifndef RTE_NEXT_ABI /* Note: ifndef */
#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_NEXT_ABI */
/* increment stat now, adding in mempool always success */
__MEMPOOL_STAT_ADD(mp, put, n);
+#ifndef RTE_NEXT_ABI /* Note: ifndef */
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#endif /* RTE_NEXT_ABI */
/* cache is not enabled or single producer or non-EAL thread */
if (unlikely(cache_size == 0 || is_mp == 0 ||
lcore_id >= RTE_MAX_LCORE))
@@ -802,7 +846,9 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
return;
ring_enqueue:
+#ifndef RTE_NEXT_ABI /* Note: ifndef */
#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_NEXT_ABI */
/* push remaining objects in ring */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -946,7 +992,9 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
unsigned n, int is_mc)
{
int ret;
+#ifndef RTE_NEXT_ABI /* Note: ifndef */
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
+#endif /* RTE_NEXT_ABI */
struct rte_mempool_cache *cache;
uint32_t index, len;
void **cache_objs;
@@ -992,7 +1040,9 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
return 0;
ring_dequeue:
+#ifndef RTE_NEXT_ABI /* Note: ifndef */
#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
+#endif /* RTE_NEXT_ABI */
/* get remaining objects from ring */
if (is_mc)
@@ -1293,7 +1343,12 @@ void rte_mempool_audit(const struct rte_mempool *mp);
*/
static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
{
+#ifdef RTE_NEXT_ABI
+ return (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
+#else
return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
+#endif /* RTE_NEXT_ABI */
}
/**
--
2.7.0
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
2016-02-08 11:02 4% ` Olivier MATZ
@ 2016-02-08 15:57 0% ` Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-02-08 15:57 UTC (permalink / raw)
To: Olivier MATZ, dev
>Hi Keith,
>
>Looks good, thanks. Please find some comments below.
>
>> [PATCH] mempool: Reduce rte_mempool structure size
>
>nit: we usually avoid uppercase letters in title
Will make that change for v2. Why no uppercase letters in the title, seems a bit odd to me in this case??
>
>On 02/03/2016 12:02 AM, Keith Wiles wrote:
>> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
>> index aff5f6d..bdf8e2e 100644
>> --- a/lib/librte_mempool/rte_mempool.c
>> +++ b/lib/librte_mempool/rte_mempool.c
>> @@ -450,15 +450,11 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
>> int page_size = getpagesize();
>>
>> /* compilation-time checks */
>> +#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
>> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
>> RTE_CACHE_LINE_MASK) != 0);
>> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
>> RTE_CACHE_LINE_MASK) != 0);
>> - RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
>> - RTE_CACHE_LINE_MASK) != 0);
>> -#endif
>> -#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
>
>I don't think the #ifdef RTE_LIBRTE_MEMPOOL_DEBUG should be moved.
>It should only protects the checks on stats which are enabled
>in debug mode.
Will make that change for v2.
>
>> @@ -194,10 +192,7 @@ struct rte_mempool {
>>
>> unsigned private_data_size; /**< Size of private data. */
>>
>> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>> - /** Per-lcore local cache. */
>> - struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
>> -#endif
>> + struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
>>
>> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
>> /** Per-lcore statistics. */
>
>As you noticed it in your initial mail, this changes the ABI. I
>think your patch justifies the ABI change, so I think it should
>follow the ABI change process described in
>dpdk/doc/guides/contributing/versioning.rst.
>
>From what I understand of versioning.rst, these kind of changes
>requires a deprecation notice first, and will be integrated in
>next version. I don't think it's easy to keep a backward compat
>in this case, especially because the rte_mempool structure is
>used by several inlined functions.
I am reading the API doc and need to understand this process a bit more, but from what I can tell I need to add a ifdef RTE_NEXT_ABI around the new structure and old. Not sure where else I need to do that as compat is a bit hard as you stated. The API revision file is there something that needs to be done in that vile too?
You can reply to me directly it you like to save some bandwidth.
>
>Regards,
>Olivier
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support
@ 2016-02-08 11:02 4% ` Olivier MATZ
0 siblings, 0 replies; 200+ results
From: Olivier MATZ @ 2016-02-08 11:02 UTC (permalink / raw)
To: Hunt, David, dev
Hi David,
On 02/04/2016 05:47 PM, Hunt, David wrote:
> Olivier,
> Thanks for your comprehensive comments. I'm working on a v2 patch
> based on feedback already received from Jerin, and I'll be sure to
> include your feedback also.
> Many thanks,
> David.
While answering to Keith, I realized there is the same kind of ABI
changes in your patchset too. It means it should also follow the
ABI deprecation process: dpdk/doc/guides/contributing/versioning.rst.
Regards,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
2016-02-02 23:02 2% [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size Keith Wiles
2016-02-03 17:11 0% ` Ananyev, Konstantin
@ 2016-02-08 11:02 4% ` Olivier MATZ
2016-02-08 15:57 0% ` Wiles, Keith
2016-02-09 17:30 2% ` [dpdk-dev] [PATCH v2] mempool: reduce " Keith Wiles
2 siblings, 1 reply; 200+ results
From: Olivier MATZ @ 2016-02-08 11:02 UTC (permalink / raw)
To: Keith Wiles, dev
Hi Keith,
Looks good, thanks. Please find some comments below.
> [PATCH] mempool: Reduce rte_mempool structure size
nit: we usually avoid uppercase letters in title
On 02/03/2016 12:02 AM, Keith Wiles wrote:
> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
> index aff5f6d..bdf8e2e 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -450,15 +450,11 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
> int page_size = getpagesize();
>
> /* compilation-time checks */
> +#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
> RTE_CACHE_LINE_MASK) != 0);
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
> RTE_CACHE_LINE_MASK) != 0);
> - RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
> - RTE_CACHE_LINE_MASK) != 0);
> -#endif
> -#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
I don't think the #ifdef RTE_LIBRTE_MEMPOOL_DEBUG should be moved.
It should only protects the checks on stats which are enabled
in debug mode.
> @@ -194,10 +192,7 @@ struct rte_mempool {
>
> unsigned private_data_size; /**< Size of private data. */
>
> -#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> - /** Per-lcore local cache. */
> - struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
> -#endif
> + struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
>
> #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> /** Per-lcore statistics. */
As you noticed it in your initial mail, this changes the ABI. I
think your patch justifies the ABI change, so I think it should
follow the ABI change process described in
dpdk/doc/guides/contributing/versioning.rst.
>From what I understand of versioning.rst, these kind of changes
requires a deprecation notice first, and will be integrated in
next version. I don't think it's easy to keep a backward compat
in this case, especially because the rte_mempool structure is
used by several inlined functions.
Regards,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 2/5] eal: move CPU flag functions out of headers
2016-02-06 22:17 1% ` [dpdk-dev] [PATCH v2 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
@ 2016-02-08 8:59 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2016-02-08 8:59 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, viktorin
On Sat, Feb 06, 2016 at 11:17:10PM +0100, Thomas Monjalon wrote:
> The patch c344eab3ee has moved the hardware definition of CPU flags.
> Now the functions checking these hardware flags are also moved.
> The function rte_cpu_get_flag_enabled() is no more inline.
>
> The benefits are:
> - remove rte_cpu_feature_table from the ABI (recently added)
> - hide hardware details from the API
> - allow to adapt structures per arch (done in next patch)
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
arm64 specific changes looks good.
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> MAINTAINERS | 4 +
> app/test/test_hash_scaling.c | 2 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
> lib/librte_eal/common/arch/arm/rte_cpuflags.c | 125 ++++++++++++++++++---
> lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 79 +++++++++++++
> lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
> lib/librte_eal/common/arch/x86/rte_cpuflags.c | 83 ++++++++++++++
> lib/librte_eal/common/eal_common_cpuflags.c | 3 +
> .../common/include/arch/arm/rte_cpuflags_32.h | 80 +------------
> .../common/include/arch/arm/rte_cpuflags_64.h | 81 +------------
> .../common/include/arch/ppc_64/rte_cpuflags.h | 66 +----------
> .../common/include/arch/tile/rte_cpuflags.h | 31 +----
> .../common/include/arch/x86/rte_cpuflags.h | 68 +----------
> .../common/include/generic/rte_cpuflags.h | 50 +--------
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 -
> 15 files changed, 300 insertions(+), 385 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b90aeea..628bc05 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -131,6 +131,7 @@ F: doc/guides/sample_app_ug/multi_process.rst
> ARM v7
> M: Jan Viktorin <viktorin@rehivetech.com>
> M: Jianbo Liu <jianbo.liu@linaro.org>
> +F: lib/librte_eal/common/arch/arm/
> F: lib/librte_eal/common/include/arch/arm/
>
> ARM v8
> @@ -141,16 +142,19 @@ F: lib/librte_acl/acl_run_neon.*
>
> EZchip TILE-Gx
> M: Zhigang Lu <zlu@ezchip.com>
> +F: lib/librte_eal/common/arch/tile/
> F: lib/librte_eal/common/include/arch/tile/
> F: drivers/net/mpipe/
>
> IBM POWER
> M: Chao Zhu <chaozhu@linux.vnet.ibm.com>
> +F: lib/librte_eal/common/arch/ppc_64/
> F: lib/librte_eal/common/include/arch/ppc_64/
>
> Intel x86
> M: Bruce Richardson <bruce.richardson@intel.com>
> M: Konstantin Ananyev <konstantin.ananyev@intel.com>
> +F: lib/librte_eal/common/arch/x86/
> F: lib/librte_eal/common/include/arch/x86/
>
> Linux EAL (with overlaps)
> diff --git a/app/test/test_hash_scaling.c b/app/test/test_hash_scaling.c
> index 744e5e3..1c4c75d 100644
> --- a/app/test/test_hash_scaling.c
> +++ b/app/test/test_hash_scaling.c
> @@ -31,6 +31,8 @@
> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> */
>
> +#include <stdio.h>
> +
> #include <rte_cycles.h>
> #include <rte_hash.h>
> #include <rte_hash_crc.h>
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index 9bea0e2..1a96203 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -142,6 +142,5 @@ DPDK_2.3 {
> rte_cpu_get_flag_name;
> rte_eal_pci_map_device;
> rte_eal_pci_unmap_device;
> - rte_cpu_feature_table;
>
> } DPDK_2.2;
> diff --git a/lib/librte_eal/common/arch/arm/rte_cpuflags.c b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
> index 62e0791..cd7a7b1 100644
> --- a/lib/librte_eal/common/arch/arm/rte_cpuflags.c
> +++ b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
> @@ -2,6 +2,7 @@
> * BSD LICENSE
> *
> * Copyright (C) Cavium networks Ltd. 2015.
> + * Copyright(c) 2015 RehiveTech. All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> @@ -32,19 +33,51 @@
>
> #include "rte_cpuflags.h"
>
> -#ifdef RTE_ARCH_64
> -const struct feature_entry rte_cpu_feature_table[] = {
> - FEAT_DEF(FP, 0x00000001, 0, REG_HWCAP, 0)
> - FEAT_DEF(NEON, 0x00000001, 0, REG_HWCAP, 1)
> - FEAT_DEF(EVTSTRM, 0x00000001, 0, REG_HWCAP, 2)
> - FEAT_DEF(AES, 0x00000001, 0, REG_HWCAP, 3)
> - FEAT_DEF(PMULL, 0x00000001, 0, REG_HWCAP, 4)
> - FEAT_DEF(SHA1, 0x00000001, 0, REG_HWCAP, 5)
> - FEAT_DEF(SHA2, 0x00000001, 0, REG_HWCAP, 6)
> - FEAT_DEF(CRC32, 0x00000001, 0, REG_HWCAP, 7)
> - FEAT_DEF(AARCH64, 0x00000001, 0, REG_PLATFORM, 1)
> +#include <elf.h>
> +#include <fcntl.h>
> +#include <assert.h>
> +#include <unistd.h>
> +#include <string.h>
> +
> +#ifndef AT_HWCAP
> +#define AT_HWCAP 16
> +#endif
> +
> +#ifndef AT_HWCAP2
> +#define AT_HWCAP2 26
> +#endif
> +
> +#ifndef AT_PLATFORM
> +#define AT_PLATFORM 15
> +#endif
> +
> +enum cpu_register_t {
> + REG_HWCAP = 0,
> + REG_HWCAP2,
> + REG_PLATFORM,
> +};
> +
> +typedef uint32_t cpuid_registers_t[4];
> +
> +/**
> + * Struct to hold a processor feature entry
> + */
> +struct feature_entry {
> + uint32_t leaf; /**< cpuid leaf */
> + uint32_t subleaf; /**< cpuid subleaf */
> + uint32_t reg; /**< cpuid register */
> + uint32_t bit; /**< cpuid register bit */
> +#define CPU_FLAG_NAME_MAX_LEN 64
> + char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
> };
> -#else
> +
> +#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
> + [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
> +
> +#ifdef RTE_ARCH_ARMv7
> +#define PLATFORM_STR "v7l"
> +typedef Elf32_auxv_t _Elfx_auxv_t;
> +
> const struct feature_entry rte_cpu_feature_table[] = {
> FEAT_DEF(SWP, 0x00000001, 0, REG_HWCAP, 0)
> FEAT_DEF(HALF, 0x00000001, 0, REG_HWCAP, 1)
> @@ -75,7 +108,73 @@ const struct feature_entry rte_cpu_feature_table[] = {
> FEAT_DEF(CRC32, 0x00000001, 0, REG_HWCAP2, 4)
> FEAT_DEF(V7L, 0x00000001, 0, REG_PLATFORM, 0)
> };
> -#endif
> +
> +#elif defined RTE_ARCH_ARM64
> +#define PLATFORM_STR "aarch64"
> +typedef Elf64_auxv_t _Elfx_auxv_t;
> +
> +const struct feature_entry rte_cpu_feature_table[] = {
> + FEAT_DEF(FP, 0x00000001, 0, REG_HWCAP, 0)
> + FEAT_DEF(NEON, 0x00000001, 0, REG_HWCAP, 1)
> + FEAT_DEF(EVTSTRM, 0x00000001, 0, REG_HWCAP, 2)
> + FEAT_DEF(AES, 0x00000001, 0, REG_HWCAP, 3)
> + FEAT_DEF(PMULL, 0x00000001, 0, REG_HWCAP, 4)
> + FEAT_DEF(SHA1, 0x00000001, 0, REG_HWCAP, 5)
> + FEAT_DEF(SHA2, 0x00000001, 0, REG_HWCAP, 6)
> + FEAT_DEF(CRC32, 0x00000001, 0, REG_HWCAP, 7)
> + FEAT_DEF(AARCH64, 0x00000001, 0, REG_PLATFORM, 1)
> +};
> +#endif /* RTE_ARCH */
> +
> +/*
> + * Read AUXV software register and get cpu features for ARM
> + */
> +static void
> +rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
> + __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
> +{
> + int auxv_fd;
> + _Elfx_auxv_t auxv;
> +
> + auxv_fd = open("/proc/self/auxv", O_RDONLY);
> + assert(auxv_fd);
> + while (read(auxv_fd, &auxv, sizeof(auxv)) == sizeof(auxv)) {
> + if (auxv.a_type == AT_HWCAP) {
> + out[REG_HWCAP] = auxv.a_un.a_val;
> + } else if (auxv.a_type == AT_HWCAP2) {
> + out[REG_HWCAP2] = auxv.a_un.a_val;
> + } else if (auxv.a_type == AT_PLATFORM) {
> + if (!strcmp((const char *)auxv.a_un.a_val, PLATFORM_STR))
> + out[REG_PLATFORM] = 0x0001;
> + }
> + }
> +}
> +
> +/*
> + * Checks if a particular flag is available on current machine.
> + */
> +int
> +rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> +{
> + const struct feature_entry *feat;
> + cpuid_registers_t regs = {0};
> +
> + if (feature >= RTE_CPUFLAG_NUMFLAGS)
> + /* Flag does not match anything in the feature tables */
> + return -ENOENT;
> +
> + feat = &rte_cpu_feature_table[feature];
> +
> + if (!feat->leaf)
> + /* This entry in the table wasn't filled out! */
> + return -EFAULT;
> +
> + /* get the cpuid leaf containing the desired feature */
> + rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> +
> + /* check if the feature is enabled */
> + return (regs[feat->reg] >> feat->bit) & 1;
> +}
>
> const char *
> rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
> diff --git a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
> index a270ccc..b7e0b72 100644
> --- a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
> +++ b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
> @@ -32,6 +32,38 @@
>
> #include "rte_cpuflags.h"
>
> +#include <elf.h>
> +#include <fcntl.h>
> +#include <assert.h>
> +#include <unistd.h>
> +
> +/* Symbolic values for the entries in the auxiliary table */
> +#define AT_HWCAP 16
> +#define AT_HWCAP2 26
> +
> +/* software based registers */
> +enum cpu_register_t {
> + REG_HWCAP = 0,
> + REG_HWCAP2,
> +};
> +
> +typedef uint32_t cpuid_registers_t[4];
> +
> +/**
> + * Struct to hold a processor feature entry
> + */
> +struct feature_entry {
> + uint32_t leaf; /**< cpuid leaf */
> + uint32_t subleaf; /**< cpuid subleaf */
> + uint32_t reg; /**< cpuid register */
> + uint32_t bit; /**< cpuid register bit */
> +#define CPU_FLAG_NAME_MAX_LEN 64
> + char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
> +};
> +
> +#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
> + [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
> +
> const struct feature_entry rte_cpu_feature_table[] = {
> FEAT_DEF(PPC_LE, 0x00000001, 0, REG_HWCAP, 0)
> FEAT_DEF(TRUE_LE, 0x00000001, 0, REG_HWCAP, 1)
> @@ -69,6 +101,53 @@ const struct feature_entry rte_cpu_feature_table[] = {
> FEAT_DEF(ARCH_2_07, 0x00000001, 0, REG_HWCAP2, 31)
> };
>
> +/*
> + * Read AUXV software register and get cpu features for Power
> + */
> +static void
> +rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
> + __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
> +{
> + int auxv_fd;
> + Elf64_auxv_t auxv;
> +
> + auxv_fd = open("/proc/self/auxv", O_RDONLY);
> + assert(auxv_fd);
> + while (read(auxv_fd, &auxv,
> + sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
> + if (auxv.a_type == AT_HWCAP)
> + out[REG_HWCAP] = auxv.a_un.a_val;
> + else if (auxv.a_type == AT_HWCAP2)
> + out[REG_HWCAP2] = auxv.a_un.a_val;
> + }
> +}
> +
> +/*
> + * Checks if a particular flag is available on current machine.
> + */
> +int
> +rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> +{
> + const struct feature_entry *feat;
> + cpuid_registers_t regs = {0};
> +
> + if (feature >= RTE_CPUFLAG_NUMFLAGS)
> + /* Flag does not match anything in the feature tables */
> + return -ENOENT;
> +
> + feat = &rte_cpu_feature_table[feature];
> +
> + if (!feat->leaf)
> + /* This entry in the table wasn't filled out! */
> + return -EFAULT;
> +
> + /* get the cpuid leaf containing the desired feature */
> + rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> +
> + /* check if the feature is enabled */
> + return (regs[feat->reg] >> feat->bit) & 1;
> +}
> +
> const char *
> rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
> {
> diff --git a/lib/librte_eal/common/arch/tile/rte_cpuflags.c b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
> index 4ca0a7b..a2b6c51 100644
> --- a/lib/librte_eal/common/arch/tile/rte_cpuflags.c
> +++ b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
> @@ -32,5 +32,16 @@
>
> #include "rte_cpuflags.h"
>
> +#include <errno.h>
> +
> const struct feature_entry rte_cpu_feature_table[] = {
> };
> +
> +/*
> + * Checks if a particular flag is available on current machine.
> + */
> +int
> +rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
> +{
> + return -ENOENT;
> +}
> diff --git a/lib/librte_eal/common/arch/x86/rte_cpuflags.c b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
> index 3346fde..0138257 100644
> --- a/lib/librte_eal/common/arch/x86/rte_cpuflags.c
> +++ b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
> @@ -33,6 +33,34 @@
>
> #include "rte_cpuflags.h"
>
> +#include <stdio.h>
> +#include <errno.h>
> +#include <stdint.h>
> +
> +enum cpu_register_t {
> + RTE_REG_EAX = 0,
> + RTE_REG_EBX,
> + RTE_REG_ECX,
> + RTE_REG_EDX,
> +};
> +
> +typedef uint32_t cpuid_registers_t[4];
> +
> +/**
> + * Struct to hold a processor feature entry
> + */
> +struct feature_entry {
> + uint32_t leaf; /**< cpuid leaf */
> + uint32_t subleaf; /**< cpuid subleaf */
> + uint32_t reg; /**< cpuid register */
> + uint32_t bit; /**< cpuid register bit */
> +#define CPU_FLAG_NAME_MAX_LEN 64
> + char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
> +};
> +
> +#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
> + [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
> +
> const struct feature_entry rte_cpu_feature_table[] = {
> FEAT_DEF(SSE3, 0x00000001, 0, RTE_REG_ECX, 0)
> FEAT_DEF(PCLMULQDQ, 0x00000001, 0, RTE_REG_ECX, 1)
> @@ -128,6 +156,61 @@ const struct feature_entry rte_cpu_feature_table[] = {
> FEAT_DEF(INVTSC, 0x80000007, 0, RTE_REG_EDX, 8)
> };
>
> +/*
> + * Execute CPUID instruction and get contents of a specific register
> + *
> + * This function, when compiled with GCC, will generate architecture-neutral
> + * code, as per GCC manual.
> + */
> +static void
> +rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
> +{
> +#if defined(__i386__) && defined(__PIC__)
> + /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
> + asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
> + : "=r" (out[RTE_REG_EBX]),
> + "=a" (out[RTE_REG_EAX]),
> + "=c" (out[RTE_REG_ECX]),
> + "=d" (out[RTE_REG_EDX])
> + : "a" (leaf), "c" (subleaf));
> +#else
> + asm volatile("cpuid"
> + : "=a" (out[RTE_REG_EAX]),
> + "=b" (out[RTE_REG_EBX]),
> + "=c" (out[RTE_REG_ECX]),
> + "=d" (out[RTE_REG_EDX])
> + : "a" (leaf), "c" (subleaf));
> +#endif
> +}
> +
> +int
> +rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> +{
> + const struct feature_entry *feat;
> + cpuid_registers_t regs;
> +
> + if (feature >= RTE_CPUFLAG_NUMFLAGS)
> + /* Flag does not match anything in the feature tables */
> + return -ENOENT;
> +
> + feat = &rte_cpu_feature_table[feature];
> +
> + if (!feat->leaf)
> + /* This entry in the table wasn't filled out! */
> + return -EFAULT;
> +
> + rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
> + if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
> + regs[RTE_REG_EAX] < feat->leaf)
> + return 0;
> +
> + /* get the cpuid leaf containing the desired feature */
> + rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> +
> + /* check if the feature is enabled */
> + return (regs[feat->reg] >> feat->bit) & 1;
> +}
> +
> const char *
> rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
> {
> diff --git a/lib/librte_eal/common/eal_common_cpuflags.c b/lib/librte_eal/common/eal_common_cpuflags.c
> index 8c0576d..a4c5a29 100644
> --- a/lib/librte_eal/common/eal_common_cpuflags.c
> +++ b/lib/librte_eal/common/eal_common_cpuflags.c
> @@ -30,6 +30,9 @@
> * (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 <stdio.h>
> +
> #include <rte_common.h>
> #include <rte_cpuflags.h>
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
> index 2ec0c2e..eb02d9b 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
> @@ -37,35 +37,6 @@
> extern "C" {
> #endif
>
> -#include <elf.h>
> -#include <fcntl.h>
> -#include <assert.h>
> -#include <unistd.h>
> -#include <string.h>
> -
> -#include "generic/rte_cpuflags.h"
> -
> -extern const struct feature_entry rte_cpu_feature_table[];
> -
> -#ifndef AT_HWCAP
> -#define AT_HWCAP 16
> -#endif
> -
> -#ifndef AT_HWCAP2
> -#define AT_HWCAP2 26
> -#endif
> -
> -#ifndef AT_PLATFORM
> -#define AT_PLATFORM 15
> -#endif
> -
> -/* software based registers */
> -enum cpu_register_t {
> - REG_HWCAP = 0,
> - REG_HWCAP2,
> - REG_PLATFORM,
> -};
> -
> /**
> * Enumeration of all CPU features supported
> */
> @@ -102,56 +73,7 @@ enum rte_cpu_flag_t {
> RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
> };
>
> -/*
> - * Read AUXV software register and get cpu features for ARM
> - */
> -static inline void
> -rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
> - __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
> -{
> - int auxv_fd;
> - Elf32_auxv_t auxv;
> -
> - auxv_fd = open("/proc/self/auxv", O_RDONLY);
> - assert(auxv_fd);
> - while (read(auxv_fd, &auxv,
> - sizeof(Elf32_auxv_t)) == sizeof(Elf32_auxv_t)) {
> - if (auxv.a_type == AT_HWCAP)
> - out[REG_HWCAP] = auxv.a_un.a_val;
> - else if (auxv.a_type == AT_HWCAP2)
> - out[REG_HWCAP2] = auxv.a_un.a_val;
> - else if (auxv.a_type == AT_PLATFORM) {
> - if (!strcmp((const char *)auxv.a_un.a_val, "v7l"))
> - out[REG_PLATFORM] = 0x0001;
> - }
> - }
> -}
> -
> -/*
> - * Checks if a particular flag is available on current machine.
> - */
> -static inline int
> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> -{
> - const struct feature_entry *feat;
> - cpuid_registers_t regs = {0};
> -
> - if (feature >= RTE_CPUFLAG_NUMFLAGS)
> - /* Flag does not match anything in the feature tables */
> - return -ENOENT;
> -
> - feat = &rte_cpu_feature_table[feature];
> -
> - if (!feat->leaf)
> - /* This entry in the table wasn't filled out! */
> - return -EFAULT;
> -
> - /* get the cpuid leaf containing the desired feature */
> - rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> -
> - /* check if the feature is enabled */
> - return (regs[feat->reg] >> feat->bit) & 1;
> -}
> +#include "generic/rte_cpuflags.h"
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
> index b36040b..810e8a0 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
> @@ -37,35 +37,6 @@
> extern "C" {
> #endif
>
> -#include <elf.h>
> -#include <fcntl.h>
> -#include <assert.h>
> -#include <unistd.h>
> -#include <string.h>
> -
> -#include "generic/rte_cpuflags.h"
> -
> -extern const struct feature_entry rte_cpu_feature_table[];
> -
> -#ifndef AT_HWCAP
> -#define AT_HWCAP 16
> -#endif
> -
> -#ifndef AT_HWCAP2
> -#define AT_HWCAP2 26
> -#endif
> -
> -#ifndef AT_PLATFORM
> -#define AT_PLATFORM 15
> -#endif
> -
> -/* software based registers */
> -enum cpu_register_t {
> - REG_HWCAP = 0,
> - REG_HWCAP2,
> - REG_PLATFORM,
> -};
> -
> /**
> * Enumeration of all CPU features supported
> */
> @@ -83,57 +54,7 @@ enum rte_cpu_flag_t {
> RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
> };
>
> -/*
> - * Read AUXV software register and get cpu features for ARM
> - */
> -static inline void
> -rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
> - __attribute__((unused)) uint32_t subleaf,
> - cpuid_registers_t out)
> -{
> - int auxv_fd;
> - Elf64_auxv_t auxv;
> -
> - auxv_fd = open("/proc/self/auxv", O_RDONLY);
> - assert(auxv_fd);
> - while (read(auxv_fd, &auxv,
> - sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
> - if (auxv.a_type == AT_HWCAP) {
> - out[REG_HWCAP] = auxv.a_un.a_val;
> - } else if (auxv.a_type == AT_HWCAP2) {
> - out[REG_HWCAP2] = auxv.a_un.a_val;
> - } else if (auxv.a_type == AT_PLATFORM) {
> - if (!strcmp((const char *)auxv.a_un.a_val, "aarch64"))
> - out[REG_PLATFORM] = 0x0001;
> - }
> - }
> -}
> -
> -/*
> - * Checks if a particular flag is available on current machine.
> - */
> -static inline int
> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> -{
> - const struct feature_entry *feat;
> - cpuid_registers_t regs = {0};
> -
> - if (feature >= RTE_CPUFLAG_NUMFLAGS)
> - /* Flag does not match anything in the feature tables */
> - return -ENOENT;
> -
> - feat = &rte_cpu_feature_table[feature];
> -
> - if (!feat->leaf)
> - /* This entry in the table wasn't filled out! */
> - return -EFAULT;
> -
> - /* get the cpuid leaf containing the desired feature */
> - rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> -
> - /* check if the feature is enabled */
> - return (regs[feat->reg] >> feat->bit) & 1;
> -}
> +#include "generic/rte_cpuflags.h"
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
> index 85c4c1a..7cc2b3c 100644
> --- a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
> +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
> @@ -37,25 +37,6 @@
> extern "C" {
> #endif
>
> -#include <elf.h>
> -#include <fcntl.h>
> -#include <assert.h>
> -#include <unistd.h>
> -
> -#include "generic/rte_cpuflags.h"
> -
> -extern const struct feature_entry rte_cpu_feature_table[];
> -
> -/* Symbolic values for the entries in the auxiliary table */
> -#define AT_HWCAP 16
> -#define AT_HWCAP2 26
> -
> -/* software based registers */
> -enum cpu_register_t {
> - REG_HWCAP = 0,
> - REG_HWCAP2,
> -};
> -
> /**
> * Enumeration of all CPU features supported
> */
> @@ -98,52 +79,7 @@ enum rte_cpu_flag_t {
> RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
> };
>
> -/*
> - * Read AUXV software register and get cpu features for Power
> - */
> -static inline void
> -rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
> - __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
> -{
> - int auxv_fd;
> - Elf64_auxv_t auxv;
> -
> - auxv_fd = open("/proc/self/auxv", O_RDONLY);
> - assert(auxv_fd);
> - while (read(auxv_fd, &auxv,
> - sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
> - if (auxv.a_type == AT_HWCAP)
> - out[REG_HWCAP] = auxv.a_un.a_val;
> - else if (auxv.a_type == AT_HWCAP2)
> - out[REG_HWCAP2] = auxv.a_un.a_val;
> - }
> -}
> -
> -/*
> - * Checks if a particular flag is available on current machine.
> - */
> -static inline int
> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> -{
> - const struct feature_entry *feat;
> - cpuid_registers_t regs = {0};
> -
> - if (feature >= RTE_CPUFLAG_NUMFLAGS)
> - /* Flag does not match anything in the feature tables */
> - return -ENOENT;
> -
> - feat = &rte_cpu_feature_table[feature];
> -
> - if (!feat->leaf)
> - /* This entry in the table wasn't filled out! */
> - return -EFAULT;
> -
> - /* get the cpuid leaf containing the desired feature */
> - rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> -
> - /* check if the feature is enabled */
> - return (regs[feat->reg] >> feat->bit) & 1;
> -}
> +#include "generic/rte_cpuflags.h"
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
> index a415857..1849b52 100644
> --- a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
> +++ b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
> @@ -37,18 +37,6 @@
> extern "C" {
> #endif
>
> -#include <elf.h>
> -#include <fcntl.h>
> -#include <assert.h>
> -#include <unistd.h>
> -
> -#include "generic/rte_cpuflags.h"
> -
> -/* software based registers */
> -enum cpu_register_t {
> - REG_DUMMY = 0
> -};
> -
> /**
> * Enumeration of all CPU features supported
> */
> @@ -56,24 +44,7 @@ enum rte_cpu_flag_t {
> RTE_CPUFLAG_NUMFLAGS /**< This should always be the last! */
> };
>
> -/*
> - * Read AUXV software register and get cpu features for Power
> - */
> -static inline void
> -rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
> - __attribute__((unused)) uint32_t subleaf,
> - __attribute__((unused)) cpuid_registers_t out)
> -{
> -}
> -
> -/*
> - * Checks if a particular flag is available on current machine.
> - */
> -static inline int
> -rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
> -{
> - return -ENOENT;
> -}
> +#include "generic/rte_cpuflags.h"
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
> index 120ea24..26204fa 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
> @@ -38,15 +38,6 @@
> extern "C" {
> #endif
>
> -#include <stdlib.h>
> -#include <stdio.h>
> -#include <errno.h>
> -#include <stdint.h>
> -
> -#include "generic/rte_cpuflags.h"
> -
> -extern const struct feature_entry rte_cpu_feature_table[];
> -
> enum rte_cpu_flag_t {
> /* (EAX 01h) ECX features*/
> RTE_CPUFLAG_SSE3 = 0, /**< SSE3 */
> @@ -153,64 +144,7 @@ enum rte_cpu_flag_t {
> RTE_CPUFLAG_NUMFLAGS, /**< This should always be the last! */
> };
>
> -enum cpu_register_t {
> - RTE_REG_EAX = 0,
> - RTE_REG_EBX,
> - RTE_REG_ECX,
> - RTE_REG_EDX,
> -};
> -
> -static inline void
> -rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
> -{
> -#if defined(__i386__) && defined(__PIC__)
> - /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
> - asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
> - : "=r" (out[RTE_REG_EBX]),
> - "=a" (out[RTE_REG_EAX]),
> - "=c" (out[RTE_REG_ECX]),
> - "=d" (out[RTE_REG_EDX])
> - : "a" (leaf), "c" (subleaf));
> -#else
> -
> - asm volatile("cpuid"
> - : "=a" (out[RTE_REG_EAX]),
> - "=b" (out[RTE_REG_EBX]),
> - "=c" (out[RTE_REG_ECX]),
> - "=d" (out[RTE_REG_EDX])
> - : "a" (leaf), "c" (subleaf));
> -
> -#endif
> -}
> -
> -static inline int
> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> -{
> - const struct feature_entry *feat;
> - cpuid_registers_t regs;
> -
> -
> - if (feature >= RTE_CPUFLAG_NUMFLAGS)
> - /* Flag does not match anything in the feature tables */
> - return -ENOENT;
> -
> - feat = &rte_cpu_feature_table[feature];
> -
> - if (!feat->leaf)
> - /* This entry in the table wasn't filled out! */
> - return -EFAULT;
> -
> - rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
> - if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
> - regs[RTE_REG_EAX] < feat->leaf)
> - return 0;
> -
> - /* get the cpuid leaf containing the desired feature */
> - rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
> -
> - /* check if the feature is enabled */
> - return (regs[feat->reg] >> feat->bit) & 1;
> -}
> +#include "generic/rte_cpuflags.h"
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h b/lib/librte_eal/common/include/generic/rte_cpuflags.h
> index 3ca2e36..c1da357 100644
> --- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
> +++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
> @@ -39,10 +39,7 @@
> * Architecture specific API to determine available CPU features at runtime.
> */
>
> -#include <stdlib.h>
> -#include <stdio.h>
> #include <errno.h>
> -#include <stdint.h>
>
> /**
> * Enumeration of all CPU features supported
> @@ -50,49 +47,6 @@
> enum rte_cpu_flag_t;
>
> /**
> - * Enumeration of CPU registers
> - */
> -#ifdef __DOXYGEN__
> -enum cpu_register_t;
> -#endif
> -
> -typedef uint32_t cpuid_registers_t[4];
> -
> -#define CPU_FLAG_NAME_MAX_LEN 64
> -
> -/**
> - * Struct to hold a processor feature entry
> - */
> -struct feature_entry {
> - uint32_t leaf; /**< cpuid leaf */
> - uint32_t subleaf; /**< cpuid subleaf */
> - uint32_t reg; /**< cpuid register */
> - uint32_t bit; /**< cpuid register bit */
> - char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
> -};
> -
> -#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
> - [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
> -
> -/**
> - * An array that holds feature entries
> - *
> - * Defined in arch-specific rte_cpuflags.h.
> - */
> -#ifdef __DOXYGEN__
> -static const struct feature_entry cpu_feature_table[];
> -#endif
> -
> -/**
> - * Execute CPUID instruction and get contents of a specific register
> - *
> - * This function, when compiled with GCC, will generate architecture-neutral
> - * code, as per GCC manual.
> - */
> -static inline void
> -rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out);
> -
> -/**
> * Get name of CPU flag
> *
> * @param feature
> @@ -114,10 +68,8 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
> * 0 if flag is not available
> * -ENOENT if flag is invalid
> */
> -#ifdef __DOXYGEN__
> -static inline int
> +int
> rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
> -#endif
>
> /**
> * This function checks that the currently used CPU supports the CPU features
> diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> index 48e8e4f..440fac2 100644
> --- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> @@ -145,6 +145,5 @@ DPDK_2.3 {
> rte_cpu_get_flag_name;
> rte_eal_pci_map_device;
> rte_eal_pci_unmap_device;
> - rte_cpu_feature_table;
>
> } DPDK_2.2;
> --
> 2.7.0
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 2/5] eal: move CPU flag functions out of headers
2016-02-06 22:17 3% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
@ 2016-02-06 22:17 1% ` Thomas Monjalon
2016-02-08 8:59 0% ` Jerin Jacob
2016-02-16 7:30 0% ` [dpdk-dev] [PATCH v2 0/5] clean-up cpuflags Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-02-06 22:17 UTC (permalink / raw)
To: david.marchand, ferruh.yigit; +Cc: dev, viktorin
The patch c344eab3ee has moved the hardware definition of CPU flags.
Now the functions checking these hardware flags are also moved.
The function rte_cpu_get_flag_enabled() is no more inline.
The benefits are:
- remove rte_cpu_feature_table from the ABI (recently added)
- hide hardware details from the API
- allow to adapt structures per arch (done in next patch)
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
MAINTAINERS | 4 +
app/test/test_hash_scaling.c | 2 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 125 ++++++++++++++++++---
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 79 +++++++++++++
lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
lib/librte_eal/common/arch/x86/rte_cpuflags.c | 83 ++++++++++++++
lib/librte_eal/common/eal_common_cpuflags.c | 3 +
.../common/include/arch/arm/rte_cpuflags_32.h | 80 +------------
.../common/include/arch/arm/rte_cpuflags_64.h | 81 +------------
.../common/include/arch/ppc_64/rte_cpuflags.h | 66 +----------
.../common/include/arch/tile/rte_cpuflags.h | 31 +----
.../common/include/arch/x86/rte_cpuflags.h | 68 +----------
.../common/include/generic/rte_cpuflags.h | 50 +--------
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 -
15 files changed, 300 insertions(+), 385 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b90aeea..628bc05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -131,6 +131,7 @@ F: doc/guides/sample_app_ug/multi_process.rst
ARM v7
M: Jan Viktorin <viktorin@rehivetech.com>
M: Jianbo Liu <jianbo.liu@linaro.org>
+F: lib/librte_eal/common/arch/arm/
F: lib/librte_eal/common/include/arch/arm/
ARM v8
@@ -141,16 +142,19 @@ F: lib/librte_acl/acl_run_neon.*
EZchip TILE-Gx
M: Zhigang Lu <zlu@ezchip.com>
+F: lib/librte_eal/common/arch/tile/
F: lib/librte_eal/common/include/arch/tile/
F: drivers/net/mpipe/
IBM POWER
M: Chao Zhu <chaozhu@linux.vnet.ibm.com>
+F: lib/librte_eal/common/arch/ppc_64/
F: lib/librte_eal/common/include/arch/ppc_64/
Intel x86
M: Bruce Richardson <bruce.richardson@intel.com>
M: Konstantin Ananyev <konstantin.ananyev@intel.com>
+F: lib/librte_eal/common/arch/x86/
F: lib/librte_eal/common/include/arch/x86/
Linux EAL (with overlaps)
diff --git a/app/test/test_hash_scaling.c b/app/test/test_hash_scaling.c
index 744e5e3..1c4c75d 100644
--- a/app/test/test_hash_scaling.c
+++ b/app/test/test_hash_scaling.c
@@ -31,6 +31,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <stdio.h>
+
#include <rte_cycles.h>
#include <rte_hash.h>
#include <rte_hash_crc.h>
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 9bea0e2..1a96203 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -142,6 +142,5 @@ DPDK_2.3 {
rte_cpu_get_flag_name;
rte_eal_pci_map_device;
rte_eal_pci_unmap_device;
- rte_cpu_feature_table;
} DPDK_2.2;
diff --git a/lib/librte_eal/common/arch/arm/rte_cpuflags.c b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
index 62e0791..cd7a7b1 100644
--- a/lib/librte_eal/common/arch/arm/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
@@ -2,6 +2,7 @@
* BSD LICENSE
*
* Copyright (C) Cavium networks Ltd. 2015.
+ * Copyright(c) 2015 RehiveTech. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -32,19 +33,51 @@
#include "rte_cpuflags.h"
-#ifdef RTE_ARCH_64
-const struct feature_entry rte_cpu_feature_table[] = {
- FEAT_DEF(FP, 0x00000001, 0, REG_HWCAP, 0)
- FEAT_DEF(NEON, 0x00000001, 0, REG_HWCAP, 1)
- FEAT_DEF(EVTSTRM, 0x00000001, 0, REG_HWCAP, 2)
- FEAT_DEF(AES, 0x00000001, 0, REG_HWCAP, 3)
- FEAT_DEF(PMULL, 0x00000001, 0, REG_HWCAP, 4)
- FEAT_DEF(SHA1, 0x00000001, 0, REG_HWCAP, 5)
- FEAT_DEF(SHA2, 0x00000001, 0, REG_HWCAP, 6)
- FEAT_DEF(CRC32, 0x00000001, 0, REG_HWCAP, 7)
- FEAT_DEF(AARCH64, 0x00000001, 0, REG_PLATFORM, 1)
+#include <elf.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <unistd.h>
+#include <string.h>
+
+#ifndef AT_HWCAP
+#define AT_HWCAP 16
+#endif
+
+#ifndef AT_HWCAP2
+#define AT_HWCAP2 26
+#endif
+
+#ifndef AT_PLATFORM
+#define AT_PLATFORM 15
+#endif
+
+enum cpu_register_t {
+ REG_HWCAP = 0,
+ REG_HWCAP2,
+ REG_PLATFORM,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
};
-#else
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
+#ifdef RTE_ARCH_ARMv7
+#define PLATFORM_STR "v7l"
+typedef Elf32_auxv_t _Elfx_auxv_t;
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SWP, 0x00000001, 0, REG_HWCAP, 0)
FEAT_DEF(HALF, 0x00000001, 0, REG_HWCAP, 1)
@@ -75,7 +108,73 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(CRC32, 0x00000001, 0, REG_HWCAP2, 4)
FEAT_DEF(V7L, 0x00000001, 0, REG_PLATFORM, 0)
};
-#endif
+
+#elif defined RTE_ARCH_ARM64
+#define PLATFORM_STR "aarch64"
+typedef Elf64_auxv_t _Elfx_auxv_t;
+
+const struct feature_entry rte_cpu_feature_table[] = {
+ FEAT_DEF(FP, 0x00000001, 0, REG_HWCAP, 0)
+ FEAT_DEF(NEON, 0x00000001, 0, REG_HWCAP, 1)
+ FEAT_DEF(EVTSTRM, 0x00000001, 0, REG_HWCAP, 2)
+ FEAT_DEF(AES, 0x00000001, 0, REG_HWCAP, 3)
+ FEAT_DEF(PMULL, 0x00000001, 0, REG_HWCAP, 4)
+ FEAT_DEF(SHA1, 0x00000001, 0, REG_HWCAP, 5)
+ FEAT_DEF(SHA2, 0x00000001, 0, REG_HWCAP, 6)
+ FEAT_DEF(CRC32, 0x00000001, 0, REG_HWCAP, 7)
+ FEAT_DEF(AARCH64, 0x00000001, 0, REG_PLATFORM, 1)
+};
+#endif /* RTE_ARCH */
+
+/*
+ * Read AUXV software register and get cpu features for ARM
+ */
+static void
+rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
+ __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
+{
+ int auxv_fd;
+ _Elfx_auxv_t auxv;
+
+ auxv_fd = open("/proc/self/auxv", O_RDONLY);
+ assert(auxv_fd);
+ while (read(auxv_fd, &auxv, sizeof(auxv)) == sizeof(auxv)) {
+ if (auxv.a_type == AT_HWCAP) {
+ out[REG_HWCAP] = auxv.a_un.a_val;
+ } else if (auxv.a_type == AT_HWCAP2) {
+ out[REG_HWCAP2] = auxv.a_un.a_val;
+ } else if (auxv.a_type == AT_PLATFORM) {
+ if (!strcmp((const char *)auxv.a_un.a_val, PLATFORM_STR))
+ out[REG_PLATFORM] = 0x0001;
+ }
+ }
+}
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs = {0};
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
diff --git a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
index a270ccc..b7e0b72 100644
--- a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
@@ -32,6 +32,38 @@
#include "rte_cpuflags.h"
+#include <elf.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <unistd.h>
+
+/* Symbolic values for the entries in the auxiliary table */
+#define AT_HWCAP 16
+#define AT_HWCAP2 26
+
+/* software based registers */
+enum cpu_register_t {
+ REG_HWCAP = 0,
+ REG_HWCAP2,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(PPC_LE, 0x00000001, 0, REG_HWCAP, 0)
FEAT_DEF(TRUE_LE, 0x00000001, 0, REG_HWCAP, 1)
@@ -69,6 +101,53 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(ARCH_2_07, 0x00000001, 0, REG_HWCAP2, 31)
};
+/*
+ * Read AUXV software register and get cpu features for Power
+ */
+static void
+rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
+ __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
+{
+ int auxv_fd;
+ Elf64_auxv_t auxv;
+
+ auxv_fd = open("/proc/self/auxv", O_RDONLY);
+ assert(auxv_fd);
+ while (read(auxv_fd, &auxv,
+ sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
+ if (auxv.a_type == AT_HWCAP)
+ out[REG_HWCAP] = auxv.a_un.a_val;
+ else if (auxv.a_type == AT_HWCAP2)
+ out[REG_HWCAP2] = auxv.a_un.a_val;
+ }
+}
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs = {0};
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/arch/tile/rte_cpuflags.c b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
index 4ca0a7b..a2b6c51 100644
--- a/lib/librte_eal/common/arch/tile/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
@@ -32,5 +32,16 @@
#include "rte_cpuflags.h"
+#include <errno.h>
+
const struct feature_entry rte_cpu_feature_table[] = {
};
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
+{
+ return -ENOENT;
+}
diff --git a/lib/librte_eal/common/arch/x86/rte_cpuflags.c b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
index 3346fde..0138257 100644
--- a/lib/librte_eal/common/arch/x86/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
@@ -33,6 +33,34 @@
#include "rte_cpuflags.h"
+#include <stdio.h>
+#include <errno.h>
+#include <stdint.h>
+
+enum cpu_register_t {
+ RTE_REG_EAX = 0,
+ RTE_REG_EBX,
+ RTE_REG_ECX,
+ RTE_REG_EDX,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SSE3, 0x00000001, 0, RTE_REG_ECX, 0)
FEAT_DEF(PCLMULQDQ, 0x00000001, 0, RTE_REG_ECX, 1)
@@ -128,6 +156,61 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(INVTSC, 0x80000007, 0, RTE_REG_EDX, 8)
};
+/*
+ * Execute CPUID instruction and get contents of a specific register
+ *
+ * This function, when compiled with GCC, will generate architecture-neutral
+ * code, as per GCC manual.
+ */
+static void
+rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
+{
+#if defined(__i386__) && defined(__PIC__)
+ /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
+ asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
+ : "=r" (out[RTE_REG_EBX]),
+ "=a" (out[RTE_REG_EAX]),
+ "=c" (out[RTE_REG_ECX]),
+ "=d" (out[RTE_REG_EDX])
+ : "a" (leaf), "c" (subleaf));
+#else
+ asm volatile("cpuid"
+ : "=a" (out[RTE_REG_EAX]),
+ "=b" (out[RTE_REG_EBX]),
+ "=c" (out[RTE_REG_ECX]),
+ "=d" (out[RTE_REG_EDX])
+ : "a" (leaf), "c" (subleaf));
+#endif
+}
+
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs;
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
+ if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
+ regs[RTE_REG_EAX] < feat->leaf)
+ return 0;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c b/lib/librte_eal/common/eal_common_cpuflags.c
index 8c0576d..a4c5a29 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -30,6 +30,9 @@
* (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 <stdio.h>
+
#include <rte_common.h>
#include <rte_cpuflags.h>
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
index 2ec0c2e..eb02d9b 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
@@ -37,35 +37,6 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-#include <string.h>
-
-#include "generic/rte_cpuflags.h"
-
-extern const struct feature_entry rte_cpu_feature_table[];
-
-#ifndef AT_HWCAP
-#define AT_HWCAP 16
-#endif
-
-#ifndef AT_HWCAP2
-#define AT_HWCAP2 26
-#endif
-
-#ifndef AT_PLATFORM
-#define AT_PLATFORM 15
-#endif
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
- REG_PLATFORM,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -102,56 +73,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for ARM
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
-{
- int auxv_fd;
- Elf32_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf32_auxv_t)) == sizeof(Elf32_auxv_t)) {
- if (auxv.a_type == AT_HWCAP)
- out[REG_HWCAP] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_HWCAP2)
- out[REG_HWCAP2] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_PLATFORM) {
- if (!strcmp((const char *)auxv.a_un.a_val, "v7l"))
- out[REG_PLATFORM] = 0x0001;
- }
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
+#include "generic/rte_cpuflags.h"
#ifdef __cplusplus
}
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
index b36040b..810e8a0 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
@@ -37,35 +37,6 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-#include <string.h>
-
-#include "generic/rte_cpuflags.h"
-
-extern const struct feature_entry rte_cpu_feature_table[];
-
-#ifndef AT_HWCAP
-#define AT_HWCAP 16
-#endif
-
-#ifndef AT_HWCAP2
-#define AT_HWCAP2 26
-#endif
-
-#ifndef AT_PLATFORM
-#define AT_PLATFORM 15
-#endif
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
- REG_PLATFORM,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -83,57 +54,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for ARM
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf,
- cpuid_registers_t out)
-{
- int auxv_fd;
- Elf64_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
- if (auxv.a_type == AT_HWCAP) {
- out[REG_HWCAP] = auxv.a_un.a_val;
- } else if (auxv.a_type == AT_HWCAP2) {
- out[REG_HWCAP2] = auxv.a_un.a_val;
- } else if (auxv.a_type == AT_PLATFORM) {
- if (!strcmp((const char *)auxv.a_un.a_val, "aarch64"))
- out[REG_PLATFORM] = 0x0001;
- }
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
+#include "generic/rte_cpuflags.h"
#ifdef __cplusplus
}
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
index 85c4c1a..7cc2b3c 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
@@ -37,25 +37,6 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-
-#include "generic/rte_cpuflags.h"
-
-extern const struct feature_entry rte_cpu_feature_table[];
-
-/* Symbolic values for the entries in the auxiliary table */
-#define AT_HWCAP 16
-#define AT_HWCAP2 26
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -98,52 +79,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for Power
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
-{
- int auxv_fd;
- Elf64_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
- if (auxv.a_type == AT_HWCAP)
- out[REG_HWCAP] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_HWCAP2)
- out[REG_HWCAP2] = auxv.a_un.a_val;
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
+#include "generic/rte_cpuflags.h"
#ifdef __cplusplus
}
diff --git a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
index a415857..1849b52 100644
--- a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
@@ -37,18 +37,6 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-
-#include "generic/rte_cpuflags.h"
-
-/* software based registers */
-enum cpu_register_t {
- REG_DUMMY = 0
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -56,24 +44,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS /**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for Power
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf,
- __attribute__((unused)) cpuid_registers_t out)
-{
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
-{
- return -ENOENT;
-}
+#include "generic/rte_cpuflags.h"
#ifdef __cplusplus
}
diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
index 120ea24..26204fa 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
@@ -38,15 +38,6 @@
extern "C" {
#endif
-#include <stdlib.h>
-#include <stdio.h>
-#include <errno.h>
-#include <stdint.h>
-
-#include "generic/rte_cpuflags.h"
-
-extern const struct feature_entry rte_cpu_feature_table[];
-
enum rte_cpu_flag_t {
/* (EAX 01h) ECX features*/
RTE_CPUFLAG_SSE3 = 0, /**< SSE3 */
@@ -153,64 +144,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS, /**< This should always be the last! */
};
-enum cpu_register_t {
- RTE_REG_EAX = 0,
- RTE_REG_EBX,
- RTE_REG_ECX,
- RTE_REG_EDX,
-};
-
-static inline void
-rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
-{
-#if defined(__i386__) && defined(__PIC__)
- /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
- asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
- : "=r" (out[RTE_REG_EBX]),
- "=a" (out[RTE_REG_EAX]),
- "=c" (out[RTE_REG_ECX]),
- "=d" (out[RTE_REG_EDX])
- : "a" (leaf), "c" (subleaf));
-#else
-
- asm volatile("cpuid"
- : "=a" (out[RTE_REG_EAX]),
- "=b" (out[RTE_REG_EBX]),
- "=c" (out[RTE_REG_ECX]),
- "=d" (out[RTE_REG_EDX])
- : "a" (leaf), "c" (subleaf));
-
-#endif
-}
-
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs;
-
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
- if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
- regs[RTE_REG_EAX] < feat->leaf)
- return 0;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
+#include "generic/rte_cpuflags.h"
#ifdef __cplusplus
}
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index 3ca2e36..c1da357 100644
--- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
@@ -39,10 +39,7 @@
* Architecture specific API to determine available CPU features at runtime.
*/
-#include <stdlib.h>
-#include <stdio.h>
#include <errno.h>
-#include <stdint.h>
/**
* Enumeration of all CPU features supported
@@ -50,49 +47,6 @@
enum rte_cpu_flag_t;
/**
- * Enumeration of CPU registers
- */
-#ifdef __DOXYGEN__
-enum cpu_register_t;
-#endif
-
-typedef uint32_t cpuid_registers_t[4];
-
-#define CPU_FLAG_NAME_MAX_LEN 64
-
-/**
- * Struct to hold a processor feature entry
- */
-struct feature_entry {
- uint32_t leaf; /**< cpuid leaf */
- uint32_t subleaf; /**< cpuid subleaf */
- uint32_t reg; /**< cpuid register */
- uint32_t bit; /**< cpuid register bit */
- char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
-};
-
-#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
- [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
-
-/**
- * An array that holds feature entries
- *
- * Defined in arch-specific rte_cpuflags.h.
- */
-#ifdef __DOXYGEN__
-static const struct feature_entry cpu_feature_table[];
-#endif
-
-/**
- * Execute CPUID instruction and get contents of a specific register
- *
- * This function, when compiled with GCC, will generate architecture-neutral
- * code, as per GCC manual.
- */
-static inline void
-rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out);
-
-/**
* Get name of CPU flag
*
* @param feature
@@ -114,10 +68,8 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
* 0 if flag is not available
* -ENOENT if flag is invalid
*/
-#ifdef __DOXYGEN__
-static inline int
+int
rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
-#endif
/**
* This function checks that the currently used CPU supports the CPU features
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 48e8e4f..440fac2 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -145,6 +145,5 @@ DPDK_2.3 {
rte_cpu_get_flag_name;
rte_eal_pci_map_device;
rte_eal_pci_unmap_device;
- rte_cpu_feature_table;
} DPDK_2.2;
--
2.7.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 0/5] clean-up cpuflags
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
` (2 preceding siblings ...)
2016-02-03 13:38 0% ` Jerin Jacob
@ 2016-02-06 22:17 3% ` Thomas Monjalon
2016-02-06 22:17 1% ` [dpdk-dev] [PATCH v2 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
2016-02-16 7:30 0% ` [dpdk-dev] [PATCH v2 0/5] clean-up cpuflags Thomas Monjalon
3 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2016-02-06 22:17 UTC (permalink / raw)
To: david.marchand, ferruh.yigit; +Cc: dev, viktorin
Following the work of Ferruh, I suggest this cleanup to remove as much
as possible of the code from the cpuflags headers.
The goal is to un-inline these functions (not performance sensitive)
and remove the CPU flags table from the ABI (just added recently).
The bonus is to stop mimic x86 in ARM and PPC implementations.
WARNING: it has not been tested nor compiled on Tilera and POWER8.
v2 changes:
- fix maintainers file
- fix include from C++ app
- fix missing REG_PLATFORM for ARM
- suggested ARM refactor from Jerin
Thomas Monjalon (5):
eal: get CPU flag name
eal: move CPU flag functions out of headers
eal/arm: adapt CPU flags check to the arch
eal/ppc: adapt CPU flags check to the arch
eal: remove compiler optimization workaround
MAINTAINERS | 4 +
app/test/test_hash_scaling.c | 2 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 179 ++++++++++++++++-----
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++----
lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
.../common/include/arch/arm/rte_cpuflags_32.h | 80 +--------
.../common/include/arch/arm/rte_cpuflags_64.h | 81 +---------
.../common/include/arch/ppc_64/rte_cpuflags.h | 66 +-------
.../common/include/arch/tile/rte_cpuflags.h | 31 +---
.../common/include/arch/x86/rte_cpuflags.h | 68 +-------
.../common/include/generic/rte_cpuflags.h | 56 ++-----
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +-
15 files changed, 378 insertions(+), 458 deletions(-)
--
2.7.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file
@ 2016-02-05 11:20 2% ` Jianfeng Tan
0 siblings, 0 replies; 200+ results
From: Jianfeng Tan @ 2016-02-05 11:20 UTC (permalink / raw)
To: dev; +Cc: nakajima.yoshihiro, mst, ann.zhuangyanying
Originally, there're two cons in using hugepage: a. needs root
privilege to touch /proc/self/pagemap, which is a premise to
alllocate physically contiguous memseg; b. possibly too many
hugepage file are created, especially used with 2M hugepage.
For virtual devices, they don't care about physical-contiguity
of allocated hugepages at all. Option --single-file is to
provide a way to allocate all hugepages into single mem-backed
file.
Known issue:
a. single-file option relys on kernel to allocate numa-affinitive
memory.
b. possible ABI break, originally, --no-huge uses anonymous memory
instead of file-backed way to create memory.
Signed-off-by: Huawei Xie <huawei.xie@intel.com>
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
lib/librte_eal/common/eal_common_options.c | 17 ++++++++++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h | 2 ++
lib/librte_eal/linuxapp/eal/eal.c | 4 +--
lib/librte_eal/linuxapp/eal/eal_memory.c | 50 +++++++++++++++++++++++++-----
5 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 29942ea..65bccbd 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM },
{OPT_VMWARE_TSC_MAP, 0, NULL, OPT_VMWARE_TSC_MAP_NUM },
{OPT_XEN_DOM0, 0, NULL, OPT_XEN_DOM0_NUM },
+ {OPT_SINGLE_FILE, 0, NULL, OPT_SINGLE_FILE_NUM },
{0, 0, NULL, 0 }
};
@@ -897,6 +898,10 @@ eal_parse_common_option(int opt, const char *optarg,
}
break;
+ case OPT_SINGLE_FILE_NUM:
+ conf->single_file = 1;
+ break;
+
/* don't know what to do, leave this to caller */
default:
return 1;
@@ -956,6 +961,16 @@ eal_check_common_options(struct internal_config *internal_cfg)
"be specified together with --"OPT_NO_HUGE"\n");
return -1;
}
+ if (internal_cfg->single_file && internal_cfg->force_sockets == 1) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_SINGLE_FILE" cannot "
+ "be specified together with --"OPT_SOCKET_MEM"\n");
+ return -1;
+ }
+ if (internal_cfg->single_file && internal_cfg->hugepage_unlink) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_HUGE_UNLINK" cannot "
+ "be specified together with --"OPT_SINGLE_FILE"\n");
+ return -1;
+ }
if (internal_cfg->no_hugetlbfs && internal_cfg->hugepage_unlink) {
RTE_LOG(ERR, EAL, "Option --"OPT_HUGE_UNLINK" cannot "
@@ -994,6 +1009,8 @@ eal_common_usage(void)
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
" -r RANKS Force number of memory ranks (don't detect)\n"
+ " --"OPT_SINGLE_FILE" Create just single file for shared memory, and \n"
+ " do not promise physical contiguity of memseg\n"
" -b, --"OPT_PCI_BLACKLIST" Add a PCI device in black list.\n"
" Prevent EAL from using this PCI device. The argument\n"
" format is <domain:bus:devid.func>.\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..9117ed9 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -61,6 +61,7 @@ struct hugepage_info {
*/
struct internal_config {
volatile size_t memory; /**< amount of asked memory */
+ volatile unsigned single_file; /**< mmap all hugepages in single file */
volatile unsigned force_nchannel; /**< force number of channels */
volatile unsigned force_nrank; /**< force number of ranks */
volatile unsigned no_hugetlbfs; /**< true to disable hugetlbfs */
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index a881c62..e5da14a 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
#define OPT_XEN_DOM0 "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_SINGLE_FILE "single-file"
+ OPT_SINGLE_FILE_NUM,
OPT_LONG_MAX_NUM
};
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..2bc84f7 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -790,6 +790,8 @@ rte_eal_init(int argc, char **argv)
rte_panic("Cannot init IVSHMEM\n");
#endif
+ eal_thread_init_master(rte_config.master_lcore);
+
if (rte_eal_memory_init() < 0)
rte_panic("Cannot init memory\n");
@@ -823,8 +825,6 @@ rte_eal_init(int argc, char **argv)
if (eal_plugins_init() < 0)
rte_panic("Cannot init plugins\n");
- eal_thread_init_master(rte_config.master_lcore);
-
ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%x;cpuset=[%s%s])\n",
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 6008533..68ef49a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1102,20 +1102,54 @@ rte_eal_hugepage_init(void)
/* get pointer to global configuration */
mcfg = rte_eal_get_configuration()->mem_config;
- /* hugetlbfs can be disabled */
- if (internal_config.no_hugetlbfs) {
- addr = mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE,
- MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+ /* when hugetlbfs is disabled or single-file option is specified */
+ if (internal_config.no_hugetlbfs || internal_config.single_file) {
+ int fd;
+ uint64_t pagesize;
+ unsigned socket_id = rte_socket_id();
+ char filepath[MAX_HUGEPAGE_PATH];
+
+ if (internal_config.no_hugetlbfs) {
+ eal_get_hugefile_path(filepath, sizeof(filepath),
+ "/dev/shm", 0);
+ pagesize = RTE_PGSIZE_4K;
+ } else {
+ struct hugepage_info *hpi;
+
+ hpi = &internal_config.hugepage_info[0];
+ eal_get_hugefile_path(filepath, sizeof(filepath),
+ hpi->hugedir, 0);
+ pagesize = hpi->hugepage_sz;
+ }
+ fd = open(filepath, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
+ if (fd < 0) {
+ RTE_LOG(ERR, EAL, "%s: open %s failed: %s\n",
+ __func__, filepath, strerror(errno));
+ return -1;
+ }
+
+ if (ftruncate(fd, internal_config.memory) < 0) {
+ RTE_LOG(ERR, EAL, "ftuncate %s failed: %s\n",
+ filepath, strerror(errno));
+ return -1;
+ }
+
+ addr = mmap(NULL, internal_config.memory,
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED | MAP_POPULATE, fd, 0);
if (addr == MAP_FAILED) {
- RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__,
- strerror(errno));
+ RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n",
+ __func__, strerror(errno));
return -1;
}
mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr;
mcfg->memseg[0].addr = addr;
- mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K;
+ mcfg->memseg[0].hugepage_sz = pagesize;
mcfg->memseg[0].len = internal_config.memory;
- mcfg->memseg[0].socket_id = 0;
+ mcfg->memseg[0].socket_id = socket_id;
+
+ close(fd);
+
return 0;
}
--
2.1.4
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
2016-01-27 13:56 3% ` Panu Matilainen
@ 2016-02-03 17:23 0% ` Olivier MATZ
2016-02-22 14:49 0% ` Xie, Huawei
0 siblings, 1 reply; 200+ results
From: Olivier MATZ @ 2016-02-03 17:23 UTC (permalink / raw)
To: Panu Matilainen, Huawei Xie, dev; +Cc: dprovan
Hi,
On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>
> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
> the library ABI and should not be listed in the version map.
>
> I assume its inline for performance reasons, but then you lose the
> benefits of dynamic linking such as ability to fix bugs and/or improve
> itby just updating the library. Since the point of having a bulk API is
> to improve performance by reducing the number of calls required, does it
> really have to be inline? As in, have you actually measured the
> difference between inline and non-inline and decided its worth all the
> downsides?
Agree with Panu. It would be interesting to compare the performance
between inline and non inline to decide whether inlining it or not.
Also, it would be nice to have a simple test function in
app/test/test_mbuf.c. For instance, you could update
test_one_pktmbuf() to take a mbuf pointer as a parameter and remove
the mbuf allocation from the function. Then it could be called with
a mbuf allocated with rte_pktmbuf_alloc() (like before) and with
all the mbufs of rte_pktmbuf_alloc_bulk().
Regards,
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
2016-02-02 23:02 2% [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size Keith Wiles
@ 2016-02-03 17:11 0% ` Ananyev, Konstantin
2016-02-08 11:02 4% ` Olivier MATZ
2016-02-09 17:30 2% ` [dpdk-dev] [PATCH v2] mempool: reduce " Keith Wiles
2 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2016-02-03 17:11 UTC (permalink / raw)
To: Wiles, Keith, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
> Sent: Tuesday, February 02, 2016 11:03 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
>
> The rte_mempool structure is changed, which will cause an ABI change
> for this structure.
>
> Allow mempool cache support to be dynamic depending on if the
> mempool being created needs cache support. Saves about 1.5M of
> memory used by the rte_mempool structure. Performance does not seem
> to be effected running l3fwd and the test_mempool execution passed.
>
> Allocating small mempools which do not require cache can consume
> larges amounts of memory if you have a number of these mempools.
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> ---
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
2016-02-03 13:38 0% ` Jerin Jacob
@ 2016-02-03 14:01 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-03 14:01 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, viktorin
2016-02-03 19:08, Jerin Jacob:
> On Tue, Feb 02, 2016 at 11:59:48PM +0100, Thomas Monjalon wrote:
> > Following the work of Ferruh, I suggest this cleanup to remove as much
> > as possible of the code from the cpuflags headers.
> > The goal is to un-inline these functions (not performance sensitive)
> > and remove the CPU flags table from the ABI (just added recently).
> > The bonus is to stop mimic x86 in ARM and PPC implementations.
> >
> > WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
> > Please help, thank you.
>
> compilation errors on arm64 too.
Yes I forgot REG_PLATFORM.
> arm64 toolchains are publicly available @
> http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
Yes I know, thank you.
I will test and make a v2.
Do you have any comment on the changes?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
2016-02-02 23:51 0% ` [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Jan Viktorin
@ 2016-02-03 13:38 0% ` Jerin Jacob
2016-02-03 14:01 0% ` Thomas Monjalon
2016-02-06 22:17 3% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
3 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2016-02-03 13:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, viktorin
On Tue, Feb 02, 2016 at 11:59:48PM +0100, Thomas Monjalon wrote:
> Following the work of Ferruh, I suggest this cleanup to remove as much
> as possible of the code from the cpuflags headers.
> The goal is to un-inline these functions (not performance sensitive)
> and remove the CPU flags table from the ABI (just added recently).
> The bonus is to stop mimic x86 in ARM and PPC implementations.
>
> WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
> Please help, thank you.
compilation errors on arm64 too.
arm64 toolchains are publicly available @
http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
➜ [master] thunderx [dpdk-master] $ make
== Build lib
== Build lib/librte_compat
== Build lib/librte_eal
== Build lib/librte_eal/common
== Build lib/librte_eal/linuxapp
== Build lib/librte_eal/linuxapp/igb_uio
(cat /dev/null; echo
kernel//home/jerin/dpdk-master/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;)
> /home/jerin/dpdk-master/build/build/lib/librte_eal/linuxapp/igb_uio/modules.order
Building modules, stage 2.
MODPOST 1 modules
== Build lib/librte_eal/linuxapp/eal
CC rte_cpuflags.o
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:83:20:
error: ‘REG_PLATFORM’ undeclared here (not in a function)
FEAT_DEF(AARCH64, REG_PLATFORM, 1)
^
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:71:26:
note: in definition of macro ‘FEAT_DEF’
[RTE_CPUFLAG_##name] = {reg, bit, #name},
^
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:
In function ‘rte_cpu_get_features’:
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:8:
error: array subscript is not an integer
out[REG_PLATFORM] = 0x0001;
^
/home/jerin/dpdk-master/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:5:
error: statement with no effect [-Werror=unused-value]
out[REG_PLATFORM] = 0x0001;
^
cc1: all warnings being treated as errors
/home/jerin/dpdk-master/mk/internal/rte.compile-pre.mk:126: recipe for
target 'rte_cpuflags.o' failed
make[5]: *** [rte_cpuflags.o] Error 1
/home/jerin/dpdk-master/mk/rte.subdir.mk:61: recipe for target 'eal'
failed
make[4]: *** [eal] Error 2
/home/jerin/dpdk-master/mk/rte.subdir.mk:61: recipe for target
'linuxapp' failed
make[3]: *** [linuxapp] Error 2
/home/jerin/dpdk-master/mk/rte.subdir.mk:61: recipe for target
'librte_eal' failed
make[2]: *** [librte_eal] Error 2
/home/jerin/dpdk-master/mk/rte.sdkbuild.mk:77: recipe for target 'lib'
failed
make[1]: *** [lib] Error 2
/home/jerin/dpdk-master/mk/rte.sdkroot.mk:123: recipe for target 'all'
failed
make: *** [all] Error 2
>
> Thomas Monjalon (5):
> eal: get CPU flag name
> eal: move CPU flag functions out of headers
> eal/arm: adapt CPU flags check to the arch
> eal/ppc: adapt CPU flags check to the arch
> eal: remove compiler optimization workaround
>
> app/test/test_hash_scaling.c | 2 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
> lib/librte_eal/common/arch/arm/rte_cpuflags.c | 170 ++++++++++++++++-----
> lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++-----
> lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
> lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
> lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
> .../common/include/arch/arm/rte_cpuflags_32.h | 78 ----------
> .../common/include/arch/arm/rte_cpuflags_64.h | 79 ----------
> .../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------
> .../common/include/arch/tile/rte_cpuflags.h | 29 ----
> .../common/include/arch/x86/rte_cpuflags.h | 66 --------
> .../common/include/generic/rte_cpuflags.h | 56 ++-----
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
> 14 files changed, 364 insertions(+), 450 deletions(-)
>
> --
> 2.5.2
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
@ 2016-02-03 8:32 4% ` Rahul Lakkireddy
0 siblings, 0 replies; 200+ results
From: Rahul Lakkireddy @ 2016-02-03 8:32 UTC (permalink / raw)
To: dev; +Cc: Kumar Sanghvi, Nirranjan Kirubaharan
Add a new raw packet flow that allows specifying generic flow input.
Add the ability to provide masks for fields in flow to allow range of
values.
Add a new behavior switch.
Add the ability to provide behavior arguments to allow rewriting matched
fields with new values. Ex: allows to provide new ip and port addresses
to rewrite the fields of packets matching a filter rule before NAT'ing.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
doc/guides/rel_notes/release_2_3.rst | 3 +++
lib/librte_ether/rte_eth_ctrl.h | 15 ++++++++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..19ce954 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,9 @@ API Changes
ABI Changes
-----------
+* New flow type ``RTE_ETH_FLOW_RAW_PKT`` had been introduced and hence
+ ``RTE_ETH_FLOW_MAX`` had been increased to 19.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..1bc0d03 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -74,7 +74,8 @@ extern "C" {
#define RTE_ETH_FLOW_IPV6_EX 15
#define RTE_ETH_FLOW_IPV6_TCP_EX 16
#define RTE_ETH_FLOW_IPV6_UDP_EX 17
-#define RTE_ETH_FLOW_MAX 18
+#define RTE_ETH_FLOW_RAW_PKT 18
+#define RTE_ETH_FLOW_MAX 19
/**
* Feature filter types
@@ -499,6 +500,9 @@ struct rte_eth_tunnel_flow {
struct ether_addr mac_addr; /**< Mac address to match. */
};
+/**< Max length of raw packet in bytes. */
+#define RTE_ETH_RAW_PKT_FLOW_MAX_LEN 256
+
/**
* An union contains the inputs for all types of flow
*/
@@ -514,6 +518,7 @@ union rte_eth_fdir_flow {
struct rte_eth_ipv6_flow ipv6_flow;
struct rte_eth_mac_vlan_flow mac_vlan_flow;
struct rte_eth_tunnel_flow tunnel_flow;
+ uint8_t raw_pkt_flow[RTE_ETH_RAW_PKT_FLOW_MAX_LEN];
};
/**
@@ -534,6 +539,8 @@ struct rte_eth_fdir_input {
uint16_t flow_type;
union rte_eth_fdir_flow flow;
/**< Flow fields to match, dependent on flow_type */
+ union rte_eth_fdir_flow flow_mask;
+ /**< Mask for the fields matched, dependent on flow */
struct rte_eth_fdir_flow_ext flow_ext;
/**< Additional fields to match */
};
@@ -545,6 +552,7 @@ enum rte_eth_fdir_behavior {
RTE_ETH_FDIR_ACCEPT = 0,
RTE_ETH_FDIR_REJECT,
RTE_ETH_FDIR_PASSTHRU,
+ RTE_ETH_FDIR_SWITCH,
};
/**
@@ -558,6 +566,9 @@ enum rte_eth_fdir_status {
RTE_ETH_FDIR_REPORT_FLEX_8, /**< Report 8 flex bytes. */
};
+/**< Max # of behavior arguments */
+#define RTE_ETH_BEHAVIOR_ARG_MAX_LEN 256
+
/**
* A structure used to define an action when match FDIR packet filter.
*/
@@ -569,6 +580,8 @@ struct rte_eth_fdir_action {
/**< If report_status is RTE_ETH_FDIR_REPORT_ID_FLEX_4 or
RTE_ETH_FDIR_REPORT_FLEX_8, flex_off specifies where the reported
flex bytes start from in flexible payload. */
+ uint8_t behavior_arg[RTE_ETH_BEHAVIOR_ARG_MAX_LEN];
+ /**< Extra arguments for behavior taken */
};
/**
--
2.5.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config
2016-02-03 3:36 3% ` Stephen Hemminger
@ 2016-02-03 8:08 3% ` Lu, Wenzhuo
0 siblings, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2016-02-03 8:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, February 3, 2016 11:36 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config
>
> On Tue, 2 Feb 2016 14:57:00 +0800
> Wenzhuo Lu <wenzhuo.lu@intel.com> wrote:
>
> > +/**
> > + * l2 tunnel configuration.
> > + */
> > +struct rte_eth_l2_tunnel {
> > + enum rte_eth_l2_tunnel_type l2_tunnel_type;
> > + uint16_t ether_type;
> > +};
>
> Building an API with an indirect (structure) parameter with only two elements
> seems like overkill. If you are building it to support future features, that won't
> work because it will break ABI.
>
> Why not just?
>
> int
> rte_eth_dev_etag_enable(uint8_t port_id, uint16_t ether_type)
I'm trying to make the rte ops can support future features, because there're some similar technology 802.1Qbg, 802.1Qbh, 802.1BR, VN-tag.
And after applying all the patches in this patch set, the struct rte_eth_l2_tunnel will be like this,
struct rte_eth_l2_tunnel {
enum rte_eth_l2_tunnel_type l2_tunnel_type;
uint16_t ether_type;
uint32_t tunnel_id; /* port tag id for e-tag */
};
If we want to support a new type of tunnel which can be described by ether type and tunnel id, we need not to extend this structure. We
only need to add new value for l2_tunnel_type. I think it's not an ABI change.
And I think using a l2 tunnel to cover all these tunnels can make interface simple :)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config
@ 2016-02-03 3:36 3% ` Stephen Hemminger
2016-02-03 8:08 3% ` Lu, Wenzhuo
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2016-02-03 3:36 UTC (permalink / raw)
To: Wenzhuo Lu; +Cc: dev
On Tue, 2 Feb 2016 14:57:00 +0800
Wenzhuo Lu <wenzhuo.lu@intel.com> wrote:
> +/**
> + * l2 tunnel configuration.
> + */
> +struct rte_eth_l2_tunnel {
> + enum rte_eth_l2_tunnel_type l2_tunnel_type;
> + uint16_t ether_type;
> +};
Building an API with an indirect (structure) parameter with only two
elements seems like overkill. If you are building it to support future
features, that won't work because it will break ABI.
Why not just?
int
rte_eth_dev_etag_enable(uint8_t port_id, uint16_t ether_type)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
@ 2016-02-02 23:51 0% ` Jan Viktorin
2016-02-03 13:38 0% ` Jerin Jacob
2016-02-06 22:17 3% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
3 siblings, 0 replies; 200+ results
From: Jan Viktorin @ 2016-02-02 23:51 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hello Thomas,
the patch set fails when compiling for ARMv7 with the following (full
build.log is attached):
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:114:22: error: ‘REG_PLATFORM’ undeclared here (not in a function)
FEAT_DEF(V7L, REG_PLATFORM, 0)
^
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:71:26: note: in definition of macro ‘FEAT_DEF’
[RTE_CPUFLAG_##name] = {reg, bit, #name},
^
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c: In function ‘rte_cpu_get_features’:
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:8: error: array subscript is not an integer
out[REG_PLATFORM] = 0x0001;
^
/var/lib/jenkins/jobs/dpdk-armv7-testing/workspace/lib/librte_eal/common/arch/arm/rte_cpuflags.c:144:5: error: statement with no effect [-Werror=unused-value]
out[REG_PLATFORM] = 0x0001;
^
cc1: all warnings being treated as errors
Regards
Jan
On Tue, 2 Feb 2016 23:59:48 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> Following the work of Ferruh, I suggest this cleanup to remove as much
> as possible of the code from the cpuflags headers.
> The goal is to un-inline these functions (not performance sensitive)
> and remove the CPU flags table from the ABI (just added recently).
> The bonus is to stop mimic x86 in ARM and PPC implementations.
>
> WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
> Please help, thank you.
>
> Thomas Monjalon (5):
> eal: get CPU flag name
> eal: move CPU flag functions out of headers
> eal/arm: adapt CPU flags check to the arch
> eal/ppc: adapt CPU flags check to the arch
> eal: remove compiler optimization workaround
>
> app/test/test_hash_scaling.c | 2 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
> lib/librte_eal/common/arch/arm/rte_cpuflags.c | 170 ++++++++++++++++-----
> lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++-----
> lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
> lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
> lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
> .../common/include/arch/arm/rte_cpuflags_32.h | 78 ----------
> .../common/include/arch/arm/rte_cpuflags_64.h | 79 ----------
> .../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------
> .../common/include/arch/tile/rte_cpuflags.h | 29 ----
> .../common/include/arch/x86/rte_cpuflags.h | 66 --------
> .../common/include/generic/rte_cpuflags.h | 56 ++-----
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
> 14 files changed, 364 insertions(+), 450 deletions(-)
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
@ 2016-02-02 23:10 1% ` Thomas Monjalon
2016-02-02 23:51 0% ` [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Jan Viktorin
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-02-02 23:10 UTC (permalink / raw)
To: david.marchand, ferruh.yigit; +Cc: dev, viktorin
The patch c344eab3ee has moved the hardware definition of CPU flags.
Now the functions checking these hardware flags are also moved.
The function rte_cpu_get_flag_enabled() is no more inline.
The benefits are:
- remove rte_cpu_feature_table from the ABI (recently added)
- hide hardware details from the API
- allow to adapt structures per arch (done in next patch)
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
app/test/test_hash_scaling.c | 2 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 99 ++++++++++++++++++++++
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 79 +++++++++++++++++
lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 +++
lib/librte_eal/common/arch/x86/rte_cpuflags.c | 83 ++++++++++++++++++
lib/librte_eal/common/eal_common_cpuflags.c | 3 +
.../common/include/arch/arm/rte_cpuflags_32.h | 78 -----------------
.../common/include/arch/arm/rte_cpuflags_64.h | 79 -----------------
.../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------------
.../common/include/arch/tile/rte_cpuflags.h | 29 -------
.../common/include/arch/x86/rte_cpuflags.h | 66 ---------------
.../common/include/generic/rte_cpuflags.h | 50 +----------
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 -
14 files changed, 278 insertions(+), 367 deletions(-)
diff --git a/app/test/test_hash_scaling.c b/app/test/test_hash_scaling.c
index 744e5e3..1c4c75d 100644
--- a/app/test/test_hash_scaling.c
+++ b/app/test/test_hash_scaling.c
@@ -31,6 +31,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <stdio.h>
+
#include <rte_cycles.h>
#include <rte_hash.h>
#include <rte_hash_crc.h>
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 1280cb2..f0aa698 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -139,7 +139,6 @@ DPDK_2.2 {
DPDK_2.3 {
global:
- rte_cpu_feature_table;
rte_cpu_get_flag_name;
} DPDK_2.2;
diff --git a/lib/librte_eal/common/arch/arm/rte_cpuflags.c b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
index 62e0791..664f527 100644
--- a/lib/librte_eal/common/arch/arm/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
@@ -2,6 +2,7 @@
* BSD LICENSE
*
* Copyright (C) Cavium networks Ltd. 2015.
+ * Copyright(c) 2015 RehiveTech. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -32,6 +33,46 @@
#include "rte_cpuflags.h"
+#include <elf.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <unistd.h>
+#include <string.h>
+
+#ifndef AT_HWCAP
+#define AT_HWCAP 16
+#endif
+
+#ifndef AT_HWCAP2
+#define AT_HWCAP2 26
+#endif
+
+#ifndef AT_PLATFORM
+#define AT_PLATFORM 15
+#endif
+
+enum cpu_register_t {
+ REG_HWCAP = 0,
+ REG_HWCAP2,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
#ifdef RTE_ARCH_64
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(FP, 0x00000001, 0, REG_HWCAP, 0)
@@ -77,6 +118,64 @@ const struct feature_entry rte_cpu_feature_table[] = {
};
#endif
+/*
+ * Read AUXV software register and get cpu features for ARM
+ */
+static void
+rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
+ __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
+{
+ int auxv_fd;
+#ifdef RTE_ARCH_64
+ Elf64_auxv_t auxv;
+#else
+ Elf32_auxv_t auxv;
+#endif
+
+ auxv_fd = open("/proc/self/auxv", O_RDONLY);
+ assert(auxv_fd);
+ while (read(auxv_fd, &auxv, sizeof(auxv)) == sizeof(auxv)) {
+ if (auxv.a_type == AT_HWCAP) {
+ out[REG_HWCAP] = auxv.a_un.a_val;
+ } else if (auxv.a_type == AT_HWCAP2) {
+ out[REG_HWCAP2] = auxv.a_un.a_val;
+ } else if (auxv.a_type == AT_PLATFORM) {
+#ifdef RTE_ARCH_64
+ if (!strcmp((const char *)auxv.a_un.a_val, "aarch64"))
+#else
+ if (!strcmp((const char *)auxv.a_un.a_val, "v7l"))
+#endif
+ out[REG_PLATFORM] = 0x0001;
+ }
+ }
+}
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs = {0};
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
index a270ccc..b7e0b72 100644
--- a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
@@ -32,6 +32,38 @@
#include "rte_cpuflags.h"
+#include <elf.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <unistd.h>
+
+/* Symbolic values for the entries in the auxiliary table */
+#define AT_HWCAP 16
+#define AT_HWCAP2 26
+
+/* software based registers */
+enum cpu_register_t {
+ REG_HWCAP = 0,
+ REG_HWCAP2,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(PPC_LE, 0x00000001, 0, REG_HWCAP, 0)
FEAT_DEF(TRUE_LE, 0x00000001, 0, REG_HWCAP, 1)
@@ -69,6 +101,53 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(ARCH_2_07, 0x00000001, 0, REG_HWCAP2, 31)
};
+/*
+ * Read AUXV software register and get cpu features for Power
+ */
+static void
+rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
+ __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
+{
+ int auxv_fd;
+ Elf64_auxv_t auxv;
+
+ auxv_fd = open("/proc/self/auxv", O_RDONLY);
+ assert(auxv_fd);
+ while (read(auxv_fd, &auxv,
+ sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
+ if (auxv.a_type == AT_HWCAP)
+ out[REG_HWCAP] = auxv.a_un.a_val;
+ else if (auxv.a_type == AT_HWCAP2)
+ out[REG_HWCAP2] = auxv.a_un.a_val;
+ }
+}
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs = {0};
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/arch/tile/rte_cpuflags.c b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
index 4ca0a7b..a2b6c51 100644
--- a/lib/librte_eal/common/arch/tile/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/tile/rte_cpuflags.c
@@ -32,5 +32,16 @@
#include "rte_cpuflags.h"
+#include <errno.h>
+
const struct feature_entry rte_cpu_feature_table[] = {
};
+
+/*
+ * Checks if a particular flag is available on current machine.
+ */
+int
+rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
+{
+ return -ENOENT;
+}
diff --git a/lib/librte_eal/common/arch/x86/rte_cpuflags.c b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
index 3346fde..0138257 100644
--- a/lib/librte_eal/common/arch/x86/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/x86/rte_cpuflags.c
@@ -33,6 +33,34 @@
#include "rte_cpuflags.h"
+#include <stdio.h>
+#include <errno.h>
+#include <stdint.h>
+
+enum cpu_register_t {
+ RTE_REG_EAX = 0,
+ RTE_REG_EBX,
+ RTE_REG_ECX,
+ RTE_REG_EDX,
+};
+
+typedef uint32_t cpuid_registers_t[4];
+
+/**
+ * Struct to hold a processor feature entry
+ */
+struct feature_entry {
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
+#define CPU_FLAG_NAME_MAX_LEN 64
+ char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
+};
+
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+ [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
+
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SSE3, 0x00000001, 0, RTE_REG_ECX, 0)
FEAT_DEF(PCLMULQDQ, 0x00000001, 0, RTE_REG_ECX, 1)
@@ -128,6 +156,61 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(INVTSC, 0x80000007, 0, RTE_REG_EDX, 8)
};
+/*
+ * Execute CPUID instruction and get contents of a specific register
+ *
+ * This function, when compiled with GCC, will generate architecture-neutral
+ * code, as per GCC manual.
+ */
+static void
+rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
+{
+#if defined(__i386__) && defined(__PIC__)
+ /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
+ asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
+ : "=r" (out[RTE_REG_EBX]),
+ "=a" (out[RTE_REG_EAX]),
+ "=c" (out[RTE_REG_ECX]),
+ "=d" (out[RTE_REG_EDX])
+ : "a" (leaf), "c" (subleaf));
+#else
+ asm volatile("cpuid"
+ : "=a" (out[RTE_REG_EAX]),
+ "=b" (out[RTE_REG_EBX]),
+ "=c" (out[RTE_REG_ECX]),
+ "=d" (out[RTE_REG_EDX])
+ : "a" (leaf), "c" (subleaf));
+#endif
+}
+
+int
+rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
+{
+ const struct feature_entry *feat;
+ cpuid_registers_t regs;
+
+ if (feature >= RTE_CPUFLAG_NUMFLAGS)
+ /* Flag does not match anything in the feature tables */
+ return -ENOENT;
+
+ feat = &rte_cpu_feature_table[feature];
+
+ if (!feat->leaf)
+ /* This entry in the table wasn't filled out! */
+ return -EFAULT;
+
+ rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
+ if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
+ regs[RTE_REG_EAX] < feat->leaf)
+ return 0;
+
+ /* get the cpuid leaf containing the desired feature */
+ rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
+
+ /* check if the feature is enabled */
+ return (regs[feat->reg] >> feat->bit) & 1;
+}
+
const char *
rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
{
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c b/lib/librte_eal/common/eal_common_cpuflags.c
index 8c0576d..a4c5a29 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -30,6 +30,9 @@
* (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 <stdio.h>
+
#include <rte_common.h>
#include <rte_cpuflags.h>
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
index 2ec0c2e..373fd46 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_32.h
@@ -37,35 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-#include <string.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
-#ifndef AT_HWCAP
-#define AT_HWCAP 16
-#endif
-
-#ifndef AT_HWCAP2
-#define AT_HWCAP2 26
-#endif
-
-#ifndef AT_PLATFORM
-#define AT_PLATFORM 15
-#endif
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
- REG_PLATFORM,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -102,57 +75,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for ARM
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
-{
- int auxv_fd;
- Elf32_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf32_auxv_t)) == sizeof(Elf32_auxv_t)) {
- if (auxv.a_type == AT_HWCAP)
- out[REG_HWCAP] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_HWCAP2)
- out[REG_HWCAP2] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_PLATFORM) {
- if (!strcmp((const char *)auxv.a_un.a_val, "v7l"))
- out[REG_PLATFORM] = 0x0001;
- }
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
index b36040b..4cf4759 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags_64.h
@@ -37,35 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-#include <string.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
-#ifndef AT_HWCAP
-#define AT_HWCAP 16
-#endif
-
-#ifndef AT_HWCAP2
-#define AT_HWCAP2 26
-#endif
-
-#ifndef AT_PLATFORM
-#define AT_PLATFORM 15
-#endif
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
- REG_PLATFORM,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -83,58 +56,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for ARM
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf,
- cpuid_registers_t out)
-{
- int auxv_fd;
- Elf64_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
- if (auxv.a_type == AT_HWCAP) {
- out[REG_HWCAP] = auxv.a_un.a_val;
- } else if (auxv.a_type == AT_HWCAP2) {
- out[REG_HWCAP2] = auxv.a_un.a_val;
- } else if (auxv.a_type == AT_PLATFORM) {
- if (!strcmp((const char *)auxv.a_un.a_val, "aarch64"))
- out[REG_PLATFORM] = 0x0001;
- }
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
index 85c4c1a..04d4c27 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
@@ -37,25 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
-/* Symbolic values for the entries in the auxiliary table */
-#define AT_HWCAP 16
-#define AT_HWCAP2 26
-
-/* software based registers */
-enum cpu_register_t {
- REG_HWCAP = 0,
- REG_HWCAP2,
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -98,53 +81,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for Power
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf, cpuid_registers_t out)
-{
- int auxv_fd;
- Elf64_auxv_t auxv;
-
- auxv_fd = open("/proc/self/auxv", O_RDONLY);
- assert(auxv_fd);
- while (read(auxv_fd, &auxv,
- sizeof(Elf64_auxv_t)) == sizeof(Elf64_auxv_t)) {
- if (auxv.a_type == AT_HWCAP)
- out[REG_HWCAP] = auxv.a_un.a_val;
- else if (auxv.a_type == AT_HWCAP2)
- out[REG_HWCAP2] = auxv.a_un.a_val;
- }
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs = {0};
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
index a415857..994884b 100644
--- a/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/tile/rte_cpuflags.h
@@ -37,18 +37,8 @@
extern "C" {
#endif
-#include <elf.h>
-#include <fcntl.h>
-#include <assert.h>
-#include <unistd.h>
-
#include "generic/rte_cpuflags.h"
-/* software based registers */
-enum cpu_register_t {
- REG_DUMMY = 0
-};
-
/**
* Enumeration of all CPU features supported
*/
@@ -56,25 +46,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS /**< This should always be the last! */
};
-/*
- * Read AUXV software register and get cpu features for Power
- */
-static inline void
-rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
- __attribute__((unused)) uint32_t subleaf,
- __attribute__((unused)) cpuid_registers_t out)
-{
-}
-
-/*
- * Checks if a particular flag is available on current machine.
- */
-static inline int
-rte_cpu_get_flag_enabled(__attribute__((unused)) enum rte_cpu_flag_t feature)
-{
- return -ENOENT;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
index 120ea24..117fed2 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
@@ -38,15 +38,8 @@
extern "C" {
#endif
-#include <stdlib.h>
-#include <stdio.h>
-#include <errno.h>
-#include <stdint.h>
-
#include "generic/rte_cpuflags.h"
-extern const struct feature_entry rte_cpu_feature_table[];
-
enum rte_cpu_flag_t {
/* (EAX 01h) ECX features*/
RTE_CPUFLAG_SSE3 = 0, /**< SSE3 */
@@ -153,65 +146,6 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS, /**< This should always be the last! */
};
-enum cpu_register_t {
- RTE_REG_EAX = 0,
- RTE_REG_EBX,
- RTE_REG_ECX,
- RTE_REG_EDX,
-};
-
-static inline void
-rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out)
-{
-#if defined(__i386__) && defined(__PIC__)
- /* %ebx is a forbidden register if we compile with -fPIC or -fPIE */
- asm volatile("movl %%ebx,%0 ; cpuid ; xchgl %%ebx,%0"
- : "=r" (out[RTE_REG_EBX]),
- "=a" (out[RTE_REG_EAX]),
- "=c" (out[RTE_REG_ECX]),
- "=d" (out[RTE_REG_EDX])
- : "a" (leaf), "c" (subleaf));
-#else
-
- asm volatile("cpuid"
- : "=a" (out[RTE_REG_EAX]),
- "=b" (out[RTE_REG_EBX]),
- "=c" (out[RTE_REG_ECX]),
- "=d" (out[RTE_REG_EDX])
- : "a" (leaf), "c" (subleaf));
-
-#endif
-}
-
-static inline int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
-{
- const struct feature_entry *feat;
- cpuid_registers_t regs;
-
-
- if (feature >= RTE_CPUFLAG_NUMFLAGS)
- /* Flag does not match anything in the feature tables */
- return -ENOENT;
-
- feat = &rte_cpu_feature_table[feature];
-
- if (!feat->leaf)
- /* This entry in the table wasn't filled out! */
- return -EFAULT;
-
- rte_cpu_get_features(feat->leaf & 0xffff0000, 0, regs);
- if (((regs[RTE_REG_EAX] ^ feat->leaf) & 0xffff0000) ||
- regs[RTE_REG_EAX] < feat->leaf)
- return 0;
-
- /* get the cpuid leaf containing the desired feature */
- rte_cpu_get_features(feat->leaf, feat->subleaf, regs);
-
- /* check if the feature is enabled */
- return (regs[feat->reg] >> feat->bit) & 1;
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index 3ca2e36..c1da357 100644
--- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
@@ -39,10 +39,7 @@
* Architecture specific API to determine available CPU features at runtime.
*/
-#include <stdlib.h>
-#include <stdio.h>
#include <errno.h>
-#include <stdint.h>
/**
* Enumeration of all CPU features supported
@@ -50,49 +47,6 @@
enum rte_cpu_flag_t;
/**
- * Enumeration of CPU registers
- */
-#ifdef __DOXYGEN__
-enum cpu_register_t;
-#endif
-
-typedef uint32_t cpuid_registers_t[4];
-
-#define CPU_FLAG_NAME_MAX_LEN 64
-
-/**
- * Struct to hold a processor feature entry
- */
-struct feature_entry {
- uint32_t leaf; /**< cpuid leaf */
- uint32_t subleaf; /**< cpuid subleaf */
- uint32_t reg; /**< cpuid register */
- uint32_t bit; /**< cpuid register bit */
- char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
-};
-
-#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
- [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
-
-/**
- * An array that holds feature entries
- *
- * Defined in arch-specific rte_cpuflags.h.
- */
-#ifdef __DOXYGEN__
-static const struct feature_entry cpu_feature_table[];
-#endif
-
-/**
- * Execute CPUID instruction and get contents of a specific register
- *
- * This function, when compiled with GCC, will generate architecture-neutral
- * code, as per GCC manual.
- */
-static inline void
-rte_cpu_get_features(uint32_t leaf, uint32_t subleaf, cpuid_registers_t out);
-
-/**
* Get name of CPU flag
*
* @param feature
@@ -114,10 +68,8 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
* 0 if flag is not available
* -ENOENT if flag is invalid
*/
-#ifdef __DOXYGEN__
-static inline int
+int
rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
-#endif
/**
* This function checks that the currently used CPU supports the CPU features
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index d8a5978..b06825a 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -142,7 +142,6 @@ DPDK_2.2 {
DPDK_2.3 {
global:
- rte_cpu_feature_table;
rte_cpu_get_flag_name;
} DPDK_2.2;
--
2.7.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size
@ 2016-02-02 23:02 2% Keith Wiles
2016-02-03 17:11 0% ` Ananyev, Konstantin
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Keith Wiles @ 2016-02-02 23:02 UTC (permalink / raw)
To: dev
The rte_mempool structure is changed, which will cause an ABI change
for this structure.
Allow mempool cache support to be dynamic depending on if the
mempool being created needs cache support. Saves about 1.5M of
memory used by the rte_mempool structure. Performance does not seem
to be effected running l3fwd and the test_mempool execution passed.
Allocating small mempools which do not require cache can consume
larges amounts of memory if you have a number of these mempools.
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
app/test/test_mempool.c | 4 +--
lib/librte_mempool/rte_mempool.c | 56 ++++++++++++++++++----------------------
lib/librte_mempool/rte_mempool.h | 29 ++++++++++-----------
3 files changed, 40 insertions(+), 49 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 72f8fb6..7b479f8 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -122,8 +122,8 @@ test_mempool_basic(void)
return -1;
printf("get private data\n");
- if (rte_mempool_get_priv(mp) !=
- (char*) mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num))
+ if (rte_mempool_get_priv(mp) != (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size))
return -1;
printf("get physical address of an object\n");
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..bdf8e2e 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -450,15 +450,11 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
int page_size = getpagesize();
/* compilation-time checks */
+#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool) &
RTE_CACHE_LINE_MASK) != 0);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
RTE_CACHE_LINE_MASK) != 0);
- RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, local_cache) &
- RTE_CACHE_LINE_MASK) != 0);
-#endif
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
RTE_CACHE_LINE_MASK) != 0);
RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, stats) &
@@ -527,9 +523,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
*/
int head = sizeof(struct rte_mempool);
int new_size = (private_data_size + head) % page_size;
- if (new_size) {
+ if (new_size)
private_data_size += page_size - new_size;
- }
}
/* try to allocate tailq entry */
@@ -544,7 +539,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
* store mempool objects. Otherwise reserve a memzone that is large
* enough to hold mempool header and metadata plus mempool objects.
*/
- mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num) + private_data_size;
+ mempool_size = MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size);
+ mempool_size += private_data_size;
mempool_size = RTE_ALIGN_CEIL(mempool_size, RTE_MEMPOOL_ALIGN);
if (vaddr == NULL)
mempool_size += (size_t)objsz.total_size * n;
@@ -598,8 +594,15 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
mp->private_data_size = private_data_size;
+ /*
+ * local_cache pointer is set even if cache_size is zero.
+ * The local_cache points to just past the elt_pa[] array.
+ */
+ mp->local_cache = (struct rte_mempool_cache *)
+ ((char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, 0));
+
/* calculate address of the first element for continuous mempool. */
- obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num) +
+ obj = (char *)mp + MEMPOOL_HEADER_SIZE(mp, pg_num, cache_size) +
private_data_size;
obj = RTE_PTR_ALIGN_CEIL(obj, RTE_MEMPOOL_ALIGN);
@@ -613,9 +616,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
mp->elt_va_start = (uintptr_t)obj;
mp->elt_pa[0] = mp->phys_addr +
(mp->elt_va_start - (uintptr_t)mp);
-
- /* mempool elements in a separate chunk of memory. */
} else {
+ /* mempool elements in a separate chunk of memory. */
mp->elt_va_start = (uintptr_t)vaddr;
memcpy(mp->elt_pa, paddr, sizeof (mp->elt_pa[0]) * pg_num);
}
@@ -645,19 +647,15 @@ unsigned
rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
+ unsigned lcore_id;
count = rte_ring_count(mp->ring);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
- {
- unsigned lcore_id;
- if (mp->cache_size == 0)
- return count;
+ if (mp->cache_size == 0)
+ return count;
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
- count += mp->local_cache[lcore_id].len;
- }
-#endif
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
+ count += mp->local_cache[lcore_id].len;
/*
* due to race condition (access to len is not locked), the
@@ -672,13 +670,15 @@ rte_mempool_count(const struct rte_mempool *mp)
static unsigned
rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
unsigned lcore_id;
unsigned count = 0;
unsigned cache_count;
fprintf(f, " cache infos:\n");
fprintf(f, " cache_size=%"PRIu32"\n", mp->cache_size);
+ if (mp->cache_size == 0)
+ return count;
+
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
cache_count = mp->local_cache[lcore_id].len;
fprintf(f, " cache_count[%u]=%u\n", lcore_id, cache_count);
@@ -686,11 +686,6 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
}
fprintf(f, " total_cache_count=%u\n", count);
return count;
-#else
- RTE_SET_USED(mp);
- fprintf(f, " cache disabled\n");
- return 0;
-#endif
}
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -755,13 +750,16 @@ mempool_audit_cookies(const struct rte_mempool *mp)
#define mempool_audit_cookies(mp) do {} while(0)
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* check cookies before and after objects */
static void
mempool_audit_cache(const struct rte_mempool *mp)
{
/* check cache size consistency */
unsigned lcore_id;
+
+ if (mp->cache_size == 0)
+ return;
+
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
if (mp->local_cache[lcore_id].len > mp->cache_flushthresh) {
RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
@@ -770,10 +768,6 @@ mempool_audit_cache(const struct rte_mempool *mp)
}
}
}
-#else
-#define mempool_audit_cache(mp) do {} while(0)
-#endif
-
/* check the consistency of mempool (size, cookies, ...) */
void
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 6e2390a..434ef98 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -95,7 +95,6 @@ struct rte_mempool_debug_stats {
} __rte_cache_aligned;
#endif
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/**
* A structure that stores a per-core object cache.
*/
@@ -107,7 +106,6 @@ struct rte_mempool_cache {
*/
void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
} __rte_cache_aligned;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/**
* A structure that stores the size of mempool elements.
@@ -194,10 +192,7 @@ struct rte_mempool {
unsigned private_data_size; /**< Size of private data. */
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
- /** Per-lcore local cache. */
- struct rte_mempool_cache local_cache[RTE_MAX_LCORE];
-#endif
+ struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
/** Per-lcore statistics. */
@@ -247,6 +242,13 @@ struct rte_mempool {
#endif
/**
+ * Size of elt_pa array size based on number of pages. (Internal use)
+ */
+#define __PA_SIZE(mp, pgn) \
+ RTE_ALIGN_CEIL((((pgn) - RTE_DIM((mp)->elt_pa)) * \
+ sizeof((mp)->elt_pa[0])), RTE_CACHE_LINE_SIZE)
+
+/**
* Calculate the size of the mempool header.
*
* @param mp
@@ -254,9 +256,9 @@ struct rte_mempool {
* @param pgn
* Number of pages used to store mempool objects.
*/
-#define MEMPOOL_HEADER_SIZE(mp, pgn) (sizeof(*(mp)) + \
- RTE_ALIGN_CEIL(((pgn) - RTE_DIM((mp)->elt_pa)) * \
- sizeof ((mp)->elt_pa[0]), RTE_CACHE_LINE_SIZE))
+#define MEMPOOL_HEADER_SIZE(mp, pgn, cs) \
+ (sizeof(*(mp)) + __PA_SIZE(mp, pgn) + (((cs) == 0) ? 0 : \
+ (sizeof(struct rte_mempool_cache) * RTE_MAX_LCORE)))
/**
* Return true if the whole mempool is in contiguous memory.
@@ -755,19 +757,16 @@ static inline void __attribute__((always_inline))
__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n, int is_mp)
{
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index;
void **cache_objs;
unsigned lcore_id = rte_lcore_id();
uint32_t cache_size = mp->cache_size;
uint32_t flushthresh = mp->cache_flushthresh;
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* increment stat now, adding in mempool always success */
__MEMPOOL_STAT_ADD(mp, put, n);
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
/* cache is not enabled or single producer or non-EAL thread */
if (unlikely(cache_size == 0 || is_mp == 0 ||
lcore_id >= RTE_MAX_LCORE))
@@ -802,7 +801,6 @@ __mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
return;
ring_enqueue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* push remaining objects in ring */
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
@@ -946,7 +944,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
unsigned n, int is_mc)
{
int ret;
-#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index, len;
void **cache_objs;
@@ -992,7 +989,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
return 0;
ring_dequeue:
-#endif /* RTE_MEMPOOL_CACHE_MAX_SIZE > 0 */
/* get remaining objects from ring */
if (is_mc)
@@ -1293,7 +1289,8 @@ void rte_mempool_audit(const struct rte_mempool *mp);
*/
static inline void *rte_mempool_get_priv(struct rte_mempool *mp)
{
- return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num);
+ return (char *)mp +
+ MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size);
}
/**
--
2.7.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags
@ 2016-02-02 22:59 3% Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Thomas Monjalon @ 2016-02-02 22:59 UTC (permalink / raw)
To: david.marchand, ferruh.yigit; +Cc: dev, viktorin
Following the work of Ferruh, I suggest this cleanup to remove as much
as possible of the code from the cpuflags headers.
The goal is to un-inline these functions (not performance sensitive)
and remove the CPU flags table from the ABI (just added recently).
The bonus is to stop mimic x86 in ARM and PPC implementations.
WARNING: it has not been tested nor compiled on Tilera, ARM and POWER8.
Please help, thank you.
Thomas Monjalon (5):
eal: get CPU flag name
eal: move CPU flag functions out of headers
eal/arm: adapt CPU flags check to the arch
eal/ppc: adapt CPU flags check to the arch
eal: remove compiler optimization workaround
app/test/test_hash_scaling.c | 2 +
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 170 ++++++++++++++++-----
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 145 +++++++++++++-----
lib/librte_eal/common/arch/tile/rte_cpuflags.c | 11 ++
lib/librte_eal/common/arch/x86/rte_cpuflags.c | 91 +++++++++++
lib/librte_eal/common/eal_common_cpuflags.c | 18 +--
.../common/include/arch/arm/rte_cpuflags_32.h | 78 ----------
.../common/include/arch/arm/rte_cpuflags_64.h | 79 ----------
.../common/include/arch/ppc_64/rte_cpuflags.h | 64 --------
.../common/include/arch/tile/rte_cpuflags.h | 29 ----
.../common/include/arch/x86/rte_cpuflags.h | 66 --------
.../common/include/generic/rte_cpuflags.h | 56 ++-----
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +-
14 files changed, 364 insertions(+), 450 deletions(-)
--
2.5.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-02-01 16:47 3% ` David Harton (dharton)
2016-02-01 21:23 0% ` Matthew Hall
@ 2016-02-02 11:40 3% ` Van Haaren, Harry
1 sibling, 0 replies; 200+ results
From: Van Haaren, Harry @ 2016-02-02 11:40 UTC (permalink / raw)
To: 'David Harton (dharton)', Thomas Monjalon; +Cc: dev
+John,
> From: David Harton
> Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> Hi folks,
>
> I didn't see any follow up to this response.
I think you may have missed one:
http://dpdk.org/ml/archives/dev/2016-January/032211.html
> <snip>
> However, if modifying that API is not desired then I'd
> really like to have some feedback about extending the current xstats model.
API / ABI modification/breakage is something that will
need to be considered in any discussions. The 2.3 (or 16.04)
V1 patch deadline has passed, so any output from this
discussion will be leading to the 16.07 release.
> Again, it is desired not to have to copy and/or parse strings for scalability reasons but
> still maintain the "ABI flexibility" for which the xstats model was geared towards.
Agreed.
From: David Harton
> enum rte_eth_stat_e {
> /* accurate desc #1 */
> RTE_ETH_STAT_1,
> /* accurate desc #2 */
> RTE_ETH_STAT_2,
> ...
> }
For this enum, do you see each stat for every PMD entered here?
RX_GOOD_PACKETS,
What about RX and TX, is it listed twice?
RX_GOOD_PACKETS,
TX_GOOD_PACKETS,
In a case where a VF has RX_GOOD_PACKETS, does it get its "own" set?
RX_GOOD_PACKETS,
TX_GOOD_PACKETS,
VF_RX_GOOD_PACKETS,
VF_TX_GOOD_PACKETS,
I'm looking at the enum thinking it will grow out of control.
Have you thought about adding metadata for RX / TX, PF / VF?
If metadata info is added, it would make retrieving a set of
statistics based on a certain mask much easier. Do you think
this may be of use?
-Harry
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] rings PMD detaching
@ 2016-02-02 5:41 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2016-02-02 5:41 UTC (permalink / raw)
To: Mauricio Vásquez; +Cc: dev, Jan Viktorin
Hello Mauricio,
On Tue, Feb 2, 2016 at 2:37 AM, Mauricio Vásquez
<mauricio.vasquezbernal@studenti.polito.it> wrote:
> I was wondering if there were a way to detach (delete) a ring pmd device
> created with rte_eth_from_rings. I realized that rte_eth_dev_detach does
> not work in this case because there is a comparison between the device's
> name and the driver's name in rte_eal_vdev_uninit, then devices created
> with arbitrary names can not be uninitialized.
I would say this is the same problem than what I observed in pci code.
Doing a "driver" lookup on detach is useless (and buggy in your case),
eal should just reuse the driver that the device had been attached to.
The problem is that, for vdev, the driver is not stored in a device
object at attach time, since there is no device object.
> My question is how to implement it?, I have two ideas on mind:
> - make rte_pmd_ring_devuninit a public function, then the user can call
> this using as argument the name of the device.
Having something like this enter abi, because of a bug in eal, does
not sound like a good idea.
> - modify rte_eal_vdev_uninit in such a way that there is not any comparison
> based on the dev name, probably it will require to add some extra field in
> the rte_eth_dev structure to distinguish between the different virtual
> devices.
No, the problem lies in eal where resources are bound to drivers.
No reason to pollute ethdev (we have enough workarounds in it ;-)).
This driver lookup should just go away.
If we had the rte_device I described [1], this kind of issues would disappear.
[1] http://dpdk.org/ml/archives/dev/2016-January/031390.html
Regards,
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-02-01 16:47 3% ` David Harton (dharton)
@ 2016-02-01 21:23 0% ` Matthew Hall
2016-02-02 11:40 3% ` Van Haaren, Harry
1 sibling, 0 replies; 200+ results
From: Matthew Hall @ 2016-02-01 21:23 UTC (permalink / raw)
To: David Harton (dharton); +Cc: dev
On Mon, Feb 01, 2016 at 04:47:56PM +0000, David Harton (dharton) wrote:
> Hi folks,
>
> I didn't see any follow up to this response.
>
> My original concern was rte_eth_stats_get() moving away from a more
> conventional based definition (note, I believe Matthew Hall made an
> interesting suggestion to follow a MIB based definition elsewhere).
> However, if modifying that API is not desired then I'd really like to have
> some feedback about extending the current xstats model.
>
> Again, it is desired not to have to copy and/or parse strings for
> scalability reasons but still maintain the "ABI flexibility" for which the
> xstats model was geared towards.
>
> Thanks,
> Dave
For me, I'd like to be able to get the core common stats in single memory
blocks which are as self-consistent and atomic as possible.
I'd prefer to only resort to stuff like xstats using some kind of
string-to-number lookup at the beginning, and only for weird stuff not the
common MIB-like items.
>From past experience this would be very valuable.
Matthew.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
@ 2016-02-01 16:47 3% ` David Harton (dharton)
2016-02-01 21:23 0% ` Matthew Hall
2016-02-02 11:40 3% ` Van Haaren, Harry
0 siblings, 2 replies; 200+ results
From: David Harton (dharton) @ 2016-02-01 16:47 UTC (permalink / raw)
To: Van Haaren, Harry, Thomas Monjalon; +Cc: dev
Hi folks,
I didn't see any follow up to this response.
My original concern was rte_eth_stats_get() moving away from a more conventional based definition (note, I believe Matthew Hall made an interesting suggestion to follow a MIB based definition elsewhere). However, if modifying that API is not desired then I'd really like to have some feedback about extending the current xstats model.
Again, it is desired not to have to copy and/or parse strings for scalability reasons but still maintain the "ABI flexibility" for which the xstats model was geared towards.
Thanks,
Dave
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Harton (dharton)
> Sent: Friday, January 22, 2016 2:26 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>; Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> > > > Do you see a fundamental problem with parsing the strings to
> > > > retrieve values?
> > >
> > > I think parsing strings is expensive CPU wise
> >
> > Parsing the strings can be done once at startup, and the index of the
> > statistics in the array cached. When actually reading statistics,
> > access of the array of statistics at the previously cached index will
> > return the same statistic. It is not needed to do strcmp() per statistic
> per read.
>
> How is this order guaranteed through the API? The stat is currently
> identified by the string not by order returned. What if a driver returns
> more/less stats based on config that changes after boot?
>
> >
> >
> > > That's why I was wondering if a binary id could be generated instead.
> >
> > I've worked with such a system before, it dynamically registered
> > string-
> > >int mappings at runtime, and allowed "reverse" mapping them too. Its
> > workable, and I'm not opposed to it if the conclusion is that it
> > really is necessary, but I'm not sure about that.
> >
> >
> > > The API
> > > would be very similar to the current xstats API except it would pass
> > > id/value pairs instead of string/value pairs. This avoids string
> > > comparisons to figure out while still allowing flexibility between
> > drivers.
> >
> > Apart from a once-off scan at startup, xstats achieves this.
>
> Partially true. You may not need to perform strcmp() per read, although I
> don't believe the defined API guarantees that this would be safe (see
> above); but, you still have to perform a strcpy() of each stat whether the
> caller is interested in it or not.
>
> >
> >
> > > It would also 100% guarantee that any strings returned by "const
> > > char* rte_eth_xstats_str_get(uint32_t stat_id)" are consistent
> > > across devices.
> >
> > Yes - that is a nice feature that xstats (in its current form) doesn't
> > have.
> > But what price is there to pay for this?
> > We need to map an ID for each stat that exists.
> >
> > How and where will this mapping happen? Perhaps would you expand a
> > little on how you see this working?
>
> I wasn't thinking dynamic registration as that might be more than
> necessary. I can code up a detailed snippet that shares the idea if
> wanted but I think the following communicates the basic idea:
>
> enum rte_eth_stat_e {
> /* accurate desc #1 */
> RTE_ETH_STAT_1,
> /* accurate desc #2 */
> RTE_ETH_STAT_2,
> ...
> }
> struct rte_eth_id_stat {
> rte_eth_stat_e id;
> uin64_t value;
> }
>
> int rte_eth_id_stats_num(uint8_t port_id, uint32_t *num_stats);
> /* returns < 0 on error or the number of stats that could have been read
> (i.e. if userd */ int rte_eth_id_stats_get(uint8_t port_id, uint32_t
> num_stats, rte_eth_id_stat *id_stats); const char*
> rte_eth_id_stat_str(rte_eth_stat_e id);
>
> This allows a driver to return whatever stats that it supports in a
> consistent manner and also in a performance friendly way. In fact, the
> driver side would be identical to what they have today but instead of
> having arrays with "string stat name" they will have the rte_eth_stat_e.
>
> >
> > > I also think there is less chance for error if drivers assign their
> > > stats to ID versus constructing a string.
> >
> > Have a look in how the mapping is done in the xstats implementation
> > for ixgbe for example:
> > http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_ethdev.c#n540
> >
> > It's a pretty simple {"string stat name" -> offsetof( stuct hw,
> > register_var_name )}
>
> It's not how they add the strings but rather the format of the string
> itself that is error prone.
> IOTW, the "string stat name" is prone to not being formatted correctly or
> consistently.
>
> >
> >
> > > I haven't checked my application, but I wonder if the binary size
> > > would actually be smaller if all the stats strings were centrally
> > > located versus distributed across binaries (highly dependent on the
> > linker and optimization level).
> >
> > Sounds like optimizing the wrong thing to me.
>
> Wasn't trying to optimize image size as much as saying it's a side benefit
> due to string consolidation.
>
> >
> >
> > > > If you like I could code up a minimal sample-app that only pulls
> > > > statistics, and you can show "interest" in various statistics for
> > > > printing / monitoring?
> > >
> > > Appreciate the offer. I actually understand what's is available.
> > > And, BTW, I apologize for being late to the game (looks like this
> > > was discussed last summer) but I'm just now getting looped in and
> > > following the mailer but I'm just wondering if something that is
> > performance friendly for the user/application and flexible for the
> > drivers is possible.
> >
> > We're all looking for the same thing - just different approaches
> > that's all :)
> >
> >
> > RE: Thomas asking about performance numbers:
> > I can scrape together some raw tsc data on Monday and post to list,
> > and we can discuss it more then.
>
> I can do the same if desired. But, just to make sure we are discussing
> the same issue:
>
> 1) call rte_eth_xtats_get()
> This will result in many string copies and depending on the driver *many*
> copies I don't want or care about.
> 2) "tokenize"/parse/hash the string returned to identify what the stat
> actually is I'm guessing you are stating that this step could be mitigated
> at startup. But, again, I don't think the API provides a guarantee which
> usually leads to bugs over time.
> 3) Copy the value of the stat into the driver agnostic container the
> application uses
> 4) Repeat steps 1-3 for every interface being serviced every 5 or 10 secs
>
> Contrast that to my suggestion which has no string copies and a compile
> time mapping between "stat_id" and "app stat" can be created for step 2.
> I think the performance differences are obvious even without generating
> cycle times.
>
> I know that dpdk is largely focused on data plane performance and rightly
> so, but, I'm hoping we can keep the control plane in mind as well
> especially in the areas around stats or things that happen periodically
> per port.
>
> Regards,
> Dave
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1] doc: add example text to release notes
@ 2016-02-01 15:24 9% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2016-02-01 15:24 UTC (permalink / raw)
To: dev
Added example text to each of the release notes sections to show
the preferred format.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
This is a little late since there are already several release note
submissions but I'd like to add some guidance on what the release
notes should look like to, hopefully, make the final edit easier.
doc/guides/rel_notes/release_2_3.rst | 75 ++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2cb04c0 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -1,13 +1,61 @@
DPDK Release 2.3
================
+
+** Read this first **
+
+The text below explains how to update the release notes.
+
+Use proper spelling, capitalization and punctuation in all sections.
+
+Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
+
+Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+
+ firefox build/doc/html/guides/rel_notes/release_2_3.html
+
+
New Features
------------
+This section should contain new features added in this release. Sample format:
+
+
+* **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense. The description
+ should be enough to allow someone scanning the release notes to understand
+ the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list like
+ this.
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
Resolved Issues
---------------
+This section should contain bug fixes added to the relevant sections. Sample
+format:
+
+
+* **code/section Fixed issue in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description of the resolved issue in the past
+ tense. The title should contain the code/lib section like a commit
+ message. Add the entries in alphabetic order in the relevant sections
+ below.
+
+
EAL
~~~
@@ -32,17 +80,44 @@ Known Issues
------------
+This section should contain new known issues in this release. Sample format:
+
+
+* **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue in the present
+ tense. Add information on any known workarounds.
+
+
+
API Changes
-----------
+This section should contain API changes. Sample format:
+
+
+* Add a short 1-2 sentence description of the API change. Use fixed width
+ quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
+ tense.
+
+
+
ABI Changes
-----------
+* Add a short 1-2 sentence description of the ABI change that was announced in
+ the previous releases and made in this release. Use fixed width quotes for
+ ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
Shared Library Versions
-----------------------
+Update any library version updated in this release and prepend with a ``+``
+sign.
+
The libraries prepended with a plus sign were incremented in this version.
.. code-block:: diff
--
2.5.0
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2] ethdev: fix byte order inconsistence between fdir flow and mask
2016-01-27 8:37 3% [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask Jingjing Wu
2016-01-27 9:19 0% ` Thomas Monjalon
@ 2016-02-01 2:48 3% ` Jingjing Wu
1 sibling, 0 replies; 200+ results
From: Jingjing Wu @ 2016-02-01 2:48 UTC (permalink / raw)
To: dev
Fixed issue of byte order in ethdev library that the structure
for setting fdir's mask and flow entry is inconsist and made
inputs of mask be in big endian.
Fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
Fixes: 2d4c1a9ea2ac ("ethdev: add new flow director masks")
Reported-by: Yaacov Hazan <yaacovh@mellanox.com>
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
v2 changes:
fix typo and reword API doc.
app/test-pmd/cmdline.c | 6 ++---
doc/guides/rel_notes/release_2_3.rst | 6 +++++
drivers/net/ixgbe/ixgbe_fdir.c | 47 ++++++++++++++++++++++--------------
lib/librte_ether/rte_eth_ctrl.h | 17 ++++++++++---
4 files changed, 51 insertions(+), 25 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..13194c9 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8687,13 +8687,13 @@ cmd_flow_director_mask_parsed(void *parsed_result,
return;
}
- mask->vlan_tci_mask = res->vlan_mask;
+ mask->vlan_tci_mask = rte_cpu_to_be_16(res->vlan_mask);
IPV4_ADDR_TO_UINT(res->ipv4_src, mask->ipv4_mask.src_ip);
IPV4_ADDR_TO_UINT(res->ipv4_dst, mask->ipv4_mask.dst_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_src, mask->ipv6_mask.src_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_dst, mask->ipv6_mask.dst_ip);
- mask->src_port_mask = res->port_src;
- mask->dst_port_mask = res->port_dst;
+ mask->src_port_mask = rte_cpu_to_be_16(res->port_src);
+ mask->dst_port_mask = rte_cpu_to_be_16(res->port_dst);
}
cmd_reconfig_device_queue(res->port_id, 1, 1);
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..77e4edd 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -19,6 +19,10 @@ Drivers
Libraries
~~~~~~~~~
+* ** fix byte order inconsistence between fdir flow and mask **
+
+ Fixed issue in ethdev library that the structure for setting
+ fdir's mask and flow entry is inconsist in byte order.
Examples
~~~~~~~~
@@ -39,6 +43,8 @@ API Changes
ABI Changes
-----------
+* The fields in ethdev structure ``rte_eth_fdir_masks`` were
+ changed to be in big endian.
Shared Library Versions
-----------------------
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index e03219b..2c874b1 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -309,6 +309,7 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
uint32_t fdiripv6m; /* IPv6 source and destination masks. */
uint16_t dst_ipv6m = 0;
uint16_t src_ipv6m = 0;
+ volatile uint32_t *reg;
PMD_INIT_FUNC_TRACE();
@@ -322,16 +323,16 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
/* use the L4 protocol mask for raw IPv4/IPv6 traffic */
fdirm |= IXGBE_FDIRM_L4P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -340,19 +341,26 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
IXGBE_WRITE_REG(hw, IXGBE_FDIRM, fdirm);
/* store the TCP/UDP port masks, bit reversed from port layout */
- fdirtcpm = reverse_fdir_bitmasks(input_mask->dst_port_mask,
- input_mask->src_port_mask);
+ fdirtcpm = reverse_fdir_bitmasks(
+ rte_be_to_cpu_16(input_mask->dst_port_mask),
+ rte_be_to_cpu_16(input_mask->src_port_mask));
- /* write all the same so that UDP, TCP and SCTP use the same mask */
+ /* write all the same so that UDP, TCP and SCTP use the same mask
+ * (little-endian)
+ */
IXGBE_WRITE_REG(hw, IXGBE_FDIRTCPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRUDPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRSCTPM, ~fdirtcpm);
info->mask.src_port_mask = input_mask->src_port_mask;
info->mask.dst_port_mask = input_mask->dst_port_mask;
- /* Store source and destination IPv4 masks (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRSIP4M, ~(input_mask->ipv4_mask.src_ip));
- IXGBE_WRITE_REG(hw, IXGBE_FDIRDIP4M, ~(input_mask->ipv4_mask.dst_ip));
+ /* Store source and destination IPv4 masks (big-endian),
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRSIP4M);
+ *reg = ~(input_mask->ipv4_mask.src_ip);
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRDIP4M);
+ *reg = ~(input_mask->ipv4_mask.dst_ip);
info->mask.src_ipv4_mask = input_mask->ipv4_mask.src_ip;
info->mask.dst_ipv4_mask = input_mask->ipv4_mask.dst_ip;
@@ -401,16 +409,16 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
/* some bits must be set for mac vlan or tunnel mode */
fdirm |= IXGBE_FDIRM_L4P | IXGBE_FDIRM_L3P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -444,7 +452,7 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
info->mask.tunnel_type_mask =
input_mask->tunnel_type_mask;
- switch (input_mask->tunnel_id_mask & 0xFFFFFFFF) {
+ switch (rte_be_to_cpu_32(input_mask->tunnel_id_mask)) {
case 0x0:
/* Mask vxlan id */
fdiripv6m |= IXGBE_FDIRIP6M_TNI_VNI;
@@ -904,13 +912,16 @@ fdir_write_perfect_filter_82599(struct ixgbe_hw *hw,
u32 addr_low, addr_high;
u32 tunnel_type = 0;
int err = 0;
+ volatile uint32_t *reg;
if (mode == RTE_FDIR_MODE_PERFECT) {
- /* record the IPv4 address (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPSA,
- input->formatted.src_ip[0]);
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPDA,
- input->formatted.dst_ip[0]);
+ /* record the IPv4 address (big-endian)
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPSA);
+ *reg = input->formatted.src_ip[0];
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPDA);
+ *reg = input->formatted.dst_ip[0];
/* record source and destination port (little-endian)*/
fdirport = IXGBE_NTOHS(input->formatted.dst_port);
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..d433e0b 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -501,6 +501,7 @@ struct rte_eth_tunnel_flow {
/**
* An union contains the inputs for all types of flow
+ * Items in flows need to be in big endian
*/
union rte_eth_fdir_flow {
struct rte_eth_l2_flow l2_flow;
@@ -588,14 +589,22 @@ struct rte_eth_fdir_filter {
* to match the various fields of RX packet headers.
*/
struct rte_eth_fdir_masks {
- uint16_t vlan_tci_mask;
+ uint16_t vlan_tci_mask; /**< Bit mask for vlan_tci in big endian */
+ /** Bit mask for ipv4 flow in big endian. */
struct rte_eth_ipv4_flow ipv4_mask;
+ /** Bit maks for ipv6 flow in big endian. */
struct rte_eth_ipv6_flow ipv6_mask;
+ /** Bit mask for L4 source port in big endian. */
uint16_t src_port_mask;
+ /** Bit mask for L4 destination port in big endian. */
uint16_t dst_port_mask;
- uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
- uint32_t tunnel_id_mask; /** tunnel ID mask */
- uint8_t tunnel_type_mask;
+ /** 6 bit mask for proper 6 bytes of Mac address, bit 0 matches the
+ first byte on the wire */
+ uint8_t mac_addr_byte_mask;
+ /** Bit mask for tunnel ID in big endian. */
+ uint32_t tunnel_id_mask;
+ uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
+ 0 - Ignore tunnel type. */
};
/**
--
2.4.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port
2016-01-28 11:54 4% ` Panu Matilainen
@ 2016-01-29 15:10 4% ` Zhang, Roy Fan
0 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2016-01-29 15:10 UTC (permalink / raw)
To: Panu Matilainen, dev
Hi Panu,
Thank you for the careful review and comments.
On 28/01/2016 11:54, Panu Matilainen wrote:
> On 01/27/2016 07:39 PM, Fan Zhang wrote:
>> Originally, source ports in librte_port is an input port used as packet
>> generator. Similar to Linux kernel /dev/zero character device, it
>> generates null packets. This patch adds optional PCAP file support to
>> source port: instead of sending NULL packets, the source port generates
>> packets copied from a PCAP file. To increase the performance, the
>> packets
>> in the file are loaded to memory initially, and copied to mbufs in
>> circular
>> manner. Users can enable or disable this feature by setting
>> CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
>>
>> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
>> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
>> ---
>> config/common_bsdapp | 1 +
>> config/common_linuxapp | 1 +
>> lib/librte_port/Makefile | 4 +
>> lib/librte_port/rte_port_source_sink.c | 190
>> +++++++++++++++++++++++++++++++++
>> lib/librte_port/rte_port_source_sink.h | 7 ++
>> mk/rte.app.mk | 1 +
>> 6 files changed, 204 insertions(+)
>>
> [...]
>> +#ifdef RTE_PORT_PCAP
>> +
>> +/**
>> + * Load PCAP file, allocate and copy packets in the file to memory
>> + *
>> + * @param p
>> + * Parameters for source port
>> + * @param port
>> + * Handle to source port
>> + * @param socket_id
>> + * Socket id where the memory is created
>> + * @return
>> + * 0 on SUCCESS
>> + * error code otherwise
>> + */
>> +static int
>> +pcap_source_load(struct rte_port_source_params *p,
>> + struct rte_port_source *port,
>> + int socket_id)
>> +{
> [...]
>> +#else
>> +static int
>> +pcap_source_load(__rte_unused struct rte_port_source_params *p,
>> + struct rte_port_source *port,
>> + __rte_unused int socket_id)
>> +{
>> + port->pkt_buff = NULL;
>> + port->pkt_len = NULL;
>> + port->pkts = NULL;
>> + port->pkt_index = 0;
>> +
>> + return 0;
>> +}
>> +#endif
>
> Same as in patch 3/4, shouldn't this return -ENOTSUP when pcap support
> is not built in, instead of success?
Thank you for the suggestion. I will make the change in V2.
> [...]
>
>> diff --git a/lib/librte_port/rte_port_source_sink.h
>> b/lib/librte_port/rte_port_source_sink.h
>> index 0f9be79..6f39bec 100644
>> --- a/lib/librte_port/rte_port_source_sink.h
>> +++ b/lib/librte_port/rte_port_source_sink.h
>> @@ -53,6 +53,13 @@ extern "C" {
>> struct rte_port_source_params {
>> /** Pre-initialized buffer pool */
>> struct rte_mempool *mempool;
>> + /** The full path of the pcap file to read packets from */
>> + char *file_name;
>> + /** The number of bytes to be read from each packet in the
>> + * pcap file. If this value is 0, the whole packet is read;
>> + * if it is bigger than packet size, the generated packets
>> + * will contain the whole packet */
>> + uint32_t n_bytes_per_pkt;
>> };
>
> This is a likely ABI-break. It "only" appends to the struct, which
> might in some cases be okay but only when there's no sensible use for
> the struct within arrays or embedded in structs. The ip_pipeline
> example for example embeds struct rte_port_source_params within
> another struct which is could be thought of as an indication that
> other applications might be doing this as well.
>
> An ABI break for librte_port has not been announced for 2.3 so you'd
> need to announce the intent to do so in 2.4 now, and then either wait
> till post 2.3 or wrap this in CONFIG_RTE_NEXT_ABI.
> - Panu -
Before Submitting the patch I have run validate-abi script, the
validation results showed "compatible" on all libraries.
Also, the patch's added line in the rte_port_source_sink.c was ensured
that, if the CONFIG_RTE_PORT_PCAP compiler option is set to "n" (by
default), the added read-only elements in the new rte_source_params
structure won't be touched.
CONFIG_RTE_PORT_PCAP compiler option lies in config/comm_bsdapp and
config/com_linuxapp, and is freshly added in this patch.
If an application is built on top of latest release version of
rte_port_source_sink library, it shall work fine with the new library if
the new CONFIG_RTE_PORT_PCAP opition is left the default "n".
ip_pipeline example works fine this way.
I hope this changes your mind on breaking the ABI.
Best regards,
Fan
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-29 10:10 3% ` Panu Matilainen
@ 2016-01-29 12:47 0% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-29 12:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ziye Yang
On 01/29/2016 12:10 PM, Panu Matilainen wrote:
> On 01/29/2016 11:34 AM, Thomas Monjalon wrote:
>> 2016-01-29 11:21, Panu Matilainen:
>>> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
>>>> 2016-01-13 14:22, Panu Matilainen:
>>>>> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
>>>>>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>>>>>>> On Tue, 29 Dec 2015 10:53:26 +0800
>>>>>>> Ziye Yang <ziye.yang@intel.com> wrote:
>>>>>>>
>>>>>>>> This patch is used to add the class_id support
>>>>>>>> for pci_probe since some devices need the class_info
>>>>>>>> (class_code, subclass_code, programming_interface)
>>>>>>>>
>>>>>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>>>>>>
>>>>>>> Since rte_pci is exposed to application this breaks the ABI.
>>>>>>
>>>>>> But applications are not going to be defining rte_pci_ids values
>>>>>> internally, are
>>>>>> they? That is for drivers to use. Is this really an ABI breakage
>>>>>> for applications that we
>>>>>> need to be concerned about?
>>>>>
>>>>> There might not be applications using it but drivers are ABI consumers
>>>>> too - think of 3rd party drivers and such.
>>>>
>>>> Drivers are not ABI consumers in the sense that ABI means
>>>> Application Binary Interface.
>>>> We are talking about drivers interface here.
>>>> When establishing the ABI policy we were discussing about
>>>> applications only.
>>>
>>> Generally speaking an ABI is an interface between two program (or
>>> software if you like) modules, its not specific to "applications".
>>> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
>>> it does only talk about applications, but an ABI consumer can also be
>>> another library. A driver calling rte_malloc() is just as much
>>> librte_eal ABI consumer as anything else.
>>>
>>> Now, I understand that drivers use and need interface(s) that
>>> applications have no use for or simply cannot use, and those interfaces
>>> could be subject to different policies. As an extreme example, the Linux
>>> kernel has two isolated ABIs, one is the userland system call interface
>>> which is guaranteed to stay forever and the other is kernel module
>>> interface, guarantees nothing at all.
>>>
>>> In DPDK the difference is far muddier than that since all the interfaces
>>> live in common, versioned userland DSOs. So if there are two different
>>> interfaces following two different policies, it's all the more important
>>> to clearly document them. One simple way could be using a different
>>> prefix than rte_.
>>
>> Good suggestion. Or we can simply have different files with a clear
>> notice
>> in their headers and in the versioning doc.
>> It was well split in rte_cryptodev_pmd.h
>
> Using separate headers is also good. Optimally both? :)
>
>>>> I agree we must allow 3rd party drivers but there is no good reason
>>>> to try to upgrade DPDK without upgrading/porting the external drivers.
>>>> If someone does not want to release its driver and keep upgrading DPDK,
>>>> it is acceptable IMHO to force an upgrade of its driver.
>>>
>>> Note that I've no particular sympathy for 3rd party drivers as such.
>>> What I *do* care about is that breakage is made explicit, as in drivers
>>> built for an incompatible version refuse to load at all, instead of
>>> silently corrupting memory etc.
>>
>> OK I agree.
>
> Cool, the rest is just details then.
>
>> Anyway the ABI versionning does not cover the structure changes.
>> What about making a DPDK version check when registering a driver?
>> So a binary driver would be clearly bound to a DPDK version.
>
> That's one possibility. Another way to achieve essentially the same is
> to make rte_eal_driver_register() symbol version follow the DPDK
> version, in which case a driver built for another version will fail at
> dlopen() already.
Thinking about this a bit more, symbol versioning doesn't cut it because
its not always used (static linkakage) and I guess we should cover that too.
Another similar possibility that blocks it at dlopen() level is to munge
the actual function name to carry a version, so it becomes something
like rte_eal_driver_register_v230() and later _v240() etc. AFAICS its
only ever invoked via PMD_REGISTER_DRIVER() so the calling details can
conveniently be hidden there.
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-29 9:34 3% ` Thomas Monjalon
@ 2016-01-29 10:10 3% ` Panu Matilainen
2016-01-29 12:47 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-29 10:10 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ziye Yang
On 01/29/2016 11:34 AM, Thomas Monjalon wrote:
> 2016-01-29 11:21, Panu Matilainen:
>> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
>>> 2016-01-13 14:22, Panu Matilainen:
>>>> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
>>>>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>>>>>> On Tue, 29 Dec 2015 10:53:26 +0800
>>>>>> Ziye Yang <ziye.yang@intel.com> wrote:
>>>>>>
>>>>>>> This patch is used to add the class_id support
>>>>>>> for pci_probe since some devices need the class_info
>>>>>>> (class_code, subclass_code, programming_interface)
>>>>>>>
>>>>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>>>>>
>>>>>> Since rte_pci is exposed to application this breaks the ABI.
>>>>>
>>>>> But applications are not going to be defining rte_pci_ids values internally, are
>>>>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
>>>>> need to be concerned about?
>>>>
>>>> There might not be applications using it but drivers are ABI consumers
>>>> too - think of 3rd party drivers and such.
>>>
>>> Drivers are not ABI consumers in the sense that ABI means
>>> Application Binary Interface.
>>> We are talking about drivers interface here.
>>> When establishing the ABI policy we were discussing about applications only.
>>
>> Generally speaking an ABI is an interface between two program (or
>> software if you like) modules, its not specific to "applications".
>> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
>> it does only talk about applications, but an ABI consumer can also be
>> another library. A driver calling rte_malloc() is just as much
>> librte_eal ABI consumer as anything else.
>>
>> Now, I understand that drivers use and need interface(s) that
>> applications have no use for or simply cannot use, and those interfaces
>> could be subject to different policies. As an extreme example, the Linux
>> kernel has two isolated ABIs, one is the userland system call interface
>> which is guaranteed to stay forever and the other is kernel module
>> interface, guarantees nothing at all.
>>
>> In DPDK the difference is far muddier than that since all the interfaces
>> live in common, versioned userland DSOs. So if there are two different
>> interfaces following two different policies, it's all the more important
>> to clearly document them. One simple way could be using a different
>> prefix than rte_.
>
> Good suggestion. Or we can simply have different files with a clear notice
> in their headers and in the versioning doc.
> It was well split in rte_cryptodev_pmd.h
Using separate headers is also good. Optimally both? :)
>>> I agree we must allow 3rd party drivers but there is no good reason
>>> to try to upgrade DPDK without upgrading/porting the external drivers.
>>> If someone does not want to release its driver and keep upgrading DPDK,
>>> it is acceptable IMHO to force an upgrade of its driver.
>>
>> Note that I've no particular sympathy for 3rd party drivers as such.
>> What I *do* care about is that breakage is made explicit, as in drivers
>> built for an incompatible version refuse to load at all, instead of
>> silently corrupting memory etc.
>
> OK I agree.
Cool, the rest is just details then.
> Anyway the ABI versionning does not cover the structure changes.
> What about making a DPDK version check when registering a driver?
> So a binary driver would be clearly bound to a DPDK version.
That's one possibility. Another way to achieve essentially the same is
to make rte_eal_driver_register() symbol version follow the DPDK
version, in which case a driver built for another version will fail at
dlopen() already.
> And we should change or remove the .so version which never change for
> most of drivers.
Yup, so-versioning DSOs which do not offer any ABI is kinda pointless.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-29 9:21 4% ` Panu Matilainen
@ 2016-01-29 9:34 3% ` Thomas Monjalon
2016-01-29 10:10 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-29 9:34 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Ziye Yang
2016-01-29 11:21, Panu Matilainen:
> On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
> > 2016-01-13 14:22, Panu Matilainen:
> >> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> >>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> >>>> On Tue, 29 Dec 2015 10:53:26 +0800
> >>>> Ziye Yang <ziye.yang@intel.com> wrote:
> >>>>
> >>>>> This patch is used to add the class_id support
> >>>>> for pci_probe since some devices need the class_info
> >>>>> (class_code, subclass_code, programming_interface)
> >>>>>
> >>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> >>>>
> >>>> Since rte_pci is exposed to application this breaks the ABI.
> >>>
> >>> But applications are not going to be defining rte_pci_ids values internally, are
> >>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
> >>> need to be concerned about?
> >>
> >> There might not be applications using it but drivers are ABI consumers
> >> too - think of 3rd party drivers and such.
> >
> > Drivers are not ABI consumers in the sense that ABI means
> > Application Binary Interface.
> > We are talking about drivers interface here.
> > When establishing the ABI policy we were discussing about applications only.
>
> Generally speaking an ABI is an interface between two program (or
> software if you like) modules, its not specific to "applications".
> Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
> it does only talk about applications, but an ABI consumer can also be
> another library. A driver calling rte_malloc() is just as much
> librte_eal ABI consumer as anything else.
>
> Now, I understand that drivers use and need interface(s) that
> applications have no use for or simply cannot use, and those interfaces
> could be subject to different policies. As an extreme example, the Linux
> kernel has two isolated ABIs, one is the userland system call interface
> which is guaranteed to stay forever and the other is kernel module
> interface, guarantees nothing at all.
>
> In DPDK the difference is far muddier than that since all the interfaces
> live in common, versioned userland DSOs. So if there are two different
> interfaces following two different policies, it's all the more important
> to clearly document them. One simple way could be using a different
> prefix than rte_.
Good suggestion. Or we can simply have different files with a clear notice
in their headers and in the versioning doc.
It was well split in rte_cryptodev_pmd.h
> > I agree we must allow 3rd party drivers but there is no good reason
> > to try to upgrade DPDK without upgrading/porting the external drivers.
> > If someone does not want to release its driver and keep upgrading DPDK,
> > it is acceptable IMHO to force an upgrade of its driver.
>
> Note that I've no particular sympathy for 3rd party drivers as such.
> What I *do* care about is that breakage is made explicit, as in drivers
> built for an incompatible version refuse to load at all, instead of
> silently corrupting memory etc.
OK I agree.
Anyway the ABI versionning does not cover the structure changes.
What about making a DPDK version check when registering a driver?
So a binary driver would be clearly bound to a DPDK version.
And we should change or remove the .so version which never change for
most of drivers.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-28 21:38 4% ` Thomas Monjalon
@ 2016-01-29 9:21 4% ` Panu Matilainen
2016-01-29 9:34 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-29 9:21 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger; +Cc: dev, Ziye Yang
On 01/28/2016 11:38 PM, Thomas Monjalon wrote:
> 2016-01-13 14:22, Panu Matilainen:
>> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
>>> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>>>> On Tue, 29 Dec 2015 10:53:26 +0800
>>>> Ziye Yang <ziye.yang@intel.com> wrote:
>>>>
>>>>> This patch is used to add the class_id support
>>>>> for pci_probe since some devices need the class_info
>>>>> (class_code, subclass_code, programming_interface)
>>>>>
>>>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>>>
>>>> Since rte_pci is exposed to application this breaks the ABI.
>>>
>>> But applications are not going to be defining rte_pci_ids values internally, are
>>> they? That is for drivers to use. Is this really an ABI breakage for applications that we
>>> need to be concerned about?
>>
>> There might not be applications using it but drivers are ABI consumers
>> too - think of 3rd party drivers and such.
>
> Drivers are not ABI consumers in the sense that ABI means
> Application Binary Interface.
> We are talking about drivers interface here.
> When establishing the ABI policy we were discussing about applications only.
Generally speaking an ABI is an interface between two program (or
software if you like) modules, its not specific to "applications".
Looking at http://dpdk.org/doc/guides/contributing/versioning.html I see
it does only talk about applications, but an ABI consumer can also be
another library. A driver calling rte_malloc() is just as much
librte_eal ABI consumer as anything else.
Now, I understand that drivers use and need interface(s) that
applications have no use for or simply cannot use, and those interfaces
could be subject to different policies. As an extreme example, the Linux
kernel has two isolated ABIs, one is the userland system call interface
which is guaranteed to stay forever and the other is kernel module
interface, guarantees nothing at all.
In DPDK the difference is far muddier than that since all the interfaces
live in common, versioned userland DSOs. So if there are two different
interfaces following two different policies, it's all the more important
to clearly document them. One simple way could be using a different
prefix than rte_.
> I agree we must allow 3rd party drivers but there is no good reason
> to try to upgrade DPDK without upgrading/porting the external drivers.
> If someone does not want to release its driver and keep upgrading DPDK,
> it is acceptable IMHO to force an upgrade of its driver.
Note that I've no particular sympathy for 3rd party drivers as such.
What I *do* care about is that breakage is made explicit, as in drivers
built for an incompatible version refuse to load at all, instead of
silently corrupting memory etc.
- Panu -
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 4/5] doc: update with link changes
@ 2016-01-29 0:42 8% ` Marc Sune
1 sibling, 0 replies; 200+ results
From: Marc Sune @ 2016-01-29 0:42 UTC (permalink / raw)
To: dev, Wenzhuo Lu, Helin Zhang, Harish Patil, Jing Chen
Add new features, ABI changes and resolved issues notice for
the refactored link patch.
Signed-off-by: Marc Sune <marcdevel@gmail.com>
---
doc/guides/rel_notes/release_2_3.rst | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..b10c3bb 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,10 +4,28 @@ DPDK Release 2.3
New Features
------------
+* **ethdev: define a set of advertised link speeds.**
+
+ Allowing to define a set of advertised speeds for auto-negociation,
+ explicitely disable link auto-negociation (single speed) and full
+ auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+ define a set of advertised link speeds.**
+
+ ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+ application to recover the supported speeds for that ethernet device.
+
Resolved Issues
---------------
+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+ 100Gbps in Mbps (100000) exceeds 16 bit max value of ``link_speed`` in
+ ``rte_eth_link``.
+
+
EAL
~~~
@@ -23,6 +41,9 @@ Libraries
Examples
~~~~~~~~
+* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical speeds
+ to bitmap fields.
+
Other
~~~~~
@@ -39,6 +60,11 @@ API Changes
ABI Changes
-----------
+* The ethdev rte_eth_link and rte_eth_conf structures were changed to
+ support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+
Shared Library Versions
-----------------------
--
2.1.4
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-13 12:22 3% ` Panu Matilainen
@ 2016-01-28 21:38 4% ` Thomas Monjalon
2016-01-29 9:21 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-28 21:38 UTC (permalink / raw)
To: Panu Matilainen, Stephen Hemminger; +Cc: dev, Ziye Yang
2016-01-13 14:22, Panu Matilainen:
> On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> > On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> >> On Tue, 29 Dec 2015 10:53:26 +0800
> >> Ziye Yang <ziye.yang@intel.com> wrote:
> >>
> >>> This patch is used to add the class_id support
> >>> for pci_probe since some devices need the class_info
> >>> (class_code, subclass_code, programming_interface)
> >>>
> >>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> >>
> >> Since rte_pci is exposed to application this breaks the ABI.
> >
> > But applications are not going to be defining rte_pci_ids values internally, are
> > they? That is for drivers to use. Is this really an ABI breakage for applications that we
> > need to be concerned about?
>
> There might not be applications using it but drivers are ABI consumers
> too - think of 3rd party drivers and such.
Drivers are not ABI consumers in the sense that ABI means
Application Binary Interface.
We are talking about drivers interface here.
When establishing the ABI policy we were discussing about applications only.
I agree we must allow 3rd party drivers but there is no good reason
to try to upgrade DPDK without upgrading/porting the external drivers.
If someone does not want to release its driver and keep upgrading DPDK,
it is acceptable IMHO to force an upgrade of its driver.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC] Abi breakage for rte_mempool to reduce footprint
@ 2016-01-28 20:07 7% Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-28 20:07 UTC (permalink / raw)
To: dev
Hi Everyone,
Currently every mempool created has a footprint of 1.5Megs of memory just for the struct rte_mempool, this also includes all of the rte_pktmbuf creates as well. The issue is the local_cache adds about 1.5Megs of memory, which is a huge amount IMHO for non-cached based mempools. Without the local_cache the structure is about 192bytes. You can set the config option for the cache to ’n’, but then all allocations will not use the per core cache. I have some code I will send as a patch to have the local_cache allocated only when a mempool is created and the caller has a non-zero cache size set in the call.
This will break ABI for the struct rte_mempool, but does remove some of the ifdefs for RTE_MEMPOOL_CACHE_SIZE in the code. The performance appears to be the same, but will do some more testing before I submit the patch.
Please let me know if this would be reasonable or other comments.
Regards,
Keith
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [RFC] ABI breakage for rte_mempool to reduce footprint
@ 2016-01-28 19:02 7% Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-28 19:02 UTC (permalink / raw)
To: dev
Hi Everyone,
Currently every mempool created has a footprint of 1.5Megs of memory just for the struct rte_mempool, this also includes all of the rte_pktmbuf creates as well. The issue is the local_cache adds about 1.5Megs of memory, which is a huge amount IMHO for non-cached based mempools. Without the local_cache the structure is about 192bytes. You can set the config option for the cache to ’n’, but then all allocations will not use the per core cache. I have some code I will send as a patch to have the local_cache allocated only when a mempool is created and the caller has a non-zero cache size set in the call.
This will break ABI for the struct rte_mempool, but does remove some of the ifdefs for RTE_MEMPOOL_CACHE_SIZE in the code. The performance appears to be the same, but will do some more testing before I submit the patch.
Please let me know if this would be reasonable or other comments.
Regards,
Keith
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port
@ 2016-01-28 11:54 4% ` Panu Matilainen
2016-01-29 15:10 4% ` Zhang, Roy Fan
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-28 11:54 UTC (permalink / raw)
To: Fan Zhang, dev
On 01/27/2016 07:39 PM, Fan Zhang wrote:
> Originally, source ports in librte_port is an input port used as packet
> generator. Similar to Linux kernel /dev/zero character device, it
> generates null packets. This patch adds optional PCAP file support to
> source port: instead of sending NULL packets, the source port generates
> packets copied from a PCAP file. To increase the performance, the packets
> in the file are loaded to memory initially, and copied to mbufs in circular
> manner. Users can enable or disable this feature by setting
> CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> config/common_bsdapp | 1 +
> config/common_linuxapp | 1 +
> lib/librte_port/Makefile | 4 +
> lib/librte_port/rte_port_source_sink.c | 190 +++++++++++++++++++++++++++++++++
> lib/librte_port/rte_port_source_sink.h | 7 ++
> mk/rte.app.mk | 1 +
> 6 files changed, 204 insertions(+)
>
[...]
> +#ifdef RTE_PORT_PCAP
> +
> +/**
> + * Load PCAP file, allocate and copy packets in the file to memory
> + *
> + * @param p
> + * Parameters for source port
> + * @param port
> + * Handle to source port
> + * @param socket_id
> + * Socket id where the memory is created
> + * @return
> + * 0 on SUCCESS
> + * error code otherwise
> + */
> +static int
> +pcap_source_load(struct rte_port_source_params *p,
> + struct rte_port_source *port,
> + int socket_id)
> +{
[...]
> +#else
> +static int
> +pcap_source_load(__rte_unused struct rte_port_source_params *p,
> + struct rte_port_source *port,
> + __rte_unused int socket_id)
> +{
> + port->pkt_buff = NULL;
> + port->pkt_len = NULL;
> + port->pkts = NULL;
> + port->pkt_index = 0;
> +
> + return 0;
> +}
> +#endif
Same as in patch 3/4, shouldn't this return -ENOTSUP when pcap support
is not built in, instead of success?
[...]
> diff --git a/lib/librte_port/rte_port_source_sink.h b/lib/librte_port/rte_port_source_sink.h
> index 0f9be79..6f39bec 100644
> --- a/lib/librte_port/rte_port_source_sink.h
> +++ b/lib/librte_port/rte_port_source_sink.h
> @@ -53,6 +53,13 @@ extern "C" {
> struct rte_port_source_params {
> /** Pre-initialized buffer pool */
> struct rte_mempool *mempool;
> + /** The full path of the pcap file to read packets from */
> + char *file_name;
> + /** The number of bytes to be read from each packet in the
> + * pcap file. If this value is 0, the whole packet is read;
> + * if it is bigger than packet size, the generated packets
> + * will contain the whole packet */
> + uint32_t n_bytes_per_pkt;
> };
This is a likely ABI-break. It "only" appends to the struct, which might
in some cases be okay but only when there's no sensible use for the
struct within arrays or embedded in structs. The ip_pipeline example for
example embeds struct rte_port_source_params within another struct which
is could be thought of as an indication that other applications might be
doing this as well.
An ABI break for librte_port has not been announced for 2.3 so you'd
need to announce the intent to do so in 2.4 now, and then either wait
till post 2.3 or wrap this in CONFIG_RTE_NEXT_ABI.
- Panu -
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure
[not found] ` <1453976778-27807-1-git-send-email-xutao.sun@intel.com>
@ 2016-01-28 10:26 13% ` Xutao Sun
1 sibling, 0 replies; 200+ results
From: Xutao Sun @ 2016-01-28 10:26 UTC (permalink / raw)
To: dev
Change the fields of outer_mac and inner_mac from pointer to struct in order to keep the code's readability.
Signed-off-by: Xutao Sun <xutao.sun@intel.com>
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
app/test-pmd/cmdline.c | 6 ++++--
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_2_3.rst | 2 ++
drivers/net/i40e/i40e_ethdev.c | 12 ++++++------
lib/librte_ether/rte_eth_ctrl.h | 4 ++--
5 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6d28c1b..67df259 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6640,8 +6640,10 @@ cmd_tunnel_filter_parsed(void *parsed_result,
struct rte_eth_tunnel_filter_conf tunnel_filter_conf;
int ret = 0;
- tunnel_filter_conf.outer_mac = &res->outer_mac;
- tunnel_filter_conf.inner_mac = &res->inner_mac;
+ rte_memcpy(&tunnel_filter_conf.outer_mac, &res->outer_mac,
+ ETHER_ADDR_LEN);
+ rte_memcpy(&tunnel_filter_conf.inner_mac, &res->inner_mac,
+ ETHER_ADDR_LEN);
tunnel_filter_conf.inner_vlan = res->inner_vlan;
if (res->ip_value.family == AF_INET) {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..a895364 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,11 +32,6 @@ Deprecation Notices
RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
but release 2.3 will.
-* ABI changes are planned for rte_eth_tunnel_filter_conf. Change the fields
- of outer_mac and inner_mac from pointer to struct in order to keep the
- code's readability. The release 2.2 does not contain these ABI changes, but
- release 2.3 will, and no backwards compatibility is planned.
-
* The scheduler statistics structure will change to allow keeping track of
RED actions.
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..ee7fd48 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,8 @@ API Changes
ABI Changes
-----------
+* The fields of outer_mac and inner_mac were changed from pointer
+ to struct in order to keep the code's readability.
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..1dd1077 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5828,10 +5828,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
}
pfilter = cld_filter;
- (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac,
- sizeof(struct ether_addr));
- (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac,
- sizeof(struct ether_addr));
+ (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac,
+ ETHER_ADDR_LEN);
+ (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
+ ETHER_ADDR_LEN);
pfilter->inner_vlan = tunnel_filter->inner_vlan;
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
@@ -6131,13 +6131,13 @@ i40e_tunnel_filter_param_check(struct i40e_pf *pf,
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_OMAC) &&
- (is_zero_ether_addr(filter->outer_mac))) {
+ (is_zero_ether_addr(&filter->outer_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL outer MAC address");
return -EINVAL;
}
if ((filter->filter_type & ETH_TUNNEL_FILTER_IMAC) &&
- (is_zero_ether_addr(filter->inner_mac))) {
+ (is_zero_ether_addr(&filter->inner_mac))) {
PMD_DRV_LOG(ERR, "Cannot add NULL inner MAC address");
return -EINVAL;
}
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..30cbde7 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
* Tunneling Packet filter configuration.
*/
struct rte_eth_tunnel_filter_conf {
- struct ether_addr *outer_mac; /**< Outer MAC address filter. */
- struct ether_addr *inner_mac; /**< Inner MAC address filter. */
+ struct ether_addr outer_mac; /**< Outer MAC address filter. */
+ struct ether_addr inner_mac; /**< Inner MAC address filter. */
uint16_t inner_vlan; /**< Inner VLAN filter. */
enum rte_tunnel_iptype ip_type; /**< IP address type. */
union {
--
1.9.3
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH v2 1/4] lib/ether: optimize the 'rte_eth_tunnel_filter_conf' structure
@ 2016-01-28 9:05 3% ` Sun, Xutao
0 siblings, 0 replies; 200+ results
From: Sun, Xutao @ 2016-01-28 9:05 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hi, Thomas
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, January 28, 2016 4:22 PM
> To: Sun, Xutao <xutao.sun@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/4] lib/ether: optimize the
> 'rte_eth_tunnel_filter_conf' structure
>
> 2016-01-28 15:30, Xutao Sun:
> > Change the fields of outer_mac and inner_mac from pointer to struct in
> order to keep the code's readability.
>
> [...]
> > - tunnel_filter_conf.outer_mac = &res->outer_mac;
> > - tunnel_filter_conf.inner_mac = &res->inner_mac;
> > + (void)rte_memcpy(&tunnel_filter_conf.outer_mac, &res-
> >outer_mac,
> > + ETHER_ADDR_LEN);
> > + (void)rte_memcpy(&tunnel_filter_conf.inner_mac, &res-
> >inner_mac,
> > + ETHER_ADDR_LEN);
>
> The (void) casting is useless here.
>
> > --- a/lib/librte_ether/rte_eth_ctrl.h
> > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > @@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
> > * Tunneling Packet filter configuration.
> > */
> > struct rte_eth_tunnel_filter_conf {
> > - struct ether_addr *outer_mac; /**< Outer MAC address filter. */
> > - struct ether_addr *inner_mac; /**< Inner MAC address filter. */
> > + struct ether_addr outer_mac; /**< Outer MAC address filter. */
> > + struct ether_addr inner_mac; /**< Inner MAC address filter. */
>
> It is an API change.
> Please remove the deprecation notice and update the release notes in this
> patch (atomically).
I will remove the deprecation notice and update the release notes.
Is it an ABI change instead of an API change?
Thanks,
Xutao
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side
@ 2016-01-28 8:40 4% Helin Zhang
2016-01-28 8:40 4% ` [dpdk-dev] [PATCH 1/3] i40e: add setting VF MAC address in DPDK PF host Helin Zhang
0 siblings, 1 reply; 200+ results
From: Helin Zhang @ 2016-01-28 8:40 UTC (permalink / raw)
To: dev
It adds pre-setting i40e VF MAC addresses from DPDK PF host side,
during host port initialization, by introduing a new port
configuration element. It then can pre-set VF MAC addresses
before any launching VFs, and the VF MAC addresses will not be
random each time launching a VF.
There should be no ABI broken, as ABI changes
in 'struct rte_eth_conf' has already been announced in R2.2.
Helin Zhang (3):
i40e: add setting VF MAC address in DPDK PF host
i40evf: use ether interface for validating MAC address
app/testpmd: set default MAC addresses for each VF
app/test-pmd/testpmd.c | 19 +++++++++++++++++++
doc/guides/rel_notes/release_2_3.rst | 9 +++++++++
drivers/net/i40e/i40e_ethdev.c | 21 +++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_ethdev_vf.c | 14 +++++++-------
drivers/net/i40e/i40e_pf.c | 2 ++
lib/librte_ether/rte_ethdev.h | 10 ++++++++++
7 files changed, 69 insertions(+), 7 deletions(-)
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/3] i40e: add setting VF MAC address in DPDK PF host
2016-01-28 8:40 4% [dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side Helin Zhang
@ 2016-01-28 8:40 4% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2016-01-28 8:40 UTC (permalink / raw)
To: dev
It adds pre-setting the VF MAC addresses from DPDK PF host
side before any VF being initialized, by introducing a new
element of 'struct rte_vf_conf' in 'struct rte_eth_conf'.
It supports up to 128 VFs per physical port of setting VF
MAC addresses.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 9 +++++++++
drivers/net/i40e/i40e_ethdev.c | 21 +++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_pf.c | 2 ++
lib/librte_ether/rte_ethdev.h | 10 ++++++++++
5 files changed, 43 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..8ba3594 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,11 @@ DPDK Release 2.3
New Features
------------
+* **Added setting default MAC address for i40e VF.**
+
+ Added setting default MAC address for i40e VF before in PF host
+ driver, by providing those MAC addresses in PF port configuration.
+
Resolved Issues
---------------
@@ -39,6 +44,10 @@ API Changes
ABI Changes
-----------
+* The ethdev structure of ``rte_eth_dev``, ``rte_eth_dev_data`` and
+ ``rte_eth_conf`` were changed to support setting default MAC address
+ for i40e VF, by DPDK PF host.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..f7cec39 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1020,6 +1020,7 @@ i40e_dev_configure(struct rte_eth_dev *dev)
I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
enum rte_eth_rx_mq_mode mq_mode = dev->data->dev_conf.rxmode.mq_mode;
+ struct ether_addr *p_mac_addr;
int i, ret;
/* Initialize to TRUE. If any of Rx queues doesn't meet the
@@ -1074,6 +1075,26 @@ i40e_dev_configure(struct rte_eth_dev *dev)
}
}
+ /* Store the configured VF MAC address */
+ for (i = 0; i < RTE_MIN(pf->vf_num, ETH_VF_NUM_MAX); i++) {
+ p_mac_addr = &(dev->data->dev_conf.vf_conf[i].mac_addr);
+ if (is_valid_assigned_ether_addr(p_mac_addr)) {
+ ether_addr_copy(p_mac_addr, &(pf->vfs[i].mac_addr));
+ PMD_DRV_LOG(INFO, "MAC address "
+ "%02x:%02x:%02x:%02x:%02x:%02x will be "
+ "used as default address of VF[%d]",
+ p_mac_addr->addr_bytes[0],
+ p_mac_addr->addr_bytes[1],
+ p_mac_addr->addr_bytes[2],
+ p_mac_addr->addr_bytes[3],
+ p_mac_addr->addr_bytes[4],
+ p_mac_addr->addr_bytes[5], i);
+ } else {
+ PMD_DRV_LOG(WARNING, "Invalid MAC address configured "
+ "for VF[%d], use zero instead", i);
+ }
+ }
+
return 0;
err_dcb:
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 1f9792b..66aad4d 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -312,6 +312,7 @@ struct i40e_pf_vf {
uint16_t vf_idx; /* VF index in pf->vfs */
uint16_t lan_nb_qps; /* Actual queues allocated */
uint16_t reset_cnt; /* Total vf reset times */
+ struct ether_addr mac_addr; /* Default MAC address */
};
/*
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index cbf4e5b..be7cbf7 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -315,6 +315,8 @@ i40e_pf_host_process_cmd_get_vf_resource(struct i40e_pf_vf *vf)
/* As assume Vf only has single VSI now, always return 0 */
vf_res->vsi_res[0].vsi_id = 0;
vf_res->vsi_res[0].num_queue_pairs = vf->vsi->nb_qps;
+ ether_addr_copy(&vf->mac_addr,
+ (struct ether_addr *)vf_res->vsi_res[0].default_mac_addr);
send_msg:
i40e_pf_host_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_GET_VF_RESOURCES,
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..88f1d9b 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -754,6 +754,15 @@ struct rte_intr_conf {
uint16_t rxq;
};
+#define ETH_VF_NUM_MAX 128 /* Maximum number of Virtual Functions supported */
+
+/**
+ * A structure to define VF configurations to be used in PF host driver.
+ */
+struct rte_vf_conf {
+ struct ether_addr mac_addr; /* Pre-configured VF MAC address. */
+};
+
/**
* A structure used to configure an Ethernet port.
* Depending upon the RX multi-queue mode, extra advanced
@@ -793,6 +802,7 @@ struct rte_eth_conf {
uint32_t dcb_capability_en;
struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
+ struct rte_vf_conf vf_conf[ETH_VF_NUM_MAX]; /**< VF configuration. */
};
/**
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
2016-01-27 15:57 0% ` Jastrzebski, MichalX K
@ 2016-01-28 7:41 3% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-28 7:41 UTC (permalink / raw)
To: Jastrzebski, MichalX K, Kerlin, MarcinX, dev
On 01/27/2016 05:57 PM, Jastrzebski, MichalX K wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Wednesday, January 27, 2016 2:38 PM
>> To: Kerlin, MarcinX <marcinx.kerlin@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
>>
>> On 01/26/2016 06:15 PM, Marcin Kerlin wrote:
>>> This patch adds new function rte_jobstats_abort. It marks *job* as finished
>>> and time of this work will be add to management time instead of execution
>> time.
>>> This function should be used instead of rte_jobstats_finish if condition
>> occure,
>>> condition is defined by the application for example when receiving n>0
>> packets.
>>>
>>> Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
>>> ---
>>> lib/librte_jobstats/rte_jobstats.c | 22 ++++++++++++++++++++++
>>> lib/librte_jobstats/rte_jobstats.h | 17 +++++++++++++++++
>>> lib/librte_jobstats/rte_jobstats_version.map | 7 +++++++
>>> 3 files changed, 46 insertions(+)
>>>
>> [...]
>>> diff --git a/lib/librte_jobstats/rte_jobstats.h
>> b/lib/librte_jobstats/rte_jobstats.h
>>> index de6a89a..9995319 100644
>>> --- a/lib/librte_jobstats/rte_jobstats.h
>>> +++ b/lib/librte_jobstats/rte_jobstats.h
>>> @@ -90,6 +90,9 @@ struct rte_jobstats {
>>> uint64_t exec_cnt;
>>> /**< Execute count. */
>>>
>>> + uint64_t last_job_time;
>>> + /**< Last job time */
>>> +
>>> char name[RTE_JOBSTATS_NAMESIZE];
>>> /**< Name of this job */
>>>
>>
>> AFAICS this is an ABI break and as such, needs to be preannounced, see
>> http://dpdk.org/doc/guides/contributing/versioning.html
>> For 2.3 it'd need to be a CONFIG_RTE_NEXT_ABI feature.
>>
>> - Panu -
>
> Hi Panu,
> Thanks for Your notice. This last_job_time field is actually not necessary here
> and will be removed from this structure.
Right, makes sense. You can always add it later on when there's a more
pressing need to break the ABI.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask
2016-01-27 9:19 0% ` Thomas Monjalon
@ 2016-01-28 5:55 0% ` Wu, Jingjing
0 siblings, 0 replies; 200+ results
From: Wu, Jingjing @ 2016-01-28 5:55 UTC (permalink / raw)
To: Thomas Monjalon, Mcnamara, John; +Cc: dev
>
> 2016-01-27 16:37, Jingjing Wu:
> > Fixed issue of byte order in ethdev library that the structure for
> > setting fdir's mask and flow entry is inconsist and made inputs of
> > mask be in big endian.
>
> Please be more precise. Which one is big endian?
> Wasn't it tested before?
>
It is tested, it works. But byte order fields in the structures for fdir are not
consist, few are in host endian. It will make user confused, so this patch
is to make all fields in the same byte order.
> > fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
> > 2d4c1a9ea2ac ("ethdev: add new flow director masks")
>
> Please put Fixes: on the two lines.
>
OK. Will add in later version.
> > --- a/doc/guides/rel_notes/release_2_3.rst
> > +++ b/doc/guides/rel_notes/release_2_3.rst
> > @@ -19,6 +19,10 @@ Drivers
> > Libraries
> > ~~~~~~~~~
> >
> > +* ** fix byte order inconsistence between fdir flow and mask **
> > +
> > + Fixed issue in ethdev library that the structure for setting
> > + fdir's mask and flow entry is inconsist in byte order.
>
> John, comment on release notes formatting?
> It's important to have the first items well formatted.
>
> > @@ -39,6 +43,8 @@ API Changes
> > ABI Changes
> > -----------
> >
> > +* The fields in The ethdev structures ``rte_eth_fdir_masks`` were
> > + changed to be in big endian.
>
> Please take care of uppercase typo here.
Ok. Thanks for point.
>
> > - /* write all the same so that UDP, TCP and SCTP use the same mask
> */
> > + /* write all the same so that UDP, TCP and SCTP use the same mask
> > + * (little-endian)
> > + */
>
> Spacing typo here.
> Sorry for the nits ;)
>
Will fix this in later version.
> > - uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
> > + uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
> > uint32_t tunnel_id_mask; /** tunnel ID mask */
> > - uint8_t tunnel_type_mask;
> > + uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
> > + 0 - Ignore tunnel type. */
>
> These changes seem unrelated with the patch.
> It's good to improve doc of this API but it's maybe not enough.
> Example:
> uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
> Are we sure everybody understand how to fill it?
OK. Will improve this.
Thanks
JIngjing
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 2/3] rte_ctrl_if: add control interface library
[not found] <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com>
@ 2016-01-27 16:24 1% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2016-01-27 16:24 UTC (permalink / raw)
To: dev
This library gets control messages form kernelspace and forwards them to
librte_ether and returns response back to the kernelspace.
Library does:
1) Trigger Linux virtual interface creation
2) Initialize the netlink socket communication
3) Provides process() API to the application that does processing the
received messages
This library requires corresponding kernel module to be inserted.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
config/common_linuxapp | 3 +-
doc/api/doxy-api-index.md | 3 +-
doc/api/doxy-api.conf | 1 +
doc/guides/rel_notes/release_2_3.rst | 9 +
lib/Makefile | 3 +-
lib/librte_ctrl_if/Makefile | 58 +++++
lib/librte_ctrl_if/rte_ctrl_if.c | 162 +++++++++++++
lib/librte_ctrl_if/rte_ctrl_if.h | 115 ++++++++++
lib/librte_ctrl_if/rte_ctrl_if_version.map | 9 +
lib/librte_ctrl_if/rte_ethtool.c | 354 +++++++++++++++++++++++++++++
lib/librte_ctrl_if/rte_ethtool.h | 54 +++++
lib/librte_ctrl_if/rte_nl.c | 259 +++++++++++++++++++++
lib/librte_ctrl_if/rte_nl.h | 60 +++++
lib/librte_eal/common/include/rte_log.h | 3 +-
mk/rte.app.mk | 3 +-
15 files changed, 1091 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_ctrl_if/Makefile
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h
create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map
create mode 100644 lib/librte_ctrl_if/rte_ethtool.c
create mode 100644 lib/librte_ctrl_if/rte_ethtool.h
create mode 100644 lib/librte_ctrl_if/rte_nl.c
create mode 100644 lib/librte_ctrl_if/rte_nl.h
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 5d5e3e4..f72ba0e 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -507,6 +507,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n
#
CONFIG_RTE_KCP_KMOD=y
CONFIG_RTE_KCP_KO_DEBUG=n
+CONFIG_RTE_LIBRTE_CTRL_IF=y
#
# Compile vhost library
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 7a91001..214d16e 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped by topics:
[common] (@ref rte_common.h),
[ABI compat] (@ref rte_compat.h),
[keepalive] (@ref rte_keepalive.h),
- [version] (@ref rte_version.h)
+ [version] (@ref rte_version.h),
+ [control interface] (@ref rte_ctrl_if.h)
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 57e8b5d..fd69bf1 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -39,6 +39,7 @@ INPUT = doc/api/doxy-api-index.md \
lib/librte_cmdline \
lib/librte_compat \
lib/librte_cryptodev \
+ lib/librte_ctrl_if \
lib/librte_distributor \
lib/librte_ether \
lib/librte_hash \
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..39725e4 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,14 @@ DPDK Release 2.3
New Features
------------
+* **Control interface support added.**
+
+ To enable controlling DPDK ports by common Linux tools.
+ Following modules added to DPDK:
+
+ * librte_ctrl_if library
+ * librte_eal/linuxapp/kcp kernel module
+
Resolved Issues
---------------
@@ -51,6 +59,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.1
+ + librte_ctrl_if.so.1
librte_distributor.so.1
librte_eal.so.2
librte_hash.so.2
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..a50bc1e 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port
DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
+DIRS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += librte_ctrl_if
ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
diff --git a/lib/librte_ctrl_if/Makefile b/lib/librte_ctrl_if/Makefile
new file mode 100644
index 0000000..4e82966
--- /dev/null
+++ b/lib/librte_ctrl_if/Makefile
@@ -0,0 +1,58 @@
+# BSD LICENSE
+#
+# Copyright(c) 2016 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.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_ctrl_if.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+EXPORT_MAP := rte_ctrl_if_version.map
+
+LIBABIVER := 1
+
+SRCS-y += rte_ctrl_if.c
+SRCS-y += rte_nl.c
+SRCS-y += rte_ethtool.c
+
+#
+# Export include files
+#
+SYMLINK-y-include += rte_ctrl_if.h
+
+# this lib depends upon:
+DEPDIRS-y += lib/librte_ether
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ctrl_if/rte_ctrl_if.c b/lib/librte_ctrl_if/rte_ctrl_if.c
new file mode 100644
index 0000000..a84eea0
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if.c
@@ -0,0 +1,162 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <fcntl.h>
+#include <unistd.h>
+
+#include <sys/ioctl.h>
+
+#include <rte_ethdev.h>
+#include "rte_ctrl_if.h"
+#include "rte_nl.h"
+
+static int kcp_fd = -1;
+static int kcp_fd_ref;
+
+static int
+control_interface_init(void)
+{
+ int ret;
+ kcp_fd = open("/dev/" KCP_DEVICE, O_RDWR);
+
+ if (kcp_fd < 0) {
+ RTE_LOG(ERR, CTRL_IF,
+ "Failed to initialize control interface.\n");
+ return -1;
+ }
+
+ ret = control_interface_nl_init();
+ if (ret < 0)
+ close(kcp_fd);
+
+ return ret;
+}
+
+static int
+control_interface_ref_get(void)
+{
+ int ret = 0;
+
+ if (kcp_fd_ref == 0)
+ ret = control_interface_init();
+
+ if (ret == 0)
+ kcp_fd_ref++;
+
+ return kcp_fd_ref;
+}
+
+static void
+control_interface_release(void)
+{
+ close(kcp_fd);
+ control_interface_nl_release();
+}
+
+static int
+control_interface_ref_put(void)
+{
+ if (kcp_fd_ref == 0)
+ return 0;
+
+ kcp_fd_ref--;
+
+ if (kcp_fd_ref == 0)
+ control_interface_release();
+
+ return kcp_fd_ref;
+}
+
+static int
+rte_eth_control_interface_create_one(uint8_t port_id)
+{
+ if (control_interface_ref_get() != 0) {
+ ioctl(kcp_fd, RTE_KCP_IOCTL_CREATE, port_id);
+ RTE_LOG(DEBUG, CTRL_IF,
+ "Control interface created for port:%u\n",
+ port_id);
+ }
+
+ return 0;
+}
+
+int
+rte_eth_control_interface_create(void)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+ if (rte_eth_dev_is_valid_port(i)) {
+ ret = rte_eth_control_interface_create_one(i);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+static int
+rte_eth_control_interface_destroy_one(uint8_t port_id)
+{
+ ioctl(kcp_fd, RTE_KCP_IOCTL_RELEASE, port_id);
+ control_interface_ref_put();
+ RTE_LOG(DEBUG, CTRL_IF, "Control interface destroyed for port:%u\n",
+ port_id);
+
+ return 0;
+}
+
+int
+rte_eth_control_interface_destroy(void)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+ if (rte_eth_dev_is_valid_port(i)) {
+ ret = rte_eth_control_interface_destroy_one(i);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+int
+rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec)
+{
+ return control_interface_process_msg(flag, timeout_sec);
+}
diff --git a/lib/librte_ctrl_if/rte_ctrl_if.h b/lib/librte_ctrl_if/rte_ctrl_if.h
new file mode 100644
index 0000000..dcaf6dd
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if.h
@@ -0,0 +1,115 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#ifndef _RTE_CTRL_IF_H_
+#define _RTE_CTRL_IF_H_
+
+/**
+ * @file
+ *
+ * Control Interface Library for RTE
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <exec-env/rte_kcp_common.h>
+
+/**
+ * Flags values for rte_eth_control_interface_process_msg() API
+ */
+enum control_interface_process_flag {
+ /**< Process if msg available. */
+ RTE_ETHTOOL_CTRL_IF_PROCESS_MSG,
+
+ /**< Discard msg if available, respond with a error value. */
+ RTE_ETHTOOL_CTRL_IF_DISCARD_MSG,
+};
+
+/**
+ * Creates control interfaces (Linux virtual network interface)for
+ * each existing eal port.
+ *
+ * This API opens device created by supportive kernel module and initializes
+ * kernel communication interface.
+ *
+ * If supportive kernel module is not inserted this API will return
+ * an error.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_create(void);
+
+/**
+ * Destroys control interfaces.
+ *
+ * This API close device created by supportive kernel module and release
+ * underlying communication interface.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_destroy(void);
+
+/**
+ * Process if any received message is available.
+ *
+ * This function can be blocking or unblocking according timeout_sec
+ * parameter value. If function will be continuous loop, like can be
+ * called by any forwarding lcore, nonblocking mode should be preferred.
+ * If a separate thread created to handle control messages, blocking
+ * mode can be preferred to save CPU cycles.
+ *
+ * @param flag
+ * Defines what to do with message, can be process or discard.
+ *
+ * @param timeout_sec
+ * if 0, function is in nonblocking mode.
+ * if > 0, blocks for given time, if there is no message available,
+ * sleeps again same amount of time. Value is in seconds.
+ *
+ * @return
+ * 0 on success.
+ * Negative value on error.
+ */
+int rte_eth_control_interface_process_msg(int flag, unsigned int timeout_sec);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_CTRL_IF_H_ */
diff --git a/lib/librte_ctrl_if/rte_ctrl_if_version.map b/lib/librte_ctrl_if/rte_ctrl_if_version.map
new file mode 100644
index 0000000..8b27e26
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ctrl_if_version.map
@@ -0,0 +1,9 @@
+DPDK_2.3 {
+ global:
+
+ rte_eth_control_interface_create;
+ rte_eth_control_interface_destroy;
+ rte_eth_control_interface_process_msg;
+
+ local: *;
+};
diff --git a/lib/librte_ctrl_if/rte_ethtool.c b/lib/librte_ctrl_if/rte_ethtool.c
new file mode 100644
index 0000000..1caeab4
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ethtool.c
@@ -0,0 +1,354 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <stdio.h>
+
+#include <linux/if_link.h>
+
+#include <rte_version.h>
+#include <rte_ethdev.h>
+#include "rte_ethtool.h"
+
+#define ETHTOOL_GEEPROM_LEN 99
+#define ETHTOOL_GREGS_LEN 98
+#define ETHTOOL_GSSET_COUNT 97
+
+static int
+get_drvinfo(int port_id, void *data, int *data_len)
+{
+ struct ethtool_drvinfo *info = data;
+ struct rte_eth_dev_info dev_info;
+ int n;
+
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(port_id, &dev_info);
+
+ snprintf(info->driver, sizeof(info->driver), "%s",
+ dev_info.driver_name);
+ snprintf(info->version, sizeof(info->version), "%s",
+ rte_version());
+ snprintf(info->bus_info, sizeof(info->bus_info),
+ "%04x:%02x:%02x.%x",
+ dev_info.pci_dev->addr.domain, dev_info.pci_dev->addr.bus,
+ dev_info.pci_dev->addr.devid, dev_info.pci_dev->addr.function);
+
+ n = rte_eth_dev_get_reg_length(port_id);
+ info->regdump_len = n < 0 ? 0 : n;
+
+ n = rte_eth_dev_get_eeprom_length(port_id);
+ info->eedump_len = n < 0 ? 0 : n;
+
+ info->n_stats = sizeof(struct rte_eth_stats) / sizeof(uint64_t);
+ info->testinfo_len = 0;
+
+ *data_len = sizeof(struct ethtool_drvinfo);
+
+ return 0;
+}
+
+static int
+get_reg_len(int port_id, void *data, int *data_len)
+{
+ int reg_length = 0;
+
+ reg_length = rte_eth_dev_get_reg_length(port_id);
+ if (reg_length < 0)
+ return reg_length;
+
+ *(int *)data = reg_length * sizeof(uint32_t);
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_reg(int port_id, void *in_data, void *out_data, int *out_data_len)
+{
+ unsigned int reg_length;
+ int reg_length_out_len;
+ struct ethtool_regs *ethtool_regs = in_data;
+ struct rte_dev_reg_info regs = {
+ .data = out_data,
+ .length = 0,
+ };
+ int ret;
+
+ ret = get_reg_len(port_id, ®_length, ®_length_out_len);
+ if (ret < 0 || reg_length > ethtool_regs->len)
+ return -1;
+
+ ret = rte_eth_dev_get_reg_info(port_id, ®s);
+ if (ret < 0)
+ return ret;
+
+ ethtool_regs->version = regs.version;
+ *out_data_len = reg_length;
+
+ return 0;
+}
+
+static int
+get_link(int port_id, void *data, int *data_len)
+{
+ struct rte_eth_link link;
+
+ rte_eth_link_get(port_id, &link);
+
+ *(int *)data = link.link_status;
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_eeprom_length(int port_id, void *data, int *data_len)
+{
+ int eeprom_length = 0;
+
+ eeprom_length = rte_eth_dev_get_eeprom_length(port_id);
+ if (eeprom_length < 0)
+ return eeprom_length;
+
+ *(int *)data = eeprom_length;
+ *data_len = sizeof(int);
+
+ return 0;
+}
+
+static int
+get_eeprom(int port_id, void *in_data, void *out_data)
+{
+ struct ethtool_eeprom *eeprom = in_data;
+ struct rte_dev_eeprom_info eeprom_info = {
+ .data = out_data,
+ .offset = eeprom->offset,
+ .length = eeprom->len,
+ };
+ int ret;
+
+ ret = rte_eth_dev_get_eeprom(port_id, &eeprom_info);
+ if (ret < 0)
+ return ret;
+
+ eeprom->magic = eeprom_info.magic;
+
+ return 0;
+}
+
+static int
+set_eeprom(int port_id, void *in_data, void *out_data)
+{
+ struct ethtool_eeprom *eeprom = in_data;
+ struct rte_dev_eeprom_info eeprom_info = {
+ .data = out_data,
+ .offset = eeprom->offset,
+ .length = eeprom->len,
+ };
+ int ret;
+
+ ret = rte_eth_dev_set_eeprom(port_id, &eeprom_info);
+ if (ret < 0)
+ return ret;
+
+ eeprom->magic = eeprom_info.magic;
+
+ return 0;
+}
+
+static int
+get_pauseparam(int port_id, void *data, void *data_len)
+{
+ struct ethtool_pauseparam *pauseparam = data;
+ struct rte_eth_fc_conf fc_conf;
+ int ret;
+
+ ret = rte_eth_dev_flow_ctrl_get(port_id, &fc_conf);
+ if (ret)
+ return ret;
+
+ pauseparam->tx_pause = 0;
+ pauseparam->rx_pause = 0;
+
+ switch (fc_conf.mode) {
+ case RTE_FC_RX_PAUSE:
+ pauseparam->rx_pause = 1;
+ break;
+ case RTE_FC_TX_PAUSE:
+ pauseparam->tx_pause = 1;
+ break;
+ case RTE_FC_FULL:
+ pauseparam->rx_pause = 1;
+ pauseparam->tx_pause = 1;
+ default:
+ break;
+ }
+ pauseparam->autoneg = (uint32_t)fc_conf.autoneg;
+
+ *(int *)data_len = sizeof(struct ethtool_pauseparam);
+
+ return 0;
+}
+
+int
+rte_eth_dev_ethtool_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len)
+{
+ int ret = 0;
+
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -ENODEV;
+
+ switch (cmd_id) {
+ case ETHTOOL_GDRVINFO:
+ return get_drvinfo(port_id, out_data, out_data_len);
+ case ETHTOOL_GREGS_LEN:
+ return get_reg_len(port_id, out_data, out_data_len);
+ case ETHTOOL_GREGS:
+ return get_reg(port_id, in_data, out_data, out_data_len);
+ case ETHTOOL_GLINK:
+ return get_link(port_id, out_data, out_data_len);
+ case ETHTOOL_GEEPROM_LEN:
+ return get_eeprom_length(port_id, out_data, out_data_len);
+ case ETHTOOL_GEEPROM:
+ return get_eeprom(port_id, in_data, out_data);
+ case ETHTOOL_SEEPROM:
+ return set_eeprom(port_id, in_data, out_data);
+ case ETHTOOL_GPAUSEPARAM:
+ return get_pauseparam(port_id, out_data, out_data_len);
+ default:
+ ret = -95 /* EOPNOTSUPP */;
+ break;
+ }
+
+ return ret;
+}
+
+static int
+set_mtu(int port_id, void *in_data)
+{
+ int *mtu = in_data;
+
+ return rte_eth_dev_set_mtu(port_id, *mtu);
+}
+
+static int
+get_stats(int port_id, void *data, int *data_len)
+{
+ struct rte_eth_stats stats;
+ struct rtnl_link_stats64 *if_stats = data;
+ int ret;
+
+ ret = rte_eth_stats_get(port_id, &stats);
+ if (ret < 0)
+ return -EOPNOTSUPP;
+
+ if_stats->rx_packets = stats.ipackets;
+ if_stats->tx_packets = stats.opackets;
+ if_stats->rx_bytes = stats.ibytes;
+ if_stats->tx_bytes = stats.obytes;
+ if_stats->rx_errors = stats.ierrors;
+ if_stats->tx_errors = stats.oerrors;
+ if_stats->rx_dropped = stats.imissed;
+ if_stats->multicast = stats.imcasts;
+
+ *data_len = sizeof(struct rtnl_link_stats64);
+
+ return 0;
+}
+
+static int
+get_mac(int port_id, void *data, int *data_len)
+{
+ struct ether_addr addr;
+
+ rte_eth_macaddr_get(port_id, &addr);
+ memcpy(data, &addr, sizeof(struct ether_addr));
+
+ *data_len = sizeof(struct ether_addr);
+
+ return 0;
+}
+
+static int
+set_mac(int port_id, void *in_data)
+{
+ struct ether_addr addr;
+
+ memcpy(&addr, in_data, ETHER_ADDR_LEN);
+
+ return rte_eth_dev_default_mac_addr_set(port_id, &addr);
+}
+
+static int
+start_port(int port_id)
+{
+ rte_eth_dev_stop(port_id);
+ return rte_eth_dev_start(port_id);
+}
+
+static int
+stop_port(int port_id)
+{
+ rte_eth_dev_stop(port_id);
+ return 0;
+}
+
+int
+rte_eth_dev_control_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len)
+{
+ int ret = 0;
+
+ if (!rte_eth_dev_is_valid_port(port_id))
+ return -ENODEV;
+
+ switch (cmd_id) {
+ case RTE_KCP_REQ_CHANGE_MTU:
+ return set_mtu(port_id, in_data);
+ case RTE_KCP_REQ_GET_STATS:
+ return get_stats(port_id, out_data, out_data_len);
+ case RTE_KCP_REQ_GET_MAC:
+ return get_mac(port_id, out_data, out_data_len);
+ case RTE_KCP_REQ_SET_MAC:
+ return set_mac(port_id, in_data);
+ case RTE_KCP_REQ_START_PORT:
+ return start_port(port_id);
+ case RTE_KCP_REQ_STOP_PORT:
+ return stop_port(port_id);
+ default:
+ ret = -95 /* EOPNOTSUPP */;
+ break;
+ }
+
+ return ret;
+}
diff --git a/lib/librte_ctrl_if/rte_ethtool.h b/lib/librte_ctrl_if/rte_ethtool.h
new file mode 100644
index 0000000..19f364f
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_ethtool.h
@@ -0,0 +1,54 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#ifndef _RTE_ETHTOOL_H_
+#define _RTE_ETHTOOL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <linux/ethtool.h>
+
+#include <exec-env/rte_kcp_common.h>
+
+int rte_eth_dev_ethtool_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len);
+int rte_eth_dev_control_process(int cmd_id, int port_id, void *in_data,
+ void *out_data, int *out_data_len);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_ETHTOOL_H_ */
diff --git a/lib/librte_ctrl_if/rte_nl.c b/lib/librte_ctrl_if/rte_nl.c
new file mode 100644
index 0000000..33f1319
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_nl.c
@@ -0,0 +1,259 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <unistd.h>
+
+#include <sys/socket.h>
+#include <linux/netlink.h>
+
+#include <rte_spinlock.h>
+#include <rte_ethdev.h>
+#include "rte_ethtool.h"
+#include "rte_nl.h"
+#include "rte_ctrl_if.h"
+
+#define KCP_NL_GRP 31
+#define MAX_PAYLOAD 1024
+
+struct ctrl_if_nl {
+ struct nlmsghdr *nlh;
+ struct msghdr msg;
+ struct iovec iov;
+};
+
+static int sock_fd = -1;
+pthread_t thread_id;
+pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
+pthread_mutex_t msg_lock = PTHREAD_MUTEX_INITIALIZER;
+static uint8_t nlmsg[NLMSG_SPACE(MAX_PAYLOAD) * 2];
+static struct sockaddr_nl dest_addr;
+static struct sockaddr_nl src_addr;
+
+static struct ctrl_if_nl nl_s = {
+ .nlh = (struct nlmsghdr *)nlmsg,
+};
+
+static struct ctrl_if_nl nl_r = {
+ .nlh = (struct nlmsghdr *)(nlmsg + NLMSG_SPACE(MAX_PAYLOAD)),
+};
+
+static int kcp_ethtool_msg_count;
+static struct kcp_ethtool_msg msg_storage;
+
+static void
+control_interface_nl_send(void *buf, size_t len)
+{
+ int ret;
+
+ /* Fill in the netlink message payload */
+ memcpy(NLMSG_DATA(nl_s.nlh), buf, len);
+
+ ret = sendmsg(sock_fd, &nl_s.msg, 0);
+
+ if (ret < 0)
+ RTE_LOG(ERR, CTRL_IF, "Failed nl msg send. ret:%d, err:%d\n",
+ ret, errno);
+}
+
+static void
+control_interface_nl_process_msg(struct kcp_ethtool_msg *msg)
+{
+ if (msg->cmd_id > RTE_KCP_REQ_UNKNOWN) {
+ msg->err = rte_eth_dev_control_process(msg->cmd_id,
+ msg->port_id, msg->input_buffer,
+ msg->output_buffer, &msg->output_buffer_len);
+ } else {
+ msg->err = rte_eth_dev_ethtool_process(msg->cmd_id,
+ msg->port_id, msg->input_buffer,
+ msg->output_buffer, &msg->output_buffer_len);
+ }
+
+ control_interface_nl_send((void *)msg,
+ sizeof(struct kcp_ethtool_msg));
+}
+
+int
+control_interface_process_msg(int flag, unsigned int timeout_sec)
+{
+ int ret = 0;
+ struct timespec ts;
+
+ pthread_mutex_lock(&msg_lock);
+
+ clock_gettime(CLOCK_REALTIME, &ts);
+ ts.tv_sec += timeout_sec;
+ while (timeout_sec && !kcp_ethtool_msg_count && !ret)
+ ret = pthread_cond_timedwait(&cond, &msg_lock, &ts);
+
+ switch (flag) {
+ case RTE_ETHTOOL_CTRL_IF_PROCESS_MSG:
+ if (kcp_ethtool_msg_count) {
+ control_interface_nl_process_msg(&msg_storage);
+ kcp_ethtool_msg_count = 0;
+ }
+ ret = 0;
+ break;
+
+ case RTE_ETHTOOL_CTRL_IF_DISCARD_MSG:
+ if (kcp_ethtool_msg_count) {
+ msg_storage.err = -1;
+ control_interface_nl_send((void *)&msg_storage,
+ sizeof(struct kcp_ethtool_msg));
+ kcp_ethtool_msg_count = 0;
+ }
+ ret = 0;
+ break;
+
+ default:
+ ret = -1;
+ break;
+ }
+ pthread_mutex_unlock(&msg_lock);
+
+ return ret;
+}
+
+static int
+msg_add_and_signal(struct nlmsghdr *nlh)
+{
+ pthread_mutex_lock(&msg_lock);
+
+ memcpy(&msg_storage, NLMSG_DATA(nlh), sizeof(struct kcp_ethtool_msg));
+ kcp_ethtool_msg_count = 1;
+
+ pthread_cond_signal(&cond);
+
+ pthread_mutex_unlock(&msg_lock);
+
+ return 0;
+}
+
+static void *
+control_interface_nl_recv(void *arg)
+{
+ int ret;
+
+ for (;;) {
+ ret = recvmsg(sock_fd, &nl_r.msg, 0);
+ if (ret < 0)
+ continue;
+
+ if ((unsigned)ret < sizeof(struct kcp_ethtool_msg)) {
+ RTE_LOG(WARNING, CTRL_IF,
+ "Received %u bytes, payload %lu\n",
+ ret, sizeof(struct kcp_ethtool_msg));
+ continue;
+ }
+
+ msg_add_and_signal(nl_r.nlh);
+ }
+
+ return arg;
+}
+
+static void
+nl_setup_header(struct ctrl_if_nl *nl, struct sockaddr_nl *daddr)
+{
+ memset(nl->nlh, 0, NLMSG_SPACE(MAX_PAYLOAD));
+
+ /* Fill the netlink message header */
+ nl->nlh->nlmsg_len = NLMSG_SPACE(MAX_PAYLOAD);
+ nl->nlh->nlmsg_pid = getpid(); /* self pid */
+ nl->nlh->nlmsg_flags = 0;
+
+ nl->iov.iov_base = (void *)nl->nlh;
+ nl->iov.iov_len = nl->nlh->nlmsg_len;
+ memset(&nl->msg, 0, sizeof(struct msghdr));
+ nl->msg.msg_name = (void *)daddr;
+ nl->msg.msg_namelen = sizeof(struct sockaddr_nl);
+ nl->msg.msg_iov = &nl->iov;
+ nl->msg.msg_iovlen = 1;
+}
+
+static int
+control_interface_nl_socket_init(void)
+{
+ int fd;
+ int ret;
+
+ fd = socket(PF_NETLINK, SOCK_RAW, KCP_NL_GRP);
+ if (fd < 0)
+ return -1;
+
+ src_addr.nl_family = AF_NETLINK;
+ src_addr.nl_pid = getpid();
+ ret = bind(fd, (struct sockaddr *)&src_addr, sizeof(src_addr));
+ if (ret) {
+ close(fd);
+ return -1;
+ }
+
+ dest_addr.nl_family = AF_NETLINK;
+ dest_addr.nl_pid = 0; /* For Linux Kernel */
+ dest_addr.nl_groups = 0;
+
+ nl_setup_header(&nl_s, &dest_addr);
+ nl_setup_header(&nl_r, &dest_addr);
+
+ return fd;
+}
+
+int
+control_interface_nl_init(void)
+{
+ int ret;
+ char buf[] = "pid";
+ sock_fd = control_interface_nl_socket_init();
+
+ if (sock_fd < 0) {
+ RTE_LOG(ERR, CTRL_IF,
+ "Failed to initialize control interface.\n");
+ return -1;
+ }
+
+ ret = pthread_create(&thread_id, NULL, control_interface_nl_recv,
+ NULL);
+ if (ret != 0)
+ return -1;
+ control_interface_nl_send((void *)buf, sizeof(buf));
+
+ return 0;
+}
+
+void
+control_interface_nl_release(void)
+{
+ pthread_cancel(thread_id);
+ pthread_join(thread_id, NULL);
+ close(sock_fd);
+}
diff --git a/lib/librte_ctrl_if/rte_nl.h b/lib/librte_ctrl_if/rte_nl.h
new file mode 100644
index 0000000..e422bf9
--- /dev/null
+++ b/lib/librte_ctrl_if/rte_nl.h
@@ -0,0 +1,60 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#ifndef _RTE_NL_H_
+#define _RTE_NL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define KCP_ETHTOOL_MSG_LEN 500
+struct kcp_ethtool_msg {
+ int cmd_id;
+ int port_id;
+ char input_buffer[KCP_ETHTOOL_MSG_LEN];
+ char output_buffer[KCP_ETHTOOL_MSG_LEN];
+ int input_buffer_len;
+ int output_buffer_len;
+ int err;
+};
+
+int control_interface_nl_init(void);
+void control_interface_nl_release(void);
+int control_interface_process_msg(int flag, unsigned int timeout_sec);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_NL_H_ */
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index 2e47e7f..a0a2c9f 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -79,6 +79,7 @@ extern struct rte_logs rte_logs;
#define RTE_LOGTYPE_PIPELINE 0x00008000 /**< Log related to pipeline. */
#define RTE_LOGTYPE_MBUF 0x00010000 /**< Log related to mbuf. */
#define RTE_LOGTYPE_CRYPTODEV 0x00020000 /**< Log related to cryptodev. */
+#define RTE_LOGTYPE_CTRL_IF 0x00040000 /**< Log related to control interface. */
/* these log types can be used in an application */
#define RTE_LOGTYPE_USER1 0x01000000 /**< User-defined log type 1. */
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 8ecab41..e1638f0 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# Copyright(c) 2014-2015 6WIND S.A.
# All rights reserved.
#
@@ -122,6 +122,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF) += -lrte_mbuf
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF_OFFLOAD) += -lrte_mbuf_offload
_LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += -lrte_ip_frag
_LDLIBS-$(CONFIG_RTE_LIBRTE_ETHER) += -lethdev
+_LDLIBS-$(CONFIG_RTE_LIBRTE_CTRL_IF) += -lrte_ctrl_if
_LDLIBS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += -lrte_cryptodev
_LDLIBS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += -lrte_mempool
_LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -lrte_ring
--
2.5.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
2016-01-27 13:37 3% ` Panu Matilainen
@ 2016-01-27 15:57 0% ` Jastrzebski, MichalX K
2016-01-28 7:41 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Jastrzebski, MichalX K @ 2016-01-27 15:57 UTC (permalink / raw)
To: Panu Matilainen, Kerlin, MarcinX, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, January 27, 2016 2:38 PM
> To: Kerlin, MarcinX <marcinx.kerlin@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
>
> On 01/26/2016 06:15 PM, Marcin Kerlin wrote:
> > This patch adds new function rte_jobstats_abort. It marks *job* as finished
> > and time of this work will be add to management time instead of execution
> time.
> > This function should be used instead of rte_jobstats_finish if condition
> occure,
> > condition is defined by the application for example when receiving n>0
> packets.
> >
> > Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
> > ---
> > lib/librte_jobstats/rte_jobstats.c | 22 ++++++++++++++++++++++
> > lib/librte_jobstats/rte_jobstats.h | 17 +++++++++++++++++
> > lib/librte_jobstats/rte_jobstats_version.map | 7 +++++++
> > 3 files changed, 46 insertions(+)
> >
> [...]
> > diff --git a/lib/librte_jobstats/rte_jobstats.h
> b/lib/librte_jobstats/rte_jobstats.h
> > index de6a89a..9995319 100644
> > --- a/lib/librte_jobstats/rte_jobstats.h
> > +++ b/lib/librte_jobstats/rte_jobstats.h
> > @@ -90,6 +90,9 @@ struct rte_jobstats {
> > uint64_t exec_cnt;
> > /**< Execute count. */
> >
> > + uint64_t last_job_time;
> > + /**< Last job time */
> > +
> > char name[RTE_JOBSTATS_NAMESIZE];
> > /**< Name of this job */
> >
>
> AFAICS this is an ABI break and as such, needs to be preannounced, see
> http://dpdk.org/doc/guides/contributing/versioning.html
> For 2.3 it'd need to be a CONFIG_RTE_NEXT_ABI feature.
>
> - Panu -
Hi Panu,
Thanks for Your notice. This last_job_time field is actually not necessary here
and will be removed from this structure.
Best regards
Michal
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API
@ 2016-01-27 13:56 3% ` Panu Matilainen
2016-02-03 17:23 0% ` Olivier MATZ
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-27 13:56 UTC (permalink / raw)
To: Huawei Xie, dev; +Cc: dprovan
On 01/26/2016 07:03 PM, Huawei Xie wrote:
> v6 changes:
> reflect the changes in release notes and library version map file
> revise our duff's code style a bit to make it more readable
>
> v5 changes:
> add comment about duff's device and our variant implementation
>
> v3 changes:
> move while after case 0
> add context about duff's device and why we use while loop in the commit
> message
>
> v2 changes:
> unroll the loop a bit to help the performance
>
> rte_pktmbuf_alloc_bulk allocates a bulk of packet mbufs.
>
> There is related thread about this bulk API.
> http://dpdk.org/dev/patchwork/patch/4718/
> Thanks to Konstantin's loop unrolling.
>
> Attached the wiki page about duff's device. It explains the performance
> optimization through loop unwinding, and also the most dramatic use of
> case label fall-through.
> https://en.wikipedia.org/wiki/Duff%27s_device
>
> In our implementation, we use while() loop rather than do{} while() loop
> because we could not assume count is strictly positive. Using while()
> loop saves one line of check if count is zero.
>
> Signed-off-by: Gerald Rogers <gerald.rogers@intel.com>
> Signed-off-by: Huawei Xie <huawei.xie@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> doc/guides/rel_notes/release_2_3.rst | 3 ++
> lib/librte_mbuf/rte_mbuf.h | 55 ++++++++++++++++++++++++++++++++++++
> lib/librte_mbuf/rte_mbuf_version.map | 7 +++++
> 3 files changed, 65 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..a52cba3 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -4,6 +4,9 @@ DPDK Release 2.3
> New Features
> ------------
>
> +* **Enable bulk allocation of mbufs. **
> + A new function ``rte_pktmbuf_alloc_bulk()`` has been added to allow the user
> + to allocate a bulk of mbufs.
>
> Resolved Issues
> ---------------
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index f234ac9..b2ed479 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -1336,6 +1336,61 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct rte_mempool *mp)
> }
>
> /**
> + * Allocate a bulk of mbufs, initialize refcnt and reset the fields to default
> + * values.
> + *
> + * @param pool
> + * The mempool from which mbufs are allocated.
> + * @param mbufs
> + * Array of pointers to mbufs
> + * @param count
> + * Array size
> + * @return
> + * - 0: Success
> + */
> +static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
> + struct rte_mbuf **mbufs, unsigned count)
> +{
> + unsigned idx = 0;
> + int rc;
> +
> + rc = rte_mempool_get_bulk(pool, (void **)mbufs, count);
> + if (unlikely(rc))
> + return rc;
> +
> + /* To understand duff's device on loop unwinding optimization, see
> + * https://en.wikipedia.org/wiki/Duff's_device.
> + * Here while() loop is used rather than do() while{} to avoid extra
> + * check if count is zero.
> + */
> + switch (count % 4) {
> + case 0:
> + while (idx != count) {
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + case 3:
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + case 2:
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + case 1:
> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
> + rte_mbuf_refcnt_set(mbufs[idx], 1);
> + rte_pktmbuf_reset(mbufs[idx]);
> + idx++;
> + }
> + }
> + return 0;
> +}
> +
> +/**
> * Attach packet mbuf to another packet mbuf.
> *
> * After attachment we refer the mbuf we attached as 'indirect',
> diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
> index e10f6bd..257c65a 100644
> --- a/lib/librte_mbuf/rte_mbuf_version.map
> +++ b/lib/librte_mbuf/rte_mbuf_version.map
> @@ -18,3 +18,10 @@ DPDK_2.1 {
> rte_pktmbuf_pool_create;
>
> } DPDK_2.0;
> +
> +DPDK_2.3 {
> + global:
> +
> + rte_pktmbuf_alloc_bulk;
> +
> +} DPDK_2.1;
>
Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
the library ABI and should not be listed in the version map.
I assume its inline for performance reasons, but then you lose the
benefits of dynamic linking such as ability to fix bugs and/or improve
itby just updating the library. Since the point of having a bulk API is
to improve performance by reducing the number of calls required, does it
really have to be inline? As in, have you actually measured the
difference between inline and non-inline and decided its worth all the
downsides?
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job
@ 2016-01-27 13:37 3% ` Panu Matilainen
2016-01-27 15:57 0% ` Jastrzebski, MichalX K
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-27 13:37 UTC (permalink / raw)
To: Marcin Kerlin, dev
On 01/26/2016 06:15 PM, Marcin Kerlin wrote:
> This patch adds new function rte_jobstats_abort. It marks *job* as finished
> and time of this work will be add to management time instead of execution time.
> This function should be used instead of rte_jobstats_finish if condition occure,
> condition is defined by the application for example when receiving n>0 packets.
>
> Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
> ---
> lib/librte_jobstats/rte_jobstats.c | 22 ++++++++++++++++++++++
> lib/librte_jobstats/rte_jobstats.h | 17 +++++++++++++++++
> lib/librte_jobstats/rte_jobstats_version.map | 7 +++++++
> 3 files changed, 46 insertions(+)
>
[...]
> diff --git a/lib/librte_jobstats/rte_jobstats.h b/lib/librte_jobstats/rte_jobstats.h
> index de6a89a..9995319 100644
> --- a/lib/librte_jobstats/rte_jobstats.h
> +++ b/lib/librte_jobstats/rte_jobstats.h
> @@ -90,6 +90,9 @@ struct rte_jobstats {
> uint64_t exec_cnt;
> /**< Execute count. */
>
> + uint64_t last_job_time;
> + /**< Last job time */
> +
> char name[RTE_JOBSTATS_NAMESIZE];
> /**< Name of this job */
>
AFAICS this is an ABI break and as such, needs to be preannounced, see
http://dpdk.org/doc/guides/contributing/versioning.html
For 2.3 it'd need to be a CONFIG_RTE_NEXT_ABI feature.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask
2016-01-27 8:37 3% [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask Jingjing Wu
@ 2016-01-27 9:19 0% ` Thomas Monjalon
2016-01-28 5:55 0% ` Wu, Jingjing
2016-02-01 2:48 3% ` [dpdk-dev] [PATCH v2] " Jingjing Wu
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-27 9:19 UTC (permalink / raw)
To: Jingjing Wu, john.mcnamara; +Cc: dev
2016-01-27 16:37, Jingjing Wu:
> Fixed issue of byte order in ethdev library that the structure
> for setting fdir's mask and flow entry is inconsist and made
> inputs of mask be in big endian.
Please be more precise. Which one is big endian?
Wasn't it tested before?
> fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
> 2d4c1a9ea2ac ("ethdev: add new flow director masks")
Please put Fixes: on the two lines.
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -19,6 +19,10 @@ Drivers
> Libraries
> ~~~~~~~~~
>
> +* ** fix byte order inconsistence between fdir flow and mask **
> +
> + Fixed issue in ethdev library that the structure for setting
> + fdir's mask and flow entry is inconsist in byte order.
John, comment on release notes formatting?
It's important to have the first items well formatted.
> @@ -39,6 +43,8 @@ API Changes
> ABI Changes
> -----------
>
> +* The fields in The ethdev structures ``rte_eth_fdir_masks`` were
> + changed to be in big endian.
Please take care of uppercase typo here.
> - /* write all the same so that UDP, TCP and SCTP use the same mask */
> + /* write all the same so that UDP, TCP and SCTP use the same mask
> + * (little-endian)
> + */
Spacing typo here.
Sorry for the nits ;)
> - uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
> + uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
> uint32_t tunnel_id_mask; /** tunnel ID mask */
> - uint8_t tunnel_type_mask;
> + uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
> + 0 - Ignore tunnel type. */
These changes seem unrelated with the patch.
It's good to improve doc of this API but it's maybe not enough.
Example:
uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
Are we sure everybody understand how to fill it?
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask
@ 2016-01-27 8:37 3% Jingjing Wu
2016-01-27 9:19 0% ` Thomas Monjalon
2016-02-01 2:48 3% ` [dpdk-dev] [PATCH v2] " Jingjing Wu
0 siblings, 2 replies; 200+ results
From: Jingjing Wu @ 2016-01-27 8:37 UTC (permalink / raw)
To: dev
Fixed issue of byte order in ethdev library that the structure
for setting fdir's mask and flow entry is inconsist and made
inputs of mask be in big endian.
fixes: 76c6f89e80d4 ("ixgbe: support new flow director masks")
2d4c1a9ea2ac ("ethdev: add new flow director masks")
Reported-by: Yaacov Hazan <yaacovh@mellanox.com>
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
app/test-pmd/cmdline.c | 6 ++---
doc/guides/rel_notes/release_2_3.rst | 6 +++++
drivers/net/ixgbe/ixgbe_fdir.c | 47 ++++++++++++++++++++++--------------
lib/librte_ether/rte_eth_ctrl.h | 7 ++++--
4 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..13194c9 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8687,13 +8687,13 @@ cmd_flow_director_mask_parsed(void *parsed_result,
return;
}
- mask->vlan_tci_mask = res->vlan_mask;
+ mask->vlan_tci_mask = rte_cpu_to_be_16(res->vlan_mask);
IPV4_ADDR_TO_UINT(res->ipv4_src, mask->ipv4_mask.src_ip);
IPV4_ADDR_TO_UINT(res->ipv4_dst, mask->ipv4_mask.dst_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_src, mask->ipv6_mask.src_ip);
IPV6_ADDR_TO_ARRAY(res->ipv6_dst, mask->ipv6_mask.dst_ip);
- mask->src_port_mask = res->port_src;
- mask->dst_port_mask = res->port_dst;
+ mask->src_port_mask = rte_cpu_to_be_16(res->port_src);
+ mask->dst_port_mask = rte_cpu_to_be_16(res->port_dst);
}
cmd_reconfig_device_queue(res->port_id, 1, 1);
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..28d0f27 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -19,6 +19,10 @@ Drivers
Libraries
~~~~~~~~~
+* ** fix byte order inconsistence between fdir flow and mask **
+
+ Fixed issue in ethdev library that the structure for setting
+ fdir's mask and flow entry is inconsist in byte order.
Examples
~~~~~~~~
@@ -39,6 +43,8 @@ API Changes
ABI Changes
-----------
+* The fields in The ethdev structures ``rte_eth_fdir_masks`` were
+ changed to be in big endian.
Shared Library Versions
-----------------------
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index e03219b..7423b2d 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -309,6 +309,7 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
uint32_t fdiripv6m; /* IPv6 source and destination masks. */
uint16_t dst_ipv6m = 0;
uint16_t src_ipv6m = 0;
+ volatile uint32_t *reg;
PMD_INIT_FUNC_TRACE();
@@ -322,16 +323,16 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
/* use the L4 protocol mask for raw IPv4/IPv6 traffic */
fdirm |= IXGBE_FDIRM_L4P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -340,19 +341,26 @@ fdir_set_input_mask_82599(struct rte_eth_dev *dev,
IXGBE_WRITE_REG(hw, IXGBE_FDIRM, fdirm);
/* store the TCP/UDP port masks, bit reversed from port layout */
- fdirtcpm = reverse_fdir_bitmasks(input_mask->dst_port_mask,
- input_mask->src_port_mask);
+ fdirtcpm = reverse_fdir_bitmasks(
+ rte_be_to_cpu_16(input_mask->dst_port_mask),
+ rte_be_to_cpu_16(input_mask->src_port_mask));
- /* write all the same so that UDP, TCP and SCTP use the same mask */
+ /* write all the same so that UDP, TCP and SCTP use the same mask
+ * (little-endian)
+ */
IXGBE_WRITE_REG(hw, IXGBE_FDIRTCPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRUDPM, ~fdirtcpm);
IXGBE_WRITE_REG(hw, IXGBE_FDIRSCTPM, ~fdirtcpm);
info->mask.src_port_mask = input_mask->src_port_mask;
info->mask.dst_port_mask = input_mask->dst_port_mask;
- /* Store source and destination IPv4 masks (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRSIP4M, ~(input_mask->ipv4_mask.src_ip));
- IXGBE_WRITE_REG(hw, IXGBE_FDIRDIP4M, ~(input_mask->ipv4_mask.dst_ip));
+ /* Store source and destination IPv4 masks (big-endian),
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRSIP4M);
+ *reg = ~(input_mask->ipv4_mask.src_ip);
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRDIP4M);
+ *reg = ~(input_mask->ipv4_mask.dst_ip);
info->mask.src_ipv4_mask = input_mask->ipv4_mask.src_ip;
info->mask.dst_ipv4_mask = input_mask->ipv4_mask.dst_ip;
@@ -401,16 +409,16 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
/* some bits must be set for mac vlan or tunnel mode */
fdirm |= IXGBE_FDIRM_L4P | IXGBE_FDIRM_L3P;
- if (input_mask->vlan_tci_mask == 0x0FFF)
+ if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0x0FFF))
/* mask VLAN Priority */
fdirm |= IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask == 0xE000)
+ else if (input_mask->vlan_tci_mask == rte_cpu_to_be_16(0xE000))
/* mask VLAN ID */
fdirm |= IXGBE_FDIRM_VLANID;
else if (input_mask->vlan_tci_mask == 0)
/* mask VLAN ID and Priority */
fdirm |= IXGBE_FDIRM_VLANID | IXGBE_FDIRM_VLANP;
- else if (input_mask->vlan_tci_mask != 0xEFFF) {
+ else if (input_mask->vlan_tci_mask != rte_cpu_to_be_16(0xEFFF)) {
PMD_INIT_LOG(ERR, "invalid vlan_tci_mask");
return -EINVAL;
}
@@ -444,7 +452,7 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
info->mask.tunnel_type_mask =
input_mask->tunnel_type_mask;
- switch (input_mask->tunnel_id_mask & 0xFFFFFFFF) {
+ switch (rte_be_to_cpu_32(input_mask->tunnel_id_mask)) {
case 0x0:
/* Mask vxlan id */
fdiripv6m |= IXGBE_FDIRIP6M_TNI_VNI;
@@ -904,13 +912,16 @@ fdir_write_perfect_filter_82599(struct ixgbe_hw *hw,
u32 addr_low, addr_high;
u32 tunnel_type = 0;
int err = 0;
+ volatile uint32_t *reg;
if (mode == RTE_FDIR_MODE_PERFECT) {
- /* record the IPv4 address (big-endian) */
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPSA,
- input->formatted.src_ip[0]);
- IXGBE_WRITE_REG(hw, IXGBE_FDIRIPDA,
- input->formatted.dst_ip[0]);
+ /* record the IPv4 address (big-endian)
+ * can not use IXGBE_WRITE_REG.
+ */
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPSA);
+ *reg = input->formatted.src_ip[0];
+ reg = IXGBE_PCI_REG_ADDR(hw, IXGBE_FDIRIPDA);
+ *reg = input->formatted.dst_ip[0];
/* record source and destination port (little-endian)*/
fdirport = IXGBE_NTOHS(input->formatted.dst_port);
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..80f9048 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -501,6 +501,7 @@ struct rte_eth_tunnel_flow {
/**
* An union contains the inputs for all types of flow
+ * Items in flows need to be in big endian
*/
union rte_eth_fdir_flow {
struct rte_eth_l2_flow l2_flow;
@@ -586,6 +587,7 @@ struct rte_eth_fdir_filter {
/**
* A structure used to configure FDIR masks that are used by the device
* to match the various fields of RX packet headers.
+ * Items in it need to be in big endian
*/
struct rte_eth_fdir_masks {
uint16_t vlan_tci_mask;
@@ -593,9 +595,10 @@ struct rte_eth_fdir_masks {
struct rte_eth_ipv6_flow ipv6_mask;
uint16_t src_port_mask;
uint16_t dst_port_mask;
- uint8_t mac_addr_byte_mask; /** Per byte MAC address mask */
+ uint8_t mac_addr_byte_mask; /** Bit mask for associated byte */
uint32_t tunnel_id_mask; /** tunnel ID mask */
- uint8_t tunnel_type_mask;
+ uint8_t tunnel_type_mask; /**< 1 - Match tunnel type,
+ 0 - Ignore tunnel type. */
};
/**
--
2.4.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format
@ 2016-01-26 6:26 4% ` Jingjing Wu
0 siblings, 0 replies; 200+ results
From: Jingjing Wu @ 2016-01-26 6:26 UTC (permalink / raw)
To: dev
This patch changed rte_eth_fdir_flow from union to struct to
support more packets formats, for example, Vxlan and GRE tunnel
packets with IP inner frame.
This patch also add new RTE_FDIR_TUNNEL_TYPE_GRE enum.
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 4 ++++
lib/librte_ether/rte_eth_ctrl.h | 27 +++++++++++++++------------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2216fee 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ API Changes
ABI Changes
-----------
+* The ethdev flow director structure ``rte_eth_fdir_flow`` structure was
+ changed. New fields were added to extend flow director's input set, and
+ organizing is also changed to support multiple input format.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 248f719..eb4c13d 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -495,6 +495,7 @@ enum rte_eth_fdir_tunnel_type {
RTE_FDIR_TUNNEL_TYPE_UNKNOWN = 0,
RTE_FDIR_TUNNEL_TYPE_NVGRE,
RTE_FDIR_TUNNEL_TYPE_VXLAN,
+ RTE_FDIR_TUNNEL_TYPE_GRE,
};
/**
@@ -508,18 +509,20 @@ struct rte_eth_tunnel_flow {
};
/**
- * An union contains the inputs for all types of flow
+ * A struct contains the inputs for all types of flow
*/
-union rte_eth_fdir_flow {
- struct rte_eth_l2_flow l2_flow;
- struct rte_eth_udpv4_flow udp4_flow;
- struct rte_eth_tcpv4_flow tcp4_flow;
- struct rte_eth_sctpv4_flow sctp4_flow;
- struct rte_eth_ipv4_flow ip4_flow;
- struct rte_eth_udpv6_flow udp6_flow;
- struct rte_eth_tcpv6_flow tcp6_flow;
- struct rte_eth_sctpv6_flow sctp6_flow;
- struct rte_eth_ipv6_flow ipv6_flow;
+struct rte_eth_fdir_flow {
+ union {
+ struct rte_eth_l2_flow l2_flow;
+ struct rte_eth_udpv4_flow udp4_flow;
+ struct rte_eth_tcpv4_flow tcp4_flow;
+ struct rte_eth_sctpv4_flow sctp4_flow;
+ struct rte_eth_ipv4_flow ip4_flow;
+ struct rte_eth_udpv6_flow udp6_flow;
+ struct rte_eth_tcpv6_flow tcp6_flow;
+ struct rte_eth_sctpv6_flow sctp6_flow;
+ struct rte_eth_ipv6_flow ipv6_flow;
+ };
struct rte_eth_mac_vlan_flow mac_vlan_flow;
struct rte_eth_tunnel_flow tunnel_flow;
};
@@ -540,7 +543,7 @@ struct rte_eth_fdir_flow_ext {
*/
struct rte_eth_fdir_input {
uint16_t flow_type;
- union rte_eth_fdir_flow flow;
+ struct rte_eth_fdir_flow flow;
/**< Flow fields to match, dependent on flow_type */
struct rte_eth_fdir_flow_ext flow_ext;
/**< Additional fields to match */
--
2.4.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format
@ 2016-01-26 6:20 4% ` Jingjing Wu
0 siblings, 0 replies; 200+ results
From: Jingjing Wu @ 2016-01-26 6:20 UTC (permalink / raw)
To: dev
This patch changed rte_eth_fdir_flow from union to struct to
support more packets formats, for example, Vxlan and GRE tunnel
packets with IP inner frame.
This patch also add new RTE_FDIR_TUNNEL_TYPE_GRE enum.
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 4 ++++
lib/librte_ether/rte_eth_ctrl.h | 27 +++++++++++++++------------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2216fee 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ API Changes
ABI Changes
-----------
+* The ethdev flow director structure ``rte_eth_fdir_flow`` structure was
+ changed. New fields were added to extend flow director's input set, and
+ organizing is also changed to support multiple input format.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 248f719..eb4c13d 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -495,6 +495,7 @@ enum rte_eth_fdir_tunnel_type {
RTE_FDIR_TUNNEL_TYPE_UNKNOWN = 0,
RTE_FDIR_TUNNEL_TYPE_NVGRE,
RTE_FDIR_TUNNEL_TYPE_VXLAN,
+ RTE_FDIR_TUNNEL_TYPE_GRE,
};
/**
@@ -508,18 +509,20 @@ struct rte_eth_tunnel_flow {
};
/**
- * An union contains the inputs for all types of flow
+ * A struct contains the inputs for all types of flow
*/
-union rte_eth_fdir_flow {
- struct rte_eth_l2_flow l2_flow;
- struct rte_eth_udpv4_flow udp4_flow;
- struct rte_eth_tcpv4_flow tcp4_flow;
- struct rte_eth_sctpv4_flow sctp4_flow;
- struct rte_eth_ipv4_flow ip4_flow;
- struct rte_eth_udpv6_flow udp6_flow;
- struct rte_eth_tcpv6_flow tcp6_flow;
- struct rte_eth_sctpv6_flow sctp6_flow;
- struct rte_eth_ipv6_flow ipv6_flow;
+struct rte_eth_fdir_flow {
+ union {
+ struct rte_eth_l2_flow l2_flow;
+ struct rte_eth_udpv4_flow udp4_flow;
+ struct rte_eth_tcpv4_flow tcp4_flow;
+ struct rte_eth_sctpv4_flow sctp4_flow;
+ struct rte_eth_ipv4_flow ip4_flow;
+ struct rte_eth_udpv6_flow udp6_flow;
+ struct rte_eth_tcpv6_flow tcp6_flow;
+ struct rte_eth_sctpv6_flow sctp6_flow;
+ struct rte_eth_ipv6_flow ipv6_flow;
+ };
struct rte_eth_mac_vlan_flow mac_vlan_flow;
struct rte_eth_tunnel_flow tunnel_flow;
};
@@ -540,7 +543,7 @@ struct rte_eth_fdir_flow_ext {
*/
struct rte_eth_fdir_input {
uint16_t flow_type;
- union rte_eth_fdir_flow flow;
+ struct rte_eth_fdir_flow flow;
/**< Flow fields to match, dependent on flow_type */
struct rte_eth_fdir_flow_ext flow_ext;
/**< Additional fields to match */
--
2.4.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/2] librte_pipeline: add support for packet redirection at action handlers
@ 2016-01-25 14:11 3% Jasvinder Singh
0 siblings, 0 replies; 200+ results
From: Jasvinder Singh @ 2016-01-25 14:11 UTC (permalink / raw)
To: dev
Currently, there is no mechanism that allows the pipeline ports (in/out) and
table action handlers to override the default forwarding decision (as
previously configured per input port or in the table entry). Therefore, new
pipeline API functions have been added which allows action handlers to
hijack packets and remove them from the pipeline processing, and then either
drop them or send them out of the pipeline on any output port. The port
(in/out) and table action handler prototypes have been changed for making
use of these new API functions. This feature will be helpful to implement
functions such as exception handling (e.g. TTL =0), load balancing etc.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -
doc/guides/rel_notes/release_2_3.rst | 5 +-
lib/librte_pipeline/Makefile | 4 +-
lib/librte_pipeline/rte_pipeline.c | 461 ++++++++++++++-------------
lib/librte_pipeline/rte_pipeline.h | 98 +++---
lib/librte_pipeline/rte_pipeline_version.map | 8 +
6 files changed, 307 insertions(+), 274 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..1a7d660 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -40,11 +40,6 @@ Deprecation Notices
* The scheduler statistics structure will change to allow keeping track of
RED actions.
-* librte_pipeline: The prototype for the pipeline input port, output port
- and table action handlers will be updated:
- the pipeline parameter will be added, the packets mask parameter will be
- either removed (for input port action handler) or made input-only.
-
* ABI changes are planned in cmdline buffer size to allow the use of long
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..eb27643 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,9 @@ API Changes
ABI Changes
-----------
+* librte_pipeline: The prototype for the pipeline input port, output port
+ and table action handlers are updated:the pipeline parameter is added,
+ the packets mask parameter has been either removed or made input-only.
Shared Library Versions
-----------------------
@@ -63,7 +66,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_mbuf.so.2
librte_mempool.so.1
librte_meter.so.1
- librte_pipeline.so.2
+ + librte_pipeline.so.3
librte_pmd_bond.so.1
librte_pmd_ring.so.2
librte_port.so.2
diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile
index 1166d3c..822fd41 100644
--- a/lib/librte_pipeline/Makefile
+++ b/lib/librte_pipeline/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_pipeline_version.map
-LIBABIVER := 2
+LIBABIVER := 3
#
# all source are stored in SRCS-y
diff --git a/lib/librte_pipeline/rte_pipeline.c b/lib/librte_pipeline/rte_pipeline.c
index d625fd2..87f7634 100644
--- a/lib/librte_pipeline/rte_pipeline.c
+++ b/lib/librte_pipeline/rte_pipeline.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -49,14 +49,30 @@
#define RTE_TABLE_INVALID UINT32_MAX
#ifdef RTE_PIPELINE_STATS_COLLECT
-#define RTE_PIPELINE_STATS_ADD(counter, val) \
- ({ (counter) += (val); })
-#define RTE_PIPELINE_STATS_ADD_M(counter, mask) \
- ({ (counter) += __builtin_popcountll(mask); })
+#define RTE_PIPELINE_STATS_AH_DROP_WRITE(p, mask) \
+ ({ (p)->n_pkts_ah_drop = __builtin_popcountll(mask); })
+
+#define RTE_PIPELINE_STATS_AH_DROP_READ(p, counter) \
+ ({ (counter) += (p)->n_pkts_ah_drop; (p)->n_pkts_ah_drop = 0; })
+
+#define RTE_PIPELINE_STATS_TABLE_DROP0(p) \
+ ({ (p)->pkts_drop_mask = (p)->action_mask0[RTE_PIPELINE_ACTION_DROP]; })
+
+#define RTE_PIPELINE_STATS_TABLE_DROP1(p, counter) \
+({ \
+ uint64_t mask = (p)->action_mask0[RTE_PIPELINE_ACTION_DROP]; \
+ mask ^= (p)->pkts_drop_mask; \
+ (counter) += __builtin_popcountll(mask); \
+})
+
#else
-#define RTE_PIPELINE_STATS_ADD(counter, val)
-#define RTE_PIPELINE_STATS_ADD_M(counter, mask)
+
+#define RTE_PIPELINE_STATS_AH_DROP_WRITE(p, mask)
+#define RTE_PIPELINE_STATS_AH_DROP_READ(p, counter)
+#define RTE_PIPELINE_STATS_TABLE_DROP0(p)
+#define RTE_PIPELINE_STATS_TABLE_DROP1(p, counter)
+
#endif
struct rte_port_in {
@@ -75,6 +91,7 @@ struct rte_port_in {
/* List of enabled ports */
struct rte_port_in *next;
+ /* Statistics */
uint64_t n_pkts_dropped_by_ah;
};
@@ -82,12 +99,12 @@ struct rte_port_out {
/* Input parameters */
struct rte_port_out_ops ops;
rte_pipeline_port_out_action_handler f_action;
- rte_pipeline_port_out_action_handler_bulk f_action_bulk;
void *arg_ah;
/* Handle to low-level port */
void *h_port;
+ /* Statistics */
uint64_t n_pkts_dropped_by_ah;
};
@@ -106,7 +123,7 @@ struct rte_table {
/* Handle to the low-level table object */
void *h_table;
- /* Stats for this table. */
+ /* Statistics */
uint64_t n_pkts_dropped_by_lkp_hit_ah;
uint64_t n_pkts_dropped_by_lkp_miss_ah;
uint64_t n_pkts_dropped_lkp_hit;
@@ -133,13 +150,16 @@ struct rte_pipeline {
/* List of enabled ports */
uint64_t enabled_port_in_mask;
- struct rte_port_in *port_in_first;
+ struct rte_port_in *port_in_next;
/* Pipeline run structures */
struct rte_mbuf *pkts[RTE_PORT_IN_BURST_SIZE_MAX];
struct rte_pipeline_table_entry *entries[RTE_PORT_IN_BURST_SIZE_MAX];
uint64_t action_mask0[RTE_PIPELINE_ACTIONS];
uint64_t action_mask1[RTE_PIPELINE_ACTIONS];
+ uint64_t pkts_mask;
+ uint64_t n_pkts_ah_drop;
+ uint64_t pkts_drop_mask;
} __rte_cache_aligned;
static inline uint32_t
@@ -234,7 +254,9 @@ rte_pipeline_create(struct rte_pipeline_params *params)
p->num_ports_out = 0;
p->num_tables = 0;
p->enabled_port_in_mask = 0;
- p->port_in_first = NULL;
+ p->port_in_next = NULL;
+ p->pkts_mask = 0;
+ p->n_pkts_ah_drop = 0;
return p;
}
@@ -759,9 +781,6 @@ rte_pipeline_port_out_check_params(struct rte_pipeline *p,
struct rte_pipeline_port_out_params *params,
uint32_t *port_id)
{
- rte_pipeline_port_out_action_handler f_ah;
- rte_pipeline_port_out_action_handler_bulk f_ah_bulk;
-
if (p == NULL) {
RTE_LOG(ERR, PIPELINE, "%s: pipeline parameter NULL\n",
__func__);
@@ -794,7 +813,7 @@ rte_pipeline_port_out_check_params(struct rte_pipeline *p,
if (params->ops->f_tx == NULL) {
RTE_LOG(ERR, PIPELINE,
- "%s: f_tx function pointer NULL\n", __func__);
+ "%s: f_tx function pointer NULL\n", __func__);
return -EINVAL;
}
@@ -804,15 +823,6 @@ rte_pipeline_port_out_check_params(struct rte_pipeline *p,
return -EINVAL;
}
- f_ah = params->f_action;
- f_ah_bulk = params->f_action_bulk;
- if (((f_ah != NULL) && (f_ah_bulk == NULL)) ||
- ((f_ah == NULL) && (f_ah_bulk != NULL))) {
- RTE_LOG(ERR, PIPELINE, "%s: Action handlers have to be either"
- "both enabled or both disabled\n", __func__);
- return -EINVAL;
- }
-
/* Do we have room for one more port? */
if (p->num_ports_out == RTE_PIPELINE_PORT_OUT_MAX) {
RTE_LOG(ERR, PIPELINE,
@@ -905,7 +915,6 @@ rte_pipeline_port_out_create(struct rte_pipeline *p,
/* Save input parameters */
memcpy(&port->ops, params->ops, sizeof(struct rte_port_out_ops));
port->f_action = params->f_action;
- port->f_action_bulk = params->f_action_bulk;
port->arg_ah = params->arg_ah;
/* Initialize port internal data structure */
@@ -959,9 +968,8 @@ int
rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
{
struct rte_port_in *port, *port_prev, *port_next;
- struct rte_port_in *port_first, *port_last;
uint64_t port_mask;
- uint32_t port_prev_id, port_next_id, port_first_id, port_last_id;
+ uint32_t port_prev_id, port_next_id;
/* Check input arguments */
if (p == NULL) {
@@ -977,6 +985,8 @@ rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
return -EINVAL;
}
+ port = &p->ports_in[port_id];
+
/* Return if current input port is already enabled */
port_mask = 1LLU << port_id;
if (p->enabled_port_in_mask & port_mask)
@@ -990,20 +1000,13 @@ rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
port_prev = &p->ports_in[port_prev_id];
port_next = &p->ports_in[port_next_id];
- port = &p->ports_in[port_id];
port_prev->next = port;
port->next = port_next;
- /* Update the first and last input ports in the chain */
- port_first_id = __builtin_ctzll(p->enabled_port_in_mask);
- port_last_id = 63 - __builtin_clzll(p->enabled_port_in_mask);
-
- port_first = &p->ports_in[port_first_id];
- port_last = &p->ports_in[port_last_id];
-
- p->port_in_first = port_first;
- port_last->next = NULL;
+ /* Check if list of enabled ports was previously empty */
+ if (p->enabled_port_in_mask == port_mask)
+ p->port_in_next = port;
return 0;
}
@@ -1011,9 +1014,9 @@ rte_pipeline_port_in_enable(struct rte_pipeline *p, uint32_t port_id)
int
rte_pipeline_port_in_disable(struct rte_pipeline *p, uint32_t port_id)
{
- struct rte_port_in *port_prev, *port_next, *port_first, *port_last;
+ struct rte_port_in *port, *port_prev, *port_next;
uint64_t port_mask;
- uint32_t port_prev_id, port_next_id, port_first_id, port_last_id;
+ uint32_t port_prev_id, port_next_id;
/* Check input arguments */
if (p == NULL) {
@@ -1028,15 +1031,18 @@ rte_pipeline_port_in_disable(struct rte_pipeline *p, uint32_t port_id)
return -EINVAL;
}
+ port = &p->ports_in[port_id];
+
/* Return if current input port is already disabled */
port_mask = 1LLU << port_id;
if ((p->enabled_port_in_mask & port_mask) == 0)
return 0;
+ p->enabled_port_in_mask &= ~port_mask;
+
/* Return if no other enabled ports */
- if (__builtin_popcountll(p->enabled_port_in_mask) == 1) {
- p->enabled_port_in_mask &= ~port_mask;
- p->port_in_first = NULL;
+ if (p->enabled_port_in_mask == 0) {
+ p->port_in_next = NULL;
return 0;
}
@@ -1049,17 +1055,10 @@ rte_pipeline_port_in_disable(struct rte_pipeline *p, uint32_t port_id)
port_next = &p->ports_in[port_next_id];
port_prev->next = port_next;
- p->enabled_port_in_mask &= ~port_mask;
-
- /* Update the first and last input ports in the chain */
- port_first_id = __builtin_ctzll(p->enabled_port_in_mask);
- port_last_id = 63 - __builtin_clzll(p->enabled_port_in_mask);
-
- port_first = &p->ports_in[port_first_id];
- port_last = &p->ports_in[port_last_id];
- p->port_in_first = port_first;
- port_last->next = NULL;
+ /* Check if the port which has just been disabled is next to serve */
+ if (port == p->port_in_next)
+ p->port_in_next = port_next;
return 0;
}
@@ -1149,28 +1148,32 @@ rte_pipeline_compute_masks(struct rte_pipeline *p, uint64_t pkts_mask)
static inline void
rte_pipeline_action_handler_port_bulk(struct rte_pipeline *p,
- uint64_t pkts_mask, uint32_t port_id)
+ uint64_t pkts_mask, uint32_t port_id)
{
struct rte_port_out *port_out = &p->ports_out[port_id];
+ p->pkts_mask = pkts_mask;
+
/* Output port user actions */
- if (port_out->f_action_bulk != NULL) {
- uint64_t mask = pkts_mask;
+ if (port_out->f_action != NULL) {
+ port_out->f_action(p, p->pkts, pkts_mask, port_out->arg_ah);
- port_out->f_action_bulk(p->pkts, &pkts_mask, port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= pkts_mask ^ mask;
- RTE_PIPELINE_STATS_ADD_M(port_out->n_pkts_dropped_by_ah,
- pkts_mask ^ mask);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
}
/* Output port TX */
- if (pkts_mask != 0)
- port_out->ops.f_tx_bulk(port_out->h_port, p->pkts, pkts_mask);
+ if (p->pkts_mask != 0)
+ port_out->ops.f_tx_bulk(port_out->h_port,
+ p->pkts,
+ p->pkts_mask);
}
static inline void
rte_pipeline_action_handler_port(struct rte_pipeline *p, uint64_t pkts_mask)
{
+ p->pkts_mask = pkts_mask;
+
if ((pkts_mask & (pkts_mask + 1)) == 0) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t i;
@@ -1185,18 +1188,18 @@ rte_pipeline_action_handler_port(struct rte_pipeline *p, uint64_t pkts_mask)
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- uint64_t pkt_mask = 1LLU;
+ uint64_t pkt_mask = 1LLU << i;
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1LLU);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1221,18 +1224,16 @@ rte_pipeline_action_handler_port(struct rte_pipeline *p, uint64_t pkts_mask)
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- pkt_mask = 1LLU;
-
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1LLU);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1244,6 +1245,8 @@ static inline void
rte_pipeline_action_handler_port_meta(struct rte_pipeline *p,
uint64_t pkts_mask)
{
+ p->pkts_mask = pkts_mask;
+
if ((pkts_mask & (pkts_mask + 1)) == 0) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t i;
@@ -1260,18 +1263,18 @@ rte_pipeline_action_handler_port_meta(struct rte_pipeline *p,
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- uint64_t pkt_mask = 1LLU;
+ uint64_t pkt_mask = 1LLU << i;
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1ULL);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1297,18 +1300,16 @@ rte_pipeline_action_handler_port_meta(struct rte_pipeline *p,
if (port_out->f_action == NULL) /* Output port TX */
port_out->ops.f_tx(port_out->h_port, pkt);
else {
- pkt_mask = 1LLU;
-
- port_out->f_action(pkt, &pkt_mask,
+ port_out->f_action(p,
+ p->pkts,
+ pkt_mask,
port_out->arg_ah);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- (pkt_mask ^ 1LLU) << i;
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah,
- pkt_mask ^ 1ULL);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_out->n_pkts_dropped_by_ah);
/* Output port TX */
- if (pkt_mask != 0)
+ if (pkt_mask & p->pkts_mask)
port_out->ops.f_tx(port_out->h_port,
pkt);
}
@@ -1342,136 +1343,140 @@ rte_pipeline_action_handler_drop(struct rte_pipeline *p, uint64_t pkts_mask)
int
rte_pipeline_run(struct rte_pipeline *p)
{
- struct rte_port_in *port_in;
-
- for (port_in = p->port_in_first; port_in != NULL;
- port_in = port_in->next) {
- uint64_t pkts_mask;
- uint32_t n_pkts, table_id;
-
- /* Input port RX */
- n_pkts = port_in->ops.f_rx(port_in->h_port, p->pkts,
- port_in->burst_size);
- if (n_pkts == 0)
- continue;
-
- pkts_mask = RTE_LEN2MASK(n_pkts, uint64_t);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] = 0;
- p->action_mask0[RTE_PIPELINE_ACTION_PORT] = 0;
- p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] = 0;
- p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
+ struct rte_port_in *port_in = p->port_in_next;
+ uint32_t n_pkts, table_id;
- /* Input port user actions */
- if (port_in->f_action != NULL) {
- uint64_t mask = pkts_mask;
+ if (port_in == NULL)
+ return 0;
- port_in->f_action(p->pkts, n_pkts, &pkts_mask, port_in->arg_ah);
- mask ^= pkts_mask;
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= mask;
- RTE_PIPELINE_STATS_ADD_M(port_in->n_pkts_dropped_by_ah, mask);
- }
+ /* Input port RX */
+ n_pkts = port_in->ops.f_rx(port_in->h_port, p->pkts,
+ port_in->burst_size);
+ if (n_pkts == 0) {
+ p->port_in_next = port_in->next;
+ return 0;
+ }
- /* Table */
- for (table_id = port_in->table_id; pkts_mask != 0; ) {
- struct rte_table *table;
- uint64_t lookup_hit_mask, lookup_miss_mask;
-
- /* Lookup */
- table = &p->tables[table_id];
- table->ops.f_lookup(table->h_table, p->pkts, pkts_mask,
- &lookup_hit_mask, (void **) p->entries);
- lookup_miss_mask = pkts_mask & (~lookup_hit_mask);
-
- /* Lookup miss */
- if (lookup_miss_mask != 0) {
- struct rte_pipeline_table_entry *default_entry =
- table->default_entry;
-
- /* Table user actions */
- if (table->f_action_miss != NULL) {
- uint64_t mask = lookup_miss_mask;
-
- table->f_action_miss(p->pkts,
- &lookup_miss_mask,
- default_entry, table->arg_ah);
- mask ^= lookup_miss_mask;
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= mask;
- RTE_PIPELINE_STATS_ADD_M(
- table->n_pkts_dropped_by_lkp_miss_ah, mask);
- }
-
- /* Table reserved actions */
- if ((default_entry->action ==
- RTE_PIPELINE_ACTION_PORT) &&
- (lookup_miss_mask != 0))
- rte_pipeline_action_handler_port_bulk(p,
- lookup_miss_mask,
- default_entry->port_id);
- else {
- uint32_t pos = default_entry->action;
-
- p->action_mask0[pos] = lookup_miss_mask;
- if (pos == RTE_PIPELINE_ACTION_DROP) {
- RTE_PIPELINE_STATS_ADD_M(table->n_pkts_dropped_lkp_miss,
- lookup_miss_mask);
- }
- }
- }
+ p->pkts_mask = RTE_LEN2MASK(n_pkts, uint64_t);
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP] = 0;
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT] = 0;
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] = 0;
+ p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
+
+ /* Input port user actions */
+ if (port_in->f_action != NULL) {
+ port_in->f_action(p, p->pkts, n_pkts, port_in->arg_ah);
+
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ port_in->n_pkts_dropped_by_ah);
+ }
+
+ /* Table */
+ for (table_id = port_in->table_id; p->pkts_mask != 0; ) {
+ struct rte_table *table;
+ uint64_t lookup_hit_mask, lookup_miss_mask;
+
+ /* Lookup */
+ table = &p->tables[table_id];
+ table->ops.f_lookup(table->h_table, p->pkts, p->pkts_mask,
+ &lookup_hit_mask, (void **) p->entries);
+ lookup_miss_mask = p->pkts_mask & (~lookup_hit_mask);
+
+ /* Lookup miss */
+ if (lookup_miss_mask != 0) {
+ struct rte_pipeline_table_entry *default_entry =
+ table->default_entry;
+
+ p->pkts_mask = lookup_miss_mask;
- /* Lookup hit */
- if (lookup_hit_mask != 0) {
- /* Table user actions */
- if (table->f_action_hit != NULL) {
- uint64_t mask = lookup_hit_mask;
-
- table->f_action_hit(p->pkts,
- &lookup_hit_mask,
- p->entries, table->arg_ah);
- mask ^= lookup_hit_mask;
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= mask;
- RTE_PIPELINE_STATS_ADD_M(
- table->n_pkts_dropped_by_lkp_hit_ah, mask);
- }
-
- /* Table reserved actions */
- rte_pipeline_compute_masks(p, lookup_hit_mask);
- p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_DROP];
- p->action_mask0[RTE_PIPELINE_ACTION_PORT] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_PORT];
- p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_PORT_META];
- p->action_mask0[RTE_PIPELINE_ACTION_TABLE] |=
- p->action_mask1[
- RTE_PIPELINE_ACTION_TABLE];
-
- RTE_PIPELINE_STATS_ADD_M(table->n_pkts_dropped_lkp_hit,
- p->action_mask1[RTE_PIPELINE_ACTION_DROP]);
+ /* Table user actions */
+ if (table->f_action_miss != NULL) {
+ table->f_action_miss(p,
+ p->pkts,
+ lookup_miss_mask,
+ default_entry,
+ table->arg_ah);
+
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ table->n_pkts_dropped_by_lkp_miss_ah);
}
- /* Prepare for next iteration */
- pkts_mask = p->action_mask0[RTE_PIPELINE_ACTION_TABLE];
- table_id = table->table_next_id;
- p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
+ /* Table reserved actions */
+ if ((default_entry->action == RTE_PIPELINE_ACTION_PORT) &&
+ (p->pkts_mask != 0))
+ rte_pipeline_action_handler_port_bulk(p,
+ p->pkts_mask,
+ default_entry->port_id);
+ else {
+ uint32_t pos = default_entry->action;
+
+ RTE_PIPELINE_STATS_TABLE_DROP0(p);
+
+ p->action_mask0[pos] |= p->pkts_mask;
+
+ RTE_PIPELINE_STATS_TABLE_DROP1(p,
+ table->n_pkts_dropped_lkp_miss);
+ }
}
- /* Table reserved action PORT */
- rte_pipeline_action_handler_port(p,
- p->action_mask0[RTE_PIPELINE_ACTION_PORT]);
+ /* Lookup hit */
+ if (lookup_hit_mask != 0) {
+ p->pkts_mask = lookup_hit_mask;
- /* Table reserved action PORT META */
- rte_pipeline_action_handler_port_meta(p,
- p->action_mask0[RTE_PIPELINE_ACTION_PORT_META]);
+ /* Table user actions */
+ if (table->f_action_hit != NULL) {
+ table->f_action_hit(p,
+ p->pkts,
+ lookup_hit_mask,
+ p->entries,
+ table->arg_ah);
- /* Table reserved action DROP */
- rte_pipeline_action_handler_drop(p,
- p->action_mask0[RTE_PIPELINE_ACTION_DROP]);
+ RTE_PIPELINE_STATS_AH_DROP_READ(p,
+ table->n_pkts_dropped_by_lkp_hit_ah);
+ }
+
+ /* Table reserved actions */
+ RTE_PIPELINE_STATS_TABLE_DROP0(p);
+ rte_pipeline_compute_masks(p, p->pkts_mask);
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_DROP];
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_PORT];
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT_META] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_PORT_META];
+ p->action_mask0[RTE_PIPELINE_ACTION_TABLE] |=
+ p->action_mask1[
+ RTE_PIPELINE_ACTION_TABLE];
+
+ RTE_PIPELINE_STATS_TABLE_DROP1(p,
+ table->n_pkts_dropped_lkp_hit);
+ }
+
+ /* Prepare for next iteration */
+ p->pkts_mask = p->action_mask0[RTE_PIPELINE_ACTION_TABLE];
+ table_id = table->table_next_id;
+ p->action_mask0[RTE_PIPELINE_ACTION_TABLE] = 0;
}
- return 0;
+ /* Table reserved action PORT */
+ rte_pipeline_action_handler_port(p,
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT]);
+
+ /* Table reserved action PORT META */
+ rte_pipeline_action_handler_port_meta(p,
+ p->action_mask0[RTE_PIPELINE_ACTION_PORT_META]);
+
+ /* Table reserved action DROP */
+ rte_pipeline_action_handler_drop(p,
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP]);
+
+ /* Pick candidate for next port IN to serve */
+ p->port_in_next = port_in->next;
+
+ return n_pkts;
}
int
@@ -1498,26 +1503,32 @@ rte_pipeline_flush(struct rte_pipeline *p)
int
rte_pipeline_port_out_packet_insert(struct rte_pipeline *p,
- uint32_t port_id, struct rte_mbuf *pkt)
+ uint32_t port_id, struct rte_mbuf *pkt)
{
struct rte_port_out *port_out = &p->ports_out[port_id];
- /* Output port user actions */
- if (port_out->f_action == NULL)
- port_out->ops.f_tx(port_out->h_port, pkt); /* Output port TX */
- else {
- uint64_t pkt_mask = 1LLU;
-
- port_out->f_action(pkt, &pkt_mask, port_out->arg_ah);
-
- if (pkt_mask != 0) /* Output port TX */
- port_out->ops.f_tx(port_out->h_port, pkt);
- else {
- rte_pktmbuf_free(pkt);
- RTE_PIPELINE_STATS_ADD(port_out->n_pkts_dropped_by_ah, 1);
- }
- }
+ port_out->ops.f_tx(port_out->h_port, pkt); /* Output port TX */
+
+ return 0;
+}
+
+int rte_pipeline_ah_packet_hijack(struct rte_pipeline *p,
+ uint64_t pkts_mask)
+{
+ pkts_mask &= p->pkts_mask;
+ p->pkts_mask &= ~pkts_mask;
+
+ return 0;
+}
+
+int rte_pipeline_ah_packet_drop(struct rte_pipeline *p,
+ uint64_t pkts_mask)
+{
+ pkts_mask &= p->pkts_mask;
+ p->pkts_mask &= ~pkts_mask;
+ p->action_mask0[RTE_PIPELINE_ACTION_DROP] |= pkts_mask;
+ RTE_PIPELINE_STATS_AH_DROP_WRITE(p, pkts_mask);
return 0;
}
diff --git a/lib/librte_pipeline/rte_pipeline.h b/lib/librte_pipeline/rte_pipeline.h
index 5459324..ec3c2ea 100644
--- a/lib/librte_pipeline/rte_pipeline.h
+++ b/lib/librte_pipeline/rte_pipeline.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -263,6 +263,8 @@ struct rte_pipeline_table_entry {
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
@@ -283,8 +285,9 @@ struct rte_pipeline_table_entry {
* 0 on success, error code otherwise
*/
typedef int (*rte_pipeline_table_action_handler_hit)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
- uint64_t *pkts_mask,
+ uint64_t pkts_mask,
struct rte_pipeline_table_entry **entries,
void *arg);
@@ -296,6 +299,8 @@ typedef int (*rte_pipeline_table_action_handler_hit)(
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
@@ -316,8 +321,9 @@ typedef int (*rte_pipeline_table_action_handler_hit)(
* 0 on success, error code otherwise
*/
typedef int (*rte_pipeline_table_action_handler_miss)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
- uint64_t *pkts_mask,
+ uint64_t pkts_mask,
struct rte_pipeline_table_entry *entry,
void *arg);
@@ -565,16 +571,14 @@ int rte_pipeline_table_stats_read(struct rte_pipeline *p, uint32_t table_id,
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
* @param n
* Number of packets in the input burst. This parameter specifies that
* elements 0 to (n-1) of pkts array are valid.
- * @param pkts_mask
- * 64-bit bitmask specifying which packets in the input burst are still valid
- * after the action handler is executed. When pkts_mask bit n is set, then
- * element n of pkts array is pointing to a valid packet.
* @param arg
* Opaque parameter registered by the user at the pipeline table creation
* time
@@ -582,9 +586,9 @@ int rte_pipeline_table_stats_read(struct rte_pipeline *p, uint32_t table_id,
* 0 on success, error code otherwise
*/
typedef int (*rte_pipeline_port_in_action_handler)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
uint32_t n,
- uint64_t *pkts_mask,
void *arg);
/** Parameters for pipeline input port creation */
@@ -692,29 +696,6 @@ int rte_pipeline_port_in_stats_read(struct rte_pipeline *p, uint32_t port_id,
#define RTE_PIPELINE_PORT_OUT_MAX 64
/**
- * Pipeline output port action handler for single packet
- *
- * The action handler can decide to drop packets by resetting the pkt_mask
- * argument. In this case, the action handler is required not to free the
- * packet buffer, which will be freed eventually by the pipeline.
- *
- * @param pkt
- * Input packet
- * @param pkt_mask
- * Output argument set to 0 when the action handler decides to drop the input
- * packet and to 1LLU otherwise
- * @param arg
- * Opaque parameter registered by the user at the pipeline table creation
- * time
- * @return
- * 0 on success, error code otherwise
- */
-typedef int (*rte_pipeline_port_out_action_handler)(
- struct rte_mbuf *pkt,
- uint64_t *pkt_mask,
- void *arg);
-
-/**
* Pipeline output port action handler bulk
*
* The action handler can decide to drop packets by resetting the associated
@@ -722,22 +703,21 @@ typedef int (*rte_pipeline_port_out_action_handler)(
* required not to free the packet buffer, which will be freed eventually by
* the pipeline.
*
+ * @param p
+ * Handle to pipeline instance
* @param pkts
* Burst of input packets specified as array of up to 64 pointers to struct
* rte_mbuf
- * @param pkts_mask
- * 64-bit bitmask specifying which packets in the input burst are valid. When
- * pkts_mask bit n is set, then element n of pkts array is pointing to a
- * valid packet. Otherwise, element n of pkts array will not be accessed.
* @param arg
* Opaque parameter registered by the user at the pipeline table creation
* time
* @return
* 0 on success, error code otherwise
*/
-typedef int (*rte_pipeline_port_out_action_handler_bulk)(
+typedef int (*rte_pipeline_port_out_action_handler)(
+ struct rte_pipeline *p,
struct rte_mbuf **pkts,
- uint64_t *pkts_mask,
+ uint64_t pkts_mask,
void *arg);
/** Parameters for pipeline output port creation. The action handlers have to
@@ -750,12 +730,9 @@ struct rte_pipeline_port_out_params {
/** Opaque parameter to be passed to create operation when invoked */
void *arg_create;
- /** Callback function executing the user actions on single input
- packet */
- rte_pipeline_port_out_action_handler f_action;
/** Callback function executing the user actions on bust of input
packets */
- rte_pipeline_port_out_action_handler_bulk f_action_bulk;
+ rte_pipeline_port_out_action_handler f_action;
/** Opaque parameter to be passed to the action handler when invoked */
void *arg_ah;
};
@@ -802,6 +779,45 @@ int rte_pipeline_port_out_packet_insert(struct rte_pipeline *p,
struct rte_mbuf *pkt);
/**
+ * Pipeline packet hijack
+ *
+ * This function is called by the pipeline action handlers (port in/out, table)
+ * to hijack the packets selected using packet mask. The hijacked packets will
+ * no longer bethe part of the burst of packets undergoing pipeline processing.
+ * The hijacked packets can either be dropped or sent out of the pipeline on
+ * any output port by the action handler.
+ *
+ * @param p
+ * Handle to pipeline instance
+ * @param pkt_mask
+ * 64-bit bitmask specifying which packets in the input burst are valid. When
+ * pkts_mask bit n is set, then element n of pkts array is pointing to a
+ * valid packet. Otherwise, element n of pkts array will not be accessed.
+ * @return
+ * 0 on success, error code otherwise
+ */
+int rte_pipeline_ah_packet_hijack(struct rte_pipeline *p,
+ uint64_t pkts_mask);
+
+/**
+ * Pipeline packet drop
+ *
+ * This function is called by the pipeline action handlers (port in/out, table)
+ * to drop the packets selected using packet mask.
+ *
+ * @param p
+ * Handle to pipeline instance
+ * @param pkts_mask
+ * 64-bit bitmask specifying which packets in the input burst are valid. When
+ * pkts_mask bit n is set, then element n of pkts array is pointing to a
+ * valid packet. Otherwise, element n of pkts array will not be accessed.
+ * @return
+ * 0 on success, error code otherwise
+ */
+int rte_pipeline_ah_packet_drop(struct rte_pipeline *p,
+ uint64_t pkts_mask);
+
+/**
* Read pipeline port out stats.
*
* This function reads port out statistics identified by *port_id* of given
diff --git a/lib/librte_pipeline/rte_pipeline_version.map b/lib/librte_pipeline/rte_pipeline_version.map
index 4cc86f6..e4ee154 100644
--- a/lib/librte_pipeline/rte_pipeline_version.map
+++ b/lib/librte_pipeline/rte_pipeline_version.map
@@ -37,3 +37,11 @@ DPDK_2.2 {
rte_pipeline_table_entry_delete_bulk;
} DPDK_2.1;
+
+DPDK_16.04 {
+ global:
+
+ rte_pipeline_ah_packet_hijack;
+ rte_pipeline_ah_packet_drop;
+
+} DPDK_2.2;
--
2.5.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] PCI: ABI change request for adding new field in rte_pci_id structure
@ 2016-01-25 2:36 9% Ziye Yang
2016-02-16 4:15 15% ` [dpdk-dev] [PATCH v2] " Ziye Yang
0 siblings, 1 reply; 200+ results
From: Ziye Yang @ 2016-01-25 2:36 UTC (permalink / raw)
To: dev; +Cc: Ziye
From: Ziye <ziye.yang@intel.com>
The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.
Signed-off-by: Ziye Yang <ziye.yang@intel.com>
---
doc/guides/rel_notes/release_2_3.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..8fcb43f 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ API Changes
ABI Changes
-----------
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+ added ``class`` field can be used to probe pci devices by class related
+ info. With this new field, the size of structure ``rte_pci_device`` will
+ be increased.
Shared Library Versions
-----------------------
--
1.9.3
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-01-22 15:22 3% ` Van Haaren, Harry
2016-01-22 15:53 0% ` Jay Rolette
@ 2016-01-22 16:04 0% ` David Harton (dharton)
1 sibling, 1 reply; 200+ results
From: David Harton (dharton) @ 2016-01-22 16:04 UTC (permalink / raw)
To: Van Haaren, Harry, Thomas Monjalon; +Cc: dev
> > xstats are driver agnostic and have a well-defined naming scheme.
>
> Indeed, described here:
> http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-
> statistics-api
Thanks for sharing. I do think what is in the link is well thought out but it also may not match how the application would choose to represent that stat (capitalization, abbreviation, etc).
> From: David Harton:
> > For example, what if there was a kind of "stats registry" composed of
> > ID and name. It would work similar to xtats except instead of
> > advertising strings only the "get" API would return ID/count pairs.
> > If the application wishes to use the DPDK provided string they can
> > call another API to get the stat string via the ID. These IDs would
> > be well-defined clearly explaining what the count represent. This way
> > the strings for counts will be uniform across drivers and also make it
> clear to the users what the counts truly represent and the application
> could obtain stats from any driver in a driver agnostic manner.
>
> What you (David Harton) describe about a well-defined name, and clearly
> explaining the value it is representing is what the goal was for xstats: a
> human readable string, which can be easily parsed and a value retrieved.
>
> The "rules" of encoding a statistic as an xstats string are pretty simple,
> and if any PMD breaks the rules, it should be considered broken and fixed.
I understand it may be broken, but that doesn't help finding them and ensuring they aren't broken to begin with. What regression/automation is in place to ensure drivers aren't broken?
>
> Consistency is key, in this case consistency in the PMD xstats
> implementations to make it useful for clients of the API.
>
> The big advantage xstats has over adding items to rte_eth_stats is that it
> won't break ABI.
100% agree. I can see the intent.
>
> Do you see a fundamental problem with parsing the strings to retrieve
> values?
I think parsing strings is expensive CPU wise and again subject to error as devices are added. That's why I was wondering if a binary id could be generated instead. The binary id could also be used to look up the string name if the application wants it. The API would be very similar to the current xstats API except it would pass id/value pairs instead of string/value pairs. This avoids string comparisons to figure out while still allowing flexibility between drivers. It would also 100% guarantee that any strings returned by "const char* rte_eth_xstats_str_get(uint32_t stat_id)" are consistent across devices.
I also think there is less chance for error if drivers assign their stats to ID versus constructing a string. I haven't checked my application, but I wonder if the binary size would actually be smaller if all the stats strings were centrally located versus distributed across binaries (highly dependent on the linker and optimization level).
>
> If you like I could code up a minimal sample-app that only pulls
> statistics, and you can show "interest" in various statistics for printing
> / monitoring?
Appreciate the offer. I actually understand what's is available. And, BTW, I apologize for being late to the game (looks like this was discussed last summer) but I'm just now getting looped in and following the mailer but I'm just wondering if something that is performance friendly for the user/application and flexible for the drivers is possible.
Thanks,
Dave
>
>
> Regards, -Harry
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
2016-01-22 15:22 3% ` Van Haaren, Harry
@ 2016-01-22 15:53 0% ` Jay Rolette
2016-01-22 16:04 0% ` David Harton (dharton)
1 sibling, 0 replies; 200+ results
From: Jay Rolette @ 2016-01-22 15:53 UTC (permalink / raw)
To: Van Haaren, Harry; +Cc: dev
On Fri, Jan 22, 2016 at 9:22 AM, Van Haaren, Harry <
harry.van.haaren@intel.com> wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> > + Harry
>
> Hey all,
>
> > xstats are driver agnostic and have a well-defined naming scheme.
>
> Indeed, described here:
>
> http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-statistics-api
>
> All of the rte_eth_stats statistics are presented in xstats consistently
> (independent of which PMD is running), as they are implemented in
> rte_ethdev.c:
> http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n1500
>
>
> From: David Harton:
> > For example, what if there was a kind of "stats registry" composed of ID
> and name. It
> > would work similar to xtats except instead of advertising strings only
> the "get" API would
> > return ID/count pairs. If the application wishes to use the DPDK
> provided string they can
> > call another API to get the stat string via the ID. These IDs would be
> well-defined
> > clearly explaining what the count represent. This way the strings for
> counts will be
> > uniform across drivers and also make it clear to the users what the
> counts truly represent
> > and the application could obtain stats from any driver in a driver
> agnostic manner.
>
> What you (David Harton) describe about a well-defined name, and clearly
> explaining the value
> it is representing is what the goal was for xstats: a human readable
> string, which can be
> easily parsed and a value retrieved.
>
> The "rules" of encoding a statistic as an xstats string are pretty simple,
> and if any PMD
> breaks the rules, it should be considered broken and fixed.
>
> Consistency is key, in this case consistency in the PMD xstats
> implementations to make it
> useful for clients of the API.
>
> The big advantage xstats has over adding items to rte_eth_stats is that it
> won't break ABI.
>
> Do you see a fundamental problem with parsing the strings to retrieve
> values?
>
When you have an appliance with a large number of ports and a large number
of stats that you need to collect, having to parse those strings constantly
is very slow compared to having fixed struct members or at least known ID
values.
Strings are also error prone. While they may be consistent at this point,
it is remarkably easy for them to get out of sync along the way. Using an
ID instead avoids that neatly.
Jay
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
@ 2016-01-22 15:22 3% ` Van Haaren, Harry
2016-01-22 15:53 0% ` Jay Rolette
2016-01-22 16:04 0% ` David Harton (dharton)
0 siblings, 2 replies; 200+ results
From: Van Haaren, Harry @ 2016-01-22 15:22 UTC (permalink / raw)
To: Thomas Monjalon, David Harton (dharton); +Cc: dev
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
> + Harry
Hey all,
> xstats are driver agnostic and have a well-defined naming scheme.
Indeed, described here:
http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-statistics-api
All of the rte_eth_stats statistics are presented in xstats consistently
(independent of which PMD is running), as they are implemented in rte_ethdev.c:
http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n1500
From: David Harton:
> For example, what if there was a kind of "stats registry" composed of ID and name. It
> would work similar to xtats except instead of advertising strings only the "get" API would
> return ID/count pairs. If the application wishes to use the DPDK provided string they can
> call another API to get the stat string via the ID. These IDs would be well-defined
> clearly explaining what the count represent. This way the strings for counts will be
> uniform across drivers and also make it clear to the users what the counts truly represent
> and the application could obtain stats from any driver in a driver agnostic manner.
What you (David Harton) describe about a well-defined name, and clearly explaining the value
it is representing is what the goal was for xstats: a human readable string, which can be
easily parsed and a value retrieved.
The "rules" of encoding a statistic as an xstats string are pretty simple, and if any PMD
breaks the rules, it should be considered broken and fixed.
Consistency is key, in this case consistency in the PMD xstats implementations to make it
useful for clients of the API.
The big advantage xstats has over adding items to rte_eth_stats is that it won't break ABI.
Do you see a fundamental problem with parsing the strings to retrieve values?
If you like I could code up a minimal sample-app that only pulls statistics,
and you can show "interest" in various statistics for printing / monitoring?
Regards, -Harry
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
2016-01-22 11:05 0% ` Ananyev, Konstantin
@ 2016-01-22 11:37 0% ` Andralojc, WojciechX
0 siblings, 0 replies; 200+ results
From: Andralojc, WojciechX @ 2016-01-22 11:37 UTC (permalink / raw)
To: Ananyev, Konstantin, Panu Matilainen; +Cc: dev
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Friday, January 22, 2016 11:05 AM
> To: Panu Matilainen; Andralojc, WojciechX
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel
> Architecture Model Specific Registers (MSR)...
>
> > -----Original Message-----
> > From: Panu Matilainen [mailto:pmatilai@redhat.com]
> > Sent: Friday, January 22, 2016 10:06 AM
> > To: Ananyev, Konstantin; Andralojc, WojciechX
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel
> Architecture Model Specific Registers (MSR)...
> >
> > On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote:
> > > Hi Panu,
> > >
> > >> -----Original Message-----
> > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu
> > >> Matilainen
> > >> Sent: Thursday, January 21, 2016 10:39 AM
> > >> To: Andralojc, WojciechX
> > >> Cc: dev@dpdk.org
> > >> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write
> Intel Architecture Model Specific Registers (MSR)...
> > >>
> > >> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
> > >>> Patch reworked.
> > >>>
> > >>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
> > >>> ---
> > >>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88
> +++++++++++++++++
> > >>> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> > >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116
> +++++++++++++++++++++++
> > >>> 3 files changed, 205 insertions(+)
> > >>> create mode 100644
> lib/librte_eal/common/include/arch/x86/rte_msr.h
> > >>> create mode 100644
> > >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
> > >>
> > >> This creates a new arch-specific public API, with rte_msr.h
> > >> installed as a public header and implementation in the library (as
> > >> opposed to inline), and so the new functions would have to be added
> > >> to rte_eal_version.map.
> > >>
> > >> However that is a bit of a problem since it only exists on IA
> > >> architectures, so it'd mean dummy entries in the version map for
> > >> all other architectures. All the other arch-specific APIs are
> > >> inline code so this is the first of its kind.
> > >
> > > My thought was:
> > > 1. implementation is linux specific (as I know not supposed to work under
> freebsd).
> > > 2. they are not supposed to be used at run-time cide-path, so no need to be
> inlined.
> >
> > Speed is not the only interesting attribute of inlining, inlined code
> > also effectively escapes the library ABI so it does not need
> > versioning / exporting.
> >
> > > 3. As I understand we plan to have a library that will use these functions
> anyway.
> >
> > Is this library going to be a generic or specific to Intel CPUs?
>
> As I understand - yes.
> It supposed to utilise new Intel chips CAT abilities.
> Wojciech, please correct me if I missed something here.
Konstantin, yes, you are right,
CAT enabling lib is Intel CPUs specific.
>
> > Also, if there are no other uses for the MSR API at the moment,
> > perhaps the best place for this code would be within that library anyway?
>
> Sounds good to me.
OK, sounds good.
Thank you both for your input.
>
> Konstantin
>
> >
> > > About dummy entries in the .map file: if we'll create a 'weak'
> > > generic implementation, that would just return an error - would it solve the
> issue?
> >
> > Sure it'd solve the issue of dummy entries in .map but people seemed
> > opposed to having a highly arch-specific API exposed to all architectures.
> >
> > - Panu -
> >
Wojciech Andralojc
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
2016-01-22 10:05 3% ` Panu Matilainen
@ 2016-01-22 11:05 0% ` Ananyev, Konstantin
2016-01-22 11:37 0% ` Andralojc, WojciechX
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-22 11:05 UTC (permalink / raw)
To: Panu Matilainen, Andralojc, WojciechX; +Cc: dev
> -----Original Message-----
> From: Panu Matilainen [mailto:pmatilai@redhat.com]
> Sent: Friday, January 22, 2016 10:06 AM
> To: Ananyev, Konstantin; Andralojc, WojciechX
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
>
> On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote:
> > Hi Panu,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> >> Sent: Thursday, January 21, 2016 10:39 AM
> >> To: Andralojc, WojciechX
> >> Cc: dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
> >>
> >> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
> >>> Patch reworked.
> >>>
> >>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
> >>> ---
> >>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88 +++++++++++++++++
> >>> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116 +++++++++++++++++++++++
> >>> 3 files changed, 205 insertions(+)
> >>> create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
> >>> create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
> >>
> >> This creates a new arch-specific public API, with rte_msr.h installed as
> >> a public header and implementation in the library (as opposed to
> >> inline), and so the new functions would have to be added to
> >> rte_eal_version.map.
> >>
> >> However that is a bit of a problem since it only exists on IA
> >> architectures, so it'd mean dummy entries in the version map for all
> >> other architectures. All the other arch-specific APIs are inline code so
> >> this is the first of its kind.
> >
> > My thought was:
> > 1. implementation is linux specific (as I know not supposed to work under freebsd).
> > 2. they are not supposed to be used at run-time cide-path, so no need to be inlined.
>
> Speed is not the only interesting attribute of inlining, inlined code
> also effectively escapes the library ABI so it does not need versioning
> / exporting.
>
> > 3. As I understand we plan to have a library that will use these functions anyway.
>
> Is this library going to be a generic or specific to Intel CPUs?
As I understand - yes.
It supposed to utilise new Intel chips CAT abilities.
Wojciech, please correct me if I missed something here.
> Also, if there are no other uses for the MSR API at the moment, perhaps
> the best place for this code would be within that library anyway?
Sounds good to me.
Konstantin
>
> > About dummy entries in the .map file: if we'll create a 'weak' generic implementation,
> > that would just return an error - would it solve the issue?
>
> Sure it'd solve the issue of dummy entries in .map but people seemed
> opposed to having a highly arch-specific API exposed to all architectures.
>
> - Panu -
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
@ 2016-01-22 10:05 3% ` Panu Matilainen
2016-01-22 11:05 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-22 10:05 UTC (permalink / raw)
To: Ananyev, Konstantin, Andralojc, WojciechX; +Cc: dev
On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote:
> Hi Panu,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Thursday, January 21, 2016 10:39 AM
>> To: Andralojc, WojciechX
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...
>>
>> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
>>> Patch reworked.
>>>
>>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
>>> ---
>>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88 +++++++++++++++++
>>> lib/librte_eal/linuxapp/eal/Makefile | 1 +
>>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116 +++++++++++++++++++++++
>>> 3 files changed, 205 insertions(+)
>>> create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
>>> create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
>>
>> This creates a new arch-specific public API, with rte_msr.h installed as
>> a public header and implementation in the library (as opposed to
>> inline), and so the new functions would have to be added to
>> rte_eal_version.map.
>>
>> However that is a bit of a problem since it only exists on IA
>> architectures, so it'd mean dummy entries in the version map for all
>> other architectures. All the other arch-specific APIs are inline code so
>> this is the first of its kind.
>
> My thought was:
> 1. implementation is linux specific (as I know not supposed to work under freebsd).
> 2. they are not supposed to be used at run-time cide-path, so no need to be inlined.
Speed is not the only interesting attribute of inlining, inlined code
also effectively escapes the library ABI so it does not need versioning
/ exporting.
> 3. As I understand we plan to have a library that will use these functions anyway.
Is this library going to be a generic or specific to Intel CPUs?
Also, if there are no other uses for the MSR API at the moment, perhaps
the best place for this code would be within that library anyway?
> About dummy entries in the .map file: if we'll create a 'weak' generic implementation,
> that would just return an error - would it solve the issue?
Sure it'd solve the issue of dummy entries in .map but people seemed
opposed to having a highly arch-specific API exposed to all architectures.
- Panu -
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/2] ethdev: add vlan type for setting ether type
@ 2016-01-22 1:37 7% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2016-01-22 1:37 UTC (permalink / raw)
To: dev
In order to set ether type of VLAN for single VLAN, inner
and outer VLAN, the VLAN type as an input parameter is added
to 'rte_eth_dev_set_vlan_ether_type()'.
In addition, corresponding changes in e1000, ixgbe and i40e are
also added.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
app/test-pmd/cmdline.c | 29 ++++++++++++++++++++---------
app/test-pmd/config.c | 8 ++++----
app/test-pmd/testpmd.h | 3 ++-
doc/guides/rel_notes/deprecation.rst | 4 ++++
doc/guides/rel_notes/release_2_3.rst | 6 ++++++
drivers/net/e1000/igb_ethdev.c | 20 +++++++++++++++-----
drivers/net/i40e/i40e_ethdev.c | 4 +++-
drivers/net/ixgbe/ixgbe_ethdev.c | 18 ++++++++++++++----
lib/librte_ether/rte_ethdev.c | 5 +++--
lib/librte_ether/rte_ethdev.h | 19 +++++++++++++++++--
10 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..ba1650b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -275,8 +275,8 @@ static void cmd_help_long_parsed(void *parsed_result,
" Set the VLAN QinQ (extended queue in queue)"
" on a port.\n\n"
- "vlan set tpid (value) (port_id)\n"
- " Set the outer VLAN TPID for Packet Filtering on"
+ "vlan set (inner|outer) tpid (value) (port_id)\n"
+ " Set the VLAN TPID for Packet Filtering on"
" a port\n\n"
"rx_vlan add (vlan_id|all) (port_id)\n"
@@ -295,10 +295,6 @@ static void cmd_help_long_parsed(void *parsed_result,
" Remove a vlan_id, to the set of VLAN identifiers"
"filtered for VF(s) from port_id.\n\n"
- "rx_vlan set tpid (value) (port_id)\n"
- " Set the outer VLAN TPID for Packet Filtering on"
- " a port\n\n"
-
"tunnel_filter add (port_id) (outer_mac) (inner_mac) (ip_addr) "
"(inner_vlan) (vxlan|nvgre) (filter_type) (tenant_id) (queue_id)\n"
" add a tunnel filter of a port.\n\n"
@@ -2845,6 +2841,7 @@ cmdline_parse_inst_t cmd_vlan_offload = {
struct cmd_vlan_tpid_result {
cmdline_fixed_string_t vlan;
cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vlan_type;
cmdline_fixed_string_t what;
uint16_t tp_id;
uint8_t port_id;
@@ -2856,8 +2853,17 @@ cmd_vlan_tpid_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_vlan_tpid_result *res = parsed_result;
- vlan_tpid_set(res->port_id, res->tp_id);
- return;
+ enum rte_vlan_type vlan_type;
+
+ if (!strcmp(res->vlan_type, "inner"))
+ vlan_type = ETH_VLAN_TYPE_INNER;
+ else if (!strcmp(res->vlan_type, "outer"))
+ vlan_type = ETH_VLAN_TYPE_OUTER;
+ else {
+ printf("Unknown vlan type\n");
+ return;
+ }
+ vlan_tpid_set(res->port_id, vlan_type, res->tp_id);
}
cmdline_parse_token_string_t cmd_vlan_tpid_vlan =
@@ -2866,6 +2872,9 @@ cmdline_parse_token_string_t cmd_vlan_tpid_vlan =
cmdline_parse_token_string_t cmd_vlan_tpid_set =
TOKEN_STRING_INITIALIZER(struct cmd_vlan_tpid_result,
set, "set");
+cmdline_parse_token_string_t cmd_vlan_type =
+ TOKEN_STRING_INITIALIZER(struct cmd_vlan_tpid_result,
+ vlan_type, "inner#outer");
cmdline_parse_token_string_t cmd_vlan_tpid_what =
TOKEN_STRING_INITIALIZER(struct cmd_vlan_tpid_result,
what, "tpid");
@@ -2879,10 +2888,12 @@ cmdline_parse_token_num_t cmd_vlan_tpid_portid =
cmdline_parse_inst_t cmd_vlan_tpid = {
.f = cmd_vlan_tpid_parsed,
.data = NULL,
- .help_str = "set tpid tp_id port_id, set the Outer VLAN Ether type",
+ .help_str = "set inner|outer tpid tp_id port_id, set the VLAN "
+ "Ether type",
.tokens = {
(void *)&cmd_vlan_tpid_vlan,
(void *)&cmd_vlan_tpid_set,
+ (void *)&cmd_vlan_type,
(void *)&cmd_vlan_tpid_what,
(void *)&cmd_vlan_tpid_tpid,
(void *)&cmd_vlan_tpid_portid,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 7088f6f..537dd0b 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1821,19 +1821,19 @@ rx_vlan_all_filter_set(portid_t port_id, int on)
}
void
-vlan_tpid_set(portid_t port_id, uint16_t tp_id)
+vlan_tpid_set(portid_t port_id, enum rte_vlan_type vlan_type, uint16_t tp_id)
{
int diag;
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
- diag = rte_eth_dev_set_vlan_ether_type(port_id, tp_id);
+ diag = rte_eth_dev_set_vlan_ether_type(port_id, vlan_type, tp_id);
if (diag == 0)
return;
- printf("tx_vlan_tpid_set(port_pi=%d, tpid=%d) failed "
+ printf("tx_vlan_tpid_set(port_pi=%d, vlan_type=%d, tpid=%d) failed "
"diag=%d\n",
- port_id, tp_id, diag);
+ port_id, vlan_type, tp_id, diag);
}
void
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index ee7de98..d79d86d 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -507,7 +507,8 @@ void rx_vlan_filter_set(portid_t port_id, int on);
void rx_vlan_all_filter_set(portid_t port_id, int on);
int rx_vft_set(portid_t port_id, uint16_t vlan_id, int on);
void vlan_extend_set(portid_t port_id, int on);
-void vlan_tpid_set(portid_t port_id, uint16_t tp_id);
+void vlan_tpid_set(portid_t port_id, enum rte_vlan_type vlan_type,
+ uint16_t tp_id);
void tx_vlan_set(portid_t port_id, uint16_t vlan_id);
void tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t vlan_id_outer);
void tx_vlan_reset(portid_t port_id);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..989db37 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,3 +49,7 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for ``vlan_tpid_set`` in ethdev structure
+ of ``eth_dev_ops`` from in release 16.07. Its return value will be changed
+ from ``void`` to ``int``.
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..1f32401 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,8 @@ DPDK Release 2.3
New Features
------------
+* **Added modifying ether type of both single and double VLAN for i40e**
+
Resolved Issues
---------------
@@ -35,6 +37,10 @@ Known Issues
API Changes
-----------
+* The function of ``rte_eth_dev_set_vlan_ether_type()`` now has one more
+ parameter of ``enum rte_vlan_type`` for configuring single VLAN, inner
+ or outer VLAN.
+
ABI Changes
-----------
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index d1bbcda..b3cec86 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -125,7 +125,9 @@ static int eth_igb_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int eth_igb_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id, int on);
-static void eth_igb_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid_id);
+static void eth_igb_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type,
+ uint16_t tpid_id);
static void eth_igb_vlan_offload_set(struct rte_eth_dev *dev, int mask);
static void igb_vlan_hw_filter_enable(struct rte_eth_dev *dev);
@@ -2185,14 +2187,22 @@ eth_igb_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
}
static void
-eth_igb_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid)
+eth_igb_vlan_tpid_set(struct rte_eth_dev *dev, enum rte_vlan_type vlan_type,
+ uint16_t tpid)
{
struct e1000_hw *hw =
E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- uint32_t reg = ETHER_TYPE_VLAN ;
+ uint32_t reg = ETHER_TYPE_VLAN;
- reg |= (tpid << 16);
- E1000_WRITE_REG(hw, E1000_VET, reg);
+ switch (vlan_type) {
+ case ETH_VLAN_TYPE_INNER:
+ reg |= (tpid << 16);
+ E1000_WRITE_REG(hw, E1000_VET, reg);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "Unsupported vlan type %d\n", vlan_type);
+ break;
+ }
}
static void
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..56ed28d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -299,7 +299,8 @@ static void i40e_dev_info_get(struct rte_eth_dev *dev,
static int i40e_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id,
int on);
-static void i40e_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid);
+static void i40e_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type, uint16_t tpid);
static void i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask);
static void i40e_vlan_strip_queue_set(struct rte_eth_dev *dev,
uint16_t queue,
@@ -2321,6 +2322,7 @@ i40e_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
static void
i40e_vlan_tpid_set(__rte_unused struct rte_eth_dev *dev,
+ __rte_unused enum rte_vlan_type vlan_type,
__rte_unused uint16_t tpid)
{
PMD_INIT_FUNC_TRACE();
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4c4c6df..20ed5b8 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -172,7 +172,9 @@ static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int ixgbe_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id, int on);
-static void ixgbe_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid_id);
+static void ixgbe_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type,
+ uint16_t tpid_id);
static void ixgbe_vlan_hw_strip_bitmap_set(struct rte_eth_dev *dev,
uint16_t queue, bool on);
static void ixgbe_vlan_strip_queue_set(struct rte_eth_dev *dev, uint16_t queue,
@@ -1517,13 +1519,21 @@ ixgbe_vlan_strip_queue_set(struct rte_eth_dev *dev, uint16_t queue, int on)
}
static void
-ixgbe_vlan_tpid_set(struct rte_eth_dev *dev, uint16_t tpid)
+ixgbe_vlan_tpid_set(struct rte_eth_dev *dev, enum rte_vlan_type vlan_type,
+ uint16_t tpid)
{
struct ixgbe_hw *hw =
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- /* Only the high 16-bits is valid */
- IXGBE_WRITE_REG(hw, IXGBE_EXVET, tpid << 16);
+ switch (vlan_type) {
+ case ETH_VLAN_TYPE_INNER:
+ /* Only the high 16-bits is valid */
+ IXGBE_WRITE_REG(hw, IXGBE_EXVET, tpid << 16);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "Unsupported vlan type %d\n", vlan_type);
+ break;
+ }
}
void
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..589b7ca 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1695,14 +1695,15 @@ rte_eth_dev_set_vlan_strip_on_queue(uint8_t port_id, uint16_t rx_queue_id, int o
}
int
-rte_eth_dev_set_vlan_ether_type(uint8_t port_id, uint16_t tpid)
+rte_eth_dev_set_vlan_ether_type(uint8_t port_id, enum rte_vlan_type vlan_type,
+ uint16_t tpid)
{
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->vlan_tpid_set, -ENOTSUP);
- (*dev->dev_ops->vlan_tpid_set)(dev, tpid);
+ (*dev->dev_ops->vlan_tpid_set)(dev, vlan_type, tpid);
return 0;
}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..c047cbe 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -351,6 +351,17 @@ struct rte_eth_rxmode {
};
/**
+ * VLAN types to indicate if it is for single VLAN, inner VLAN or outer VLAN.
+ * Note that most of time single VLAN is treated the same as inner VLAN.
+ */
+enum rte_vlan_type {
+ ETH_VLAN_TYPE_UNKNOWN = 0,
+ ETH_VLAN_TYPE_INNER, /**< Single VLAN, or inner VLAN. */
+ ETH_VLAN_TYPE_OUTER, /**< Outer VLAN. */
+ ETH_VLAN_TYPE_MAX,
+};
+
+/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
* If not NULL, the *rss_key* pointer of the *rss_conf* structure points
@@ -1077,7 +1088,7 @@ typedef int (*vlan_filter_set_t)(struct rte_eth_dev *dev,
/**< @internal filtering of a VLAN Tag Identifier by an Ethernet device. */
typedef void (*vlan_tpid_set_t)(struct rte_eth_dev *dev,
- uint16_t tpid);
+ enum rte_vlan_type type, uint16_t tpid);
/**< @internal set the outer VLAN-TPID by an Ethernet device. */
typedef void (*vlan_offload_set_t)(struct rte_eth_dev *dev, int mask);
@@ -2349,6 +2360,8 @@ extern int rte_eth_dev_set_vlan_strip_on_queue(uint8_t port_id,
*
* @param port_id
* The port identifier of the Ethernet device.
+ * @vlan_type
+ * The vlan type.
* @param tag_type
* The Tag Protocol ID
* @return
@@ -2356,7 +2369,9 @@ extern int rte_eth_dev_set_vlan_strip_on_queue(uint8_t port_id,
* - (-ENOSUP) if hardware-assisted VLAN TPID setup is not supported.
* - (-ENODEV) if *port_id* invalid.
*/
-extern int rte_eth_dev_set_vlan_ether_type(uint8_t port_id, uint16_t tag_type);
+extern int rte_eth_dev_set_vlan_ether_type(uint8_t port_id,
+ enum rte_vlan_type vlan_type,
+ uint16_t tag_type);
/**
* Set VLAN offload configuration on an Ethernet device
--
2.5.0
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] cfgfile: support looking up sections by index
@ 2016-01-21 7:42 3% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2016-01-21 7:42 UTC (permalink / raw)
To: Rich Lane, dev
On 01/19/2016 06:41 AM, Rich Lane wrote:
> This is useful when sections have duplicate names.
>
> Signed-off-by: Rich Lane <rlane@bigswitch.com>
> ---
> v1->v2:
> - Added new symbol to version script.
>
> lib/librte_cfgfile/rte_cfgfile.c | 16 ++++++++++++++++
> lib/librte_cfgfile/rte_cfgfile.h | 23 +++++++++++++++++++++++
> lib/librte_cfgfile/rte_cfgfile_version.map | 6 ++++++
> 3 files changed, 45 insertions(+)
>
> diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
> index a677dad..0bb40a4 100644
> --- a/lib/librte_cfgfile/rte_cfgfile.c
> +++ b/lib/librte_cfgfile/rte_cfgfile.c
> @@ -333,6 +333,22 @@ rte_cfgfile_section_entries(struct rte_cfgfile *cfg, const char *sectionname,
> return i;
> }
>
> +int
> +rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg, int index,
> + struct rte_cfgfile_entry *entries, int max_entries)
> +{
> + int i;
> + const struct rte_cfgfile_section *sect;
> +
> + if (index >= cfg->num_sections)
> + return -1;
> +
> + sect = cfg->sections[index];
Since index is a signed int, I think you should check for < 0 as well in
the above. Sorry for not noticing/mentioning that on the first round, I
wasn't so much reviewing the code as just skimming through for general
API/ABI issues.
Other than that, looks ok to me.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: expose link status and speed using xstats
@ 2016-01-20 18:36 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2016-01-20 18:36 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, 20 Jan 2016 16:13:34 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> > We already have the rte_eth_link_get function. Why not let users
> > continue to use that? It's well defined, it is simple, and it is
> > consistent.
+1
API's should not duplicate results (DRY)
That said, it would be useful to have some way to get statistics
on the number of link transitions and time since last change.
But this ideally should be in rte_eth_link_get() but that wouldn't
be ABI compatiable.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
@ 2016-01-19 10:59 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2016-01-19 10:59 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
Jan,
On Tue, Jan 19, 2016 at 11:29 AM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Mon, 18 Jan 2016 22:11:56 +0100
> David Marchand <david.marchand@6wind.com> wrote:
>> Ok, so what you propose is something like this ?
>
> I've expressed my basic understanding of this topic in the RFC patch set
> yesterday (as you know).
>
>>
>> - keep rte_driver as it is (init and uninit), I would say the name can
>> be changed later.
>
> Agreed.
>
>> - add rte_bus_driver (idem, not sure it is a good name) in place of
>> the rte_driver I mentioned in my initial mail.
>
> I don't like the name either. I have no other idea at the moment.
My initial intention was to go as far as possible with the approach I
described without caring about the api / abi.
Then if the result is worth, see how we could maintain the api / abi
and how to manage the changes if not possible.
So please, do not hesitate to break stuff.
>> Rather than have init / uninit, how about attach / detach methods ?
>
> You mean attach a driver to a device? Yes, much better. And what about
> probe? I was quite confused when writing a PMD as I couldn't understand
> clearly where should I start touching the hardware.
Yes, I also thought of probe name, but then for unplugging ?
We could use the same names as linux kernel probe/remove ?
I think freebsd kernel uses the same, so why not.
Regards,
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-16 15:53 0% ` David Marchand
@ 2016-01-18 15:49 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2016-01-18 15:49 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Jan Viktorin
2016-01-16 16:53, David Marchand:
> On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> > On Thu, 14 Jan 2016 11:38:16 +0100
> > David Marchand <david.marchand@6wind.com> wrote:
> >> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> >> follow) and eal structures.
[...]
> >> ABI is most likely broken with this, but I think this discussion can come later.
> >
> > I was trying in my initial approach to stay as much API and ABI backwards
> > compatible as possible to be acceptable into upstream. As just a few
> > people have shown their interest in these changes, I consider the ABI
> > compatibility very important.
> >
> > I can see, that your approach does not care too much... Otherwise, it looks
> > good to me. It is closer to the Linux drivers infra, so it seems to be clearer
> > then the current one.
>
> I did this on purpose.
> From my point of view, we will have an API/ABI breakage in this code
> at one point.
> So I sent this mail to show where I'd like us to go, because this
> looks saner on the mid/long term.
[...]
> > Another point is that the ethdev infra should not know about the
> > underlying bus infra. The question is whether we do a big clean
> > up (extract PCI-bus code out) or a small clean up (give the ethdev
> > infra a hint which bus system it deals with).
>
> Yes, and I think these two choices are reflected by our two respective
> proposals :-)
Regarding the API/ABI breaks and how the big the changes must be, I'd say
it is nice to have some changes without breaking the user interfaces.
Though sometimes there is a great value to refactor things and break them.
In such case, it is better to do the big changes at once so the breaking
would impact only one version instead of breaking the same API again and
again.
About this proposal, I vote for: +1
[...]
> > Moreover, there is no way how to pass arguments to pdevs, only to
> > vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
> >
> > [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
>
> Shorty discussed with Thomas, yes.
> But after some experiments, it appears that you can pass devargs after
> a whitelist option at init (--pci-whitelist
> xxxx:xx:xx.x,whataniceoptionwehavehere=1).
> This does not work for hotplug.
> This is undocumented and this looks like a workaround, so I would
> prefer we come up with a better api for 2.3.
Yes we need also to redefine the command line syntax to have a generic way
of passing per-device parameters to the drivers.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-14 10:38 2% [dpdk-dev] Proposal for a big eal / ethdev cleanup David Marchand
2016-01-14 11:46 4% ` Jan Viktorin
@ 2016-01-18 14:54 0% ` Declan Doherty
[not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2 siblings, 0 replies; 200+ results
From: Declan Doherty @ 2016-01-18 14:54 UTC (permalink / raw)
To: David Marchand, dev; +Cc: Jan Viktorin
On 14/01/16 10:38, David Marchand wrote:
> Hello all,
>
> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> follow) and eal structures.
> This is something I wanted to do for quite some time and the arrival of
> a new bus makes me think we need it.
>
> This is an alternative to what Jan proposed [1].
>
> ABI is most likely broken with this, but I think this discussion can come later.
>
>
> First some context on how dpdk is initialized at the moment :
>
> Let's imagine a system with one ixgbe pci device and take some
> part of ixgbe driver as an example.
>
> static struct eth_driver rte_ixgbe_pmd = {
> .pci_drv = {
> .name = "rte_ixgbe_pmd",
> .id_table = pci_id_ixgbe_map,
> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
> },
> .eth_dev_init = eth_ixgbe_dev_init,
> .eth_dev_uninit = eth_ixgbe_dev_uninit,
> .dev_private_size = sizeof(struct ixgbe_adapter),
> };
>
> static int
> rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
> __rte_unused)
> {
> PMD_INIT_FUNC_TRACE();
> rte_eth_driver_register(&rte_ixgbe_pmd);
> return 0;
> }
>
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> };
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver)
>
>
> DPDK initialisation goes as follows (focusing on ixgbe driver):
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
>
> rte_eal_init()
> -> rte_eal_pci_init()
> -> rte_eal_pci_scan() which fills pci_device_list
>
> -> rte_eal_dev_init()
> -> for each rte_driver (first vdev, then pdev), call driver->init()
> so here rte_ixgbe_pmd_init(NULL, NULL)
> -> rte_eth_driver_register(&rte_ixgbe_pmd);
> -> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
> -> call rte_eal_pci_register() which adds it to pci_driver_list
>
> -> rte_eal_pci_probe()
> -> for each rte_pci_device found in rte_eal_pci_scan(), and for all
> rte_pci_driver registered, call devinit(dr, dev),
> so here rte_eth_dev_init(dr, dev)
> -> creates a new eth_dev (which is a rte_eth_dev), then adds
> reference to passed dev pointer (which is a rte_pci_device), to
> passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
> -> call eth_drv->eth_dev_init(eth_dev)
> so here eth_ixgbe_dev_init(eth_dev)
> -> fills other parts of eth_dev
> -> rte_eth_copy_pci_info(eth_dev, pci_dev)
>
>
> By the way, when invoking ethdev init, the pci-specific stuff is only
> handled in functions called from the drivers themselves, which already
> know that they are dealing with pci resources.
>
>
> Later in the life of the application, ethdev api is called for hotplug.
>
> int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
>
> A devargs is used to identify a vdev/pdev driver and call it to create a
> new rte_eth_dev.
> Current code goes as far as parsing devargs to understand if this is a
> pci device or a vdev.
> This part should be moved to eal since this is where all the "bus" logic
> is.
>
>
>
> So now, what I had in mind is something like this.
> It is far from perfect and I certainly did some shortcuts in my
> reasoning.
>
>
> Generic device/driver
>
> - introduce a rte_device structure,
> - a rte_device has a name, that identifies it in a unique way across
> all buses, maybe something like pci:0000:00:01.0, and for vdev,
> vdev:name
> - a rte_device references a rte_driver,
> - a rte_device references devargs
> - a rte_device embeds a intr_handle
> - rte_device objects are created by "buses"
> - a function to retrieve rte_device objects based on name is added
>
> - current rte_driver does not need to know about the pmd_type
> (pdev/vdev), this is only a way to order drivers init in eal, we could
> use the rte_driver names to order them or maybe remove this ordering
> - init and uninit functions are changed to take a pointer to a
> rte_device
>
> rte_device and rte_driver structures are at the "bus" level.
> Those are the basic structures we will build the other objects on.
>
>
> Impact on PCI device/driver
>
> - rte_pci_device is modified to embed a rte_device (embedding makes it
> possible later to cast the rte_device and get the rte_pci_device in pci
> specific functions)
> - no need for a rte_pci_driver reference in rte_pci_device, since we
> have the rte_device driver
>
> - rte_pci_driver is modified to embed a rte_driver
> - no more devinit and devuninit functions in rte_pci_driver, they can
> be moved as init / uninit functions in rte_driver
>
> - pci scan code creates rte_pci_device objects, associates them to
> rte_pci_driver, fills the driver field of the rte_driver then pass
> them to rte_driver init function.
>
> rte_pci_device and rte_pci_driver are specific implementation of
> rte_device and rte_driver.
> There are there to maintain pci private methods, create upper layer
> objects (ethdev / crypto) etc..
>
>
> Impact on vdev
>
> - introduce a rte_vdev_driver structure
> - a rte_vdev_driver embeds a rte_driver
> - a rte_vdev_driver has a priv size for vdev objects creation
>
> - no need for a vdev device object, this is specific to vdev drivers
>
> - eal init code associates devargs to vdev drivers, creates a
> rte_device object (using the priv size), fills the driver field then
> pass them to rte_driver init function.
>
>
> Impact on ethdev
>
> - a rte_eth_dev object references a rte_device in place of
> rte_pci_device
> - no more information about a driver in rte_eth_dev, this is the
> rte_device that has a reference to its rte_driver
> - eth_driver can be removed, it is only a wrapper of a rte_pci_driver
> at the moment, maybe some init function wrappers can stay in ethdev
> with dev_private_size to be handled in the rte_driver
> - rte_eth_dev objects are created by rte_drivers during probe (pci
> scan, vdev init, hotplug)
> - ethdev ops are populated by rte_drivers
>
>
> Impact on hotplug
>
> - hotplug moves from ethdev to eal
> - a notification framework is added to ethdev when hotplugging
>
> - eal uses the name (remember the pci:0000:00:01.0 / vdev:name
> example) in devargs to identify the right bus (pci / vdev)
> - pci scan code is reused to create a rte_pci_device object etc...
> - vdev init code is reused
>
>
> We end up with something like this.
> An arrow means that the structure contains a pointer to an object of the
> other struct.
> I only wrote the fields I mentioned in this mail, for pci device a lot
> of other fields are omitted.
>
> - for ethdev on top of pci devices
>
> +------------------+ +-------------------------------+
> | | | |
> | rte_pci_device | | rte_pci_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> +-------------------------------+
>
> - for ethdev on top of vdev devices
>
> +------------------+ +-------------------------------+
> | | | |
> | drv specific | | rte_vdev_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> | int priv_size |
> | |
> +-------------------------------+
>
>
> Thanks for reading.
> Comments ?
>
>
Hey David,
form the work we done on the cryptodev I definitely agree this is
something we need to look at. There is some duplication of code between
ethdev and cryptodev which would disappear with a common rte_device
abstraction. I just haven't had time to write anything down and didn't
want to further complicate the cryptodev patches by introducing EAL
changes with it as well.
In your proposal above, having an bus type enumeration in the rte_device
which specifies the bus type might be simpler than having to parse a
specific name formatting.
Moving the hot-plugging infrastructure to the EAL would be great as this
is an element we didn't address in the cryptodev layer as currently we
would need to re-implement a lot of the same logic which is done in
lib_ethdev. Again this was something on our list of things to look at.
One thing that we are working on at the moment and it will affect your
proposed solution above quite a lot is the ability to support devices
with share-able buses in DPDK, we will have a RFC for this proposal in
the next few days but I'll give a quick overview now. The Quick Assist
device which we currently support a symmetric crypto cryptodev PMD for
in DPDK is a mufti-function device, in that it supports symmetric and
asymmetric crypto and compression functionality. These features are
supported from a single device instance through different hardware
queues. We want to provide each service through as a separate dpdk
device but with and underlying shared bus (in our case PCI), this way a
device/queue will only provide 1 service type. What we are going to
propose is to allow a rte_pci_device to be shared my multiple pdevs, to
do this we would register multiple drivers against the same pci_id and
with a small modification to the EAL rte_eal_pci_probe_all()/
rte_eal_pci_probe() functions we create a device instance for each
matched driver as long as the diver has a share-able flag.
So with the current DPDK architecture where the rte_cryptodev (also the
same for the rte_eth_dev) has a pointer from the rte_pci_driver to the
rte_pci_device and a back pointer from the rte_pci_device to the
rte_pci_driver, we are proposing to remove the back pointer from
rte_pci_device and then allow multiple rte_pci_driver. This will require
an API change to the PCI device uninit function. We'll outline all of
this in the RFC, but I just wanted to make you aware of it, as something
to keep in mind. Our solution will logically look something a bit like
below.
+-----------------------+ +------------------------+
| qat_sym_pmd | | qat_asym_pmd |
+-----------------------+ +------------------------+
| |
V V
+-----------------------+ +------------------------+
| rte_cryptodev | | rte_cryptodev |
+-----------------------+ +------------------------+
| |
V V
+----------------+ +----------------+
| rte_pci_driver | | rte_pci_driver |
+----------------+ +----------------+
^ | | ^
| ------------------------ |
/ | /
/ V /
| +----------------+ |
---------| rte_pci_device |---------
+----------------+
I guess the main change from your proposal to allow similar
functionality would be that dependency chain is reversed with the
rte_driver having the reference to the rte_device which could be shared
by multiple drivers.
+----------------------------+ +----------------+
| | | |
| drv specific | | bus specific |
| | | |
+-------------+ |+--------------------------+| |+--------------+|
| | || || || ||
| rte_eth_dev +--> rte_driver +--+--> rte_device ||
| | || char name[] || | || char name[] ||
+-------------+ || int init(rte_device *) || | || bool shared ||
|| int uninit(rte_device *)|| | || mutex lock ||
|| || | || ||
|+--------------------------+| | |+--------------+|
| | | +----------------+
+----------------------------+ |
|
|
+----------------------------+ |
| | |
| drv specific | |
| | |
+-------------+ |+--------------------------+| |
| | || || |
| rte_eth_dev +--> rte_driver +--+
| | || char name[] ||
+-------------+ || int init(rte_device *) ||
|| int uninit(rte_device *) ||
|| ||
|+--------------------------+|
| |
+----------------------------+
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-15 9:00 3% ` Panu Matilainen
@ 2016-01-18 14:38 4% ` Olivier MATZ
0 siblings, 0 replies; 200+ results
From: Olivier MATZ @ 2016-01-18 14:38 UTC (permalink / raw)
To: Panu Matilainen, Nélio Laranjeiro, john.mcnamara; +Cc: dev
Hi,
On 01/15/2016 10:00 AM, Panu Matilainen wrote:
>>>> diff --git a/lib/librte_cmdline/cmdline_rdline.h
>>>> b/lib/librte_cmdline/cmdline_rdline.h
>>>> index b9aad9b..72e2dad 100644
>>>> --- a/lib/librte_cmdline/cmdline_rdline.h
>>>> +++ b/lib/librte_cmdline/cmdline_rdline.h
>>>> @@ -93,7 +93,7 @@ extern "C" {
>>>> #endif
>>>>
>>>> /* configuration */
>>>> -#define RDLINE_BUF_SIZE 256
>>>> +#define RDLINE_BUF_SIZE 512
>>>> #define RDLINE_PROMPT_SIZE 32
>>>> #define RDLINE_VT100_BUF_SIZE 8
>>>> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>>>
>>> Having to break a library ABI for a change like this is a bit
>>> ridiculous.
>>
>> Sure, but John McNamara needed it to handle flow director with IPv6[1].
>>
>> For my part, I was needing it to manipulate the RETA table, but as I
>> wrote in the cover letter, it ends by breaking other commands.
>> Olivier Matz, has proposed another way to handle long commands lines[2],
>> it could be a good idea to go on this direction.
>>
>> For RETA situation, we already discussed on a new API, but for now, I
>> do not have time for it (and as it is another ABI breakage it could only
>> be done for 16.07 or 2.4)[3].
>>
>> If this patch is no more needed we can just drop it, for that I would
>> like to have the point of view from John.
>
> Note that I was not objecting to the patch as such, I can easily see 256
> characters not being enough for commandline buffer.
>
> I was merely noting that having to break an ABI to increase an
> effectively internal buffer size is a sign of a, um, less-than-optimal
> library design.
You are right about the cmdline ABI. Changing this buffer size
should not imply an ABI change. I'll try to find some time to
investigate this issue.
Another question we could raise is: should we export the API of
librte_cmdline to external applications? Now that baremetal dpdk is
not supported, having this library in dpdk is probably useless as
we can surely find standard replacements for it. A first step could
be to mark it as "internal".
About the patch Nélio's patch itself, I'm not so convinced having more
than 256 characters is absolutely required, and I would prefer to see
the commands beeing reworked to be more human-readable. On the other
hand, the ABI breakage was announced so there is no reason to nack
this patch now.
Regards,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-14 11:46 4% ` Jan Viktorin
@ 2016-01-16 15:53 0% ` David Marchand
2016-01-18 15:49 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2016-01-16 15:53 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
Hello Jan,
On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Thu, 14 Jan 2016 11:38:16 +0100
> David Marchand <david.marchand@6wind.com> wrote:
>
>> Hello all,
>>
>> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
>> follow) and eal structures.
>> This is something I wanted to do for quite some time and the arrival of
>> a new bus makes me think we need it.
>>
>> This is an alternative to what Jan proposed [1].
>
> As I need to extend DPDK by a non-PCI bus system, I would prefer any such
> working solution :). By [1], you probably mean:
>
> [1] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/30973
>
> (I didn't find it in the e-mail.)
Thought I put the reference after my signature.
Anyway, yes, I was referring to your thread.
>> ABI is most likely broken with this, but I think this discussion can come later.
>
> I was trying in my initial approach to stay as much API and ABI backwards
> compatible as possible to be acceptable into upstream. As just a few
> people have shown their interest in these changes, I consider the ABI
> compatibility very important.
>
> I can see, that your approach does not care too much... Otherwise, it looks
> good to me. It is closer to the Linux drivers infra, so it seems to be clearer
> then the current one.
I did this on purpose.
>From my point of view, we will have an API/ABI breakage in this code
at one point.
So I sent this mail to show where I'd like us to go, because this
looks saner on the mid/long term.
>> First some context on how dpdk is initialized at the moment :
>>
>> Let's imagine a system with one ixgbe pci device and take some
>> part of ixgbe driver as an example.
>>
>> static struct eth_driver rte_ixgbe_pmd = {
>> .pci_drv = {
>> .name = "rte_ixgbe_pmd",
>> .id_table = pci_id_ixgbe_map,
>> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
>> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
>> },
>> .eth_dev_init = eth_ixgbe_dev_init,
>> .eth_dev_uninit = eth_ixgbe_dev_uninit,
>> .dev_private_size = sizeof(struct ixgbe_adapter),
>> };
>
> Note, that the biggest issue here is that the eth_driver has no way to
> distinguish among PCI or other subsystem. There is no field that helps
> the generic ethdev code (librte_ether) to decide what bus we are on
> (and it needs to know it in the current DPDK).
>
> Another point is that the ethdev infra should not know about the
> underlying bus infra. The question is whether we do a big clean
> up (extract PCI-bus code out) or a small clean up (give the ethdev
> infra a hint which bus system it deals with).
Yes, and I think these two choices are reflected by our two respective
proposals :-)
>> So now, what I had in mind is something like this.
>> It is far from perfect and I certainly did some shortcuts in my
>> reasoning.
>>
>>
>> Generic device/driver
>>
>> - introduce a rte_device structure,
>> - a rte_device has a name, that identifies it in a unique way across
>> all buses, maybe something like pci:0000:00:01.0, and for vdev,
>> vdev:name
>
> Having a prefix is good but would this break the user API? Is the
> name exposed to users?
Maybe define new apis, and wrap the old one in it ?
Not too sure, I need to experiment.
>> - current rte_driver does not need to know about the pmd_type
>> (pdev/vdev), this is only a way to order drivers init in eal, we could
>> use the rte_driver names to order them or maybe remove this ordering
>
> What is the main reason to have pdev/vdev distinction here? After I
> register the driver, does eal really need to know the pmd_type?
Already did some cleanup in the past because of pmd_type :
http://dpdk.org/browse/dpdk/commit/?id=78aecefed955917753bfb6f44ae970dde4c652d0
http://dpdk.org/browse/dpdk/commit/?id=6bc2415c3387ae72f2ce3677f0e3540e734583d5
For me, there is no reason but the init ordering (vdevs come before
pdevs), and I am pretty sure we don't need this for ethdev.
> Moreover, there is no way how to pass arguments to pdevs, only to
> vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
>
> [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
Shorty discussed with Thomas, yes.
But after some experiments, it appears that you can pass devargs after
a whitelist option at init (--pci-whitelist
xxxx:xx:xx.x,whataniceoptionwehavehere=1).
This does not work for hotplug.
This is undocumented and this looks like a workaround, so I would
prefer we come up with a better api for 2.3.
>> Impact on PCI device/driver
>>
>> - rte_pci_device is modified to embed a rte_device (embedding makes it
>> possible later to cast the rte_device and get the rte_pci_device in pci
>> specific functions)
>> - no need for a rte_pci_driver reference in rte_pci_device, since we
>> have the rte_device driver
>
> I've noticed that DPDK does not use any kind of the container_of macro
> like the Linux Kernel does. Instead, some considerations like the
> rte_pci_driver MUST be placed at the beginning of the eth_driver (if I
> am not mistaken). Here, it should be considered to do it another way.
Ah, yes, we could use this.
Just did not think of using it :-)
Regards,
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-15 8:44 3% ` Nélio Laranjeiro
@ 2016-01-15 9:00 3% ` Panu Matilainen
2016-01-18 14:38 4% ` Olivier MATZ
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-15 9:00 UTC (permalink / raw)
To: Nélio Laranjeiro, john.mcnamara; +Cc: dev
On 01/15/2016 10:44 AM, Nélio Laranjeiro wrote:
> On Tue, Jan 12, 2016 at 02:46:07PM +0200, Panu Matilainen wrote:
>> On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote:
>>> Allow long command lines in testpmd (like flow director with IPv6, ...).
>>>
>>> Signed-off-by: John McNamara <john.mcnamara@intel.com>
>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>>> ---
>>> doc/guides/rel_notes/deprecation.rst | 5 -----
>>> lib/librte_cmdline/cmdline_rdline.h | 2 +-
>>> 2 files changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>>> index e94d4a2..9cb288c 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -44,8 +44,3 @@ Deprecation Notices
>>> and table action handlers will be updated:
>>> the pipeline parameter will be added, the packets mask parameter will be
>>> either removed (for input port action handler) or made input-only.
>>> -
>>> -* ABI changes are planned in cmdline buffer size to allow the use of long
>>> - commands (such as RETA update in testpmd). This should impact
>>> - CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
>>> - It should be integrated in release 2.3.
>>> diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
>>> index b9aad9b..72e2dad 100644
>>> --- a/lib/librte_cmdline/cmdline_rdline.h
>>> +++ b/lib/librte_cmdline/cmdline_rdline.h
>>> @@ -93,7 +93,7 @@ extern "C" {
>>> #endif
>>>
>>> /* configuration */
>>> -#define RDLINE_BUF_SIZE 256
>>> +#define RDLINE_BUF_SIZE 512
>>> #define RDLINE_PROMPT_SIZE 32
>>> #define RDLINE_VT100_BUF_SIZE 8
>>> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>>
>> Having to break a library ABI for a change like this is a bit ridiculous.
>
> Sure, but John McNamara needed it to handle flow director with IPv6[1].
>
> For my part, I was needing it to manipulate the RETA table, but as I
> wrote in the cover letter, it ends by breaking other commands.
> Olivier Matz, has proposed another way to handle long commands lines[2],
> it could be a good idea to go on this direction.
>
> For RETA situation, we already discussed on a new API, but for now, I
> do not have time for it (and as it is another ABI breakage it could only
> be done for 16.07 or 2.4)[3].
>
> If this patch is no more needed we can just drop it, for that I would
> like to have the point of view from John.
Note that I was not objecting to the patch as such, I can easily see 256
characters not being enough for commandline buffer.
I was merely noting that having to break an ABI to increase an
effectively internal buffer size is a sign of a, um, less-than-optimal
library design.
Apologies if I wasn't clear about that,
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-12 12:46 3% ` Panu Matilainen
@ 2016-01-15 8:44 3% ` Nélio Laranjeiro
2016-01-15 9:00 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Nélio Laranjeiro @ 2016-01-15 8:44 UTC (permalink / raw)
To: Panu Matilainen, john.mcnamara; +Cc: dev
On Tue, Jan 12, 2016 at 02:46:07PM +0200, Panu Matilainen wrote:
> On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote:
> >Allow long command lines in testpmd (like flow director with IPv6, ...).
> >
> >Signed-off-by: John McNamara <john.mcnamara@intel.com>
> >Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> >---
> > doc/guides/rel_notes/deprecation.rst | 5 -----
> > lib/librte_cmdline/cmdline_rdline.h | 2 +-
> > 2 files changed, 1 insertion(+), 6 deletions(-)
> >
> >diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> >index e94d4a2..9cb288c 100644
> >--- a/doc/guides/rel_notes/deprecation.rst
> >+++ b/doc/guides/rel_notes/deprecation.rst
> >@@ -44,8 +44,3 @@ Deprecation Notices
> > and table action handlers will be updated:
> > the pipeline parameter will be added, the packets mask parameter will be
> > either removed (for input port action handler) or made input-only.
> >-
> >-* ABI changes are planned in cmdline buffer size to allow the use of long
> >- commands (such as RETA update in testpmd). This should impact
> >- CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> >- It should be integrated in release 2.3.
> >diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
> >index b9aad9b..72e2dad 100644
> >--- a/lib/librte_cmdline/cmdline_rdline.h
> >+++ b/lib/librte_cmdline/cmdline_rdline.h
> >@@ -93,7 +93,7 @@ extern "C" {
> > #endif
> >
> > /* configuration */
> >-#define RDLINE_BUF_SIZE 256
> >+#define RDLINE_BUF_SIZE 512
> > #define RDLINE_PROMPT_SIZE 32
> > #define RDLINE_VT100_BUF_SIZE 8
> > #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>
> Having to break a library ABI for a change like this is a bit ridiculous.
Sure, but John McNamara needed it to handle flow director with IPv6[1].
For my part, I was needing it to manipulate the RETA table, but as I
wrote in the cover letter, it ends by breaking other commands.
Olivier Matz, has proposed another way to handle long commands lines[2],
it could be a good idea to go on this direction.
For RETA situation, we already discussed on a new API, but for now, I
do not have time for it (and as it is another ABI breakage it could only
be done for 16.07 or 2.4)[3].
If this patch is no more needed we can just drop it, for that I would
like to have the point of view from John.
>
> I didn't try it so could be wrong, but based on a quick look, struct rdline
> could easily be made opaque to consumers by just adding functions for
> allocating and freeing it.
>
> - Panu -
>
[1] http://dpdk.org/ml/archives/dev/2015-November/027643.html
[2] http://dpdk.org/ml/archives/dev/2015-November/028557.html
[3] http://dpdk.org/ml/archives/dev/2015-October/025294.html
--
Nélio Laranjeiro
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-14 10:38 2% [dpdk-dev] Proposal for a big eal / ethdev cleanup David Marchand
@ 2016-01-14 11:46 4% ` Jan Viktorin
2016-01-16 15:53 0% ` David Marchand
2016-01-18 14:54 0% ` Declan Doherty
[not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2 siblings, 1 reply; 200+ results
From: Jan Viktorin @ 2016-01-14 11:46 UTC (permalink / raw)
To: David Marchand; +Cc: dev
Hello David,
nice to see that the things are moving...
On Thu, 14 Jan 2016 11:38:16 +0100
David Marchand <david.marchand@6wind.com> wrote:
> Hello all,
>
> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> follow) and eal structures.
> This is something I wanted to do for quite some time and the arrival of
> a new bus makes me think we need it.
>
> This is an alternative to what Jan proposed [1].
As I need to extend DPDK by a non-PCI bus system, I would prefer any such
working solution :). By [1], you probably mean:
[1] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/30973
(I didn't find it in the e-mail.)
>
> ABI is most likely broken with this, but I think this discussion can come later.
I was trying in my initial approach to stay as much API and ABI backwards
compatible as possible to be acceptable into upstream. As just a few
people have shown their interest in these changes, I consider the ABI
compatibility very important.
I can see, that your approach does not care too much... Otherwise, it looks
good to me. It is closer to the Linux drivers infra, so it seems to be clearer
then the current one.
>
>
> First some context on how dpdk is initialized at the moment :
>
> Let's imagine a system with one ixgbe pci device and take some
> part of ixgbe driver as an example.
>
> static struct eth_driver rte_ixgbe_pmd = {
> .pci_drv = {
> .name = "rte_ixgbe_pmd",
> .id_table = pci_id_ixgbe_map,
> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
> },
> .eth_dev_init = eth_ixgbe_dev_init,
> .eth_dev_uninit = eth_ixgbe_dev_uninit,
> .dev_private_size = sizeof(struct ixgbe_adapter),
> };
Note, that the biggest issue here is that the eth_driver has no way to
distinguish among PCI or other subsystem. There is no field that helps
the generic ethdev code (librte_ether) to decide what bus we are on
(and it needs to know it in the current DPDK).
Another point is that the ethdev infra should not know about the
underlying bus infra. The question is whether we do a big clean
up (extract PCI-bus code out) or a small clean up (give the ethdev
infra a hint which bus system it deals with).
>
> static int
> rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
> __rte_unused)
> {
> PMD_INIT_FUNC_TRACE();
> rte_eth_driver_register(&rte_ixgbe_pmd);
> return 0;
> }
>
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> };
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver)
>
>
> DPDK initialisation goes as follows (focusing on ixgbe driver):
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
>
> rte_eal_init()
> -> rte_eal_pci_init()
> -> rte_eal_pci_scan() which fills pci_device_list
>
> -> rte_eal_dev_init()
> -> for each rte_driver (first vdev, then pdev), call driver->init()
> so here rte_ixgbe_pmd_init(NULL, NULL)
> -> rte_eth_driver_register(&rte_ixgbe_pmd);
> -> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
> -> call rte_eal_pci_register() which adds it to pci_driver_list
>
> -> rte_eal_pci_probe()
> -> for each rte_pci_device found in rte_eal_pci_scan(), and for all
> rte_pci_driver registered, call devinit(dr, dev),
> so here rte_eth_dev_init(dr, dev)
> -> creates a new eth_dev (which is a rte_eth_dev), then adds
> reference to passed dev pointer (which is a rte_pci_device), to
> passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
> -> call eth_drv->eth_dev_init(eth_dev)
> so here eth_ixgbe_dev_init(eth_dev)
> -> fills other parts of eth_dev
> -> rte_eth_copy_pci_info(eth_dev, pci_dev)
>
>
> By the way, when invoking ethdev init, the pci-specific stuff is only
> handled in functions called from the drivers themselves, which already
> know that they are dealing with pci resources.
This is an important note as it allows to (almost) avoid touching the
current drivers.
>
>
> Later in the life of the application, ethdev api is called for hotplug.
>
> int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
>
> A devargs is used to identify a vdev/pdev driver and call it to create a
> new rte_eth_dev.
> Current code goes as far as parsing devargs to understand if this is a
> pci device or a vdev.
> This part should be moved to eal since this is where all the "bus" logic
> is.
Parsing of devargs is quite wierd - I mean whitelisting and
blacklisting. At the moment, it guesses whether the given argument is
a PCI device identification or an arbitrary string (vdev). It is not
easy to extend this reliably.
OK, I can see you are addressing this below.
>
>
>
> So now, what I had in mind is something like this.
> It is far from perfect and I certainly did some shortcuts in my
> reasoning.
>
>
> Generic device/driver
>
> - introduce a rte_device structure,
> - a rte_device has a name, that identifies it in a unique way across
> all buses, maybe something like pci:0000:00:01.0, and for vdev,
> vdev:name
Having a prefix is good but would this break the user API? Is the
name exposed to users?
> - a rte_device references a rte_driver,
> - a rte_device references devargs
> - a rte_device embeds a intr_handle
> - rte_device objects are created by "buses"
> - a function to retrieve rte_device objects based on name is added
>
> - current rte_driver does not need to know about the pmd_type
> (pdev/vdev), this is only a way to order drivers init in eal, we could
> use the rte_driver names to order them or maybe remove this ordering
What is the main reason to have pdev/vdev distinction here? After I
register the driver, does eal really need to know the pmd_type?
Moreover, there is no way how to pass arguments to pdevs, only to
vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
[2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
> - init and uninit functions are changed to take a pointer to a
> rte_device
>
> rte_device and rte_driver structures are at the "bus" level.
> Those are the basic structures we will build the other objects on.
>
>
> Impact on PCI device/driver
>
> - rte_pci_device is modified to embed a rte_device (embedding makes it
> possible later to cast the rte_device and get the rte_pci_device in pci
> specific functions)
> - no need for a rte_pci_driver reference in rte_pci_device, since we
> have the rte_device driver
I've noticed that DPDK does not use any kind of the container_of macro
like the Linux Kernel does. Instead, some considerations like the
rte_pci_driver MUST be placed at the beginning of the eth_driver (if I
am not mistaken). Here, it should be considered to do it another way.
>
> - rte_pci_driver is modified to embed a rte_driver
> - no more devinit and devuninit functions in rte_pci_driver, they can
> be moved as init / uninit functions in rte_driver
>
> - pci scan code creates rte_pci_device objects, associates them to
> rte_pci_driver, fills the driver field of the rte_driver then pass
> them to rte_driver init function.
>
> rte_pci_device and rte_pci_driver are specific implementation of
> rte_device and rte_driver.
> There are there to maintain pci private methods, create upper layer
> objects (ethdev / crypto) etc..
>
>
> Impact on vdev
>
> - introduce a rte_vdev_driver structure
> - a rte_vdev_driver embeds a rte_driver
> - a rte_vdev_driver has a priv size for vdev objects creation
>
> - no need for a vdev device object, this is specific to vdev drivers
>
> - eal init code associates devargs to vdev drivers, creates a
> rte_device object (using the priv size), fills the driver field then
> pass them to rte_driver init function.
>
>
> Impact on ethdev
>
> - a rte_eth_dev object references a rte_device in place of
> rte_pci_device
> - no more information about a driver in rte_eth_dev, this is the
> rte_device that has a reference to its rte_driver
> - eth_driver can be removed, it is only a wrapper of a rte_pci_driver
> at the moment, maybe some init function wrappers can stay in ethdev
> with dev_private_size to be handled in the rte_driver
> - rte_eth_dev objects are created by rte_drivers during probe (pci
> scan, vdev init, hotplug)
> - ethdev ops are populated by rte_drivers
>
>
> Impact on hotplug
>
> - hotplug moves from ethdev to eal
> - a notification framework is added to ethdev when hotplugging
This seems to be a good idea. I was suprised to find such code in
librte_ether...
>
> - eal uses the name (remember the pci:0000:00:01.0 / vdev:name
> example) in devargs to identify the right bus (pci / vdev)
> - pci scan code is reused to create a rte_pci_device object etc...
> - vdev init code is reused
>
>
> We end up with something like this.
> An arrow means that the structure contains a pointer to an object of the
> other struct.
> I only wrote the fields I mentioned in this mail, for pci device a lot
> of other fields are omitted.
>
> - for ethdev on top of pci devices
>
> +------------------+ +-------------------------------+
> | | | |
> | rte_pci_device | | rte_pci_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> +-------------------------------+
>
> - for ethdev on top of vdev devices
>
> +------------------+ +-------------------------------+
> | | | |
> | drv specific | | rte_vdev_driver |
> | | | |
> +-------------+ | +--------------+ | | +---------------------------+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-----> rte_driver | |
> | | | | char name[] | | | | char name[] | |
> +-------------+ | | | | | | int init(rte_device *) | |
> | +--------------+ | | | int uninit(rte_device *) | |
> | | | | | |
> +------------------+ | +---------------------------+ |
> | |
> | int priv_size |
> | |
> +-------------------------------+
>
>
> Thanks for reading.
> Comments ?
>
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 4%]
* [dpdk-dev] Proposal for a big eal / ethdev cleanup
@ 2016-01-14 10:38 2% David Marchand
2016-01-14 11:46 4% ` Jan Viktorin
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: David Marchand @ 2016-01-14 10:38 UTC (permalink / raw)
To: dev; +Cc: Jan Viktorin
Hello all,
Here is a proposal of a big cleanup in ethdev (cryptodev would have to
follow) and eal structures.
This is something I wanted to do for quite some time and the arrival of
a new bus makes me think we need it.
This is an alternative to what Jan proposed [1].
ABI is most likely broken with this, but I think this discussion can come later.
First some context on how dpdk is initialized at the moment :
Let's imagine a system with one ixgbe pci device and take some
part of ixgbe driver as an example.
static struct eth_driver rte_ixgbe_pmd = {
.pci_drv = {
.name = "rte_ixgbe_pmd",
.id_table = pci_id_ixgbe_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING |
RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
},
.eth_dev_init = eth_ixgbe_dev_init,
.eth_dev_uninit = eth_ixgbe_dev_uninit,
.dev_private_size = sizeof(struct ixgbe_adapter),
};
static int
rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
__rte_unused)
{
PMD_INIT_FUNC_TRACE();
rte_eth_driver_register(&rte_ixgbe_pmd);
return 0;
}
static struct rte_driver rte_ixgbe_driver = {
.type = PMD_PDEV,
.init = rte_ixgbe_pmd_init,
};
PMD_REGISTER_DRIVER(rte_ixgbe_driver)
DPDK initialisation goes as follows (focusing on ixgbe driver):
PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
rte_eal_init()
-> rte_eal_pci_init()
-> rte_eal_pci_scan() which fills pci_device_list
-> rte_eal_dev_init()
-> for each rte_driver (first vdev, then pdev), call driver->init()
so here rte_ixgbe_pmd_init(NULL, NULL)
-> rte_eth_driver_register(&rte_ixgbe_pmd);
-> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
-> call rte_eal_pci_register() which adds it to pci_driver_list
-> rte_eal_pci_probe()
-> for each rte_pci_device found in rte_eal_pci_scan(), and for all
rte_pci_driver registered, call devinit(dr, dev),
so here rte_eth_dev_init(dr, dev)
-> creates a new eth_dev (which is a rte_eth_dev), then adds
reference to passed dev pointer (which is a rte_pci_device), to
passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
-> call eth_drv->eth_dev_init(eth_dev)
so here eth_ixgbe_dev_init(eth_dev)
-> fills other parts of eth_dev
-> rte_eth_copy_pci_info(eth_dev, pci_dev)
By the way, when invoking ethdev init, the pci-specific stuff is only
handled in functions called from the drivers themselves, which already
know that they are dealing with pci resources.
Later in the life of the application, ethdev api is called for hotplug.
int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
A devargs is used to identify a vdev/pdev driver and call it to create a
new rte_eth_dev.
Current code goes as far as parsing devargs to understand if this is a
pci device or a vdev.
This part should be moved to eal since this is where all the "bus" logic
is.
So now, what I had in mind is something like this.
It is far from perfect and I certainly did some shortcuts in my
reasoning.
Generic device/driver
- introduce a rte_device structure,
- a rte_device has a name, that identifies it in a unique way across
all buses, maybe something like pci:0000:00:01.0, and for vdev,
vdev:name
- a rte_device references a rte_driver,
- a rte_device references devargs
- a rte_device embeds a intr_handle
- rte_device objects are created by "buses"
- a function to retrieve rte_device objects based on name is added
- current rte_driver does not need to know about the pmd_type
(pdev/vdev), this is only a way to order drivers init in eal, we could
use the rte_driver names to order them or maybe remove this ordering
- init and uninit functions are changed to take a pointer to a
rte_device
rte_device and rte_driver structures are at the "bus" level.
Those are the basic structures we will build the other objects on.
Impact on PCI device/driver
- rte_pci_device is modified to embed a rte_device (embedding makes it
possible later to cast the rte_device and get the rte_pci_device in pci
specific functions)
- no need for a rte_pci_driver reference in rte_pci_device, since we
have the rte_device driver
- rte_pci_driver is modified to embed a rte_driver
- no more devinit and devuninit functions in rte_pci_driver, they can
be moved as init / uninit functions in rte_driver
- pci scan code creates rte_pci_device objects, associates them to
rte_pci_driver, fills the driver field of the rte_driver then pass
them to rte_driver init function.
rte_pci_device and rte_pci_driver are specific implementation of
rte_device and rte_driver.
There are there to maintain pci private methods, create upper layer
objects (ethdev / crypto) etc..
Impact on vdev
- introduce a rte_vdev_driver structure
- a rte_vdev_driver embeds a rte_driver
- a rte_vdev_driver has a priv size for vdev objects creation
- no need for a vdev device object, this is specific to vdev drivers
- eal init code associates devargs to vdev drivers, creates a
rte_device object (using the priv size), fills the driver field then
pass them to rte_driver init function.
Impact on ethdev
- a rte_eth_dev object references a rte_device in place of
rte_pci_device
- no more information about a driver in rte_eth_dev, this is the
rte_device that has a reference to its rte_driver
- eth_driver can be removed, it is only a wrapper of a rte_pci_driver
at the moment, maybe some init function wrappers can stay in ethdev
with dev_private_size to be handled in the rte_driver
- rte_eth_dev objects are created by rte_drivers during probe (pci
scan, vdev init, hotplug)
- ethdev ops are populated by rte_drivers
Impact on hotplug
- hotplug moves from ethdev to eal
- a notification framework is added to ethdev when hotplugging
- eal uses the name (remember the pci:0000:00:01.0 / vdev:name
example) in devargs to identify the right bus (pci / vdev)
- pci scan code is reused to create a rte_pci_device object etc...
- vdev init code is reused
We end up with something like this.
An arrow means that the structure contains a pointer to an object of the
other struct.
I only wrote the fields I mentioned in this mail, for pci device a lot
of other fields are omitted.
- for ethdev on top of pci devices
+------------------+ +-------------------------------+
| | | |
| rte_pci_device | | rte_pci_driver |
| | | |
+-------------+ | +--------------+ | | +---------------------------+ |
| | | | | | | | | |
| rte_eth_dev +---> rte_device +-----> rte_driver | |
| | | | char name[] | | | | char name[] | |
+-------------+ | | | | | | int init(rte_device *) | |
| +--------------+ | | | int uninit(rte_device *) | |
| | | | | |
+------------------+ | +---------------------------+ |
| |
+-------------------------------+
- for ethdev on top of vdev devices
+------------------+ +-------------------------------+
| | | |
| drv specific | | rte_vdev_driver |
| | | |
+-------------+ | +--------------+ | | +---------------------------+ |
| | | | | | | | | |
| rte_eth_dev +---> rte_device +-----> rte_driver | |
| | | | char name[] | | | | char name[] | |
+-------------+ | | | | | | int init(rte_device *) | |
| +--------------+ | | | int uninit(rte_device *) | |
| | | | | |
+------------------+ | +---------------------------+ |
| |
| int priv_size |
| |
+-------------------------------+
Thanks for reading.
Comments ?
--
David Marchand
[1] http://dpdk.org/ml/archives/dev/2016-January/030975.html
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v2 1/6] lib/librte_ether: change function name of tunnel port config
@ 2016-01-14 1:38 4% ` Wenzhuo Lu
0 siblings, 0 replies; 200+ results
From: Wenzhuo Lu @ 2016-01-14 1:38 UTC (permalink / raw)
To: dev
The names of function for tunnel port configuration are not
accurate. They're tunnel_add/del, better change them to
tunnel_port_add/del.
As it may be an ABI change if change the names directly, the
new functions are added but not remove the old ones. The old
ones will be removed in the next release after an ABI change
announcement.
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
app/test-pmd/cmdline.c | 6 +++--
examples/tep_termination/vxlan_setup.c | 2 +-
lib/librte_ether/rte_ethdev.c | 45 ++++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 18 ++++++++++++++
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..4e71e90 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6780,9 +6780,11 @@ cmd_tunnel_udp_config_parsed(void *parsed_result,
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
if (!strcmp(res->what, "add"))
- ret = rte_eth_dev_udp_tunnel_add(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_add(res->port_id,
+ &tunnel_udp);
else
- ret = rte_eth_dev_udp_tunnel_delete(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_delete(res->port_id,
+ &tunnel_udp);
if (ret < 0)
printf("udp tunneling add error: (%s)\n", strerror(-ret));
diff --git a/examples/tep_termination/vxlan_setup.c b/examples/tep_termination/vxlan_setup.c
index 51ad133..8836603 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -191,7 +191,7 @@ vxlan_port_init(uint8_t port, struct rte_mempool *mbuf_pool)
/* Configure UDP port for UDP tunneling */
tunnel_udp.udp_port = udp_port;
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
- retval = rte_eth_dev_udp_tunnel_add(port, &tunnel_udp);
+ retval = rte_eth_dev_udp_tunnel_port_add(port, &tunnel_udp);
if (retval < 0)
return retval;
rte_eth_macaddr_get(port, &ports_eth_addr[port]);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..74428f4 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1987,6 +1987,28 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_add, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_add)(dev, udp_tunnel);
+}
+
+int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *udp_tunnel)
{
@@ -2010,6 +2032,29 @@ rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_del, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_del)(dev, udp_tunnel);
+}
+
+int
rte_eth_led_on(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..2e064f4 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1261,6 +1261,14 @@ typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
/**< @internal Program eeprom data */
+typedef int (*eth_udp_tunnel_port_add_t)(struct rte_eth_dev *dev,
+ struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Add tunneling UDP port */
+
+typedef int (*eth_udp_tunnel_port_del_t)(struct rte_eth_dev *dev,
+ struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Delete tunneling UDP port */
+
#ifdef RTE_NIC_BYPASS
enum {
@@ -1443,6 +1451,10 @@ struct eth_dev_ops {
eth_timesync_read_time timesync_read_time;
/** Set the device clock time. */
eth_timesync_write_time timesync_write_time;
+ /** Add UDP tunnel port. */
+ eth_udp_tunnel_port_add_t udp_tunnel_port_add;
+ /** Del UDP tunnel port. */
+ eth_udp_tunnel_port_del_t udp_tunnel_port_del;
};
/**
@@ -3408,6 +3420,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t port_id,
int
rte_eth_dev_udp_tunnel_add(uint8_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
+int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* Detete UDP tunneling port configuration of Ethernet device
@@ -3425,6 +3440,9 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
+int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* Check whether the filter type is supported on an Ethernet device.
--
1.9.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 00/14] Step towards PCI independency
@ 2016-01-13 14:07 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2016-01-13 14:07 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
Hello Jan,
On Mon, Jan 11, 2016 at 6:29 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> Hello David,
>
> did you find time to see the patchset? I am working on a PMD on top of
> these so I'd be glad to base on the code close to the (potentially)
> upstreamed one.
I took a quick look but since we still have an abi breakage, I am
trying to put my ideas on paper and will share to you asap.
Regards,
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2016-01-13 11:55 3% ` Bruce Richardson
@ 2016-01-13 12:22 3% ` Panu Matilainen
2016-01-28 21:38 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-13 12:22 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: Ziye Yang, dev
On 01/13/2016 01:55 PM, Bruce Richardson wrote:
> On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
>> On Tue, 29 Dec 2015 10:53:26 +0800
>> Ziye Yang <ziye.yang@intel.com> wrote:
>>
>>> This patch is used to add the class_id support
>>> for pci_probe since some devices need the class_info
>>> (class_code, subclass_code, programming_interface)
>>>
>>> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>>
>> Since rte_pci is exposed to application this breaks the ABI.
>
> But applications are not going to be defining rte_pci_ids values internally, are
> they? That is for drivers to use. Is this really an ABI breakage for applications that we
> need to be concerned about?
There might not be applications using it but drivers are ABI consumers
too - think of 3rd party drivers and such.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
2015-12-31 17:12 3% ` Stephen Hemminger
@ 2016-01-13 11:55 3% ` Bruce Richardson
2016-01-13 12:22 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2016-01-13 11:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Ziye Yang, dev
On Thu, Dec 31, 2015 at 09:12:14AM -0800, Stephen Hemminger wrote:
> On Tue, 29 Dec 2015 10:53:26 +0800
> Ziye Yang <ziye.yang@intel.com> wrote:
>
> > This patch is used to add the class_id support
> > for pci_probe since some devices need the class_info
> > (class_code, subclass_code, programming_interface)
> >
> > Signed-off-by: Ziye Yang <ziye.yang@intel.com>
>
> Since rte_pci is exposed to application this breaks the ABI.
But applications are not going to be defining rte_pci_ids values internally, are
they? That is for drivers to use. Is this really an ABI breakage for applications that we
need to be concerned about?
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
2016-01-12 12:37 0% ` Thomas Monjalon
@ 2016-01-13 2:50 0% ` Lu, Wenzhuo
0 siblings, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2016-01-13 2:50 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, January 12, 2016 8:37 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Cc: dev@dpdk.org; Vincent JARDIN <vincent.jardin@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
>
> Hi,
>
> 2016-01-11 08:28, Lu, Wenzhuo:
> > [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed.
> I just use them. Honestly I agree with you they are not accurate name. Better
> change them to udp_tunnel_port_add and udp_tunnel_port_del. But it
> should be a ABI change if I’m not wrong. I think we can announce it this
> release and change them in the next release. Would you agree? Thanks.
>
> You can introduce the new name and keep the old one for backward compat
> while announcing its deprecation.
Good suggestion, I'll send a new patch set for this change. Thanks.
> Thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 13:57 3% ` Pavel Fedin
@ 2016-01-12 14:13 4% ` Sergio Gonzalez Monroy
0 siblings, 0 replies; 200+ results
From: Sergio Gonzalez Monroy @ 2016-01-12 14:13 UTC (permalink / raw)
To: Pavel Fedin
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
On 12/01/2016 13:57, Pavel Fedin wrote:
> Hello!
>
>> I might be missing something obvious here but, aside from having memory
>> SHARED which most DPDK apps using hugepages will have anyway, what is
>> the backward compatibility issues that you see here?
> Heh, sorry once again for confusing. Indeed, with hugepages we always get MAP_SHARED. I missed that. So, we indeed need
> --shared-mem only in addition to --no-huge.
>
> Backwards compatibility issue is stated in the description of PATCH 1/4:
> --- cut ---
> b. possible ABI break, originally, --no-huge uses anonymous memory
> instead of file-backed way to create memory.
> --- cut ---
> The patch unconditionally changes that to SHARED. That's all.
I should read more carefully!
Sorry about that, I thought you were the one with the ABI concerns.
Regarding ABI, I don't think there is any ABI issue with the change, we
just have our memory file-backed and SHARED but we do that when using
hugepages so I don't think it would be a huge issue.
But if folks have concerns about it, we could always keep old behavior
by default and, as you suggest, introduce another option for changing
the flag.
Sergio
> Kind regards,
> Pavel Fedin
> Senior Engineer
> Samsung Electronics Research center Russia
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
@ 2016-01-12 13:57 3% ` Pavel Fedin
2016-01-12 14:13 4% ` Sergio Gonzalez Monroy
0 siblings, 1 reply; 200+ results
From: Pavel Fedin @ 2016-01-12 13:57 UTC (permalink / raw)
To: 'Sergio Gonzalez Monroy'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
> I might be missing something obvious here but, aside from having memory
> SHARED which most DPDK apps using hugepages will have anyway, what is
> the backward compatibility issues that you see here?
Heh, sorry once again for confusing. Indeed, with hugepages we always get MAP_SHARED. I missed that. So, we indeed need
--shared-mem only in addition to --no-huge.
Backwards compatibility issue is stated in the description of PATCH 1/4:
--- cut ---
b. possible ABI break, originally, --no-huge uses anonymous memory
instead of file-backed way to create memory.
--- cut ---
The patch unconditionally changes that to SHARED. That's all.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
@ 2016-01-12 12:46 3% ` Panu Matilainen
2016-01-15 8:44 3% ` Nélio Laranjeiro
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2016-01-12 12:46 UTC (permalink / raw)
To: Nelio Laranjeiro, dev
On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote:
> Allow long command lines in testpmd (like flow director with IPv6, ...).
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 -----
> lib/librte_cmdline/cmdline_rdline.h | 2 +-
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index e94d4a2..9cb288c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -44,8 +44,3 @@ Deprecation Notices
> and table action handlers will be updated:
> the pipeline parameter will be added, the packets mask parameter will be
> either removed (for input port action handler) or made input-only.
> -
> -* ABI changes are planned in cmdline buffer size to allow the use of long
> - commands (such as RETA update in testpmd). This should impact
> - CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> - It should be integrated in release 2.3.
> diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
> index b9aad9b..72e2dad 100644
> --- a/lib/librte_cmdline/cmdline_rdline.h
> +++ b/lib/librte_cmdline/cmdline_rdline.h
> @@ -93,7 +93,7 @@ extern "C" {
> #endif
>
> /* configuration */
> -#define RDLINE_BUF_SIZE 256
> +#define RDLINE_BUF_SIZE 512
> #define RDLINE_PROMPT_SIZE 32
> #define RDLINE_VT100_BUF_SIZE 8
> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
Having to break a library ABI for a change like this is a bit ridiculous.
I didn't try it so could be wrong, but based on a quick look, struct
rdline could easily be made opaque to consumers by just adding functions
for allocating and freeing it.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
2016-01-11 8:28 3% ` Lu, Wenzhuo
2016-01-11 8:41 3% ` Vincent JARDIN
@ 2016-01-12 12:37 0% ` Thomas Monjalon
2016-01-13 2:50 0% ` Lu, Wenzhuo
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2016-01-12 12:37 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev
Hi,
2016-01-11 08:28, Lu, Wenzhuo:
> [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I just use them. Honestly I agree with you they are not accurate name. Better change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should be a ABI change if I’m not wrong. I think we can announce it this release and change them in the next release. Would you agree? Thanks.
You can introduce the new name and keep the old one for backward compat
while announcing its deprecation.
Thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
@ 2016-01-12 11:44 3% ` Sergio Gonzalez Monroy
1 sibling, 0 replies; 200+ results
From: Sergio Gonzalez Monroy @ 2016-01-12 11:44 UTC (permalink / raw)
To: Pavel Fedin
Cc: dev, nakajima.yoshihiro, ann.zhuangyanying, 'Michael S. Tsirkin'
On 12/01/2016 11:07, Sergio Gonzalez Monroy wrote:
> Hi Pavel,
>
> On 12/01/2016 11:00, Pavel Fedin wrote:
>> Hello!
>>
>>>> BTW, i'm still unhappy about ABI breakage here. I think we could
>>>> easily add --shared-mem
Could you elaborate a bit more on your concerns regarding ABI breakage ?
>>> option, which would simply change mapping mode to SHARED. So, we
>>> could use it with both
>>> hugepages (default) and plain mmap (with --no-hugepages).
>>>
>>> You mean, use "--no-hugepages --shared-mem" together, right?
>> Yes. This would be perfectly backwards-compatible because.
>
> So are you suggesting to not introduce --single-file option but
> instead --shared-mem?
> AFAIK --single-file was trying to workaround the limitation of just
> being able to map 8 fds.
>
My bad, I misread the posts.
Jianfeng pointed out that you are suggesting to have --shared-mem to
have same functionality
with or without hugepages.
Sergio
> Sergio
>> Kind regards,
>> Pavel Fedin
>> Senior Engineer
>> Samsung Electronics Research center Russia
>>
>>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 11:00 0% ` Pavel Fedin
@ 2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
2016-01-12 11:44 3% ` Sergio Gonzalez Monroy
0 siblings, 2 replies; 200+ results
From: Sergio Gonzalez Monroy @ 2016-01-12 11:07 UTC (permalink / raw)
To: Pavel Fedin
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hi Pavel,
On 12/01/2016 11:00, Pavel Fedin wrote:
> Hello!
>
>>> BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem
>> option, which would simply change mapping mode to SHARED. So, we could use it with both
>> hugepages (default) and plain mmap (with --no-hugepages).
>>
>> You mean, use "--no-hugepages --shared-mem" together, right?
> Yes. This would be perfectly backwards-compatible because.
So are you suggesting to not introduce --single-file option but instead
--shared-mem?
AFAIK --single-file was trying to workaround the limitation of just
being able to map 8 fds.
Sergio
> Kind regards,
> Pavel Fedin
> Senior Engineer
> Samsung Electronics Research center Russia
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 10:48 0% ` Tan, Jianfeng
@ 2016-01-12 11:00 0% ` Pavel Fedin
2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
0 siblings, 1 reply; 200+ results
From: Pavel Fedin @ 2016-01-12 11:00 UTC (permalink / raw)
To: 'Tan, Jianfeng', 'Rich Lane'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
> > BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem
> option, which would simply change mapping mode to SHARED. So, we could use it with both
> hugepages (default) and plain mmap (with --no-hugepages).
>
> You mean, use "--no-hugepages --shared-mem" together, right?
Yes. This would be perfectly backwards-compatible because.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
@ 2016-01-12 10:49 11% ` Nelio Laranjeiro
1 sibling, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-12 10:49 UTC (permalink / raw)
To: dev
Several NICs can handle 512 entries/queues in their RETA table, an 8 bit field
is not large enough for them.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
4 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..9c7cda0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1767,7 +1767,7 @@ parse_reta_config(const char *str,
int i;
unsigned size;
uint16_t hash_index, idx, shift;
- uint8_t nb_queue;
+ uint16_t nb_queue;
char s[256];
const char *p, *p0 = str;
char *end;
@@ -1800,7 +1800,7 @@ parse_reta_config(const char *str,
}
hash_index = (uint16_t)int_fld[FLD_HASH_INDEX];
- nb_queue = (uint8_t)int_fld[FLD_QUEUE];
+ nb_queue = (uint16_t)int_fld[FLD_QUEUE];
if (hash_index >= nb_entries) {
printf("Invalid RETA hash index=%d\n", hash_index);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 9cb288c..9930b5a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -15,11 +15,6 @@ Deprecation Notices
* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
must be updated to support 100G link and to have a cleaner link speed API.
-* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
- which handles at most 256 queues (8 bits) while newer NICs support larger
- tables (512 queues).
- It should be integrated in release 2.3.
-
* ABI changes are planned for struct rte_eth_fdir_flow in order to support
extend flow director's input set. The release 2.2 does not contain these ABI
changes, but release 2.3 will, and no backwards compatibility is planned.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..b0aa94d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1857,7 +1857,7 @@ rte_eth_check_reta_mask(struct rte_eth_rss_reta_entry64 *reta_conf,
static int
rte_eth_check_reta_entry(struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size,
- uint8_t max_rxq)
+ uint16_t max_rxq)
{
uint16_t i, idx, shift;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..8302a2d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -520,7 +520,7 @@ struct rte_eth_mirror_conf {
struct rte_eth_rss_reta_entry64 {
uint64_t mask;
/**< Mask bits indicate which entries need to be updated/queried. */
- uint8_t reta[RTE_RETA_GROUP_SIZE];
+ uint16_t reta[RTE_RETA_GROUP_SIZE];
/**< Group of 64 redirection table entries. */
};
--
2.1.4
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
@ 2016-01-12 10:49 5% ` Nelio Laranjeiro
2016-01-12 12:46 3% ` Panu Matilainen
2016-01-12 10:49 11% ` [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
1 sibling, 1 reply; 200+ results
From: Nelio Laranjeiro @ 2016-01-12 10:49 UTC (permalink / raw)
To: dev
Allow long command lines in testpmd (like flow director with IPv6, ...).
Signed-off-by: John McNamara <john.mcnamara@intel.com>
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_cmdline/cmdline_rdline.h | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..9cb288c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -44,8 +44,3 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
-
-* ABI changes are planned in cmdline buffer size to allow the use of long
- commands (such as RETA update in testpmd). This should impact
- CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
- It should be integrated in release 2.3.
diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
index b9aad9b..72e2dad 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -93,7 +93,7 @@ extern "C" {
#endif
/* configuration */
-#define RDLINE_BUF_SIZE 256
+#define RDLINE_BUF_SIZE 512
#define RDLINE_PROMPT_SIZE 32
#define RDLINE_VT100_BUF_SIZE 8
#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
--
2.1.4
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2016-01-06 14:32 5% ` [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer Nelio Laranjeiro
@ 2016-01-12 10:49 4% ` Nelio Laranjeiro
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 10:49 11% ` [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2 siblings, 2 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-12 10:49 UTC (permalink / raw)
To: dev
Previous version of commit
"cmdline: increase command line buffer", had side effects and was breaking
some commands.
In this version, I only applied John McNamara's solution which consists in
increasing only RDLINE_BUF_SIZE define from 256 to 512 bytes [1].
[1] http://dpdk.org/ml/archives/dev/2015-November/027643.html
Nelio Laranjeiro (3):
cmdline: increase command line buffer
ethdev: change RETA type in rte_eth_rss_reta_entry64
mlx5: increase RETA table size
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 10 ----------
drivers/net/mlx5/mlx5_defs.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
6 files changed, 6 insertions(+), 16 deletions(-)
--
2.1.4
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
2016-01-12 10:04 3% ` Pavel Fedin
@ 2016-01-12 10:48 0% ` Tan, Jianfeng
2016-01-12 11:00 0% ` Pavel Fedin
0 siblings, 1 reply; 200+ results
From: Tan, Jianfeng @ 2016-01-12 10:48 UTC (permalink / raw)
To: Pavel Fedin, 'Rich Lane'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
> But in this case host gets this page size for total region size, therefore qva_to_vva() fails.
> I haven't worked with hugepages, but i guess that with real hugepages we get one file per page, therefore page size == mapping size. With newly introduced --single-file we now have something that pretends to be a single "uber-huge-page", so we need to specify total size of the mapping here.
Oh I get it and recognize the problem here. The actual problem lies in
the API rte_eal_get_backfile_info().
backfiles[i].size = hugepage_files[i].size;
Should use statfs or hugepage_files[i].size * hugepage_files[i].repeated
to calculate the total size.
>
> BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem option, which would simply change mapping mode to SHARED. So, we could use it with both hugepages (default) and plain mmap (with --no-hugepages).
You mean, use "--no-hugepages --shared-mem" together, right?
That makes sense to me.
Thanks,
Jianfeng
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
@ 2016-01-12 10:04 3% ` Pavel Fedin
2016-01-12 10:48 0% ` Tan, Jianfeng
0 siblings, 1 reply; 200+ results
From: Pavel Fedin @ 2016-01-12 10:04 UTC (permalink / raw)
To: 'Tan, Jianfeng', 'Rich Lane'
Cc: nakajima.yoshihiro, 'Michael S. Tsirkin', dev, ann.zhuangyanying
Hello!
>> Should this be "hugepage->size = internal_config.memory"? Otherwise the vhost-user
>> memtable entry has a size of only 2MB.
> I don't think so. See the definition:
> 47 struct hugepage_file {
> 48 void *orig_va; /**< virtual addr of first mmap() */
> 49 void *final_va; /**< virtual addr of 2nd mmap() */
> 50 uint64_t physaddr; /**< physical addr */
> 51 size_t size; /**< the page size */
> 52 int socket_id; /**< NUMA socket ID */
> 53 int file_id; /**< the '%d' in HUGEFILE_FMT */
> 54 int memseg_id; /**< the memory segment to which page belongs */
> 55 #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS
> 56 int repeated; /**< number of times the page size is repeated */
> 57 #endif
> 58 char filepath[MAX_HUGEPAGE_PATH]; /**< path to backing file on filesystem */
> 59 };
> size stands for the page size instead of total size.
But in this case host gets this page size for total region size, therefore qva_to_vva() fails.
I haven't worked with hugepages, but i guess that with real hugepages we get one file per page, therefore page size == mapping size. With newly introduced --single-file we now have something that pretends to be a single "uber-huge-page", so we need to specify total size of the mapping here.
BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem option, which would simply change mapping mode to SHARED. So, we could use it with both hugepages (default) and plain mmap (with --no-hugepages).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter
2015-12-23 12:41 3% ` [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter Rahul Lakkireddy
@ 2016-01-11 13:50 0% ` Rahul Lakkireddy
0 siblings, 0 replies; 200+ results
From: Rahul Lakkireddy @ 2016-01-11 13:50 UTC (permalink / raw)
To: dev; +Cc: Kumar Sanghvi, Felix Marti, Nirranjan Kirubaharan
Hi All,
On Wednesday, December 12/23/15, 2015 at 18:11:19 +0530, Rahul Lakkireddy wrote:
> This RFC series of patches attempt to extend the flow director filter to
> add support for Chelsio T5 hardware filtering capabilities.
>
> Chelsio T5 supports carrying out filtering in hardware which supports 3
> actions to carry out on a packet which hit a filter viz.
>
> 1. Action Pass - Packets hitting a filter rule can be directed to a
> particular RXQ.
>
> 2. Action Drop - Packets hitting a filter rule are dropped in h/w.
>
> 3. Action Switch - Packets hitting a filter rule can be switched in h/w
> from one port to another, without involvement of host. Also, the
> action Switch also supports rewrite of src-mac/dst-mac headers as
> well as rewrite of vlan headers. It also supports rewrite of IP
> headers and thereby, supports NAT (Network Address Translation)
> in h/w.
>
> Also, each filter rule can optionally support specifying a mask value
> i.e. it's possible to create a filter rule for an entire subnet of IP
> addresses or a range of tcp/udp ports, etc.
>
> Patch 1 does the following:
> - Adds an additional flow rte_eth_pkt_filter_flow which encapsulates
> ingress ports, l2 payload, vlan and ntuples.
> - Adds an additional mask for the flow to allow range of values to be
> matched.
> - Adds an ability to set both filters with masks (Maskfull) and
> without masks (Maskless). Also allow prioritizing one of these
> filter types over the other when a packet matches several types.
> - Adds a new behavior 'switch'.
> - Adds behavior arguments that can be passed when a particular behavior
> is taken. For ex: in case of action 'switch', pass additional 4-tuple
> to allow rewriting src/dst ip and port addresses to support NAT'ing.
>
> Patch 2 shows testpmd command line example to support packet filter
> flow.
>
> The patch series has been compile tested on all x86 gcc targets and the
> current fdir filter supported drivers seem to return appropriate error
> codes when this new flow type and the new action are not supported and
> hence are not affected.
>
> Posting this series mainly for discussion on API change. Once this is
> agreeable then, I will post the cxgbe PMD changes to use the new API.
>
> ---
> v2:
> 1. Added ttl to rte_eth_ipv4_flow and tc, flow_label, next_header,
> and hop_limit to rte_eth_ipv6_flow.
>
> 2. Added new field type to rte_eth_pkt_filter_flow to differentiate
> between maskfull and maskless filter types.
>
> 3. Added new field prio to rte_eth_pkt_filter_flow to allow setting
> priority over maskfull or maskless when packet matches multiple
> filter types.
>
> 4. Added new behavior sub op RTE_FDIR_BEHAVIOR_SUB_OP_SWAP to allow
> swapping fields in matched flows. For ex, useful when swapping mac
> addresses in hardware before switching.
>
> 5. Updated the testpmd example to reflect the above new changes.
>
> 6. Dropped Patch 3 since the ABI announcement has already been merged.
>
> Rahul Lakkireddy (2):
> ethdev: add packet filter flow and new behavior switch to fdir
> testpmd: add an example to show packet filter flow
>
> app/test-pmd/cmdline.c | 528 +++++++++++++++++++++++++++++++++++++++-
> lib/librte_ether/rte_eth_ctrl.h | 127 +++++++++-
> 2 files changed, 646 insertions(+), 9 deletions(-)
>
> --
> 2.5.3
>
Any comments on this RFC series? If the overall approach is fine then,
I'll re-submit it as a PATCH series along with the CXGBE PMD driver
changes.
Thanks,
Rahul
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
2016-01-11 8:28 3% ` Lu, Wenzhuo
@ 2016-01-11 8:41 3% ` Vincent JARDIN
2016-01-12 12:37 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Vincent JARDIN @ 2016-01-11 8:41 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev
> [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I
just use them. Honestly I agree with you they are not accurate name. Better
change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should
be a ABI change if I’m not wrong. I think we can announce it this release
and change them in the next release. Would you agree? Thanks.
Yes you are right.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
@ 2016-01-11 8:28 3% ` Lu, Wenzhuo
2016-01-11 8:41 3% ` Vincent JARDIN
2016-01-12 12:37 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Lu, Wenzhuo @ 2016-01-11 8:28 UTC (permalink / raw)
To: Vincent JARDIN; +Cc: dev
Hi Vincent,
From: Vincent JARDIN [mailto:vincent.jardin@6wind.com]
Sent: Monday, January 11, 2016 3:41 PM
To: Lu, Wenzhuo <wenzhuo.lu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del
see inline
Le 11 janv. 2016 08:08, "Wenzhuo Lu" <wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>> a écrit :
>
> Add UDP tunnel add/del support on ixgbe. Now it only support
> VxLAN port configuration.
> Although the VxLAN port has a default value 4789, it can be
> changed. We support VxLAN port configuration to meet the
> change.
> Note, the default value of VxLAN port in ixgbe NICs is 0. So
> please set it when using VxLAN off-load.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>>
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 93 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 4c4c6df..381cbad 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -337,6 +337,10 @@ static int ixgbe_timesync_read_time(struct rte_eth_dev *dev,
> struct timespec *timestamp);
> static int ixgbe_timesync_write_time(struct rte_eth_dev *dev,
> const struct timespec *timestamp);
> +static int ixgbe_dev_udp_tunnel_add(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel);
> +static int ixgbe_dev_udp_tunnel_del(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel);
>
> /*
> * Define VF Stats MACRO for Non "cleared on read" register
> @@ -495,6 +499,8 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
> .timesync_adjust_time = ixgbe_timesync_adjust_time,
> .timesync_read_time = ixgbe_timesync_read_time,
> .timesync_write_time = ixgbe_timesync_write_time,
> + .udp_tunnel_add = ixgbe_dev_udp_tunnel_add,
> + .udp_tunnel_del = ixgbe_dev_udp_tunnel_del,
> };
>
Your patch is not adding HW tunnel support but port management.
> /*
> @@ -6191,6 +6197,93 @@ ixgbe_dev_get_dcb_info(struct rte_eth_dev *dev,
> return 0;
> }
>
> +#define DEFAULT_VXLAN_PORT 4789
> +
> +/* on x550, there's only one register for VxLAN UDP port.
> + * So, we cannot add or del the port. We only update it.
> + */
> +static int
> +ixgbe_update_vxlan_port(struct ixgbe_hw *hw,
> + uint16_t port)
> +{
> + IXGBE_WRITE_REG(hw, IXGBE_VXLANCTRL, port);
> + IXGBE_WRITE_FLUSH(hw);
> +
> + return 0;
> +}
> +
> +/* Add UDP tunneling port */
> +static int
> +ixgbe_dev_udp_tunnel_add(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel)
> +{
> + int ret = 0;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + if (hw->mac.type != ixgbe_mac_X550 &&
> + hw->mac.type != ixgbe_mac_X550EM_x) {
> + return -ENOTSUP;
> + }
> +
> + if (udp_tunnel == NULL)
> + return -EINVAL;
> +
> + switch (udp_tunnel->prot_type) {
> + case RTE_TUNNEL_TYPE_VXLAN:
> + /* cannot add a port, update the port value */
> + ret = ixgbe_update_vxlan_port(hw, udp_tunnel->udp_port);
> + break;
> +
> + case RTE_TUNNEL_TYPE_GENEVE:
> + case RTE_TUNNEL_TYPE_TEREDO:
> + PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
> + ret = -1;
> + break;
> +
> + default:
> + PMD_DRV_LOG(ERR, "Invalid tunnel type");
> + ret = -1;
> + break;
> + }
> +
> + return ret;
> +}
Is tunnel_add a proper naming? We need to keep flexibility for NICs that will support full HW tunneling support.
Here it is about setting registers.
> +
> +/* Remove UDP tunneling port */
> +static int
> +ixgbe_dev_udp_tunnel_del(struct rte_eth_dev *dev,
> + struct rte_eth_udp_tunnel *udp_tunnel)
> +{
> + int ret = 0;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + if (hw->mac.type != ixgbe_mac_X550 &&
> + hw->mac.type != ixgbe_mac_X550EM_x) {
> + return -ENOTSUP;
> + }
> +
> + if (udp_tunnel == NULL)
> + return -EINVAL;
> +
> + switch (udp_tunnel->prot_type) {
> + case RTE_TUNNEL_TYPE_VXLAN:
> + /* cannot del the port, reset it to default */
> + ret = ixgbe_update_vxlan_port(hw, DEFAULT_VXLAN_PORT);
> + break;
> + case RTE_TUNNEL_TYPE_GENEVE:
> + case RTE_TUNNEL_TYPE_TEREDO:
> + PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
> + ret = -1;
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "Invalid tunnel type");
> + ret = -1;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> --
> 1.9.3
>
I think the semantic of this serie should be revisited. It is about adding the support of inner/outer checksum for encapsulated packets but not the support of HW encap/decap (tunnel?).
[Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I just use them. Honestly I agree with you they are not accurate name. Better change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should be a ABI change if I’m not wrong. I think we can announce it this release and change them in the next release. Would you agree? Thanks.
Thank you,
Vincent
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/4] mem: add --single-file to create single mem-backed file
@ 2016-01-10 11:42 2% ` Jianfeng Tan
1 sibling, 0 replies; 200+ results
From: Jianfeng Tan @ 2016-01-10 11:42 UTC (permalink / raw)
To: dev; +Cc: nakajima.yoshihiro, mst, ann.zhuangyanying
Originally, there're two cons in using hugepage: a. needs root
privilege to touch /proc/self/pagemap, which is a premise to
alllocate physically contiguous memseg; b. possibly too many
hugepage file are created, especially used with 2M hugepage.
For virtual devices, they don't care about physical-contiguity
of allocated hugepages at all. Option --single-file is to
provide a way to allocate all hugepages into single mem-backed
file.
Known issue:
a. single-file option relys on kernel to allocate numa-affinitive
memory.
b. possible ABI break, originally, --no-huge uses anonymous memory
instead of file-backed way to create memory.
Signed-off-by: Huawei Xie <huawei.xie@intel.com>
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
lib/librte_eal/common/eal_common_options.c | 17 +++++++++++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h | 2 ++
lib/librte_eal/linuxapp/eal/eal_memory.c | 45 ++++++++++++++++++++++++++----
4 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 29942ea..65bccbd 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM },
{OPT_VMWARE_TSC_MAP, 0, NULL, OPT_VMWARE_TSC_MAP_NUM },
{OPT_XEN_DOM0, 0, NULL, OPT_XEN_DOM0_NUM },
+ {OPT_SINGLE_FILE, 0, NULL, OPT_SINGLE_FILE_NUM },
{0, 0, NULL, 0 }
};
@@ -897,6 +898,10 @@ eal_parse_common_option(int opt, const char *optarg,
}
break;
+ case OPT_SINGLE_FILE_NUM:
+ conf->single_file = 1;
+ break;
+
/* don't know what to do, leave this to caller */
default:
return 1;
@@ -956,6 +961,16 @@ eal_check_common_options(struct internal_config *internal_cfg)
"be specified together with --"OPT_NO_HUGE"\n");
return -1;
}
+ if (internal_cfg->single_file && internal_cfg->force_sockets == 1) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_SINGLE_FILE" cannot "
+ "be specified together with --"OPT_SOCKET_MEM"\n");
+ return -1;
+ }
+ if (internal_cfg->single_file && internal_cfg->hugepage_unlink) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_HUGE_UNLINK" cannot "
+ "be specified together with --"OPT_SINGLE_FILE"\n");
+ return -1;
+ }
if (internal_cfg->no_hugetlbfs && internal_cfg->hugepage_unlink) {
RTE_LOG(ERR, EAL, "Option --"OPT_HUGE_UNLINK" cannot "
@@ -994,6 +1009,8 @@ eal_common_usage(void)
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
" -r RANKS Force number of memory ranks (don't detect)\n"
+ " --"OPT_SINGLE_FILE" Create just single file for shared memory, and \n"
+ " do not promise physical contiguity of memseg\n"
" -b, --"OPT_PCI_BLACKLIST" Add a PCI device in black list.\n"
" Prevent EAL from using this PCI device. The argument\n"
" format is <domain:bus:devid.func>.\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..9117ed9 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -61,6 +61,7 @@ struct hugepage_info {
*/
struct internal_config {
volatile size_t memory; /**< amount of asked memory */
+ volatile unsigned single_file; /**< mmap all hugepages in single file */
volatile unsigned force_nchannel; /**< force number of channels */
volatile unsigned force_nrank; /**< force number of ranks */
volatile unsigned no_hugetlbfs; /**< true to disable hugetlbfs */
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index a881c62..e5da14a 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
#define OPT_XEN_DOM0 "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_SINGLE_FILE "single-file"
+ OPT_SINGLE_FILE_NUM,
OPT_LONG_MAX_NUM
};
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 846fd31..2bb1163 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -80,6 +80,10 @@
#include <errno.h>
#include <sys/ioctl.h>
#include <sys/time.h>
+#include <mntent.h>
+#include <sys/mman.h>
+#include <sys/file.h>
+#include <sys/vfs.h>
#include <rte_log.h>
#include <rte_memory.h>
@@ -92,6 +96,9 @@
#include <rte_common.h>
#include <rte_string_fns.h>
+#define _GNU_SOURCE
+#include <sys/syscall.h>
+
#include "eal_private.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
@@ -768,6 +775,7 @@ create_shared_memory(const char *filename, const size_t mem_size)
}
retval = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
close(fd);
+
return retval;
}
@@ -1110,10 +1118,34 @@ rte_eal_hugepage_init(void)
/* get pointer to global configuration */
mcfg = rte_eal_get_configuration()->mem_config;
- /* hugetlbfs can be disabled */
- if (internal_config.no_hugetlbfs) {
+ /* when hugetlbfs is disabled or single-file option is specified */
+ if (internal_config.no_hugetlbfs || internal_config.single_file) {
+ int fd;
+ uint64_t pagesize;
+ unsigned socket_id;
+ char filepath[MAX_HUGEPAGE_PATH];
+
+ syscall(SYS_getcpu, NULL, &socket_id, NULL);
+
+ if (internal_config.no_hugetlbfs) {
+ eal_get_hugefile_path(filepath, sizeof(filepath),
+ "/dev/shm", 0);
+ pagesize = RTE_PGSIZE_4K;
+ } else {
+ struct hugepage_info *hpi = &internal_config.hugepage_info[0];
+ eal_get_hugefile_path(filepath, sizeof(filepath),
+ hpi->hugedir, 0);
+ pagesize = hpi->hugepage_sz;
+ }
+ fd = open(filepath, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
+ if (fd < 0) {
+ RTE_LOG(ERR, EAL, "%s: open %s failed: %s\n", __func__,
+ filepath, strerror(errno));
+ return -1;
+ }
+
addr = mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE,
- MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+ MAP_SHARED | MAP_POPULATE, fd, 0);
if (addr == MAP_FAILED) {
RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__,
strerror(errno));
@@ -1121,9 +1153,12 @@ rte_eal_hugepage_init(void)
}
mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr;
mcfg->memseg[0].addr = addr;
- mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K;
+ mcfg->memseg[0].hugepage_sz = pagesize;
mcfg->memseg[0].len = internal_config.memory;
- mcfg->memseg[0].socket_id = 0;
+ mcfg->memseg[0].socket_id = socket_id;
+
+ close(fd);
+
return 0;
}
--
2.1.4
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-07 10:24 0% ` Ananyev, Konstantin
@ 2016-01-07 13:32 0% ` Adrien Mazarguil
0 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2016-01-07 13:32 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Thu, Jan 07, 2016 at 10:24:19AM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 5:23 PM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > Sent: Wednesday, January 06, 2016 3:45 PM
> > > > To: Ananyev, Konstantin
> > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > >
> > > > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > > > To: Ananyev, Konstantin
> > > > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > > > >
> > > > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > > > [...]
> > > > > > > > -----Original Message-----
> > > > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > > > [...]
> > > > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > > > >
> > > > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > > > any case.
> > > > > > >
> > > > > > > I think we'd better keep mask argument.
> > > > > > > In many cases upper layer only interested in some particular subset of
> > > > > > > all packet types that HW can recognise.
> > > > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > > > tunnelling packet types, etc.
> > > > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > > > In that case all supported packet types will be returned.
> > > > > >
> > > > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > > > possible masks. We can't predict it will be large enough forever but on the
> > > > > > other hand, using uint64_t seems overkill at this point.
> > > > >
> > > > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > > > These 32 bits are divided into several fields to mark packet types,
> > > > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> > > >
> > > > Sure, however why not do it now this issue has been raised so this function
> > > > doesn't need updating the day it breaks? I know there's a million other
> > > > places with a similar problem but I'm all for making new code future proof.
> > >
> > > If rte_mbuf packet_type will have to be increased to 64bit long, then
> > > this function will have to change anyway (with or without mask parameter).
> > > It will have to become:
> > >
> > > rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
> > >
> > > So I think we don't have to worry about mask parameter itself.
> >
> > Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
> > the type width of the mask wouldn't help much.
> >
> > > > Perhaps in this particular case there is no way to hit the limit (although
> > > > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > > > seen this happen too many times with subsequent ABI breakage.
> > >
> > > When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> > > so it wouldn't be overrun immediately.
> > > But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> > > Do you have any particular use-case in mind?
> >
> > No, that was just to illustrate my point.
> >
> > > > > > I think this use for masks should be avoided when performance does not
> > > > > > matter much, as in this case, user application cannot know the number of
> > > > > > entries in advance and must rely on the returned value to iterate.
> > > > >
> > > > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > > > That's why this function was introduced at first place.
> > > > >
> > > > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > > > packet types (only L2 let say).
> > > >
> > > > OK, so we definitely need something to let applications know the layer a
> > > > given packet type belongs to, I'm sure it can be done in a convenient way
> > > > that won't be limited to the underlying type of the mask.
> > > >
> > > > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > > > it belongs to (using enum to define possible values).
> > > > >
> > > > > Not sure what for?
> > > >
> > > > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > > > "mask" argument). In that case a separate function must be added to convert
> > > > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > > > packet types while parsing plist[] on their own.
> > >
> > > Honestly, I don't see why do you need that.
> > > You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> > > Why do you need some extra enum here?
> > > From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> > > So let say user would need to iterate over 10 elements, instead of 100 to find
> > > the ones he is interested in.
> >
> > Since this is already a slow manner for retrieving types, 10 or 100 doesn't
> > make much difference. Such a function shouldn't be used in the data path
> > directly.
>
> Yes, it is not supposed to be called from data-path.
>
> > My point is, since we're dealing with a slow function, let's keep its API as
> > simple as possible.
>
> Well, API should be simple, but from other side it has to be flexible and convenient
> for the user.
> As I user, I would prefer to have an ability to select the layers here - that's
> why I suggested to add the mask parameter.
>
> >By having a mask to match, a large number of checks are
> > added in all PMDs while they could just fill the array without
> > bothering.
>
> That's a valid point.
> We could move filter point into rte_ethdev layer.
> So PMD would always return an array of all supported ptypes, and
> then rte_ethdev layer will filter it based on mask parameter.
> Does it sound reasonable to you?
Yes, I think it's fine that way, thanks.
> >The filtering logic is an application requirement that could be
> > useful in its own function as well (converting any random value to its
> > related layer or mask).
> >
> > > > This layer information could be defined as an enum, i.e.:
> > > >
> > > > enum rte_ptype_info {
> > > > RTE_PTYPE_UNKNOWN,
> > > > RTE_PTYPE_L2,
> > > > RTE_PTYPE_L3,
> > > > ...
> > > > };
> > > >
> > > > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > > > wouldn't be described easily that way though). It's just an idea.
> > > >
> > > > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > > > this enum instead of the mask argument.
> > > > > > Since it won't be a mask, it won't
> > > > > > have to be updated every time a new protocol requires extending one.
> > > > >
> > > > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > > > there are few reserved values right now.
> > > > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> > > >
> > > > I'm aware of this, only pointing out we tend to rely on masks and type
> > > > boundaries a bit too much when there are other methods that are as (if not
> > > > more) convenient.
> > >
> > > Yes, we do rely on masks in ptype.
> > > That's how ptype was defined.
> > > Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> > > you probably would do:
> > >
> > > if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> > > (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
> >
> > All right, let's not use a different method to filter packet types.
> >
> > > > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > > > four remaining bits will be added? That could happen soon.
> > >
> > > As I said above: do you have particular scenario in mind when 32bits for packet_type
> > > might be not enough?
> > > If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> > > or introduce packet_type2, or whatever would be your preferred way to deal with it.
> >
> > No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
> > filtering separately still stands.
> >
> > > Konstantin
> > >
> >
> > --
> > Adrien Mazarguil
> > 6WIND
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 17:22 0% ` Adrien Mazarguil
@ 2016-01-07 10:24 0% ` Ananyev, Konstantin
2016-01-07 13:32 0% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-07 10:24 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, January 06, 2016 5:23 PM
> To: Ananyev, Konstantin
> Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
>
> On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Wednesday, January 06, 2016 3:45 PM
> > > To: Ananyev, Konstantin
> > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > >
> > > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > > To: Ananyev, Konstantin
> > > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > > >
> > > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > > [...]
> > > > > > > -----Original Message-----
> > > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > > [...]
> > > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > > >
> > > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > > any case.
> > > > > >
> > > > > > I think we'd better keep mask argument.
> > > > > > In many cases upper layer only interested in some particular subset of
> > > > > > all packet types that HW can recognise.
> > > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > > tunnelling packet types, etc.
> > > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > > In that case all supported packet types will be returned.
> > > > >
> > > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > > possible masks. We can't predict it will be large enough forever but on the
> > > > > other hand, using uint64_t seems overkill at this point.
> > > >
> > > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > > These 32 bits are divided into several fields to mark packet types,
> > > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> > >
> > > Sure, however why not do it now this issue has been raised so this function
> > > doesn't need updating the day it breaks? I know there's a million other
> > > places with a similar problem but I'm all for making new code future proof.
> >
> > If rte_mbuf packet_type will have to be increased to 64bit long, then
> > this function will have to change anyway (with or without mask parameter).
> > It will have to become:
> >
> > rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
> >
> > So I think we don't have to worry about mask parameter itself.
>
> Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
> the type width of the mask wouldn't help much.
>
> > > Perhaps in this particular case there is no way to hit the limit (although
> > > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > > seen this happen too many times with subsequent ABI breakage.
> >
> > When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> > so it wouldn't be overrun immediately.
> > But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> > Do you have any particular use-case in mind?
>
> No, that was just to illustrate my point.
>
> > > > > I think this use for masks should be avoided when performance does not
> > > > > matter much, as in this case, user application cannot know the number of
> > > > > entries in advance and must rely on the returned value to iterate.
> > > >
> > > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > > That's why this function was introduced at first place.
> > > >
> > > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > > packet types (only L2 let say).
> > >
> > > OK, so we definitely need something to let applications know the layer a
> > > given packet type belongs to, I'm sure it can be done in a convenient way
> > > that won't be limited to the underlying type of the mask.
> > >
> > > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > > it belongs to (using enum to define possible values).
> > > >
> > > > Not sure what for?
> > >
> > > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > > "mask" argument). In that case a separate function must be added to convert
> > > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > > packet types while parsing plist[] on their own.
> >
> > Honestly, I don't see why do you need that.
> > You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> > Why do you need some extra enum here?
> > From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> > So let say user would need to iterate over 10 elements, instead of 100 to find
> > the ones he is interested in.
>
> Since this is already a slow manner for retrieving types, 10 or 100 doesn't
> make much difference. Such a function shouldn't be used in the data path
> directly.
Yes, it is not supposed to be called from data-path.
> My point is, since we're dealing with a slow function, let's keep its API as
> simple as possible.
Well, API should be simple, but from other side it has to be flexible and convenient
for the user.
As I user, I would prefer to have an ability to select the layers here - that's
why I suggested to add the mask parameter.
>By having a mask to match, a large number of checks are
> added in all PMDs while they could just fill the array without
> bothering.
That's a valid point.
We could move filter point into rte_ethdev layer.
So PMD would always return an array of all supported ptypes, and
then rte_ethdev layer will filter it based on mask parameter.
Does it sound reasonable to you?
Konstantin
>The filtering logic is an application requirement that could be
> useful in its own function as well (converting any random value to its
> related layer or mask).
>
> > > This layer information could be defined as an enum, i.e.:
> > >
> > > enum rte_ptype_info {
> > > RTE_PTYPE_UNKNOWN,
> > > RTE_PTYPE_L2,
> > > RTE_PTYPE_L3,
> > > ...
> > > };
> > >
> > > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > > wouldn't be described easily that way though). It's just an idea.
> > >
> > > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > > this enum instead of the mask argument.
> > > > > Since it won't be a mask, it won't
> > > > > have to be updated every time a new protocol requires extending one.
> > > >
> > > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > > there are few reserved values right now.
> > > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> > >
> > > I'm aware of this, only pointing out we tend to rely on masks and type
> > > boundaries a bit too much when there are other methods that are as (if not
> > > more) convenient.
> >
> > Yes, we do rely on masks in ptype.
> > That's how ptype was defined.
> > Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> > you probably would do:
> >
> > if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> > (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
>
> All right, let's not use a different method to filter packet types.
>
> > > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > > four remaining bits will be added? That could happen soon.
> >
> > As I said above: do you have particular scenario in mind when 32bits for packet_type
> > might be not enough?
> > If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> > or introduce packet_type2, or whatever would be your preferred way to deal with it.
>
> No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
> filtering separately still stands.
>
> > Konstantin
> >
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] vhost: fix leak of fds and mmaps
2016-01-07 2:31 3% ` Yuanhan Liu
@ 2016-01-07 6:50 0% ` Xie, Huawei
0 siblings, 0 replies; 200+ results
From: Xie, Huawei @ 2016-01-07 6:50 UTC (permalink / raw)
To: Yuanhan Liu, Rich Lane; +Cc: dev
On 1/7/2016 10:27 AM, Yuanhan Liu wrote:
> On Tue, Jan 05, 2016 at 02:14:09PM -0800, Rich Lane wrote:
>> The common vhost code only supported a single mmap per device. vhost-user
>> worked around this by saving the address/length/fd of each mmap after the end
>> of the rte_virtio_memory struct. This only works if the vhost-user code frees
>> dev->mem, since the common code is unaware of the extra info. The
>> VHOST_USER_RESET_OWNER message is one situation where the common code frees
>> dev->mem and leaks the fds and mappings. This happens every time I shut down a
>> VM.
> That is a good catch! But I don't think it needs the complexity your
> patch has to fix it. Besides that, your patch has ABI change, which
> is not acceptable at this stage.
>
> Back to the issue, the thing is that, mmap/unmap is vhost-user/vhost-cuse
> specific, thus we'd better to handle them inside vhost-user/vhost-cuse
> differently, but not in the common path, virtio-net.c: let the common
> path handle common things only. That would make the logic clear, and
> hence less error prone.
>
> Note that we have already handled the mmap inside vhost-user/vhost-cuse,
> thinking of that way, there is no reason to handle unmap at virtio-net.c:
> it should be a historic issue while we added vhost-cuse first, which will
> not be an issue until we added vhost-user.
Agree. Let vhost-user part handle its specific cleanup and let the
virtio-net.c handle the common logic.
>
> Another note is that you should not name an internal function with "rte_"
> prefix; it should be reserved for public functions.
>
> --yliu
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] vhost: fix leak of fds and mmaps
@ 2016-01-07 2:31 3% ` Yuanhan Liu
2016-01-07 6:50 0% ` Xie, Huawei
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2016-01-07 2:31 UTC (permalink / raw)
To: Rich Lane; +Cc: dev
On Tue, Jan 05, 2016 at 02:14:09PM -0800, Rich Lane wrote:
> The common vhost code only supported a single mmap per device. vhost-user
> worked around this by saving the address/length/fd of each mmap after the end
> of the rte_virtio_memory struct. This only works if the vhost-user code frees
> dev->mem, since the common code is unaware of the extra info. The
> VHOST_USER_RESET_OWNER message is one situation where the common code frees
> dev->mem and leaks the fds and mappings. This happens every time I shut down a
> VM.
That is a good catch! But I don't think it needs the complexity your
patch has to fix it. Besides that, your patch has ABI change, which
is not acceptable at this stage.
Back to the issue, the thing is that, mmap/unmap is vhost-user/vhost-cuse
specific, thus we'd better to handle them inside vhost-user/vhost-cuse
differently, but not in the common path, virtio-net.c: let the common
path handle common things only. That would make the logic clear, and
hence less error prone.
Note that we have already handled the mmap inside vhost-user/vhost-cuse,
thinking of that way, there is no reason to handle unmap at virtio-net.c:
it should be a historic issue while we added vhost-cuse first, which will
not be an issue until we added vhost-user.
Another note is that you should not name an internal function with "rte_"
prefix; it should be reserved for public functions.
--yliu
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 16:44 0% ` Ananyev, Konstantin
@ 2016-01-06 17:22 0% ` Adrien Mazarguil
2016-01-07 10:24 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2016-01-06 17:22 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 3:45 PM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > To: Ananyev, Konstantin
> > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > >
> > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > [...]
> > > > > > -----Original Message-----
> > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > [...]
> > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > >
> > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > any case.
> > > > >
> > > > > I think we'd better keep mask argument.
> > > > > In many cases upper layer only interested in some particular subset of
> > > > > all packet types that HW can recognise.
> > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > tunnelling packet types, etc.
> > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > In that case all supported packet types will be returned.
> > > >
> > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > possible masks. We can't predict it will be large enough forever but on the
> > > > other hand, using uint64_t seems overkill at this point.
> > >
> > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > These 32 bits are divided into several fields to mark packet types,
> > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> >
> > Sure, however why not do it now this issue has been raised so this function
> > doesn't need updating the day it breaks? I know there's a million other
> > places with a similar problem but I'm all for making new code future proof.
>
> If rte_mbuf packet_type will have to be increased to 64bit long, then
> this function will have to change anyway (with or without mask parameter).
> It will have to become:
>
> rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
>
> So I think we don't have to worry about mask parameter itself.
Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
the type width of the mask wouldn't help much.
> > Perhaps in this particular case there is no way to hit the limit (although
> > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > seen this happen too many times with subsequent ABI breakage.
>
> When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> so it wouldn't be overrun immediately.
> But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> Do you have any particular use-case in mind?
No, that was just to illustrate my point.
> > > > I think this use for masks should be avoided when performance does not
> > > > matter much, as in this case, user application cannot know the number of
> > > > entries in advance and must rely on the returned value to iterate.
> > >
> > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > That's why this function was introduced at first place.
> > >
> > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > packet types (only L2 let say).
> >
> > OK, so we definitely need something to let applications know the layer a
> > given packet type belongs to, I'm sure it can be done in a convenient way
> > that won't be limited to the underlying type of the mask.
> >
> > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > it belongs to (using enum to define possible values).
> > >
> > > Not sure what for?
> >
> > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > "mask" argument). In that case a separate function must be added to convert
> > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > packet types while parsing plist[] on their own.
>
> Honestly, I don't see why do you need that.
> You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> Why do you need some extra enum here?
> From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> So let say user would need to iterate over 10 elements, instead of 100 to find
> the ones he is interested in.
Since this is already a slow manner for retrieving types, 10 or 100 doesn't
make much difference. Such a function shouldn't be used in the data path
directly.
My point is, since we're dealing with a slow function, let's keep its API as
simple as possible. By having a mask to match, a large number of checks are
added in all PMDs while they could just fill the array without
bothering. The filtering logic is an application requirement that could be
useful in its own function as well (converting any random value to its
related layer or mask).
> > This layer information could be defined as an enum, i.e.:
> >
> > enum rte_ptype_info {
> > RTE_PTYPE_UNKNOWN,
> > RTE_PTYPE_L2,
> > RTE_PTYPE_L3,
> > ...
> > };
> >
> > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > wouldn't be described easily that way though). It's just an idea.
> >
> > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > this enum instead of the mask argument.
> > > > Since it won't be a mask, it won't
> > > > have to be updated every time a new protocol requires extending one.
> > >
> > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > there are few reserved values right now.
> > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> >
> > I'm aware of this, only pointing out we tend to rely on masks and type
> > boundaries a bit too much when there are other methods that are as (if not
> > more) convenient.
>
> Yes, we do rely on masks in ptype.
> That's how ptype was defined.
> Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> you probably would do:
>
> if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
All right, let's not use a different method to filter packet types.
> > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > four remaining bits will be added? That could happen soon.
>
> As I said above: do you have particular scenario in mind when 32bits for packet_type
> might be not enough?
> If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> or introduce packet_type2, or whatever would be your preferred way to deal with it.
No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
filtering separately still stands.
> Konstantin
>
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 15:44 3% ` Adrien Mazarguil
@ 2016-01-06 16:44 0% ` Ananyev, Konstantin
2016-01-06 17:22 0% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-06 16:44 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, January 06, 2016 3:45 PM
> To: Ananyev, Konstantin
> Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
>
> On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > To: Ananyev, Konstantin
> > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > >
> > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > [...]
> > > > > -----Original Message-----
> > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > [...]
> > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > less. It will help a lot anyone who needs to add a new type.
> > > > >
> > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > entire list every time. Applications need to iterate on the result in
> > > > > any case.
> > > >
> > > > I think we'd better keep mask argument.
> > > > In many cases upper layer only interested in some particular subset of
> > > > all packet types that HW can recognise.
> > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > tunnelling packet types, etc.
> > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > In that case all supported packet types will be returned.
> > >
> > > There are other drawbacks to the mask argument in my opinion. The API will
> > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > possible masks. We can't predict it will be large enough forever but on the
> > > other hand, using uint64_t seems overkill at this point.
> >
> > Inside rte_mbuf packet_type itself is a 32 bit value.
> > These 32 bits are divided into several fields to mark packet types,
> > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
>
> Sure, however why not do it now this issue has been raised so this function
> doesn't need updating the day it breaks? I know there's a million other
> places with a similar problem but I'm all for making new code future proof.
If rte_mbuf packet_type will have to be increased to 64bit long, then
this function will have to change anyway (with or without mask parameter).
It will have to become:
rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
So I think we don't have to worry about mask parameter itself.
>
> Perhaps in this particular case there is no way to hit the limit (although
> there are only four unused bits left to extend RTE_PTYPE masks) but we've
> seen this happen too many times with subsequent ABI breakage.
When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
so it wouldn't be overrun immediately.
But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
Do you have any particular use-case in mind?
>
> > > I think this use for masks should be avoided when performance does not
> > > matter much, as in this case, user application cannot know the number of
> > > entries in advance and must rely on the returned value to iterate.
> >
> > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > That's why this function was introduced at first place.
> >
> > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > packet types (only L2 let say).
>
> OK, so we definitely need something to let applications know the layer a
> given packet type belongs to, I'm sure it can be done in a convenient way
> that won't be limited to the underlying type of the mask.
>
> > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > it belongs to (using enum to define possible values).
> >
> > Not sure what for?
>
> This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> "mask" argument). In that case a separate function must be added to convert
> RTE_PTYPE_* values to a layer, so applications can look for interesting
> packet types while parsing plist[] on their own.
Honestly, I don't see why do you need that.
You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
Why do you need some extra enum here?
From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
So let say user would need to iterate over 10 elements, instead of 100 to find
the ones he is interested in.
>
> This layer information could be defined as an enum, i.e.:
>
> enum rte_ptype_info {
> RTE_PTYPE_UNKNOWN,
> RTE_PTYPE_L2,
> RTE_PTYPE_L3,
> ...
> };
>
> Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> wouldn't be described easily that way though). It's just an idea.
>
> > > If we absolutely want a mean to filter returned values, I suggest we use
> > > this enum instead of the mask argument.
> > > Since it won't be a mask, it won't
> > > have to be updated every time a new protocol requires extending one.
> >
> > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > there are few reserved values right now.
> > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > it would mean change of the packet_type layout and possible ABI breakage anyway.
>
> I'm aware of this, only pointing out we tend to rely on masks and type
> boundaries a bit too much when there are other methods that are as (if not
> more) convenient.
Yes, we do rely on masks in ptype.
That's how ptype was defined.
Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
you probably would do:
if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
(RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
>
> Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> four remaining bits will be added? That could happen soon.
As I said above: do you have particular scenario in mind when 32bits for packet_type
might be not enough?
If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
or introduce packet_type2, or whatever would be your preferred way to deal with it.
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
2016-01-06 14:29 4% ` Ananyev, Konstantin
@ 2016-01-06 15:44 3% ` Adrien Mazarguil
2016-01-06 16:44 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2016-01-06 15:44 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 10:01 AM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > [...]
> > > > -----Original Message-----
> > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > [...]
> > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > because, according to the mask, I expect 16 possibilities but I get
> > > > less. It will help a lot anyone who needs to add a new type.
> > > >
> > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > entire list every time. Applications need to iterate on the result in
> > > > any case.
> > >
> > > I think we'd better keep mask argument.
> > > In many cases upper layer only interested in some particular subset of
> > > all packet types that HW can recognise.
> > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > tunnelling packet types, etc.
> > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > In that case all supported packet types will be returned.
> >
> > There are other drawbacks to the mask argument in my opinion. The API will
> > have to be updated again as soon as 32 bits aren't enough to represent all
> > possible masks. We can't predict it will be large enough forever but on the
> > other hand, using uint64_t seems overkill at this point.
>
> Inside rte_mbuf packet_type itself is a 32 bit value.
> These 32 bits are divided into several fields to mark packet types,
> i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> As long as packet_type itself is 32bits, 32bit mask is sufficient.
> If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
Sure, however why not do it now this issue has been raised so this function
doesn't need updating the day it breaks? I know there's a million other
places with a similar problem but I'm all for making new code future proof.
Perhaps in this particular case there is no way to hit the limit (although
there are only four unused bits left to extend RTE_PTYPE masks) but we've
seen this happen too many times with subsequent ABI breakage.
> > I think this use for masks should be avoided when performance does not
> > matter much, as in this case, user application cannot know the number of
> > entries in advance and must rely on the returned value to iterate.
>
> User doesn't know numbers of entries in advance anyway (with and without the mask).
> That's why this function was introduced at first place.
>
> With mask it just a bit more handy, in case user cares only about particular subset of supported
> packet types (only L2 let say).
OK, so we definitely need something to let applications know the layer a
given packet type belongs to, I'm sure it can be done in a convenient way
that won't be limited to the underlying type of the mask.
> > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > it belongs to (using enum to define possible values).
>
> Not sure what for?
This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
"mask" argument). In that case a separate function must be added to convert
RTE_PTYPE_* values to a layer, so applications can look for interesting
packet types while parsing plist[] on their own.
This layer information could be defined as an enum, i.e.:
enum rte_ptype_info {
RTE_PTYPE_UNKNOWN,
RTE_PTYPE_L2,
RTE_PTYPE_L3,
...
};
Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
wouldn't be described easily that way though). It's just an idea.
> > If we absolutely want a mean to filter returned values, I suggest we use
> > this enum instead of the mask argument.
> > Since it won't be a mask, it won't
> > have to be updated every time a new protocol requires extending one.
>
> Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> there are few reserved values right now.
> if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> it would mean change of the packet_type layout and possible ABI breakage anyway.
I'm aware of this, only pointing out we tend to rely on masks and type
boundaries a bit too much when there are other methods that are as (if not
more) convenient.
Perhaps some sort of tunneled packet types beyond inner L4 consuming the
four remaining bits will be added? That could happen soon.
> Konstantin
>
> >
> > > > rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptypes[],
> > > > size_t max_entries)
> > > >
> > > >
> > > >
> > > > Another point, I have read the example patch (l3fwd) but I don't
> > > > understand why the PMD is not responsible for filling the packet type in
> > > > the MBUF (packet parsing is done by parse_packet_type()). Why the extra
> > > > computation?
> > >
> > > As I understand there are 3 possibilities now:
> > > 1. HW supports ptype recognition and SW ptype parsing is never done
> > > (--parse-ptype is not specified).
> > > 2. HW supports ptype recognition, but and SW ptype parsing is done anyway
> > > (--parse-ptype is specified).
> > > 3. HW doesn't support and ptype recognition, and and SW ptype parsing is done
> > > (--parse-ptype is specified).
> > >
> > > I suppose the question is what for introduce '--parse-ptype' at all?
> > > My thought because of #2, so people can easily check what will be the performance impact of SW parsing.
> > >
> > > Konstantin
> > >
> > > >
> > > > I see it more like an offload request (as checksum, etc...) and if the
> > > > NIC does not support it then the application does the necessary overload.
> > > >
> > > > Best regards,
> > > >
> > > > --
> > > > Nélio Laranjeiro
> > > > 6WIND
> >
> > --
> > Adrien Mazarguil
> > 6WIND
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
@ 2016-01-06 14:32 5% ` Nelio Laranjeiro
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2 siblings, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-06 14:32 UTC (permalink / raw)
To: dev
For RETA query/update with a table of 512 entries, buffers are too small to
handle the request.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_cmdline/cmdline_parse.h | 2 +-
lib/librte_cmdline/cmdline_parse_string.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
4 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e8a3ed6..9930b5a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -39,8 +39,3 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
-
-* ABI changes are planned in cmdline buffer size to allow the use of long
- commands (such as RETA update in testpmd). This should impact
- CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
- It should be integrated in release 2.3.
diff --git a/lib/librte_cmdline/cmdline_parse.h b/lib/librte_cmdline/cmdline_parse.h
index 4b25c45..89b28b1 100644
--- a/lib/librte_cmdline/cmdline_parse.h
+++ b/lib/librte_cmdline/cmdline_parse.h
@@ -81,7 +81,7 @@ extern "C" {
#define CMDLINE_PARSE_COMPLETED_BUFFER 2
/* maximum buffer size for parsed result */
-#define CMDLINE_PARSE_RESULT_BUFSIZE 8192
+#define CMDLINE_PARSE_RESULT_BUFSIZE 65536
/**
* Stores a pointer to the ops struct, and the offset: the place to
diff --git a/lib/librte_cmdline/cmdline_parse_string.h b/lib/librte_cmdline/cmdline_parse_string.h
index c205622..61e0627 100644
--- a/lib/librte_cmdline/cmdline_parse_string.h
+++ b/lib/librte_cmdline/cmdline_parse_string.h
@@ -66,7 +66,7 @@ extern "C" {
#endif
/* size of a parsed string */
-#define STR_TOKEN_SIZE 128
+#define STR_TOKEN_SIZE 8192
typedef char cmdline_fixed_string_t[STR_TOKEN_SIZE];
diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
index b9aad9b..07f8faa 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -93,7 +93,7 @@ extern "C" {
#endif
/* configuration */
-#define RDLINE_BUF_SIZE 256
+#define RDLINE_BUF_SIZE 16384
#define RDLINE_PROMPT_SIZE 32
#define RDLINE_VT100_BUF_SIZE 8
#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
--
2.1.4
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
@ 2016-01-06 14:32 11% ` Nelio Laranjeiro
2016-01-06 14:32 5% ` [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2 siblings, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-06 14:32 UTC (permalink / raw)
To: dev
Several NICs can handle 512 entries/queues in their RETA table, an 8 bit field
is not large enough for them.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 5 -----
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
4 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..9c7cda0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1767,7 +1767,7 @@ parse_reta_config(const char *str,
int i;
unsigned size;
uint16_t hash_index, idx, shift;
- uint8_t nb_queue;
+ uint16_t nb_queue;
char s[256];
const char *p, *p0 = str;
char *end;
@@ -1800,7 +1800,7 @@ parse_reta_config(const char *str,
}
hash_index = (uint16_t)int_fld[FLD_HASH_INDEX];
- nb_queue = (uint8_t)int_fld[FLD_QUEUE];
+ nb_queue = (uint16_t)int_fld[FLD_QUEUE];
if (hash_index >= nb_entries) {
printf("Invalid RETA hash index=%d\n", hash_index);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e94d4a2..e8a3ed6 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -15,11 +15,6 @@ Deprecation Notices
* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
must be updated to support 100G link and to have a cleaner link speed API.
-* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
- which handles at most 256 queues (8 bits) while newer NICs support larger
- tables (512 queues).
- It should be integrated in release 2.3.
-
* ABI changes are planned for struct rte_eth_fdir_flow in order to support
extend flow director's input set. The release 2.2 does not contain these ABI
changes, but release 2.3 will, and no backwards compatibility is planned.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..b0aa94d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1857,7 +1857,7 @@ rte_eth_check_reta_mask(struct rte_eth_rss_reta_entry64 *reta_conf,
static int
rte_eth_check_reta_entry(struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size,
- uint8_t max_rxq)
+ uint16_t max_rxq)
{
uint16_t i, idx, shift;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..8302a2d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -520,7 +520,7 @@ struct rte_eth_mirror_conf {
struct rte_eth_rss_reta_entry64 {
uint64_t mask;
/**< Mask bits indicate which entries need to be updated/queried. */
- uint8_t reta[RTE_RETA_GROUP_SIZE];
+ uint16_t reta[RTE_RETA_GROUP_SIZE];
/**< Group of 64 redirection table entries. */
};
--
2.1.4
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline)
@ 2016-01-06 14:32 4% Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Nelio Laranjeiro @ 2016-01-06 14:32 UTC (permalink / raw)
To: dev
Change ABIs as announced:
* rte_eth_rss_reta_entry64.reta field to handle large number of
queues (above 256).
* Increase cmdline buffers to support long command lines, include long
RETA update commands.
Nelio Laranjeiro (3):
ethdev: change RETA type in rte_eth_rss_reta_entry64
cmdline: increase command line buffer
mlx5: increase RETA table size
app/test-pmd/cmdline.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 10 ----------
drivers/net/mlx5/mlx5_defs.h | 2 +-
lib/librte_cmdline/cmdline_parse.h | 2 +-
lib/librte_cmdline/cmdline_parse_string.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
lib/librte_ether/rte_ethdev.c | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
8 files changed, 8 insertions(+), 18 deletions(-)
--
2.1.4
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
@ 2016-01-06 14:29 4% ` Ananyev, Konstantin
2016-01-06 15:44 3% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2016-01-06 14:29 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, January 06, 2016 10:01 AM
> To: Ananyev, Konstantin
> Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
>
> On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> [...]
> > > -----Original Message-----
> > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> [...]
> > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > because, according to the mask, I expect 16 possibilities but I get
> > > less. It will help a lot anyone who needs to add a new type.
> > >
> > > Extending the snprintf behavior above, it is best to remove the mask
> > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > entire list every time. Applications need to iterate on the result in
> > > any case.
> >
> > I think we'd better keep mask argument.
> > In many cases upper layer only interested in some particular subset of
> > all packet types that HW can recognise.
> > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > tunnelling packet types, etc.
> > If caller needs to know all recognised ptypes, he can set mask==-1,
> > In that case all supported packet types will be returned.
>
> There are other drawbacks to the mask argument in my opinion. The API will
> have to be updated again as soon as 32 bits aren't enough to represent all
> possible masks. We can't predict it will be large enough forever but on the
> other hand, using uint64_t seems overkill at this point.
Inside rte_mbuf packet_type itself is a 32 bit value.
These 32 bits are divided into several fields to mark packet types,
i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
As long as packet_type itself is 32bits, 32bit mask is sufficient.
If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
>
> I think this use for masks should be avoided when performance does not
> matter much, as in this case, user application cannot know the number of
> entries in advance and must rely on the returned value to iterate.
User doesn't know numbers of entries in advance anyway (with and without the mask).
That's why this function was introduced at first place.
With mask it just a bit more handy, in case user cares only about particular subset of supported
packet types (only L2 let say).
>
> A helper function can be added to convert a RTE_PTYPE_* value to the layer
> it belongs to (using enum to define possible values).
Not sure what for?
>
> If we absolutely want a mean to filter returned values, I suggest we use
> this enum instead of the mask argument.
> Since it won't be a mask, it won't
> have to be updated every time a new protocol requires extending one.
Number of bits PTYPE_L2/L3/L4,... layers are already defined.
So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
there are few reserved values right now.
if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
it would mean change of the packet_type layout and possible ABI breakage anyway.
Konstantin
>
> > > rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptypes[],
> > > size_t max_entries)
> > >
> > >
> > >
> > > Another point, I have read the example patch (l3fwd) but I don't
> > > understand why the PMD is not responsible for filling the packet type in
> > > the MBUF (packet parsing is done by parse_packet_type()). Why the extra
> > > computation?
> >
> > As I understand there are 3 possibilities now:
> > 1. HW supports ptype recognition and SW ptype parsing is never done
> > (--parse-ptype is not specified).
> > 2. HW supports ptype recognition, but and SW ptype parsing is done anyway
> > (--parse-ptype is specified).
> > 3. HW doesn't support and ptype recognition, and and SW ptype parsing is done
> > (--parse-ptype is specified).
> >
> > I suppose the question is what for introduce '--parse-ptype' at all?
> > My thought because of #2, so people can easily check what will be the performance impact of SW parsing.
> >
> > Konstantin
> >
> > >
> > > I see it more like an offload request (as checksum, etc...) and if the
> > > NIC does not support it then the application does the necessary overload.
> > >
> > > Best regards,
> > >
> > > --
> > > Nélio Laranjeiro
> > > 6WIND
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] vhost: remove lockless enqueue to the virtio ring
@ 2016-01-05 7:16 4% ` Xie, Huawei
0 siblings, 0 replies; 200+ results
From: Xie, Huawei @ 2016-01-05 7:16 UTC (permalink / raw)
To: dev; +Cc: ann.zhuangyanying
On 1/5/2016 2:42 PM, Xie, Huawei wrote:
> This patch removes the internal lockless enqueue implmentation.
> DPDK doesn't support receiving/transmitting packets from/to the same
> queue. Vhost PMD wraps vhost device as normal DPDK port. DPDK
> applications normally have their own lock implmentation when enqueue
> packets to the same queue of a port.
>
> The atomic cmpset is a costly operation. This patch should help
> performance a bit.
>
> Signed-off-by: Huawei Xie <huawei.xie@intel.com>
This patch modifies the API's behavior, which is also a trivial ABI
change. In my opinion, application shouldn't rely on previous behavior.
Anyway, i am checking how to declare the ABI change.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 00/14] Step towards PCI independency
@ 2016-01-04 20:08 2% Jan Viktorin
[not found] ` <CALwxeUtxE5Gd+UvZOHz+fyHSjLi9Tjkc=99QHpag62KV+UP+NA@mail.gmail.com>
0 siblings, 1 reply; 200+ results
From: Jan Viktorin @ 2016-01-04 20:08 UTC (permalink / raw)
To: dev; +Cc: Jan Viktorin
Hello DPDK community,
A few days ago, I've proposed an RFC of a new infrastructure that allows to
detect non-PCI devices present on SoC systems. It is, however, the easier part
of the story. To bring support of non-PCI devices, it is necessary to do much
deeper changes in DPDK. In this patch series, I am proposing changes that shows
a possible way how to do it.
I extended the rte_pci_{device,driver} with a member .magic. This member holds
a magic number unique to the PCI-infra. Another one (SoC-infra) would get a
different set of magics. This allows to define unions of bus-specific devices
and drivers while not loosing information about the original data type. It can
also add some type-safety into the system. It solves the problem of a missing
'type' member in the eth_driver structure.
Those extensions are then used to generalize the librte_ether library that
seems (to me) to be independent on the PCI now. What is important, the API
stays backwards compatible at the moment. From the point of ABI, I am afraid
that the .magic member breaks it anyway...
The code builds successfully for both x86_64 and ARMv7. I didn't test it in
runtime as the tests are not very suitable for this.
This patch set is independent on the previous one (which was adding the SoC
infra), however, if it is approved I expect them to be joined or to make them
dependent on each other in some way.
Regards
Jan
---
Jan Viktorin (14):
eal/common: introduce RTE_PCI_DRV_MAGIC
eal/common: introduce RTE_PCI_DEVICE_MAGIC
eal/common: introduce union rte_device and related
eal/common: introduce function to_pci_driver
eal/common: introduce function to_pci_device
Include rte_dev.h instead of rte_pci.h
lib/ether: generalize rte_eth_dev_init/uninit
eal/common: introduce rte_bus_addr
lib/ether: generalize attach/detach of devices
lib/ether: copy the rte_device union instead of rte_pci_device
lib/ether: extract function rte_device_get_intr_handle
lib/ether: check magic before naming a zone
lib/ether: check magic in rte_eth_copy_pci_info
lib/ether: introduce rte_eth_copy_dev_info
app/test-pipeline/config.c | 2 +-
app/test-pipeline/init.c | 2 +-
app/test-pipeline/main.c | 2 +-
app/test-pipeline/runtime.c | 2 +-
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/config.c | 2 +-
app/test-pmd/csumonly.c | 2 +-
app/test-pmd/flowgen.c | 2 +-
app/test-pmd/iofwd.c | 2 +-
app/test-pmd/macfwd-retry.c | 2 +-
app/test-pmd/macfwd.c | 2 +-
app/test-pmd/macswap.c | 2 +-
app/test-pmd/parameters.c | 2 +-
app/test-pmd/rxonly.c | 2 +-
app/test-pmd/testpmd.c | 2 +-
app/test-pmd/txonly.c | 2 +-
app/test/test_pci.c | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 2 +
drivers/net/bnx2x/bnx2x_ethdev.h | 2 +-
drivers/net/cxgbe/base/t4_hw.c | 2 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 3 +-
drivers/net/cxgbe/cxgbe_main.c | 2 +-
drivers/net/cxgbe/sge.c | 2 +-
drivers/net/e1000/em_ethdev.c | 3 +-
drivers/net/e1000/em_rxtx.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 4 +-
drivers/net/e1000/igb_rxtx.c | 2 +-
drivers/net/enic/base/vnic_dev.h | 2 +-
drivers/net/enic/enic_ethdev.c | 2 +-
drivers/net/enic/enic_main.c | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 1 +
drivers/net/i40e/i40e_ethdev.c | 3 +-
drivers/net/i40e/i40e_ethdev_vf.c | 3 +-
drivers/net/i40e/i40e_pf.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +-
drivers/net/ixgbe/ixgbe_fdir.c | 2 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 2 +-
drivers/net/mlx4/mlx4.c | 1 +
drivers/net/mlx5/mlx5.c | 3 +-
drivers/net/virtio/virtio_ethdev.c | 3 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 3 +-
drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +-
examples/bond/main.c | 2 +-
examples/dpdk_qat/main.c | 2 +-
examples/exception_path/main.c | 2 +-
examples/ip_fragmentation/main.c | 2 +-
examples/ip_reassembly/main.c | 2 +-
examples/ipv4_multicast/main.c | 2 +-
examples/kni/main.c | 2 +-
examples/l2fwd-crypto/main.c | 2 +-
examples/l2fwd-ivshmem/guest/guest.c | 2 +-
examples/l2fwd-jobstats/main.c | 2 +-
examples/l2fwd-keepalive/main.c | 2 +-
examples/l2fwd/main.c | 2 +-
examples/l3fwd-acl/main.c | 2 +-
examples/l3fwd-power/main.c | 2 +-
examples/l3fwd-vf/main.c | 2 +-
examples/l3fwd/main.c | 2 +-
examples/link_status_interrupt/main.c | 2 +-
examples/load_balancer/config.c | 2 +-
examples/load_balancer/init.c | 2 +-
examples/load_balancer/main.c | 2 +-
examples/load_balancer/runtime.c | 2 +-
.../client_server_mp/mp_client/client.c | 2 +-
.../client_server_mp/mp_server/init.c | 2 +-
.../client_server_mp/mp_server/main.c | 2 +-
examples/multi_process/l2fwd_fork/flib.c | 2 +-
examples/multi_process/l2fwd_fork/main.c | 2 +-
examples/multi_process/symmetric_mp/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 2 +-
examples/vmdq/main.c | 2 +-
examples/vmdq_dcb/main.c | 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 4 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 1 -
lib/librte_eal/bsdapp/eal/eal.c | 1 -
lib/librte_eal/bsdapp/eal/eal_pci.c | 2 +-
lib/librte_eal/common/eal_common_devargs.c | 2 +-
lib/librte_eal/common/eal_common_pci.c | 2 +-
lib/librte_eal/common/eal_private.h | 2 +-
lib/librte_eal/common/include/rte_dev.h | 44 ++++
lib/librte_eal/common/include/rte_devargs.h | 2 +-
lib/librte_eal/common/include/rte_pci.h | 27 +++
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_ivshmem.c | 2 +-
lib/librte_ether/rte_ethdev.c | 224 +++++++++++++++------
lib/librte_ether/rte_ethdev.h | 25 ++-
87 files changed, 351 insertions(+), 144 deletions(-)
--
2.6.3
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
2016-01-02 19:14 0% ` Stephen Hemminger
@ 2016-01-02 19:22 0% ` Wiles, Keith
0 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-02 19:22 UTC (permalink / raw)
To: Stephen Hemminger, Jan Viktorin; +Cc: dev
On 1/2/16, 1:14 PM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>On Sat, 2 Jan 2016 19:52:16 +0100
>Jan Viktorin <viktorin@rehivetech.com> wrote:
>
>> On Sat, 2 Jan 2016 18:35:08 +0000
>> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>
>> > >Yes, DPDK needs to work in embedded environments with device tree.
>> > >Would it be possible reimplement device tree parsing in user space?
>> > >Ideally with a shared code from kernel??
>> >
>> > Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
>>
>> We will need a kernel module. But this is not necessarily related to the
>> device-tree parsing.
>>
>> > >
>> > >On a pratical level, the new SoC support must be optional
>> > >(via DPDK config infrastructure), since most architectures won't be using it.
>> > >In most cases, it is better from usability if everything is runtime based,
>> > >but with SoC this is a platform/architecture configuration.
>> >
>> > I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
>>
>> This is a matter of preserving ABI. Turning PCI-support to be optional
>> seems to be a difficult step at the moment.
>>
>> >
>> > Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>>
>> IMO, we can detect two things: "PCI is present on the system" and
>> "Device tree is accessible in /proc/device-tree". Is this acceptable?
>>
>
>I am just as concerned with building and having useless code.
>For now most environments can just use PCI, and having to carry around
>dead code seems wasteful and potential for some security abuse as well.
Hi Stephen,
With including every archive with the include whole archive option means we already have a huge amount of dead code in a DPDK image :-( Adding a bit more is not going to make a difference IMO. Also a system without PCI could be a security abuse too.
I think we just figure out how not to call the PCI or SoC code at runtime if not supported and compile it in always.
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
2016-01-02 18:52 3% ` Jan Viktorin
2016-01-02 19:13 0% ` Wiles, Keith
@ 2016-01-02 19:14 0% ` Stephen Hemminger
2016-01-02 19:22 0% ` Wiles, Keith
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2016-01-02 19:14 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
On Sat, 2 Jan 2016 19:52:16 +0100
Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Sat, 2 Jan 2016 18:35:08 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>
> > >Yes, DPDK needs to work in embedded environments with device tree.
> > >Would it be possible reimplement device tree parsing in user space?
> > >Ideally with a shared code from kernel??
> >
> > Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
>
> We will need a kernel module. But this is not necessarily related to the
> device-tree parsing.
>
> > >
> > >On a pratical level, the new SoC support must be optional
> > >(via DPDK config infrastructure), since most architectures won't be using it.
> > >In most cases, it is better from usability if everything is runtime based,
> > >but with SoC this is a platform/architecture configuration.
> >
> > I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
>
> This is a matter of preserving ABI. Turning PCI-support to be optional
> seems to be a difficult step at the moment.
>
> >
> > Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>
> IMO, we can detect two things: "PCI is present on the system" and
> "Device tree is accessible in /proc/device-tree". Is this acceptable?
>
I am just as concerned with building and having useless code.
For now most environments can just use PCI, and having to carry around
dead code seems wasteful and potential for some security abuse as well.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
2016-01-02 18:52 3% ` Jan Viktorin
@ 2016-01-02 19:13 0% ` Wiles, Keith
2016-01-02 19:14 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Wiles, Keith @ 2016-01-02 19:13 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
On 1/2/16, 12:52 PM, "Jan Viktorin" <viktorin@rehivetech.com> wrote:
>On Sat, 2 Jan 2016 18:35:08 +0000
>"Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>> >Yes, DPDK needs to work in embedded environments with device tree.
>> >Would it be possible reimplement device tree parsing in user space?
>> >Ideally with a shared code from kernel??
>>
>> Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
>
>We will need a kernel module. But this is not necessarily related to the
>device-tree parsing.
>
>> >
>> >On a pratical level, the new SoC support must be optional
>> >(via DPDK config infrastructure), since most architectures won't be using it.
>> >In most cases, it is better from usability if everything is runtime based,
>> >but with SoC this is a platform/architecture configuration.
>>
>> I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
>
>This is a matter of preserving ABI. Turning PCI-support to be optional
>seems to be a difficult step at the moment.
Turning off PCI support is bit hard to do as well, I was looking for a way to execute the PCI or SoC code during startup. I think having both compiled into the DPDK , but figure out how to detect if that code needs to be run is the better solution as you have pointed out later.
>
>>
>> Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>
>IMO, we can detect two things: "PCI is present on the system" and
>"Device tree is accessible in /proc/device-tree". Is this acceptable?
I guess this would be fine with me, as I do not like us to add ifdefs.
>
>--
> Jan Viktorin E-mail: Viktorin@RehiveTech.com
> System Architect Web: www.RehiveTech.com
> RehiveTech
> Brno, Czech Republic
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
@ 2016-01-02 18:52 3% ` Jan Viktorin
2016-01-02 19:13 0% ` Wiles, Keith
2016-01-02 19:14 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Jan Viktorin @ 2016-01-02 18:52 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dev
On Sat, 2 Jan 2016 18:35:08 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:
> >Yes, DPDK needs to work in embedded environments with device tree.
> >Would it be possible reimplement device tree parsing in user space?
> >Ideally with a shared code from kernel??
>
> Stephen, Do you mean we have to add kernel code to support DPDK on SoC Platforms? If that is the case I would like to not require code be added to the kernel to support DPDK.
We will need a kernel module. But this is not necessarily related to the
device-tree parsing.
> >
> >On a pratical level, the new SoC support must be optional
> >(via DPDK config infrastructure), since most architectures won't be using it.
> >In most cases, it is better from usability if everything is runtime based,
> >but with SoC this is a platform/architecture configuration.
>
> I am not sure I agree with the optional support, as it could be stated that PCI support is optional on SoC platforms. It would be best to not treat SoC support as special compared to PCI support. Other then extra footprint it does not seem reasonable to require SoC support to be ifdef’ed in the code. Plus adding more ifdefs is not a good testing solution.
This is a matter of preserving ABI. Turning PCI-support to be optional
seems to be a difficult step at the moment.
>
> Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
IMO, we can detect two things: "PCI is present on the system" and
"Device tree is accessible in /proc/device-tree". Is this acceptable?
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
@ 2016-01-02 18:45 4% ` Jan Viktorin
1 sibling, 0 replies; 200+ results
From: Jan Viktorin @ 2016-01-02 18:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Sat, 2 Jan 2016 10:01:44 -0800
Stephen Hemminger <stephen@networkplumber.org> wrote:
> On Fri, 1 Jan 2016 22:05:20 +0100
> Jan Viktorin <viktorin@rehivetech.com> wrote:
>
> > Introduce the interface to SoC device infrastructure. A SoC device
> > here means a device integrated on the chip via a (simple) bus
> > that lacks of auto-discovery and other properties which are common
> > for PCI. A counterpart in the Linux Kernel would be a platform_device
> > (but this is not necessarily 1:1 mapping).
> >
> > Systems without auto-discovery properties are described by a (Flat)
> > Device Tree. Device Tree is usually available on embedded systems
> > in /proc/device-tree. Every device has a unique path in the Device
> > Tree and so it identifies every such device. This path is used
> > to identify a device in rte_soc_addr.
> >
> > Binding of drivers to devices in the Linux Kernel is often done
> > by matching the compatible entry in the Device Tree. As there is
> > no standard/generic way to read information like vendor, model, etc.
> > from each SoC device, we match devices by the compatible entry too.
> > The rte_soc_id contains an array of compatible strings telling what
> > each device is compatible with.
> >
> > There are no DPDK-specific OS drivers for SoC devices at the moment
> > and unfortunately we cannot use the PCI-related ones as they contain
> > too much PCI-specific logic.
> >
> > Whitelisting and blacklisting of devices is based on the Device Tree
> > identifier (rte_soc_addr) to mimic the PCI behaviour.
> >
> > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
>
> Yes, DPDK needs to work in embedded environments with device tree.
> Would it be possible reimplement device tree parsing in user space?
This is possible, I've already done a simple library for this few years
ago [1]. However, I don't think it is suitable for DPDK.
> Ideally with a shared code from kernel??
I have no idea what kernel code do you mean to share with... the
drivers/of/*? In userspace, the device-tree is accessible via the
filesystem (/proc/device-tree). So, I cannot see any overlap with
the kernel code.
>
> On a pratical level, the new SoC support must be optional
> (via DPDK config infrastructure), since most architectures won't be using it.
> In most cases, it is better from usability if everything is runtime based,
> but with SoC this is a platform/architecture configuration.
I agree. In this RFC, it is not optional yet. On the EAL level, it's a
matter of the right ifdefs and Makefile conditionals (I think) - it does
not look to be an issue from my point of view.
The problem will arise with the lib/* stuff as eg. librte_ether depends
on pci-specific data structures very deeply. I've just finished a quick
raw librte_ether extension of the SoC devices support trying to preserve
API/ABI. Although, it is hopefully possible to preserve ABI (with SoC
disabled), the code becomes a little bit spagetti-like...
>
> Do you consider this will break binary compatibility since
> sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the
> union inside rte_devargs are much smaller (like 32 bytes).
>
I had a bad feeling about this... Originally, I started with a pointer
'const char *' so it can be done that way... However, this brings
compilator mad as it does not allow to cast char * -> const char *
because of the strict DPDK compilation settings. I didn't find any
workaround yet. I think I can make it just 'char *' for the next version
of the patch set.
[1] https://github.com/jviki/dtree
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
@ 2015-12-31 17:12 3% ` Stephen Hemminger
2016-01-13 11:55 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-31 17:12 UTC (permalink / raw)
To: Ziye Yang; +Cc: dev
On Tue, 29 Dec 2015 10:53:26 +0800
Ziye Yang <ziye.yang@intel.com> wrote:
> This patch is used to add the class_id support
> for pci_probe since some devices need the class_info
> (class_code, subclass_code, programming_interface)
>
> Signed-off-by: Ziye Yang <ziye.yang@intel.com>
Since rte_pci is exposed to application this breaks the ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
2015-12-18 2:00 4% ` Liu, Jijiang
@ 2015-12-24 13:28 4% ` Ivan Boule
0 siblings, 0 replies; 200+ results
From: Ivan Boule @ 2015-12-24 13:28 UTC (permalink / raw)
To: Liu, Jijiang; +Cc: dev
Hi Jijiang,
See my comments inline below prefixewd with IB>
Ivan
On 12/18/2015 03:00 AM, Liu, Jijiang wrote:
> Hi Boule,
>
>> -----Original Message-----
>> From: Ivan Boule [mailto:ivan.boule@6wind.com]
>> Sent: Tuesday, December 15, 2015 4:50 PM
>> To: Liu, Jijiang
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
>> rte_eth_conf
>>
>> On 12/14/2015 08:48 AM, Jijiang Liu wrote:
>>> In current codes, tunnel configuration information is not stored in a device
>> configuration, and it will get nothing if application want to retrieve tunnel
>> config, so I think it is necessary to add rte_eth_dev_tunnel_configure()
>> function is to do the configurations including flow and classification
>> information and store it in a device configuration.
>>>
>>> And tunneling packet encapsulation operation will benifit from the change.
>>>
>>> There are more descriptions for the ABI changes below,
>>>
>>> The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
>>> struct rte_eth_tunnel_conf {
>>> uint16_t tx_queue;
>>> uint16_t filter_type;
>>> struct rte_eth_tunnel_flow flow_tnl; };
>>>
>>> The ABI change announcement of struct 'rte_eth_tunnel_flow' have
>> already sent out, refer to [1].
>>>
>>> [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
>>>
>>> The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
>>> struct rte_eth_conf {
>>> ...
>>> uint32_t dcb_capability_en;
>>> struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
>>> struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
>>> struct rte_eth_tunnel_conf
>> *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
>>> /**< Tunnel configuration. */
>>> };
>>>
>>> v2 change:
>>> Add more description for the change.
>>>
>>> v3 change:
>>> Change ABI announcement description.
>>>
>>> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com> ---cmdline.c
>>> doc/guides/rel_notes/deprecation.rst | 6 ++++++
>>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>> b/doc/guides/rel_notes/deprecation.rst
>>> index 5c458f2..9dbe89e 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -23,3 +23,9 @@ Deprecation Notices
>>> * ABI changes are planned for struct rte_eth_tunnel_flow in order to
>> extend new fileds to support
>>> tunneling packet configuration in unified tunneling APIs. The release 2.2
>> does not contain these ABI
>>> changes, but release 2.3 will, and no backwards compatibility is planned.
>>> +
>>> +* ABI changes are planned for the struct rte_eth_conf in order to add
>>> +'tunnel_conf' variable
>>> + in the struct to store tunnel configuration when using new API
>>> +rte_eth_dev_tunnel_configure
>>> + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf *
>>> +tunnel_conf) to configure
>>> + tunnel flow and classification information. The release 2.2 does
>>> +not contain these ABI change,
>>> + but release 2.3 will, and no backward compatibility is planned.
>>>
>> Hi Jijiang,
>>
>> Can you provide a real use case - I mean an example of a real network
>> application - that really needs to save tunnel configurations in a data
>> structure associated with a NIC port?
>
> I'm trying to provide a tunneling packet solution in DPDK, which would accelerate de/encapsulation operation of tunneling packet.
IB> I was asking for an example of an application that needs to SAVE in
the DPDK structure associated with a port a tunnel configuration that it
applies to that port.
Where does that saved tunnel configuration will participate to the
acceleration of decap/encap ops?
>
> It was described at [1],
> [1] http://dpdk.org/ml/archives/dev/2015-December/030283.html
>
>
> Let me provide more details on this, these data structure definition have not fully finalized yet, just for your reference.
> We are talking about why tunnel configuration need to be stored.
IB? yes :-)
>
> For NIC A RX process,
> VM 0--->VTEP A---> VXLAN network--->VTEP B---NIC A (Rx queue 1 with info [1] )--->SW decapsulation--->vSwitch--->VM 0
>
> For NIC A TX process,
> VM 0<---VTEP A<---VXLAN network<---VTEP B<---NIC A (TX queue 1)<---SW Encapsulation with info[2]<---vSwitch<---VM 0
>
> The[2] information will be got by retrieving the tunnel configuration, if the tunnel configuration is not stored in 'rt_eth_conf', and how to get it?
IB> it is assumed that the encapsulation acceleration relies on having
this operation done in hardware. Am I wrong?
If I am right, then can you tell me which PMD function accesses the
saved tunnel configuration?
>
> Of course, the tunnel configuration is also stored in Application, does it make sense?
IB> No. Why store it twice? Are you considering that memory if available
for free?
>
> [1] outr src ip(192.168.10.1) + outer dst ip(10.239.129.11) + outer src port(1000) + outer dst port(2000) + tunnel id(100)
> [2] outer src ip(10.239.129.11) + outer dst ip(192.168.10.1) + outer src port(2000) + outr dst port(1000) + tunnel id(100)
>
>>
>> Firstly, if the only usage is to enable applications to retrieve tunnel
>> configurations, then you are simply growing the size of the per-port structure
>> with tunnel configurations, and imposing it to every DPDK application.
>> You impose it to those applications that don't care about tunneling, but also
>> to those applications which do care, but which prefer to have their own
>> representation of ports where they store everything they need to.
>> If the tunnel configuration is also used for other purposes, then it must be
>> precisely described what happens with the saved tunnel configuration when
>> the application changes the state of a port.
>> This is the case for instance when the application reconfigures the number of
>> RX queues of a port.
>> Who is responsible for checking that some tunnels won't be matched
>> anymore?
>> Who is responsible for dropping/invalidating the saved tunnel configuration,
>> if such operations must be performed?
>> This list is likely to be not exhaustive, of course.
>
> About above these question, it is related to design, I will send RFC patch out for review.
IB> Do you mean that I will find EXPLICIT answers to those questions in
your RFC patch? If so, why not supply them inline ?
>
>>
>> More globally, all side-effects of saving the tunnel configuration must be
>> considered and addressed in a coherent way and in an easy-to-use approach.
>>
>> By the way, as far as I know, the Linux kernel does not [need to] save tunnel
>> data or ARP entries behind "netdevice" structures.
>
> It is not related ARP entries, I'm talking about tunnel flow.
IB> Really? I did not notice :-)
IB> More seriously, what I meant is that it is a good programming
practice for an application to have its private representation of
low-level objects (a DPDK port here) it uses, and to maintain into it
whatever informations it need to.
I referred to ARP entries as an example of such informations that can be
associated with a port, and thus that might also be saved
in a data structure of the DPDK port. Just to outline that there is no
end to such approach...
>
>> PS : in the "rte_eth_tunnel_conf" data structure, I think that the first field
>> should be named "rx_queue" instead of "tx_queue".
>
> No, 'rx_queue' id can be as index of tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
IB> then, what does the tx_index refer to in in the
"rte_eth_tunnel_conf" data structure, and how is it used, and by which
DPDK code ?
Please, note that by design, the default DPDK rule for the usage of TX
queues consists in having DPDK applications assigning each TX queue of a
port to a different [paquet processing] core, so that each core can
safely transmit paquets through a port in a lockless fashion.
Can you guarantee that your tunneling spec. still comply with this rule?
Regards,
Ivan
--
Ivan Boule
6WIND Development Engineer
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter
@ 2015-12-23 12:41 3% ` Rahul Lakkireddy
2016-01-11 13:50 0% ` Rahul Lakkireddy
1 sibling, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-23 12:41 UTC (permalink / raw)
To: dev; +Cc: Felix Marti, Kumar Sanghvi, Nirranjan Kirubaharan
This RFC series of patches attempt to extend the flow director filter to
add support for Chelsio T5 hardware filtering capabilities.
Chelsio T5 supports carrying out filtering in hardware which supports 3
actions to carry out on a packet which hit a filter viz.
1. Action Pass - Packets hitting a filter rule can be directed to a
particular RXQ.
2. Action Drop - Packets hitting a filter rule are dropped in h/w.
3. Action Switch - Packets hitting a filter rule can be switched in h/w
from one port to another, without involvement of host. Also, the
action Switch also supports rewrite of src-mac/dst-mac headers as
well as rewrite of vlan headers. It also supports rewrite of IP
headers and thereby, supports NAT (Network Address Translation)
in h/w.
Also, each filter rule can optionally support specifying a mask value
i.e. it's possible to create a filter rule for an entire subnet of IP
addresses or a range of tcp/udp ports, etc.
Patch 1 does the following:
- Adds an additional flow rte_eth_pkt_filter_flow which encapsulates
ingress ports, l2 payload, vlan and ntuples.
- Adds an additional mask for the flow to allow range of values to be
matched.
- Adds an ability to set both filters with masks (Maskfull) and
without masks (Maskless). Also allow prioritizing one of these
filter types over the other when a packet matches several types.
- Adds a new behavior 'switch'.
- Adds behavior arguments that can be passed when a particular behavior
is taken. For ex: in case of action 'switch', pass additional 4-tuple
to allow rewriting src/dst ip and port addresses to support NAT'ing.
Patch 2 shows testpmd command line example to support packet filter
flow.
The patch series has been compile tested on all x86 gcc targets and the
current fdir filter supported drivers seem to return appropriate error
codes when this new flow type and the new action are not supported and
hence are not affected.
Posting this series mainly for discussion on API change. Once this is
agreeable then, I will post the cxgbe PMD changes to use the new API.
---
v2:
1. Added ttl to rte_eth_ipv4_flow and tc, flow_label, next_header,
and hop_limit to rte_eth_ipv6_flow.
2. Added new field type to rte_eth_pkt_filter_flow to differentiate
between maskfull and maskless filter types.
3. Added new field prio to rte_eth_pkt_filter_flow to allow setting
priority over maskfull or maskless when packet matches multiple
filter types.
4. Added new behavior sub op RTE_FDIR_BEHAVIOR_SUB_OP_SWAP to allow
swapping fields in matched flows. For ex, useful when swapping mac
addresses in hardware before switching.
5. Updated the testpmd example to reflect the above new changes.
6. Dropped Patch 3 since the ABI announcement has already been merged.
Rahul Lakkireddy (2):
ethdev: add packet filter flow and new behavior switch to fdir
testpmd: add an example to show packet filter flow
app/test-pmd/cmdline.c | 528 +++++++++++++++++++++++++++++++++++++++-
lib/librte_ether/rte_eth_ctrl.h | 127 +++++++++-
2 files changed, 646 insertions(+), 9 deletions(-)
--
2.5.3
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 3/3] doc: rename release 2.3 to 16.04
@ 2015-12-21 13:26 8% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2015-12-21 13:26 UTC (permalink / raw)
To: dev
Update documentation to reflect new numbering scheme
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/index.rst | 2 +-
doc/guides/rel_notes/release_16_04.rst | 83 ++++++++++++++++++++++++++++++++++
doc/guides/rel_notes/release_2_3.rst | 76 -------------------------------
3 files changed, 84 insertions(+), 77 deletions(-)
create mode 100644 doc/guides/rel_notes/release_16_04.rst
delete mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 29013cf..84317b8 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,7 +36,7 @@ Release Notes
:numbered:
rel_description
- release_2_3
+ release_16_04
release_2_2
release_2_1
release_2_0
diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
new file mode 100644
index 0000000..2c487c5
--- /dev/null
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -0,0 +1,83 @@
+DPDK Release 16.04
+==================
+
+.. note::
+
+ Following on from the DPDK Release 2.2, the numbering scheme for this
+ project has changed. Releases are now being numbered based off the year
+ and month of release. What would have been DPDK Release 2.3 is now called
+ Release 16.04, as its release date is April 2016.
+
+New Features
+------------
+
+
+Resolved Issues
+---------------
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
deleted file mode 100644
index 99de186..0000000
--- a/doc/guides/rel_notes/release_2_3.rst
+++ /dev/null
@@ -1,76 +0,0 @@
-DPDK Release 2.3
-================
-
-New Features
-------------
-
-
-Resolved Issues
----------------
-
-EAL
-~~~
-
-
-Drivers
-~~~~~~~
-
-
-Libraries
-~~~~~~~~~
-
-
-Examples
-~~~~~~~~
-
-
-Other
-~~~~~
-
-
-Known Issues
-------------
-
-
-API Changes
------------
-
-
-ABI Changes
------------
-
-
-Shared Library Versions
------------------------
-
-The libraries prepended with a plus sign were incremented in this version.
-
-.. code-block:: diff
-
- libethdev.so.2
- librte_acl.so.2
- librte_cfgfile.so.2
- librte_cmdline.so.1
- librte_distributor.so.1
- librte_eal.so.2
- librte_hash.so.2
- librte_ip_frag.so.1
- librte_ivshmem.so.1
- librte_jobstats.so.1
- librte_kni.so.2
- librte_kvargs.so.1
- librte_lpm.so.2
- librte_mbuf.so.2
- librte_mempool.so.1
- librte_meter.so.1
- librte_pipeline.so.2
- librte_pmd_bond.so.1
- librte_pmd_ring.so.2
- librte_port.so.2
- librte_power.so.1
- librte_reorder.so.1
- librte_ring.so.1
- librte_sched.so.1
- librte_table.so.2
- librte_timer.so.1
- librte_vhost.so.2
--
2.5.0
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf
@ 2015-12-18 2:00 4% ` Liu, Jijiang
2015-12-24 13:28 4% ` Ivan Boule
0 siblings, 1 reply; 200+ results
From: Liu, Jijiang @ 2015-12-18 2:00 UTC (permalink / raw)
To: Ivan Boule; +Cc: dev
Hi Boule,
> -----Original Message-----
> From: Ivan Boule [mailto:ivan.boule@6wind.com]
> Sent: Tuesday, December 15, 2015 4:50 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
> rte_eth_conf
>
> On 12/14/2015 08:48 AM, Jijiang Liu wrote:
> > In current codes, tunnel configuration information is not stored in a device
> configuration, and it will get nothing if application want to retrieve tunnel
> config, so I think it is necessary to add rte_eth_dev_tunnel_configure()
> function is to do the configurations including flow and classification
> information and store it in a device configuration.
> >
> > And tunneling packet encapsulation operation will benifit from the change.
> >
> > There are more descriptions for the ABI changes below,
> >
> > The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
> > struct rte_eth_tunnel_conf {
> > uint16_t tx_queue;
> > uint16_t filter_type;
> > struct rte_eth_tunnel_flow flow_tnl; };
> >
> > The ABI change announcement of struct 'rte_eth_tunnel_flow' have
> already sent out, refer to [1].
> >
> > [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
> >
> > The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> > struct rte_eth_conf {
> > ...
> > uint32_t dcb_capability_en;
> > struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
> > struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> > struct rte_eth_tunnel_conf
> *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> > /**< Tunnel configuration. */
> > };
> >
> > v2 change:
> > Add more description for the change.
> >
> > v3 change:
> > Change ABI announcement description.
> >
> > Signed-off-by: Jijiang Liu <jijiang.liu@intel.com> ---cmdline.c
> > doc/guides/rel_notes/deprecation.rst | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 5c458f2..9dbe89e 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -23,3 +23,9 @@ Deprecation Notices
> > * ABI changes are planned for struct rte_eth_tunnel_flow in order to
> extend new fileds to support
> > tunneling packet configuration in unified tunneling APIs. The release 2.2
> does not contain these ABI
> > changes, but release 2.3 will, and no backwards compatibility is planned.
> > +
> > +* ABI changes are planned for the struct rte_eth_conf in order to add
> > +'tunnel_conf' variable
> > + in the struct to store tunnel configuration when using new API
> > +rte_eth_dev_tunnel_configure
> > + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf *
> > +tunnel_conf) to configure
> > + tunnel flow and classification information. The release 2.2 does
> > +not contain these ABI change,
> > + but release 2.3 will, and no backward compatibility is planned.
> >
> Hi Jijiang,
>
> Can you provide a real use case - I mean an example of a real network
> application - that really needs to save tunnel configurations in a data
> structure associated with a NIC port?
I'm trying to provide a tunneling packet solution in DPDK, which would accelerate de/encapsulation operation of tunneling packet.
It was described at [1],
[1] http://dpdk.org/ml/archives/dev/2015-December/030283.html
Let me provide more details on this, these data structure definition have not fully finalized yet, just for your reference.
We are talking about why tunnel configuration need to be stored.
strucrt rte_eth_tunnel_conf tc;
....
rte_eth_dev_configure(port, ...);
for(...) {rte_eth_rx_queue_setup(port, ...);}
rte_eth_tunnel_config(port, &tc);
Here we need to the configuration when encapsulating tunnel packet.
struct rte_eth_tunnel_conf {
uint16_t rx_queue;
uint16_t tx_queue;
uint16_t filter_type;
struct rte_eth_tunnel_flow flow_tnl;
};
struct rte_eth_tunnel_flow {
enum rte_eth_tunnel_type tunnel_type;
uint64_t tunnel_id; /**< Tunnel ID to match. TNI, VNI... */
uint16_t flags;
struct ether_addr remote_mac;
enum rte_tunnel_iptype ip_type; /**< IP address type. */
union {
struct rte_eth_ipv4_flow outer_ipv4;
struct rte_eth_ipv6_flow outer_ipv6;
} ip_addr;
uint16_t dst_port;
uint16_t src_port;
};
We will do the following configuration,
struct rte_eth_tunnel_conf{
.tunnel_type = VXLAN,
.rx_queue = 1,
.tx_queue = 1,
. filter_type = 'src ip + dst ip + src port + dst port + tunnel id'
.flow_tnl {
. tunnel_type = VXLAN,
. tunnel_id = 100,
. ip_type = ipv4,
. outer_ipv4.src_ip = 192.168.10.1
. outer_ipv4.dst_ip = 10.239.129.11
.src_port = 1000,
.dst_port =2000
};
For NIC A RX process,
VM 0--->VTEP A---> VXLAN network--->VTEP B---NIC A (Rx queue 1 with info [1] )--->SW decapsulation--->vSwitch--->VM 0
For NIC A TX process,
VM 0<---VTEP A<---VXLAN network<---VTEP B<---NIC A (TX queue 1)<---SW Encapsulation with info[2]<---vSwitch<---VM 0
The[2] information will be got by retrieving the tunnel configuration, if the tunnel configuration is not stored in 'rt_eth_conf', and how to get it?
Of course, the tunnel configuration is also stored in Application, does it make sense?
[1] outr src ip(192.168.10.1) + outer dst ip(10.239.129.11) + outer src port(1000) + outer dst port(2000) + tunnel id(100)
[2] outer src ip(10.239.129.11) + outer dst ip(192.168.10.1) + outer src port(2000) + outr dst port(1000) + tunnel id(100)
>
> Firstly, if the only usage is to enable applications to retrieve tunnel
> configurations, then you are simply growing the size of the per-port structure
> with tunnel configurations, and imposing it to every DPDK application.
> You impose it to those applications that don't care about tunneling, but also
> to those applications which do care, but which prefer to have their own
> representation of ports where they store everything they need to.
> If the tunnel configuration is also used for other purposes, then it must be
> precisely described what happens with the saved tunnel configuration when
> the application changes the state of a port.
> This is the case for instance when the application reconfigures the number of
> RX queues of a port.
> Who is responsible for checking that some tunnels won't be matched
> anymore?
> Who is responsible for dropping/invalidating the saved tunnel configuration,
> if such operations must be performed?
> This list is likely to be not exhaustive, of course.
About above these question, it is related to design, I will send RFC patch out for review.
>
> More globally, all side-effects of saving the tunnel configuration must be
> considered and addressed in a coherent way and in an easy-to-use approach.
>
> By the way, as far as I know, the Linux kernel does not [need to] save tunnel
> data or ARP entries behind "netdevice" structures.
It is not related ARP entries, I'm talking about tunnel flow.
> PS : in the "rte_eth_tunnel_conf" data structure, I think that the first field
> should be named "rx_queue" instead of "tx_queue".
No, 'rx_queue' id can be as index of tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
It depends on final design.
> Regards,
> Ivan
>
> --
> Ivan Boule
> 6WIND Development Engineer
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 2/2] doc: init next release notes
@ 2015-12-17 11:16 5% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-17 11:16 UTC (permalink / raw)
To: John McNamara; +Cc: dev
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_2_3.rst | 76 ++++++++++++++++++++++++++++++++++++
2 files changed, 77 insertions(+)
create mode 100644 doc/guides/rel_notes/release_2_3.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index e633e13..29013cf 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,6 +36,7 @@ Release Notes
:numbered:
rel_description
+ release_2_3
release_2_2
release_2_1
release_2_0
diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
new file mode 100644
index 0000000..99de186
--- /dev/null
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -0,0 +1,76 @@
+DPDK Release 2.3
+================
+
+New Features
+------------
+
+
+Resolved Issues
+---------------
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+
+API Changes
+-----------
+
+
+ABI Changes
+-----------
+
+
+Shared Library Versions
+-----------------------
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
--
2.5.2
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration
2015-12-15 15:58 8% ` Zhang, Helin
@ 2015-12-15 16:15 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 16:15 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
> Replace "entries" by "queues", it clarifies the case.
>
> Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration
2015-12-15 14:15 13% [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration Nelio Laranjeiro
@ 2015-12-15 15:58 8% ` Zhang, Helin
2015-12-15 16:15 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Zhang, Helin @ 2015-12-15 15:58 UTC (permalink / raw)
To: Nelio Laranjeiro, dev
-----Original Message-----
From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
Sent: Tuesday, December 15, 2015 10:15 PM
To: dev@dpdk.org
Cc: Zhang, Helin <helin.zhang@intel.com>; thomas.monjalon@6wind.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; adrien.mazarguil@6wind.com
Subject: [PATCH] doc: fix ABI announce change for RETA configuration
Replace "entries" by "queues", it clarifies the case.
Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support
2015-12-15 14:10 12% [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support Rahul Lakkireddy
@ 2015-12-15 14:27 7% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 14:27 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar Sanghvi
2015-12-15 19:40, Rahul Lakkireddy:
> Current filtering support will be enhanced to accommodate support
> for Chelsio T5 hardware filtering support.
>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index f8a41dd..15e766d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -41,3 +41,11 @@ Deprecation Notices
> commands (such as RETA update in testpmd). This should impact
> CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
> It should be integrated in release 2.3.
> +
> +* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
> + include more fields to be matched against. The release 2.2 does not
> + contain these ABI changes, but release 2.3 will.
> +
> +* ABI changes are planned for adding four new flow types. This impacts
> + RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
> + but release 2.3 will.
They were already other ABI changes planned for flow director.
So it doesn't hurt to merge this announce, and we'll with the coming patches
if the new flows can be accepted.
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag
2015-12-15 14:16 4% ` Neil Horman
@ 2015-12-15 14:20 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 14:20 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-12-15 09:16, Neil Horman:
> On Tue, Dec 15, 2015 at 03:55:15PM +0200, Panu Matilainen wrote:
> > Commit 9cbae2aa64eb managed to break the only previously supported
> > case where a tag is used as a revision, due to git show output
> > differing between tags and other objects. The hash is on the last
> > line of the output in both cases though so just grab that.
> >
> > Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation range")
> > Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> > ---
> > scripts/validate-abi.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
> > index 8d7be24..c36ad61 100755
> > --- a/scripts/validate-abi.sh
> > +++ b/scripts/validate-abi.sh
> > @@ -121,8 +121,8 @@ then
> > cleanup_and_exit 1
> > fi
> >
> > -HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
> > -HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
> > +HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
> > +HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
> >
> > # Make sure our tags exist
> > res=$(validate_tags)
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag
2015-12-15 13:55 15% [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag Panu Matilainen
@ 2015-12-15 14:16 4% ` Neil Horman
2015-12-15 14:20 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Neil Horman @ 2015-12-15 14:16 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On Tue, Dec 15, 2015 at 03:55:15PM +0200, Panu Matilainen wrote:
> Commit 9cbae2aa64eb managed to break the only previously supported
> case where a tag is used as a revision, due to git show output
> differing between tags and other objects. The hash is on the last
> line of the output in both cases though so just grab that.
>
> Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation range")
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> ---
> scripts/validate-abi.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
> index 8d7be24..c36ad61 100755
> --- a/scripts/validate-abi.sh
> +++ b/scripts/validate-abi.sh
> @@ -121,8 +121,8 @@ then
> cleanup_and_exit 1
> fi
>
> -HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
> -HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
> +HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
> +HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
>
> # Make sure our tags exist
> res=$(validate_tags)
> --
> 2.5.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration
@ 2015-12-15 14:15 13% Nelio Laranjeiro
2015-12-15 15:58 8% ` Zhang, Helin
0 siblings, 1 reply; 200+ results
From: Nelio Laranjeiro @ 2015-12-15 14:15 UTC (permalink / raw)
To: dev
Replace "entries" by "queues", it clarifies the case.
Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f8a41dd..afab2ed 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -16,8 +16,8 @@ Deprecation Notices
must be updated to support 100G link and to have a cleaner link speed API.
* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
- which handles at most 256 entries (8 bits) while newer NICs support larger
- tables (512 entries).
+ which handles at most 256 queues (8 bits) while newer NICs support larger
+ tables (512 queues).
It should be integrated in release 2.3.
* ABI changes are planned for struct rte_eth_fdir_flow in order to support
--
2.1.4
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support
@ 2015-12-15 14:10 12% Rahul Lakkireddy
2015-12-15 14:27 7% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-15 14:10 UTC (permalink / raw)
To: dev; +Cc: Felix Marti, Kumar Sanghvi, Nirranjan Kirubaharan
Current filtering support will be enhanced to accommodate support
for Chelsio T5 hardware filtering support.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
doc/guides/rel_notes/deprecation.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f8a41dd..15e766d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -41,3 +41,11 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
+ include more fields to be matched against. The release 2.2 does not
+ contain these ABI changes, but release 2.3 will.
+
+* ABI changes are planned for adding four new flow types. This impacts
+ RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
+ but release 2.3 will.
--
2.5.3
^ permalink raw reply [relevance 12%]
* Re: [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
2015-12-15 13:51 9% ` Rahul Lakkireddy
@ 2015-12-15 13:57 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 13:57 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar A S
2015-12-15 19:21, Rahul Lakkireddy:
> Hi Thomas,
>
> On Tuesday, December 12/15/15, 2015 at 00:55:20 -0800, Thomas Monjalon wrote:
> > 2015-12-15 14:10, Rahul Lakkireddy:
> > > Hi Thomas,
> > >
> > > I am preparing a v2 of this series where I will be accomodating some
> > > more fields to be considered for filtering. However, if the overall
> > > approach seems ok to everyone then, should I submit a separate patch
> > > for this ABI change announcement ?
> >
> > Yes, if this announce is not enough:
> > http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
> >
>
> Apart from rte_eth_fdir_flow ABI change mentioned in above link, new
> fields will be added to rte_eth_ipv4_flow and rte_eth_ipv6_flow,
> which break their ABI.
>
> Also, 4 new flow types will be added, which increases RTE_ETH_FLOW_MAX
> from 18 to 22 and breaks the ABI.
>
> Should I send a separate ABI change announce patch for each of them?
Yes please send a patch (1 is enough).
You have less than 30 minutes :)
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag
@ 2015-12-15 13:55 15% Panu Matilainen
2015-12-15 14:16 4% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-15 13:55 UTC (permalink / raw)
To: dev
Commit 9cbae2aa64eb managed to break the only previously supported
case where a tag is used as a revision, due to git show output
differing between tags and other objects. The hash is on the last
line of the output in both cases though so just grab that.
Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation range")
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
scripts/validate-abi.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 8d7be24..c36ad61 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -121,8 +121,8 @@ then
cleanup_and_exit 1
fi
-HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
-HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
+HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
+HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
# Make sure our tags exist
res=$(validate_tags)
--
2.5.0
^ permalink raw reply [relevance 15%]
* Re: [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support
@ 2015-12-15 13:51 9% ` Rahul Lakkireddy
2015-12-15 13:57 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Rahul Lakkireddy @ 2015-12-15 13:51 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar A S
Hi Thomas,
On Tuesday, December 12/15/15, 2015 at 00:55:20 -0800, Thomas Monjalon wrote:
> 2015-12-15 14:10, Rahul Lakkireddy:
> > Hi Thomas,
> >
> > I am preparing a v2 of this series where I will be accomodating some
> > more fields to be considered for filtering. However, if the overall
> > approach seems ok to everyone then, should I submit a separate patch
> > for this ABI change announcement ?
>
> Yes, if this announce is not enough:
> http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
>
Apart from rte_eth_fdir_flow ABI change mentioned in above link, new
fields will be added to rte_eth_ipv4_flow and rte_eth_ipv6_flow,
which break their ABI.
Also, 4 new flow types will be added, which increases RTE_ETH_FLOW_MAX
from 18 to 22 and breaks the ABI.
Should I send a separate ABI change announce patch for each of them?
Thanks,
Rahul
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH] doc: improve linux guide layout
@ 2015-12-15 13:34 2% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2015-12-15 13:34 UTC (permalink / raw)
To: dev
Fixed Linux Getting Started Guide rst layout to improve
rendering in PDF.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/linux_gsg/build_dpdk.rst | 88 +++++++++---------
doc/guides/linux_gsg/build_sample_apps.rst | 141 +++++++++++++++++------------
doc/guides/linux_gsg/enable_func.rst | 95 ++++++++++---------
doc/guides/linux_gsg/intro.rst | 8 +-
doc/guides/linux_gsg/quick_start.rst | 25 ++---
doc/guides/linux_gsg/sys_reqs.rst | 114 ++++++++---------------
6 files changed, 234 insertions(+), 237 deletions(-)
diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst
index c4d1e08..1f4c1f7 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -28,14 +28,13 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-.. _linux_gsg_compiling_dpdk:
-
Compiling the DPDK Target from Source
=====================================
.. note::
- Parts of this process can also be done using the setup script described in Chapter 6 of this document.
+ Parts of this process can also be done using the setup script described in
+ the :ref:`linux_setup_script` section of this document.
Install the DPDK and Browse Sources
-----------------------------------
@@ -44,10 +43,12 @@ First, uncompress the archive and move to the uncompressed DPDK source directory
.. code-block:: console
- user@host:~$ unzip DPDK-<version>.zip
- user@host:~$ cd DPDK-<version>
- user@host:~/DPDK-<version>$ ls
- app/ config/ drivers/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile mk/ scripts/ tools/
+ unzip DPDK-<version>.zip
+ cd DPDK-<version>
+
+ ls
+ app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile
+ mk/ scripts/ tools/
The DPDK is composed of several directories:
@@ -64,19 +65,19 @@ The DPDK is composed of several directories:
Installation of DPDK Target Environments
----------------------------------------
-The format of a DPDK target is:
+The format of a DPDK target is::
ARCH-MACHINE-EXECENV-TOOLCHAIN
where:
-* ARCH can be: i686, x86_64, ppc_64
+* ``ARCH`` can be: ``i686``, ``x86_64``, ``ppc_64``
-* MACHINE can be: native, ivshmem, power8
+* ``MACHINE`` can be: ``native``, ``ivshmem``, ``power8``
-* EXECENV can be: linuxapp, bsdapp
+* ``EXECENV`` can be: ``linuxapp``, ``bsdapp``
-* TOOLCHAIN can be: gcc, icc
+* ``TOOLCHAIN`` can be: ``gcc``, ``icc``
The targets to be installed depend on the 32-bit and/or 64-bit packages and compilers installed on the host.
Available targets can be found in the DPDK/config directory.
@@ -84,13 +85,13 @@ The defconfig\_ prefix should not be used.
.. note::
- Configuration files are provided with the RTE_MACHINE optimization level set.
- Within the configuration files, the RTE_MACHINE configuration value is set to native,
+ Configuration files are provided with the ``RTE_MACHINE`` optimization level set.
+ Within the configuration files, the ``RTE_MACHINE`` configuration value is set to native,
which means that the compiled software is tuned for the platform on which it is built.
For more information on this setting, and its possible values, see the *DPDK Programmers Guide*.
When using the Intel® C++ Compiler (icc), one of the following commands should be invoked for 64-bit or 32-bit use respectively.
-Notice that the shell scripts update the $PATH variable and therefore should not be performed in the same session.
+Notice that the shell scripts update the ``$PATH`` variable and therefore should not be performed in the same session.
Also, verify the compiler's installation directory since the path may be different:
.. code-block:: console
@@ -98,7 +99,7 @@ Also, verify the compiler's installation directory since the path may be differe
source /opt/intel/bin/iccvars.sh intel64
source /opt/intel/bin/iccvars.sh ia32
-To install and make targets, use the make install T=<target> command in the top-level DPDK directory.
+To install and make targets, use the ``make install T=<target>`` command in the top-level DPDK directory.
For example, to compile a 64-bit target using icc, run:
@@ -113,7 +114,7 @@ To compile a 32-bit build using gcc, the make command should be:
make install T=i686-native-linuxapp-gcc
To prepare a target without building it, for example, if the configuration changes need to be made before compilation,
-use the make config T=<target> command:
+use the ``make config T=<target>`` command:
.. code-block:: console
@@ -121,10 +122,10 @@ use the make config T=<target> command:
.. warning::
- Any kernel modules to be used, e.g. igb_uio, kni, must be compiled with the
+ Any kernel modules to be used, e.g. ``igb_uio``, ``kni``, must be compiled with the
same kernel as the one running on the target.
If the DPDK is not being built on the target machine,
- the RTE_KERNELDIR environment variable should be used to point the compilation at a copy of the kernel version to be used on the target machine.
+ the ``RTE_KERNELDIR`` environment variable should be used to point the compilation at a copy of the kernel version to be used on the target machine.
Once the target environment is created, the user may move to the target environment directory and continue to make code changes and re-compile.
The user may also make modifications to the compile-time DPDK configuration by editing the .config file in the build directory.
@@ -147,21 +148,22 @@ A kmod directory is also present that contains kernel modules which may be load
.. code-block:: console
- $ ls x86_64-native-linuxapp-gcc
+ ls x86_64-native-linuxapp-gcc
+
app build hostapp include kmod lib Makefile
Loading Modules to Enable Userspace IO for DPDK
-----------------------------------------------
To run any DPDK application, a suitable uio module can be loaded into the running kernel.
-In many cases, the standard uio_pci_generic module included in the Linux kernel
+In many cases, the standard ``uio_pci_generic`` module included in the Linux kernel
can provide the uio capability. This module can be loaded using the command
.. code-block:: console
sudo modprobe uio_pci_generic
-As an alternative to the uio_pci_generic, the DPDK also includes the igb_uio
+As an alternative to the ``uio_pci_generic``, the DPDK also includes the igb_uio
module which can be found in the kmod subdirectory referred to above. It can
be loaded as shown below:
@@ -173,7 +175,7 @@ be loaded as shown below:
.. note::
For some devices which lack support for legacy interrupts, e.g. virtual function
- (VF) devices, the igb_uio module may be needed in place of uio_pci_generic.
+ (VF) devices, the ``igb_uio`` module may be needed in place of ``uio_pci_generic``.
Since DPDK release 1.7 onward provides VFIO support, use of UIO is optional
for platforms that support using VFIO.
@@ -181,7 +183,7 @@ for platforms that support using VFIO.
Loading VFIO Module
-------------------
-To run an DPDK application and make use of VFIO, the vfio-pci module must be loaded:
+To run an DPDK application and make use of VFIO, the ``vfio-pci`` module must be loaded:
.. code-block:: console
@@ -196,29 +198,31 @@ Also, to use VFIO, both kernel and BIOS must support and be configured to use IO
For proper operation of VFIO when running DPDK applications as a non-privileged user, correct permissions should also be set up.
This can be done by using the DPDK setup script (called setup.sh and located in the tools directory).
+.. _linux_gsg_binding_kernel:
+
Binding and Unbinding Network Ports to/from the Kernel Modules
-----------------------------------------------------------------------
+--------------------------------------------------------------
As of release 1.4, DPDK applications no longer automatically unbind all supported network ports from the kernel driver in use.
Instead, all ports that are to be used by an DPDK application must be bound to the
-uio_pci_generic, igb_uio or vfio-pci module before the application is run.
+``uio_pci_generic``, ``igb_uio`` or ``vfio-pci`` module before the application is run.
Any network ports under Linux* control will be ignored by the DPDK poll-mode drivers and cannot be used by the application.
.. warning::
The DPDK will, by default, no longer automatically unbind network ports from the kernel driver at startup.
Any ports to be used by an DPDK application must be unbound from Linux* control and
- bound to the uio_pci_generic, igb_uio or vfio-pci module before the application is run.
+ bound to the ``uio_pci_generic``, ``igb_uio`` or ``vfio-pci`` module before the application is run.
-To bind ports to the uio_pci_generic, igb_uio or vfio-pci module for DPDK use,
+To bind ports to the ``uio_pci_generic``, ``igb_uio`` or ``vfio-pci`` module for DPDK use,
and then subsequently return ports to Linux* control,
a utility script called dpdk_nic _bind.py is provided in the tools subdirectory.
This utility can be used to provide a view of the current state of the network ports on the system,
and to bind and unbind those ports from the different kernel modules, including the uio and vfio modules.
The following are some examples of how the script can be used.
-A full description of the script and its parameters can be obtained by calling the script with the --help or --usage options.
+A full description of the script and its parameters can be obtained by calling the script with the ``--help`` or ``--usage`` options.
Note that the uio or vfio kernel modules to be used, should be loaded into the kernel before
-running the dpdk_nic_bind.py script.
+running the ``dpdk_nic_bind.py`` script.
.. warning::
@@ -239,38 +243,38 @@ To see the status of all network ports on the system:
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --status
+ ./tools/dpdk_nic_bind.py --status
Network devices using DPDK-compatible driver
============================================
- 0000:82:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=uio_pci_generic unused=ixgbe
- 0000:82:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=uio_pci_generic unused=ixgbe
+ 0000:82:00.0 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
+ 0000:82:00.1 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
Network devices using kernel driver
===================================
- 0000:04:00.0 'I350 Gigabit Network Connection' if=em0 drv=igb unused=uio_pci_generic *Active*
- 0000:04:00.1 'I350 Gigabit Network Connection' if=eth1 drv=igb unused=uio_pci_generic
- 0000:04:00.2 'I350 Gigabit Network Connection' if=eth2 drv=igb unused=uio_pci_generic
- 0000:04:00.3 'I350 Gigabit Network Connection' if=eth3 drv=igb unused=uio_pci_generic
+ 0000:04:00.0 'I350 1-GbE NIC' if=em0 drv=igb unused=uio_pci_generic *Active*
+ 0000:04:00.1 'I350 1-GbE NIC' if=eth1 drv=igb unused=uio_pci_generic
+ 0000:04:00.2 'I350 1-GbE NIC' if=eth2 drv=igb unused=uio_pci_generic
+ 0000:04:00.3 'I350 1-GbE NIC' if=eth3 drv=igb unused=uio_pci_generic
Other network devices
=====================
<none>
-To bind device eth1, 04:00.1, to the uio_pci_generic driver:
+To bind device ``eth1``,``04:00.1``, to the ``uio_pci_generic`` driver:
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 04:00.1
+ ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 04:00.1
or, alternatively,
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --bind=uio_pci_generic eth1
+ ./tools/dpdk_nic_bind.py --bind=uio_pci_generic eth1
-To restore device 82:00.0 to its original kernel binding:
+To restore device ``82:00.0`` to its original kernel binding:
.. code-block:: console
- root@host:DPDK# ./tools/dpdk_nic_bind.py --bind=ixgbe 82:00.0
+ ./tools/dpdk_nic_bind.py --bind=ixgbe 82:00.0
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 07d84df..e53bd51 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -36,59 +36,62 @@ It also provides a pointer to where sample applications are stored.
.. note::
- Parts of this process can also be done using the setup script described in **Chapter 6** of this document.
+ Parts of this process can also be done using the setup script described the
+ :ref:`linux_setup_script` section of this document.
Compiling a Sample Application
------------------------------
-Once an DPDK target environment directory has been created (such as x86_64-native-linuxapp-gcc),
+Once an DPDK target environment directory has been created (such as ``x86_64-native-linuxapp-gcc``),
it contains all libraries and header files required to build an application.
When compiling an application in the Linux* environment on the DPDK, the following variables must be exported:
-* RTE_SDK - Points to the DPDK installation directory.
+* ``RTE_SDK`` - Points to the DPDK installation directory.
-* RTE_TARGET - Points to the DPDK target environment directory.
+* ``RTE_TARGET`` - Points to the DPDK target environment directory.
-The following is an example of creating the helloworld application, which runs in the DPDK Linux environment.
-This example may be found in the ${RTE_SDK}/examples directory.
+The following is an example of creating the ``helloworld`` application, which runs in the DPDK Linux environment.
+This example may be found in the ``${RTE_SDK}/examples`` directory.
-The directory contains the main.c file. This file, when combined with the libraries in the DPDK target environment,
+The directory contains the ``main.c`` file. This file, when combined with the libraries in the DPDK target environment,
calls the various functions to initialize the DPDK environment,
then launches an entry point (dispatch application) for each core to be utilized.
By default, the binary is generated in the build directory.
.. code-block:: console
- user@host:~/DPDK$ cd examples/helloworld/
- user@host:~/DPDK/examples/helloworld$ export RTE_SDK=$HOME/DPDK
- user@host:~/DPDK/examples/helloworld$ export RTE_TARGET=x86_64-native-linuxapp-gcc
- user@host:~/DPDK/examples/helloworld$ make
+ cd examples/helloworld/
+ export RTE_SDK=$HOME/DPDK
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ make
CC main.o
LD helloworld
INSTALL-APP helloworld
INSTALL-MAP helloworld.map
- user@host:~/DPDK/examples/helloworld$ ls build/app
+ ls build/app
helloworld helloworld.map
.. note::
- In the above example, helloworld was in the directory structure of the DPDK.
+ In the above example, ``helloworld`` was in the directory structure of the DPDK.
However, it could have been located outside the directory structure to keep the DPDK structure intact.
- In the following case, the helloworld application is copied to a new directory as a new starting point.
+ In the following case, the ``helloworld`` application is copied to a new directory as a new starting point.
.. code-block:: console
- user@host:~$ export RTE_SDK=/home/user/DPDK
- user@host:~$ cp -r $(RTE_SDK)/examples/helloworld my_rte_app
- user@host:~$ cd my_rte_app/
- user@host:~$ export RTE_TARGET=x86_64-native-linuxapp-gcc
- user@host:~/my_rte_app$ make
- CC main.o
- LD helloworld
- INSTALL-APP helloworld
- INSTALL-MAP helloworld.map
+ export RTE_SDK=/home/user/DPDK
+ cp -r $(RTE_SDK)/examples/helloworld my_rte_app
+ cd my_rte_app/
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ make
+ CC main.o
+ LD helloworld
+ INSTALL-APP helloworld
+ INSTALL-MAP helloworld.map
Running a Sample Application
----------------------------
@@ -100,7 +103,7 @@ Running a Sample Application
.. warning::
Any ports to be used by the application must be already bound to an appropriate kernel
- module, as described in Section 3.5, prior to running the application.
+ module, as described in :ref:`linux_gsg_binding_kernel`, prior to running the application.
The application is linked with the DPDK target environment's Environmental Abstraction Layer (EAL) library,
which provides some options that are generic to every DPDK application.
@@ -109,55 +112,75 @@ The following is the list of options that can be given to the EAL:
.. code-block:: console
- ./rte-app -n NUM [-c COREMASK] [-b <domain:bus:devid.func>] [--socket-mem=MB,...] [-m MB] [-r NUM] [-v] [--file-prefix] [--proc-type <primary|secondary|auto>] [-- xen-dom0]
+ ./rte-app -c COREMASK [-n NUM] [-b <domain:bus:devid.func>] \
+ [--socket-mem=MB,...] [-m MB] [-r NUM] [-v] [--file-prefix] \
+ [--proc-type <primary|secondary|auto>] [-- xen-dom0]
The EAL options are as follows:
-* -c COREMASK: An hexadecimal bit mask of the cores to run on. Note that core numbering can change between platforms and should be determined beforehand.
+* ``-c COREMASK``:
+ An hexadecimal bit mask of the cores to run on. Note that core numbering can
+ change between platforms and should be determined beforehand.
-* -n NUM: Number of memory channels per processor socket
+* ``-n NUM``:
+ Number of memory channels per processor socket.
-* -b <domain:bus:devid.func>: blacklisting of ports; prevent EAL from using specified PCI device (multiple -b options are allowed)
+* ``-b <domain:bus:devid.func>``:
+ Blacklisting of ports; prevent EAL from using specified PCI device
+ (multiple ``-b`` options are allowed).
-* --use-device: use the specified Ethernet device(s) only. Use comma-separate <[domain:]bus:devid.func> values. Cannot be used with -b option
+* ``--use-device``:
+ use the specified Ethernet device(s) only. Use comma-separate
+ ``[domain:]bus:devid.func`` values. Cannot be used with ``-b`` option.
-* --socket-mem: Memory to allocate from hugepages on specific sockets
+* ``--socket-mem``:
+ Memory to allocate from hugepages on specific sockets.
-* -m MB: Memory to allocate from hugepages, regardless of processor socket. It is recommended that --socket-mem be used instead of this option.
+* ``-m MB``:
+ Memory to allocate from hugepages, regardless of processor socket. It is
+ recommended that ``--socket-mem`` be used instead of this option.
-* -r NUM: Number of memory ranks
+* ``-r NUM``:
+ Number of memory ranks.
-* -v: Display version information on startup
+* ``-v``:
+ Display version information on startup.
-* --huge-dir: The directory where hugetlbfs is mounted
+* ``--huge-dir``:
+ The directory where hugetlbfs is mounted.
-* --file-prefix: The prefix text used for hugepage filenames
+* ``--file-prefix``:
+ The prefix text used for hugepage filenames.
-* --proc-type: The type of process instance
+* ``--proc-type``:
+ The type of process instance.
-* --xen-dom0: Support application running on Xen Domain0 without hugetlbfs
+* ``--xen-dom0``:
+ Support application running on Xen Domain0 without hugetlbfs.
-* --vmware-tsc-map: use VMware TSC map instead of native RDTSC
+* ``--vmware-tsc-map``:
+ Use VMware TSC map instead of native RDTSC.
-* --base-virtaddr: specify base virtual address
+* ``--base-virtaddr``:
+ Specify base virtual address.
-* --vfio-intr: specify interrupt type to be used by VFIO (has no effect if VFIO is not used)
+* ``--vfio-intr``:
+ Specify interrupt type to be used by VFIO (has no effect if VFIO is not used).
-The -c and the -n options are mandatory; the others are optional.
+The ``-c`` and option is mandatory; the others are optional.
Copy the DPDK application binary to your target, then run the application as follows
(assuming the platform has four memory channels per processor socket,
-and that cores 0-3 are present and are to be used for running the application):
-
-.. code-block:: console
+and that cores 0-3 are present and are to be used for running the application)::
- user@target:~$ ./helloworld -c f -n 4
+ ./helloworld -c f -n 4
.. note::
- The --proc-type and --file-prefix EAL options are used for running multiple DPDK processes.
- See the “Multi-process Sample Application” chapter in the *DPDK Sample Applications User Guide* and
- the *DPDK Programmers Guide* for more details.
+ The ``--proc-type`` and ``--file-prefix`` EAL options are used for running
+ multiple DPDK processes. See the "Multi-process Sample Application"
+ chapter in the *DPDK Sample Applications User Guide* and the *DPDK
+ Programmers Guide* for more details.
Logical Core Use by Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -168,16 +191,14 @@ Since these logical core numbers, and their mapping to specific cores on specifi
it is recommended that the core layout for each platform be considered when choosing the coremask to use in each case.
On initialization of the EAL layer by an DPDK application, the logical cores to be used and their socket location are displayed.
-This information can also be determined for all cores on the system by examining the /proc/cpuinfo file, for example, by running cat /proc/cpuinfo.
+This information can also be determined for all cores on the system by examining the ``/proc/cpuinfo`` file, for example, by running cat ``/proc/cpuinfo``.
The physical id attribute listed for each processor indicates the CPU socket to which it belongs.
This can be useful when using other processors to understand the mapping of the logical cores to the sockets.
.. note::
- A more graphical view of the logical core layout may be obtained using the lstopo Linux utility.
- On Fedora* Linux, this may be installed and run using the following command:
-
-.. code-block:: console
+ A more graphical view of the logical core layout may be obtained using the ``lstopo`` Linux utility.
+ On Fedora Linux, this may be installed and run using the following command::
sudo yum install hwloc
./lstopo
@@ -191,25 +212,25 @@ Hugepage Memory Use by Applications
When running an application, it is recommended to use the same amount of memory as that allocated for hugepages.
This is done automatically by the DPDK application at startup,
-if no -m or --socket-mem parameter is passed to it when run.
+if no ``-m`` or ``--socket-mem`` parameter is passed to it when run.
-If more memory is requested by explicitly passing a -m or --socket-mem value, the application fails.
-However, the application itself can also fail if the user requests less memory than the reserved amount of hugepage-memory, particularly if using the -m option.
+If more memory is requested by explicitly passing a ``-m`` or ``--socket-mem`` value, the application fails.
+However, the application itself can also fail if the user requests less memory than the reserved amount of hugepage-memory, particularly if using the ``-m`` option.
The reason is as follows.
Suppose the system has 1024 reserved 2 MB pages in socket 0 and 1024 in socket 1.
If the user requests 128 MB of memory, the 64 pages may not match the constraints:
* The hugepage memory by be given to the application by the kernel in socket 1 only.
In this case, if the application attempts to create an object, such as a ring or memory pool in socket 0, it fails.
- To avoid this issue, it is recommended that the -- socket-mem option be used instead of the -m option.
+ To avoid this issue, it is recommended that the ``--socket-mem`` option be used instead of the ``-m`` option.
* These pages can be located anywhere in physical memory, and, although the DPDK EAL will attempt to allocate memory in contiguous blocks,
it is possible that the pages will not be contiguous. In this case, the application is not able to allocate big memory pools.
The socket-mem option can be used to request specific amounts of memory for specific sockets.
-This is accomplished by supplying the --socket-mem flag followed by amounts of memory requested on each socket,
-for example, supply --socket-mem=0,512 to try and reserve 512 MB for socket 1 only.
-Similarly, on a four socket system, to allocate 1 GB memory on each of sockets 0 and 2 only, the parameter --socket-mem=1024,0,1024 can be used.
+This is accomplished by supplying the ``--socket-mem`` flag followed by amounts of memory requested on each socket,
+for example, supply ``--socket-mem=0,512`` to try and reserve 512 MB for socket 1 only.
+Similarly, on a four socket system, to allocate 1 GB memory on each of sockets 0 and 2 only, the parameter ``--socket-mem=1024,0,1024`` can be used.
No memory will be reserved on any CPU socket that is not explicitly referenced, for example, socket 3 in this case.
If the DPDK cannot allocate enough memory on each socket, the EAL initialization fails.
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index 0105a82..c3fa6d3 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -47,11 +47,9 @@ The BIOS is typically accessed by pressing F2 while the platform is starting up.
The user can then navigate to the HPET option. On the Crystal Forest platform BIOS, the path is:
**Advanced -> PCH-IO Configuration -> High Precision Timer ->** (Change from Disabled to Enabled if necessary).
-On a system that has already booted, the following command can be issued to check if HPET is enabled:
+On a system that has already booted, the following command can be issued to check if HPET is enabled::
-.. code-block:: console
-
- # grep hpet /proc/timer_list
+ grep hpet /proc/timer_list
If no entries are returned, HPET must be enabled in the BIOS (as per the instructions above) and the system rebooted.
@@ -59,75 +57,84 @@ Linux Kernel Support
~~~~~~~~~~~~~~~~~~~~
The DPDK makes use of the platform HPET timer by mapping the timer counter into the process address space, and as such,
-requires that the HPET_MMAP kernel configuration option be enabled.
+requires that the ``HPET_MMAP`` kernel configuration option be enabled.
.. warning::
- On Fedora*, and other common distributions such as Ubuntu*, the HPET_MMAP kernel option is not enabled by default.
+ On Fedora, and other common distributions such as Ubuntu, the ``HPET_MMAP`` kernel option is not enabled by default.
To recompile the Linux kernel with this option enabled, please consult the distributions documentation for the relevant instructions.
Enabling HPET in the DPDK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, HPET support is disabled in the DPDK build configuration files.
-To use HPET, the CONFIG_RTE_LIBEAL_USE_HPET setting should be changed to “y”, which will enable the HPET settings at compile time.
+To use HPET, the ``CONFIG_RTE_LIBEAL_USE_HPET`` setting should be changed to ``y``, which will enable the HPET settings at compile time.
-For an application to use the rte_get_hpet_cycles() and rte_get_hpet_hz() API calls,
+For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls,
and optionally to make the HPET the default time source for the rte_timer library,
-the new rte_eal_hpet_init() API call should be called at application initialization.
+the new ``rte_eal_hpet_init()`` API call should be called at application initialization.
This API call will ensure that the HPET is accessible, returning an error to the application if it is not,
-for example, if HPET_MMAP is not enabled in the kernel.
+for example, if ``HPET_MMAP`` is not enabled in the kernel.
The application can then determine what action to take, if any, if the HPET is not available at run-time.
.. note::
For applications that require timing APIs, but not the HPET timer specifically,
- it is recommended that the rte_get_timer_cycles() and rte_get_timer_hz() API calls be used instead of the HPET-specific APIs.
- These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to rte_eal_hpet_init(),
+ it is recommended that the ``rte_get_timer_cycles()`` and ``rte_get_timer_hz()`` API calls be used instead of the HPET-specific APIs.
+ These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to ``rte_eal_hpet_init()``,
if any, and on what is available on the system at runtime.
Running DPDK Applications Without Root Privileges
--------------------------------------------------------
Although applications using the DPDK use network ports and other hardware resources directly,
-with a number of small permission adjustments it is possible to run these applications as a user other than “root”.
+with a number of small permission adjustments it is possible to run these applications as a user other than "root".
To do so, the ownership, or permissions, on the following Linux file system objects should be adjusted to ensure that
the Linux user account being used to run the DPDK application has access to them:
-* All directories which serve as hugepage mount points, for example, /mnt/huge
+* All directories which serve as hugepage mount points, for example, ``/mnt/huge``
+
+* The userspace-io device files in ``/dev``, for example, ``/dev/uio0``, ``/dev/uio1``, and so on
-* The userspace-io device files in /dev, for example, /dev/uio0, /dev/uio1, and so on
+* The userspace-io sysfs config and resource files, for example for ``uio0``::
-* The userspace-io sysfs config and resource files, for example for uio0: /sys/class/uio/uio0/device/config /sys/class/uio/uio0/device/resource*
+ /sys/class/uio/uio0/device/config
+ /sys/class/uio/uio0/device/resource*
-* If the HPET is to be used, /dev/hpet
+* If the HPET is to be used, ``/dev/hpet``
.. note::
- On some Linux installations, /dev/hugepages is also a hugepage mount point created by default.
+ On some Linux installations, ``/dev/hugepages`` is also a hugepage mount point created by default.
Power Management and Power Saving Functionality
-----------------------------------------------
Enhanced Intel SpeedStep® Technology must be enabled in the platform BIOS if the power management feature of DPDK is to be used.
-Otherwise, the sys file folder /sys/devices/system/cpu/cpu0/cpufreq will not exist, and the CPU frequency- based power management cannot be used.
+Otherwise, the sys file folder ``/sys/devices/system/cpu/cpu0/cpufreq`` will not exist, and the CPU frequency- based power management cannot be used.
Consult the relevant BIOS documentation to determine how these settings can be accessed.
-For example, on some Intel reference platform BIOS variants, the path to Enhanced Intel SpeedStep® Technology is:
+For example, on some Intel reference platform BIOS variants, the path to Enhanced Intel SpeedStep® Technology is::
-**Advanced->Processor Configuration->Enhanced Intel SpeedStep® Tech**
+ Advanced
+ -> Processor Configuration
+ -> Enhanced Intel SpeedStep® Tech
-In addition, C3 and C6 should be enabled as well for power management. The path of C3 and C6 on the same platform BIOS is:
+In addition, C3 and C6 should be enabled as well for power management. The path of C3 and C6 on the same platform BIOS is::
-**Advanced->Processor Configuration->Processor C3 Advanced->Processor Configuration-> Processor C6**
+ Advanced
+ -> Processor Configuration
+ -> Processor C3 Advanced
+ -> Processor Configuration
+ -> Processor C6
-Using Linux* Core Isolation to Reduce Context Switches
-------------------------------------------------------
+Using Linux Core Isolation to Reduce Context Switches
+-----------------------------------------------------
While the threads used by an DPDK application are pinned to logical cores on the system,
it is possible for the Linux scheduler to run other tasks on those cores also.
To help prevent additional workloads from running on those cores,
-it is possible to use the isolcpus Linux* kernel parameter to isolate them from the general Linux scheduler.
+it is possible to use the ``isolcpus`` Linux kernel parameter to isolate them from the general Linux scheduler.
For example, if DPDK applications are to run on logical cores 2, 4 and 6,
the following should be added to the kernel parameter list:
@@ -137,38 +144,38 @@ the following should be added to the kernel parameter list:
isolcpus=2,4,6
Loading the DPDK KNI Kernel Module
------------------------------------------
+----------------------------------
To run the DPDK Kernel NIC Interface (KNI) sample application, an extra kernel module (the kni module) must be loaded into the running kernel.
The module is found in the kmod sub-directory of the DPDK target directory.
-Similar to the loading of the igb_uio module, this module should be loaded using the insmod command as shown below
+Similar to the loading of the ``igb_uio`` module, this module should be loaded using the insmod command as shown below
(assuming that the current directory is the DPDK target directory):
.. code-block:: console
- #insmod kmod/rte_kni.ko
+ insmod kmod/rte_kni.ko
.. note::
- See the “Kernel NIC Interface Sample Application” chapter in the *DPDK Sample Applications User Guide* for more details.
+ See the "Kernel NIC Interface Sample Application" chapter in the *DPDK Sample Applications User Guide* for more details.
Using Linux IOMMU Pass-Through to Run DPDK with Intel® VT-d
-----------------------------------------------------------
To enable Intel® VT-d in a Linux kernel, a number of kernel configuration options must be set. These include:
-* IOMMU_SUPPORT
+* ``IOMMU_SUPPORT``
-* IOMMU_API
+* ``IOMMU_API``
-* INTEL_IOMMU
+* ``INTEL_IOMMU``
-In addition, to run the DPDK with Intel® VT-d, the iommu=pt kernel parameter must be used when using igb_uio driver.
+In addition, to run the DPDK with Intel® VT-d, the ``iommu=pt`` kernel parameter must be used when using ``igb_uio`` driver.
This results in pass-through of the DMAR (DMA Remapping) lookup in the host.
-Also, if INTEL_IOMMU_DEFAULT_ON is not set in the kernel, the intel_iommu=on kernel parameter must be used too.
+Also, if ``INTEL_IOMMU_DEFAULT_ON`` is not set in the kernel, the ``intel_iommu=on`` kernel parameter must be used too.
This ensures that the Intel IOMMU is being initialized as expected.
-Please note that while using iommu=pt is compulsory for igb_uio driver, the vfio-pci driver can actually work with both iommu=pt and iommu=on.
+Please note that while using ``iommu=pt`` is compulsory for ``igb_uio driver``, the ``vfio-pci`` driver can actually work with both ``iommu=pt`` and ``iommu=on``.
High Performance of Small Packets on 40G NIC
--------------------------------------------
@@ -182,12 +189,12 @@ DPDK release, so currently the validated firmware version is 4.2.6.
Enabling Extended Tag and Setting Max Read Request Size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-PCI configurations of extended_tag and max _read_requ st_size have big impacts on performance of small packets on 40G NIC.
-Enabling extended_tag and setting max _read_requ st_size to small size such as 128 bytes provide great helps to high performance of small packets.
+PCI configurations of ``extended_tag`` and max _read_requ st_size have big impacts on performance of small packets on 40G NIC.
+Enabling extended_tag and setting ``max_read_request_size`` to small size such as 128 bytes provide great helps to high performance of small packets.
* These can be done in some BIOS implementations.
-* For other BIOS implementations, PCI configurations can be changed by using command of setpci, or special configurations in DPDK config file of common_linux.
+* For other BIOS implementations, PCI configurations can be changed by using command of ``setpci``, or special configurations in DPDK config file of ``common_linux``.
* Bits 7:5 at address of 0xA8 of each PCI device is used for setting the max_read_request_size,
and bit 8 of 0xA8 of each PCI device is used for enabling/disabling the extended_tag.
@@ -195,24 +202,24 @@ Enabling extended_tag and setting max _read_requ st_size to small size such as 1
* In config file of common_linux, below three configurations can be changed for the same purpose.
- CONFIG_RTE_PCI_CONFIG
+ ``CONFIG_RTE_PCI_CONFIG``
- CONFIG_RTE_PCI_EXTENDED_TAG
+ ``CONFIG_RTE_PCI_EXTENDED_TAG``
- CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE
+ ``CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE``
Use 16 Bytes RX Descriptor Size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes size can provide helps to high performance of small packets.
-Configuration of CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC in config files can be changed to use 16 bytes size RX descriptors.
+Configuration of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can be changed to use 16 bytes size RX descriptors.
High Performance and per Packet Latency Tradeoff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Due to the hardware design, the interrupt signal inside NIC is needed for per
packet descriptor write-back. The minimum interval of interrupts could be set
-at compile time by CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL in configuration files.
+at compile time by ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` in configuration files.
Though there is a default configuration, the interval could be tuned by the
users with that configuration item depends on what the user cares about more,
performance or per packet latency.
diff --git a/doc/guides/linux_gsg/intro.rst b/doc/guides/linux_gsg/intro.rst
index a6ee188..eef7e83 100644
--- a/doc/guides/linux_gsg/intro.rst
+++ b/doc/guides/linux_gsg/intro.rst
@@ -33,7 +33,7 @@ Introduction
This document contains instructions for installing and configuring the Intel® Data Plane Development Kit (DPDK) software.
It is designed to get customers up and running quickly.
-The document describes how to compile and run a DPDK application in a Linux* application (linuxapp) environment,
+The document describes how to compile and run a DPDK application in a Linux application (linuxapp) environment,
without going deeply into detail.
Documentation Roadmap
@@ -48,7 +48,7 @@ The following is a list of DPDK documents in the suggested reading order:
* Programmer's Guide: Describes:
- * The software architecture and how to use it (through examples), specifically in a Linux* application (linuxapp) environment
+ * The software architecture and how to use it (through examples), specifically in a Linux application (linuxapp) environment
* The content of the DPDK, the build system (including the commands that can be used in the root DPDK Makefile to build the development kit and
an application) and guidelines for porting an application
@@ -61,7 +61,3 @@ The following is a list of DPDK documents in the suggested reading order:
* Sample Applications User Guide: Describes a set of sample applications.
Each chapter describes a sample application that showcases specific functionality and provides instructions on how to compile, run and use the sample application.
-
-.. note::
-
- These documents are available for download as a separate documentation package at the same location as the DPDK code package.
diff --git a/doc/guides/linux_gsg/quick_start.rst b/doc/guides/linux_gsg/quick_start.rst
index b07fc87..1e0f8ff 100644
--- a/doc/guides/linux_gsg/quick_start.rst
+++ b/doc/guides/linux_gsg/quick_start.rst
@@ -28,6 +28,8 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.. _linux_setup_script:
+
Quick Start Setup Script
========================
@@ -51,7 +53,7 @@ The setup.sh script, found in the tools subdirectory, allows the user to perform
* Look at hugepages in the meminfo
-* List hugepages in /mnt/huge
+* List hugepages in ``/mnt/huge``
* Remove built DPDK libraries
@@ -106,7 +108,7 @@ Some options in the script prompt the user for further data before proceeding.
.. code-block:: console
- user@host:~/rte$ source tools/setup.sh
+ source tools/setup.sh
------------------------------------------------------------------------
@@ -202,7 +204,7 @@ Some options in the script prompt the user for further data before proceeding.
Option:
-The following selection demonstrates the creation of the x86_64-native-linuxapp-gcc DPDK library.
+The following selection demonstrates the creation of the ``x86_64-native-linuxapp-gcc`` DPDK library.
.. code-block:: console
@@ -214,7 +216,7 @@ The following selection demonstrates the creation of the x86_64-native-linuxapp-
== Build lib
...
Build complete
- RTE_TARGET exported as x86_64-native -linuxapp-gcc
+ RTE_TARGET exported as x86_64-native-linuxapp-gcc
The following selection demonstrates the starting of the DPDK UIO driver.
@@ -277,15 +279,16 @@ the logical core layout of the platform should be determined when selecting a co
.. code-block:: console
- rte@rte-desktop:~/rte/examples$ cd helloworld/
- rte@rte-desktop:~/rte/examples/helloworld$ make
- CC main.o
- LD helloworld
- INSTALL-APP helloworld
- INSTALL-MAP helloworld.map
+ cd helloworld/
+ make
+ CC main.o
+ LD helloworld
+ INSTALL-APP helloworld
+ INSTALL-MAP helloworld.map
- rte@rte-desktop:~/rte/examples/helloworld$ sudo ./build/app/helloworld -c 0xf -n 3
+ sudo ./build/app/helloworld -c 0xf -n 3
[sudo] password for rte:
+
EAL: coremask set to f
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 0 on socket 1
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index ef01944..a20a407 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -28,7 +28,6 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
System Requirements
===================
@@ -37,7 +36,7 @@ This chapter describes the packages required to compile the DPDK.
.. note::
If the DPDK is being used on an Intel® Communications Chipset 89xx Series platform,
- please consult the *Intel® Communications Chipset 89xx Series Software for Linux* Getting Started Guide*.
+ please consult the *Intel® Communications Chipset 89xx Series Software for Linux Getting Started Guide*.
BIOS Setting Prerequisite on x86
--------------------------------
@@ -45,7 +44,7 @@ BIOS Setting Prerequisite on x86
For the majority of platforms, no special BIOS settings are needed to use basic DPDK functionality.
However, for additional HPET timer and power management functionality,
and high performance of small packets on 40G NIC, BIOS setting changes may be needed.
-Consult :ref:`Chapter 5. Enabling Additional Functionality <Enabling_Additional_Functionality>`
+Consult the section on :ref:`Enabling Additional Functionality <Enabling_Additional_Functionality>`
for more information on the required changes.
Compilation of the DPDK
@@ -55,17 +54,17 @@ Compilation of the DPDK
.. note::
- Testing has been performed using Fedora* 18. The setup commands and installed packages needed on other systems may be different.
+ Testing has been performed using Fedora 18. The setup commands and installed packages needed on other systems may be different.
For details on other Linux distributions and the versions tested, please consult the DPDK Release Notes.
-* GNU make
+* GNU ``make``.
-* coreutils: cmp, sed, grep, arch
+* coreutils: ``cmp``, ``sed``, ``grep``, ``arch``, etc.
-* gcc: versions 4.5.x or later is recommended for i686/x86_64. versions 4.8.x or later is recommended
- for ppc_64 and x86_x32 ABI. On some distributions, some specific compiler flags and linker flags are enabled by
- default and affect performance (- fstack-protector, for example). Please refer to the documentation
- of your distribution and to gcc -dumpspecs.
+* gcc: versions 4.5.x or later is recommended for ``i686/x86_64``. Versions 4.8.x or later is recommended
+ for ``ppc_64`` and ``x86_x32`` ABI. On some distributions, some specific compiler flags and linker flags are enabled by
+ default and affect performance (``-fstack-protector``, for example). Please refer to the documentation
+ of your distribution and to ``gcc -dumpspecs``.
* libc headers (glibc-devel.i686 / libc6-dev-i386; glibc-devel.x86_64 for 64-bit compilation on Intel
architecture; glibc-devel.ppc64 for 64 bit IBM Power architecture;)
@@ -75,9 +74,9 @@ Compilation of the DPDK
* Additional packages required for 32-bit compilation on 64-bit systems are:
- glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel i686/x86_64;
+ * glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel i686/x86_64;
- glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM ppc_64;
+ * glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM ppc_64;
.. note::
@@ -86,21 +85,20 @@ Compilation of the DPDK
.. note::
- Python, version 2.6 or 2.7, to use various helper scripts included in the DPDK package
+ Python, version 2.6 or 2.7, to use various helper scripts included in the DPDK package.
**Optional Tools:**
-* Intel® C++ Compiler (icc). For installation, additional libraries may be required.
+* Intel® C++ Compiler (icc). For installation, additional libraries may be required.
See the icc Installation Guide found in the Documentation directory under the compiler installation.
- This release has been tested using version 12.1.
* IBM® Advance ToolChain for Powerlinux. This is a set of open source development tools and runtime libraries
which allows users to take leading edge advantage of IBM's latest POWER hardware features on Linux. To install
it, see the IBM official installation document.
* libpcap headers and libraries (libpcap-devel) to compile and use the libpcap-based poll-mode driver.
- This driver is disabled by default and can be enabled by setting CONFIG_RTE_LIBRTE_PMD_PCAP=y in the build time config file.
+ This driver is disabled by default and can be enabled by setting ``CONFIG_RTE_LIBRTE_PMD_PCAP=y`` in the build time config file.
Running DPDK Applications
-------------------------
@@ -114,29 +112,17 @@ System Software
* Kernel version >= 2.6.34
- The kernel version in use can be checked using the command:
-
- .. code-block:: console
+ The kernel version in use can be checked using the command::
uname -r
* glibc >= 2.7 (for features related to cpuset)
- The version can be checked using the ldd --version command. A sample output is shown below:
-
- .. code-block:: console
-
- # ldd --version
-
- ldd (GNU libc) 2.14.90
- Copyright (C) 2011 Free Software Foundation, Inc.
- This is free software; see the source for copying conditions. There is NO
- warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- Written by Roland McGrath and Ulrich Drepper.
+ The version can be checked using the ``ldd --version`` command.
* Kernel configuration
- In the Fedora* OS and other common distributions, such as Ubuntu*, or Red Hat Enterprise Linux*,
+ In the Fedora OS and other common distributions, such as Ubuntu, or Red Hat Enterprise Linux,
the vendor supplied kernel configurations can be used to run most DPDK applications.
For other kernel builds, options which should be enabled for DPDK include:
@@ -148,15 +134,15 @@ System Software
* PROC_PAGE_MONITOR support
* HPET and HPET_MMAP configuration options should also be enabled if HPET support is required.
- See :ref:`Section 5.1 High Precision Event Timer (HPET) Functionality <High_Precision_Event_Timer>` for more details.
+ See the section on :ref:`High Precision Event Timer (HPET) Functionality <High_Precision_Event_Timer>` for more details.
.. _linux_gsg_hugepages:
-Use of Hugepages in the Linux* Environment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Use of Hugepages in the Linux Environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hugepage support is required for the large memory pool allocation used for packet buffers
-(the HUGETLBFS option must be enabled in the running kernel as indicated in Section 2.3).
+(the HUGETLBFS option must be enabled in the running kernel as indicated the previous section).
By using hugepage allocations, performance is increased since fewer pages are needed,
and therefore less Translation Lookaside Buffers (TLBs, high speed translation caches),
which reduce the time it takes to translate a virtual page address to a physical page address.
@@ -167,19 +153,15 @@ Reserving Hugepages for DPDK Use
The allocation of hugepages should be done at boot time or as soon as possible after system boot
to prevent memory from being fragmented in physical memory.
-To reserve hugepages at boot time, a parameter is passed to the Linux* kernel on the kernel command line.
-
-For 2 MB pages, just pass the hugepages option to the kernel. For example, to reserve 1024 pages of 2 MB, use:
+To reserve hugepages at boot time, a parameter is passed to the Linux kernel on the kernel command line.
-.. code-block:: console
+For 2 MB pages, just pass the hugepages option to the kernel. For example, to reserve 1024 pages of 2 MB, use::
hugepages=1024
For other hugepage sizes, for example 1G pages, the size must be specified explicitly and
can also be optionally set as the default hugepage size for the system.
-For example, to reserve 4G of hugepage memory in the form of four 1G pages, the following options should be passed to the kernel:
-
-.. code-block:: console
+For example, to reserve 4G of hugepage memory in the form of four 1G pages, the following options should be passed to the kernel::
default_hugepagesz=1G hugepagesz=1G hugepages=4
@@ -197,21 +179,17 @@ In the case of a dual-socket NUMA system,
the number of hugepages reserved at boot time is generally divided equally between the two sockets
(on the assumption that sufficient memory is present on both sockets).
-See the Documentation/kernel-parameters.txt file in your Linux* source tree for further details of these and other kernel options.
+See the Documentation/kernel-parameters.txt file in your Linux source tree for further details of these and other kernel options.
**Alternative:**
For 2 MB pages, there is also the option of allocating hugepages after the system has booted.
-This is done by echoing the number of hugepages required to a nr_hugepages file in the /sys/devices/ directory.
-For a single-node system, the command to use is as follows (assuming that 1024 pages are required):
-
-.. code-block:: console
+This is done by echoing the number of hugepages required to a nr_hugepages file in the ``/sys/devices/`` directory.
+For a single-node system, the command to use is as follows (assuming that 1024 pages are required)::
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
-On a NUMA machine, pages should be allocated explicitly on separate nodes:
-
-.. code-block:: console
+On a NUMA machine, pages should be allocated explicitly on separate nodes::
echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
@@ -223,29 +201,23 @@ On a NUMA machine, pages should be allocated explicitly on separate nodes:
Using Hugepages with the DPDK
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Once the hugepage memory is reserved, to make the memory available for DPDK use, perform the following steps:
-
-.. code-block:: console
+Once the hugepage memory is reserved, to make the memory available for DPDK use, perform the following steps::
mkdir /mnt/huge
mount -t hugetlbfs nodev /mnt/huge
-The mount point can be made permanent across reboots, by adding the following line to the /etc/fstab file:
-
-.. code-block:: console
+The mount point can be made permanent across reboots, by adding the following line to the ``/etc/fstab`` file::
nodev /mnt/huge hugetlbfs defaults 0 0
-For 1GB pages, the page size must be specified as a mount option:
-
-.. code-block:: console
+For 1GB pages, the page size must be specified as a mount option::
nodev /mnt/huge_1GB hugetlbfs pagesize=1GB 0 0
-Xen Domain0 Support in the Linux* Environment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Xen Domain0 Support in the Linux Environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The existing memory management implementation is based on the Linux* kernel hugepage mechanism.
+The existing memory management implementation is based on the Linux kernel hugepage mechanism.
On the Xen hypervisor, hugepage support for DomainU (DomU) Guests means that DPDK applications work as normal for guests.
However, Domain0 (Dom0) does not support hugepages.
@@ -263,11 +235,9 @@ Furthermore, the CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID setting should also be chang
Loading the DPDK rte_dom0_mm Module
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To run any DPDK application on Xen Dom0, the rte_dom0_mm module must be loaded into the running kernel with rsv_memsize option.
+To run any DPDK application on Xen Dom0, the ``rte_dom0_mm`` module must be loaded into the running kernel with rsv_memsize option.
The module is found in the kmod sub-directory of the DPDK target directory.
-This module should be loaded using the insmod command as shown below (assuming that the current directory is the DPDK target directory):
-
-.. code-block:: console
+This module should be loaded using the insmod command as shown below (assuming that the current directory is the DPDK target directory)::
sudo insmod kmod/rte_dom0_mm.ko rsv_memsize=X
@@ -278,19 +248,15 @@ Configuring Memory for DPDK Use
After the rte_dom0_mm.ko kernel module has been loaded, the user must configure the memory size for DPDK usage.
This is done by echoing the memory size to a memsize file in the /sys/devices/ directory.
-Use the following command (assuming that 2048 MB is required):
-
-.. code-block:: console
+Use the following command (assuming that 2048 MB is required)::
echo 2048 > /sys/kernel/mm/dom0-mm/memsize-mB/memsize
-The user can also check how much memory has already been used:
-
-.. code-block:: console
+The user can also check how much memory has already been used::
cat /sys/kernel/mm/dom0-mm/memsize-mB/memsize_rsvd
-Xen Domain0 does not support NUMA configuration, as a result the --socket-mem command line option is invalid for Xen Domain0.
+Xen Domain0 does not support NUMA configuration, as a result the ``--socket-mem`` command line option is invalid for Xen Domain0.
.. note::
@@ -299,4 +265,4 @@ Xen Domain0 does not support NUMA configuration, as a result the --socket-mem co
Running the DPDK Application on Xen Domain0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To run the DPDK application on Xen Domain0, an extra command line option --xen-dom0 is required.
+To run the DPDK application on Xen Domain0, an extra command line option ``--xen-dom0`` is required.
--
2.5.0
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
2015-12-15 11:59 4% ` Matej Vido
@ 2015-12-15 12:52 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-15 12:52 UTC (permalink / raw)
To: dev; +Cc: Matej Vido
> > A rework was prepared by Marc Sune:
> > http://dpdk.org/ml/archives/dev/2015-October/026037.html
> > The goal is to retrieve the supported link speed of a device
> > and to allow 100G devices while having a consistent API.
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> Acked-by: Olga Shern <olgas@mellanox.com>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Acked-by: Jan Viktorin <viktorin@rehivetech.com>
> Acked-by: Matej Vido <matejvido@gmail.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for link speed
@ 2015-12-15 11:59 4% ` Matej Vido
2015-12-15 12:52 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Matej Vido @ 2015-12-15 11:59 UTC (permalink / raw)
To: Thomas Monjalon, dev
Acked-by: Matej Vido <matejvido@gmail.com>
Dňa 15.12.2015 o 08:21 Thomas Monjalon napísal(a):
> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
^ permalink raw reply [relevance 4%]
Results 12401-12600 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2015-08-29 0:16 [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap Marc Sune
2015-10-04 21:12 ` [dpdk-dev] [PATCH v5 0/4] ethdev: add speed capabilities and refactor link API Marc Sune
2015-10-04 21:12 ` [dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API Marc Sune
2016-01-28 17:33 ` Harish Patil
2016-02-02 2:20 ` Stephen Hemminger
2016-02-02 22:30 ` Marc
2016-02-11 15:27 3% ` Nélio Laranjeiro
2016-02-11 23:23 0% ` Marc
2015-10-25 21:59 [dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and refactor link API Marc Sune
2016-01-29 0:42 ` [dpdk-dev] [PATCH v7 " Marc Sune
2016-01-29 0:42 8% ` [dpdk-dev] [PATCH v7 4/5] doc: update with link changes Marc Sune
2016-02-14 22:17 ` [dpdk-dev] [PATCH v8 0/4] ethdev: add speed capabilities and refactor link API Marc Sune
2016-02-14 22:17 8% ` [dpdk-dev] [PATCH v8 4/4] doc: update with link changes Marc Sune
2016-02-18 18:14 0% ` Mcnamara, John
2015-11-05 18:31 [dpdk-dev] [RFC 0/5] virtio support for container Jianfeng Tan
2016-01-10 11:42 ` [dpdk-dev] [PATCH 0/4] " Jianfeng Tan
2016-01-10 11:42 2% ` [dpdk-dev] [PATCH 1/4] mem: add --single-file to create single mem-backed file Jianfeng Tan
2016-01-10 11:43 ` [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info Jianfeng Tan
2016-01-11 20:26 ` Rich Lane
2016-01-12 9:12 ` Tan, Jianfeng
2016-01-12 10:04 3% ` Pavel Fedin
2016-01-12 10:48 0% ` Tan, Jianfeng
2016-01-12 11:00 0% ` Pavel Fedin
2016-01-12 11:07 0% ` Sergio Gonzalez Monroy
2016-01-12 11:37 ` Pavel Fedin
2016-01-12 12:12 ` Sergio Gonzalez Monroy
2016-01-12 13:57 3% ` Pavel Fedin
2016-01-12 14:13 4% ` Sergio Gonzalez Monroy
2016-01-12 11:44 3% ` Sergio Gonzalez Monroy
2016-02-05 11:20 ` [dpdk-dev] [PATCH v2 0/5] virtio support for container Jianfeng Tan
2016-02-05 11:20 2% ` [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file Jianfeng Tan
2015-11-24 14:31 [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script Panu Matilainen
2016-02-23 22:20 4% ` [dpdk-dev] [PATCH v2] mk: replace the combined library " Thomas Monjalon
2015-12-10 14:01 [dpdk-dev] [RFC 0/3] ethdev: Enhancements to flow director filter Rahul Lakkireddy
2015-12-10 14:01 ` [dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support Rahul Lakkireddy
2015-12-15 8:40 ` Rahul Lakkireddy
2015-12-15 8:55 ` Thomas Monjalon
2015-12-15 13:51 9% ` Rahul Lakkireddy
2015-12-15 13:57 4% ` Thomas Monjalon
2015-12-23 12:41 3% ` [dpdk-dev] [RFC v2 0/2] ethdev: Enhancements to flow director filter Rahul Lakkireddy
2016-01-11 13:50 0% ` Rahul Lakkireddy
2015-12-13 23:35 [dpdk-dev] [PATCH 0/2] provide rte_pktmbuf_alloc_bulk API and call it in vhost dequeue Huawei Xie
2016-01-26 17:03 ` [dpdk-dev] [PATCH v6 " Huawei Xie
2016-01-26 17:03 ` [dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API Huawei Xie
2016-01-27 13:56 3% ` Panu Matilainen
2016-02-03 17:23 0% ` Olivier MATZ
2016-02-22 14:49 0% ` Xie, Huawei
2016-02-23 5:35 0% ` Xie, Huawei
2016-02-24 12:11 0% ` Panu Matilainen
2016-02-24 13:23 3% ` Ananyev, Konstantin
2015-12-14 7:48 [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf Jijiang Liu
2015-12-15 8:50 ` Ivan Boule
2015-12-18 2:00 4% ` Liu, Jijiang
2015-12-24 13:28 4% ` Ivan Boule
2015-12-15 7:21 [dpdk-dev] [PATCH] doc: announce ABI change for link speed Thomas Monjalon
2015-12-15 11:59 4% ` Matej Vido
2015-12-15 12:52 4% ` Thomas Monjalon
2015-12-15 13:34 2% [dpdk-dev] [PATCH] doc: improve linux guide layout John McNamara
2015-12-15 13:55 15% [dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag Panu Matilainen
2015-12-15 14:16 4% ` Neil Horman
2015-12-15 14:20 4% ` Thomas Monjalon
2015-12-15 14:10 12% [dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support Rahul Lakkireddy
2015-12-15 14:27 7% ` Thomas Monjalon
2015-12-15 14:15 13% [dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration Nelio Laranjeiro
2015-12-15 15:58 8% ` Zhang, Helin
2015-12-15 16:15 4% ` Thomas Monjalon
2015-12-17 11:16 [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0 Thomas Monjalon
2015-12-17 11:16 5% ` [dpdk-dev] [PATCH 2/2] doc: init next release notes Thomas Monjalon
2015-12-21 2:38 [dpdk-dev] [PATCH 0/3] i40e: enable extended tag Helin Zhang
2016-02-22 6:31 3% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Helin Zhang
2016-02-22 6:31 6% ` [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files Helin Zhang
2015-12-21 2:38 [dpdk-dev] [PATCH 2/3] eal: remove pci config of extended tag Helin Zhang
2016-02-22 3:59 3% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Helin Zhang
2016-02-22 3:59 6% ` [dpdk-dev] [PATCH v2 3/3] igb_uio: deprecate sys files Helin Zhang
2016-02-22 5:52 0% ` [dpdk-dev] [PATCH v2 0/3] enable extended tag for i40e Wu, Jingjing
2015-12-21 13:26 [dpdk-dev] [PATCH 0/3] switch to using YY.MM version numbers Bruce Richardson
2015-12-21 13:26 8% ` [dpdk-dev] [PATCH 3/3] doc: rename release 2.3 to 16.04 Bruce Richardson
2016-02-10 17:02 ` [dpdk-dev] [PATCH v3 1/2] version: switch to year/month version numbers John McNamara
2016-02-10 17:02 9% ` [dpdk-dev] [PATCH v3 2/2] doc: rename release notes 2.3 to 16.04 John McNamara
2015-12-21 13:26 [dpdk-dev] [PATCH 1/3] version: switch to year/month version numbers Bruce Richardson
2016-02-10 14:33 ` [dpdk-dev] [PATCH v2 1/2] " John McNamara
2016-02-10 14:33 9% ` [dpdk-dev] [PATCH v2 2/2] doc: rename release notes 2.3 to 16.04 John McNamara
2015-12-25 8:29 [dpdk-dev] [PATCH 0/4] extend flow director's IP fields in i40e driver Jingjing Wu
2016-01-26 6:26 ` [dpdk-dev] [PATCH 00/12] extend flow director's " Jingjing Wu
2016-01-26 6:26 4% ` [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format Jingjing Wu
2015-12-29 2:53 [dpdk-dev] [PATCH] pci: Add the class_id support in pci probe Ziye Yang
2015-12-31 17:12 3% ` Stephen Hemminger
2016-01-13 11:55 3% ` Bruce Richardson
2016-01-13 12:22 3% ` Panu Matilainen
2016-01-28 21:38 4% ` Thomas Monjalon
2016-01-29 9:21 4% ` Panu Matilainen
2016-01-29 9:34 3% ` Thomas Monjalon
2016-01-29 10:10 3% ` Panu Matilainen
2016-01-29 12:47 0% ` Panu Matilainen
2015-12-31 6:53 [dpdk-dev] [PATCH 00/12] Add API to get packet type info Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set Jianfeng Tan
2016-01-04 11:38 ` Adrien Mazarguil
2016-01-04 14:36 ` Ananyev, Konstantin
2016-01-05 16:14 ` Nélio Laranjeiro
2016-01-05 16:50 ` Ananyev, Konstantin
2016-01-06 10:00 ` Adrien Mazarguil
2016-01-06 14:29 4% ` Ananyev, Konstantin
2016-01-06 15:44 3% ` Adrien Mazarguil
2016-01-06 16:44 0% ` Ananyev, Konstantin
2016-01-06 17:22 0% ` Adrien Mazarguil
2016-01-07 10:24 0% ` Ananyev, Konstantin
2016-01-07 13:32 0% ` Adrien Mazarguil
2016-01-01 21:05 [dpdk-dev] [RFC 0/7] Support non-PCI devices Jan Viktorin
2016-01-01 21:05 ` [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface Jan Viktorin
2016-01-02 18:01 ` Stephen Hemminger
2016-01-02 18:35 ` Wiles, Keith
2016-01-02 18:52 3% ` Jan Viktorin
2016-01-02 19:13 0% ` Wiles, Keith
2016-01-02 19:14 0% ` Stephen Hemminger
2016-01-02 19:22 0% ` Wiles, Keith
2016-01-02 18:45 4% ` Jan Viktorin
2016-01-04 14:46 [dpdk-dev] [PATCH] vhost: remove lockless enqueue to the virtio ring Huawei Xie
2016-01-05 7:16 4% ` Xie, Huawei
2016-01-04 20:08 2% [dpdk-dev] [PATCH 00/14] Step towards PCI independency Jan Viktorin
[not found] ` <CALwxeUtxE5Gd+UvZOHz+fyHSjLi9Tjkc=99QHpag62KV+UP+NA@mail.gmail.com>
2016-01-11 17:29 ` Jan Viktorin
2016-01-13 14:07 3% ` David Marchand
2016-01-05 22:14 [dpdk-dev] [PATCH] vhost: fix leak of fds and mmaps Rich Lane
2016-01-07 2:31 3% ` Yuanhan Liu
2016-01-07 6:50 0% ` Xie, Huawei
2016-01-06 14:32 4% [dpdk-dev] [PATCH 0/3] ABI changes (RETA, cmdline) Nelio Laranjeiro
2016-01-06 14:32 11% ` [dpdk-dev] [PATCH 1/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2016-01-06 14:32 5% ` [dpdk-dev] [PATCH 2/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 10:49 4% ` [dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline Nelio Laranjeiro
2016-01-12 10:49 5% ` [dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer Nelio Laranjeiro
2016-01-12 12:46 3% ` Panu Matilainen
2016-01-15 8:44 3% ` Nélio Laranjeiro
2016-01-15 9:00 3% ` Panu Matilainen
2016-01-18 14:38 4% ` Olivier MATZ
2016-01-12 10:49 11% ` [dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64 Nelio Laranjeiro
2016-01-11 7:07 [dpdk-dev] [PATCH 0/4] Support VxLAN & NVGRE checksum off-load on X550 Wenzhuo Lu
2016-01-11 7:07 ` [dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del Wenzhuo Lu
2016-01-11 7:40 ` Vincent JARDIN
2016-01-11 8:28 3% ` Lu, Wenzhuo
2016-01-11 8:41 3% ` Vincent JARDIN
2016-01-12 12:37 0% ` Thomas Monjalon
2016-01-13 2:50 0% ` Lu, Wenzhuo
2016-01-14 1:38 ` [dpdk-dev] [PATCH v2 0/6] Support VxLAN & NVGRE checksum off-load on X550 Wenzhuo Lu
2016-01-14 1:38 4% ` [dpdk-dev] [PATCH v2 1/6] lib/librte_ether: change function name of tunnel port config Wenzhuo Lu
2016-02-18 3:17 ` [dpdk-dev] [PATCH v3 0/5] Support VxLAN & NVGRE checksum off-load on X550 Wenzhuo Lu
2016-02-18 3:17 4% ` [dpdk-dev] [PATCH v3 1/5] lib/librte_ether: change function name of tunnel port config Wenzhuo Lu
2016-01-14 10:38 2% [dpdk-dev] Proposal for a big eal / ethdev cleanup David Marchand
2016-01-14 11:46 4% ` Jan Viktorin
2016-01-16 15:53 0% ` David Marchand
2016-01-18 15:49 3% ` Thomas Monjalon
2016-01-18 14:54 0% ` Declan Doherty
[not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2016-01-18 21:11 ` David Marchand
2016-01-19 10:29 ` Jan Viktorin
2016-01-19 10:59 4% ` David Marchand
2016-01-15 2:40 [dpdk-dev] [PATCH 00/29] i40e base driver update Helin Zhang
2016-02-18 6:29 ` [dpdk-dev] [PATCH v2 00/30] " Helin Zhang
2016-02-18 6:30 4% ` [dpdk-dev] [PATCH v2 28/30] i40e: add/remove new device IDs Helin Zhang
2016-01-15 14:43 [dpdk-dev] [PATCH 0/2] add support for buffered tx to ethdev Tomasz Kulasek
2016-01-15 14:43 ` [dpdk-dev] [PATCH 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-01-15 18:44 ` Ananyev, Konstantin
2016-02-02 10:00 ` Kulasek, TomaszX
2016-02-02 13:49 ` Ananyev, Konstantin
2016-02-09 17:02 ` Kulasek, TomaszX
2016-02-09 23:56 ` Ananyev, Konstantin
2016-02-12 11:44 3% ` Ananyev, Konstantin
2016-02-12 16:40 0% ` Ivan Boule
2016-02-12 17:33 0% ` Bruce Richardson
2016-02-24 17:08 4% ` [dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev Tomasz Kulasek
2016-02-24 17:08 2% ` [dpdk-dev] [PATCH v2 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-01-17 3:58 [dpdk-dev] [PATCH] cfgfile: support looking up sections by index Rich Lane
2016-01-19 4:41 ` [dpdk-dev] [PATCH v2] " Rich Lane
2016-01-21 7:42 3% ` Panu Matilainen
2016-01-20 11:25 [dpdk-dev] [PATCH v2] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR) Ananyev, Konstantin
2016-01-21 8:18 ` [dpdk-dev] [PATCH v3] " Wojciech Andralojc
2016-01-21 10:38 ` Panu Matilainen
2016-01-21 10:51 ` Ananyev, Konstantin
2016-01-22 10:05 3% ` Panu Matilainen
2016-01-22 11:05 0% ` Ananyev, Konstantin
2016-01-22 11:37 0% ` Andralojc, WojciechX
2016-01-20 14:28 [dpdk-dev] [PATCH] ethdev: expose link status and speed using xstats Harry van Haaren
2016-01-20 14:45 ` Van Haaren, Harry
2016-01-20 15:03 ` Kyle Larose
2016-01-20 15:13 ` Thomas Monjalon
2016-01-20 18:36 3% ` Stephen Hemminger
2016-01-20 17:18 [dpdk-dev] Future Direction for rte_eth_stats_get() David Harton (dharton)
2016-01-22 14:18 ` Tahhan, Maryam
2016-01-22 14:40 ` David Harton (dharton)
2016-01-22 14:48 ` Thomas Monjalon
2016-01-22 15:22 3% ` Van Haaren, Harry
2016-01-22 15:53 0% ` Jay Rolette
2016-01-22 16:04 0% ` David Harton (dharton)
2016-01-22 16:41 ` Van Haaren, Harry
2016-01-22 19:26 ` David Harton (dharton)
2016-02-01 16:47 3% ` David Harton (dharton)
2016-02-01 21:23 0% ` Matthew Hall
2016-02-02 11:40 3% ` Van Haaren, Harry
2016-01-22 1:37 [dpdk-dev] [PATCH 0/2] i40e setting ether type of VLANs Helin Zhang
2016-01-22 1:37 7% ` [dpdk-dev] [PATCH 1/2] ethdev: add vlan type for setting ether type Helin Zhang
2016-01-25 2:36 9% [dpdk-dev] [PATCH] PCI: ABI change request for adding new field in rte_pci_id structure Ziye Yang
2016-02-16 4:15 15% ` [dpdk-dev] [PATCH v2] " Ziye Yang
2016-02-16 10:11 7% ` Bruce Richardson
2016-02-16 10:34 7% ` Thomas Monjalon
2016-02-17 1:54 11% ` [dpdk-dev] [PATCH v3] " Ziye Yang
2016-02-17 10:14 4% ` Bruce Richardson
2016-02-18 1:57 4% ` Zhang, Helin
2016-02-18 2:46 4% ` Liang, Cunming
2016-01-25 7:25 [dpdk-dev] [PATCH 0/4] Add tunnel filter support for IP in GRE on i40e Xutao Sun
2016-01-28 7:30 ` [dpdk-dev] [PATCH v2 " Xutao Sun
2016-01-28 7:30 ` [dpdk-dev] [PATCH v2 1/4] lib/ether: optimize the 'rte_eth_tunnel_filter_conf' structure Xutao Sun
2016-01-28 8:21 ` Thomas Monjalon
2016-01-28 9:05 3% ` Sun, Xutao
[not found] ` <1453976778-27807-1-git-send-email-xutao.sun@intel.com>
2016-01-28 10:26 13% ` [dpdk-dev] [PATCH v3 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure Xutao Sun
2016-02-18 9:58 ` [dpdk-dev] [PATCH v4 0/4] Add tunnel filter support for IP in GRE on i40e Xutao Sun
2016-02-18 9:58 17% ` [dpdk-dev] [PATCH v4 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure Xutao Sun
2016-02-19 7:31 ` [dpdk-dev] [PATCH v5 0/4] Add tunnel filter support for IP in GRE on i40e Xutao Sun
2016-02-19 7:31 15% ` [dpdk-dev] [PATCH v5 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure Xutao Sun
2016-01-25 14:11 3% [dpdk-dev] [PATCH 1/2] librte_pipeline: add support for packet redirection at action handlers Jasvinder Singh
2016-01-26 6:20 [dpdk-dev] [PATCH 00/12] extend flow director's fields in i40e driver Jingjing Wu
2016-01-26 6:20 4% ` [dpdk-dev] [PATCH 07/12] librte_ether: extend rte_eth_fdir_flow to support tunnel format Jingjing Wu
2016-01-26 16:15 [dpdk-dev] [PATCH V1 1/1] jobstats: added function abort for job Marcin Kerlin
2016-01-27 13:37 3% ` Panu Matilainen
2016-01-27 15:57 0% ` Jastrzebski, MichalX K
2016-01-28 7:41 3% ` Panu Matilainen
2016-01-26 17:25 [dpdk-dev] [PATCH 0/5] add external mempool manager David Hunt
2016-01-26 17:25 ` [dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support David Hunt
2016-02-04 14:52 ` Olivier MATZ
2016-02-04 16:47 ` Hunt, David
2016-02-08 11:02 4% ` Olivier MATZ
2016-02-16 14:48 3% ` [dpdk-dev] [PATCH 0/6] external mempool manager David Hunt
2016-02-16 14:48 4% ` [dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages David Hunt
2016-02-19 13:33 7% ` Olivier MATZ
2016-01-27 8:37 3% [dpdk-dev] [PATCH] ethdev: fix byte order inconsistence between fdir flow and mask Jingjing Wu
2016-01-27 9:19 0% ` Thomas Monjalon
2016-01-28 5:55 0% ` Wu, Jingjing
2016-02-01 2:48 3% ` [dpdk-dev] [PATCH v2] " Jingjing Wu
[not found] <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com>
2016-01-27 16:24 1% ` [dpdk-dev] [PATCH 2/3] rte_ctrl_if: add control interface library Ferruh Yigit
2016-02-12 13:45 ` [dpdk-dev] [PATCH v2 0/3] Use common Linux tools to control DPDK ports Ferruh Yigit
2016-02-12 13:45 1% ` [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library Ferruh Yigit
2016-02-17 19:58 0% ` Ananyev, Konstantin
2016-02-18 10:43 0% ` Yigit, Ferruh
2016-01-27 17:39 [dpdk-dev] [PATCH 0/4] Add PCAP support to source and sink port Fan Zhang
2016-01-27 17:39 ` [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port Fan Zhang
2016-01-28 11:54 4% ` Panu Matilainen
2016-01-29 15:10 4% ` Zhang, Roy Fan
2016-01-28 8:40 4% [dpdk-dev] [PATCH 0/3] support setting i40e VF MAC address from DPDK host side Helin Zhang
2016-01-28 8:40 4% ` [dpdk-dev] [PATCH 1/3] i40e: add setting VF MAC address in DPDK PF host Helin Zhang
2016-01-28 19:02 7% [dpdk-dev] [RFC] ABI breakage for rte_mempool to reduce footprint Wiles, Keith
2016-01-28 20:07 7% [dpdk-dev] [RFC] Abi " Wiles, Keith
2016-01-29 7:03 [dpdk-dev] [PATCH 0/8] support E-tag offloading and forwarding on Intel X550 NIC Wenzhuo Lu
2016-02-02 6:56 ` [dpdk-dev] [PATCH v2 0/7] " Wenzhuo Lu
2016-02-02 6:57 ` [dpdk-dev] [PATCH v2 2/7] lib/librte_ether: support l2 tunnel config Wenzhuo Lu
2016-02-03 3:36 3% ` Stephen Hemminger
2016-02-03 8:08 3% ` Lu, Wenzhuo
2016-02-01 15:24 9% [dpdk-dev] [PATCH v1] doc: add example text to release notes John McNamara
2016-02-02 1:37 [dpdk-dev] rings PMD detaching Mauricio Vásquez
2016-02-02 5:41 3% ` David Marchand
2016-02-02 22:59 3% [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:10 1% ` [dpdk-dev] [PATCH v1 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
2016-02-02 23:51 0% ` [dpdk-dev] [PATCH v1 0/5] clean-up cpuflags Jan Viktorin
2016-02-03 13:38 0% ` Jerin Jacob
2016-02-03 14:01 0% ` Thomas Monjalon
2016-02-06 22:17 3% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2016-02-06 22:17 1% ` [dpdk-dev] [PATCH v2 2/5] eal: move CPU flag functions out of headers Thomas Monjalon
2016-02-08 8:59 0% ` Jerin Jacob
2016-02-16 7:30 0% ` [dpdk-dev] [PATCH v2 0/5] clean-up cpuflags Thomas Monjalon
2016-02-02 23:02 2% [dpdk-dev] [PATCH] mempool: Reduce rte_mempool structure size Keith Wiles
2016-02-03 17:11 0% ` Ananyev, Konstantin
2016-02-08 11:02 4% ` Olivier MATZ
2016-02-08 15:57 0% ` Wiles, Keith
2016-02-09 17:30 2% ` [dpdk-dev] [PATCH v2] mempool: reduce " Keith Wiles
2016-02-10 21:18 7% ` [dpdk-dev] [PATCH v3] " Keith Wiles
2016-02-12 11:23 0% ` Panu Matilainen
2016-02-12 14:19 ` Panu Matilainen
2016-02-12 15:07 ` Wiles, Keith
2016-02-12 15:38 4% ` Thomas Monjalon
2016-02-12 15:50 0% ` Olivier MATZ
2016-02-12 15:58 0% ` Wiles, Keith
2016-02-15 9:58 ` Hunt, David
2016-02-15 10:15 4% ` Olivier MATZ
2016-02-15 10:21 0% ` Hunt, David
2016-02-15 12:31 0% ` Olivier MATZ
2016-02-12 15:54 0% ` Wiles, Keith
2016-02-12 18:36 3% ` [dpdk-dev] [PATCH v4] " Keith Wiles
2016-02-15 9:20 0% ` Olivier MATZ
2016-02-03 8:32 [dpdk-dev] [PATCH 00/10] cxgbe: Add flow director support Rahul Lakkireddy
2016-02-03 8:32 4% ` [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir Rahul Lakkireddy
2016-02-10 18:01 3% [dpdk-dev] [PATCH v2] mempool: reduce rte_mempool structure size Wiles, Keith
2016-02-10 18:02 3% ` Thomas Monjalon
2016-02-12 11:52 3% ` Panu Matilainen
2016-02-11 16:37 3% [dpdk-dev] [PATCH v3] af_packet: make the device detachable Wojciech Zmuda
2016-02-24 14:08 3% ` Iremonger, Bernard
2016-02-12 18:38 5% [dpdk-dev] [PATCH] doc: deprecation notice in 16.04 for rte_mempool changes Keith Wiles
2016-02-16 3:16 15% [dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure Ziye Yang
2016-02-16 7:38 9% ` Panu Matilainen
2016-02-16 7:43 9% ` Yang, Ziye
2016-02-16 7:55 7% ` Panu Matilainen
[not found] <1453689419-237252>
2016-02-16 4:08 15% ` Ziye Yang
2016-02-17 14:20 3% [dpdk-dev] [PATCH 0/3] ethdev: add helper functions to get eth_dev and dev private data Ferruh Yigit
2016-02-17 14:20 3% ` [dpdk-dev] [PATCH 1/3] " Ferruh Yigit
2016-02-18 10:26 [dpdk-dev] [PATCH 6/8] bond: handle slaves with fewer queues than bonding device Iremonger, Bernard
2016-02-19 19:17 ` [dpdk-dev] [PATCH v2 0/6] bonding: fixes and enhancements Eric Kinzie
2016-02-19 19:17 ` [dpdk-dev] [PATCH v2 4/6] bond mode 4: allow external state machine Eric Kinzie
2016-02-22 13:03 4% ` Panu Matilainen
2016-02-19 6:32 [dpdk-dev] [PATCH RFC 0/4] Thread safe rte_vhost_enqueue_burst() Ilya Maximets
2016-02-19 6:32 ` [dpdk-dev] [PATCH RFC 2/4] vhost: make buf vector for scatter RX local Ilya Maximets
2016-02-19 7:06 3% ` Yuanhan Liu
2016-02-19 7:30 0% ` Ilya Maximets
2016-02-19 8:10 3% ` Xie, Huawei
2016-02-19 10:56 [dpdk-dev] [PATCH RFC v2 0/3] Thread safe rte_vhost_enqueue_burst() Ilya Maximets
2016-02-19 10:56 4% ` [dpdk-dev] [PATCH RFC v2 2/3] vhost: make buf vector for scatter RX local Ilya Maximets
2016-02-22 13:53 6% [dpdk-dev] [PATCH] config: remove duplicate configuration information Keith Wiles
2016-02-22 15:09 0% ` Trahe, Fiona
2016-02-22 16:02 0% ` Wiles, Keith
2016-02-24 13:58 0% ` Wiles, Keith
2016-02-24 11:47 [dpdk-dev] [PATCH RFC v3 0/3] Thread safe rte_vhost_enqueue_burst() Ilya Maximets
2016-02-24 11:47 4% ` [dpdk-dev] [PATCH RFC v3 2/3] vhost: make buf vector for scatter RX local Ilya Maximets
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).