[dpdk-dev] [PATCH v3 1/2] mk: fix build with gcc 4.4 and clang
With GCC 4.4.7 from CentOS 6.5, the following errors arise:
lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function 'ixgbe_dev_rx_queue_setup':
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: missing initializer
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: (near initialization for
'dev_info.driver_name')
lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function 'ixgbe_set_rsc':
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:4072: error: missing initializer
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:4072: error: (near initialization for
'dev_info.driver_name')
lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function
'ixgbe_recv_pkts_lro_single_alloc':
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:1479: error: 'next_rsc_entry' may be used
uninitialized in this function
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:1480: error: 'next_rxe' may be used
uninitialized in this function
The "missing initializer" warning is a GCC bug which seems fixed in 4.7.
The same warning is thrown by clang.
The "may be used uninitialized" warning is another GCC bug which seems fixed in
4.7.
Fixes: 8eecb3295aed ("ixgbe: add LRO support")
Signed-off-by: Thomas Monjalon
---
changes in v2:
- option -Wno-missing-field-initializers for old GCC instead of code workaround
changes in v3:
- option -Wno-missing-field-initializers for clang
- option -Wno-uninitialized for old GCC instead of code workaround (=NULL)
- remove redundants -Wno-uninitialized from ixgbe Makefile
lib/librte_pmd_ixgbe/Makefile | 4
mk/toolchain/clang/rte.vars.mk | 3 +++
mk/toolchain/gcc/rte.vars.mk | 9 +
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile
index ae36202..fbf6966 100644
--- a/lib/librte_pmd_ixgbe/Makefile
+++ b/lib/librte_pmd_ixgbe/Makefile
@@ -76,10 +76,6 @@ ifeq ($(shell test $(GCC_VERSION) -ge 50 && echo 1), 1)
CFLAGS_ixgbe_common.o += -Wno-logical-not-parentheses
endif
-ifeq ($(shell test $(GCC_VERSION) -le 46 && echo 1), 1)
-CFLAGS_ixgbe_x550.o += -Wno-uninitialized
-CFLAGS_ixgbe_phy.o += -Wno-uninitialized
-endif
endif
#
diff --git a/mk/toolchain/clang/rte.vars.mk b/mk/toolchain/clang/rte.vars.mk
index 40cb389..245ea7e 100644
--- a/mk/toolchain/clang/rte.vars.mk
+++ b/mk/toolchain/clang/rte.vars.mk
@@ -72,5 +72,8 @@ WERROR_FLAGS += -Wundef -Wwrite-strings
# process cpu flags
include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain-compat.mk
+# workaround clang bug with warning "missing field initializer" for "= {0}"
+WERROR_FLAGS += -Wno-missing-field-initializers
+
export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk
index 88f235c..0f51c66 100644
--- a/mk/toolchain/gcc/rte.vars.mk
+++ b/mk/toolchain/gcc/rte.vars.mk
@@ -80,5 +80,14 @@ WERROR_FLAGS += -Wundef -Wwrite-strings
# process cpu flags
include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain-compat.mk
+# workaround GCC bug with warning "missing initializer" for "= {0}"
+ifeq ($(shell test $(GCC_VERSION) -lt 47 && echo 1), 1)
+WERROR_FLAGS += -Wno-missing-field-initializers
+endif
+# workaround GCC bug with warning "may be used uninitialized"
+ifeq ($(shell test $(GCC_VERSION) -lt 47 && echo 1), 1)
+WERROR_FLAGS += -Wno-uninitialized
+endif
+
export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
--
2.2.2
[dpdk-dev] [PATCH v3 2/2] use simple zero initializers
To initialize a structure with zeros, one field was explicitly set
to avoid "missing initializer" bug with old GCC (e.g. 4.4).
This warning is now disabled (commit ) for old versions of GCC,
so the workarounds may be removed.
These initializers should not be needed for static variables but they
are still used to workaround an ICC bug (see commit b2595c4aa92d).
There is one remaining exception where {0} initializer doesn't work cleanly,
even with recent GCC:
lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:735:9:
error: missing braces around initializer [-Werror=missing-braces]
struct rte_mbuf mb_def = {0}; /* zeroed mbuf */
Tested with gcc-4.4.7 (CentOS), gcc-4.7.2 (Debian), gcc-4.9.2 (Arch),
clang-3.6.0 and icc-13.1.1.
Signed-off-by: Thomas Monjalon
Tested-by: Thomas Monjalon
Tested-by: John McNamara
---
changes in v2:
- new patch
changes in v3:
- tested with clang and icc
app/test/test_ring_perf.c | 2 +-
lib/librte_pmd_e1000/em_ethdev.c | 2 +-
lib/librte_pmd_e1000/igb_ethdev.c | 4 ++--
lib/librte_pmd_e1000/igb_rxtx.c | 6 ++
lib/librte_pmd_enic/enic_clsf.c | 2 +-
lib/librte_pmd_i40e/i40e_rxtx.c | 2 +-
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 8 +++-
lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 3 +--
lib/librte_pmd_mlx4/mlx4.c| 2 +-
9 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/app/test/test_ring_perf.c b/app/test/test_ring_perf.c
index 44dda4d..8c47ccb 100644
--- a/app/test/test_ring_perf.c
+++ b/app/test/test_ring_perf.c
@@ -253,7 +253,7 @@ static void
run_on_core_pair(struct lcore_pair *cores,
lcore_function_t f1, lcore_function_t f2)
{
- struct thread_params param1 = {.size = 0}, param2 = {.size = 0};
+ struct thread_params param1 = {0}, param2 = {0};
unsigned i;
for (i = 0; i < sizeof(bulk_sizes)/sizeof(bulk_sizes[0]); i++) {
lcore_count = 0;
diff --git a/lib/librte_pmd_e1000/em_ethdev.c b/lib/librte_pmd_e1000/em_ethdev.c
index 12ecf5f..82e0b7a 100644
--- a/lib/librte_pmd_e1000/em_ethdev.c
+++ b/lib/librte_pmd_e1000/em_ethdev.c
@@ -130,7 +130,7 @@ static struct rte_pci_id pci_id_em_map[] = {
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "rte_pci_dev_ids.h"
-{.device_id = 0},
+{0},
};
static const struct eth_dev_ops eth_em_ops = {
diff --git a/lib/librte_pmd_e1000/igb_ethdev.c
b/lib/librte_pmd_e1000/igb_ethdev.c
index 1ea2d38..e2b7cf3 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -221,7 +221,7 @@ static struct rte_pci_id pci_id_igb_map[] = {
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "rte_pci_dev_ids.h"
-{.device_id = 0},
+{0},
};
/*
@@ -232,7 +232,7 @@ static struct rte_pci_id pci_id_igbvf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IGBVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "rte_pci_dev_ids.h"
-{.device_id = 0},
+{0},
};
static const struct eth_dev_ops eth_igb_ops = {
diff --git a/lib/librte_pmd_e1000/igb_rxtx.c b/lib/librte_pmd_e1000/igb_rxtx.c
index 946b39d..084e45a 100644
--- a/lib/librte_pmd_e1000/igb_rxtx.c
+++ b/lib/librte_pmd_e1000/igb_rxtx.c
@@ -1164,8 +1164,7 @@ igb_reset_tx_queue_stat(struct igb_tx_queue *txq)
static void
igb_reset_tx_queue(struct igb_tx_queue *txq, struct rte_eth_dev *dev)
{
- static const union e1000_adv_tx_desc zeroed_desc = { .read = {
- .buffer_addr = 0}};
+ static const union e1000_adv_tx_desc zeroed_desc = {{0}};
struct igb_tx_entry *txe = txq->sw_ring;
uint16_t i, prev;
struct e1000_hw *hw;
@@ -1330,8 +1329,7 @@ eth_igb_rx_queue_release(void *rxq)
static void
igb_reset_rx_queue(struct igb_rx_queue *rxq)
{
- static const union e1000_adv_rx_desc zeroed_desc = { .read = {
- .pkt_addr = 0}};
+ static const union e1000_adv_rx_desc zeroed_desc = {{0}};
unsigned i;
/* Zero out HW ring memory */
diff --git a/lib/librte_pmd_enic/enic_clsf.c b/lib/librte_pmd_enic/enic_clsf.c
index b61d625..a069194 100644
--- a/lib/librte_pmd_enic/enic_clsf.c
+++ b/lib/librte_pmd_enic/enic_clsf.c
@@ -96,7 +96,7 @@ int enic_fdir_add_fltr(struct enic *enic, struct
rte_fdir_filter *params,
u16 queue, u8 drop)
{
struct enic_fdir_node *key;
- struct filter fltr = {.type = 0};
+ struct filter fltr = {0};
int32_t pos;
u8 do_free = 0;
u16 old_fltr_id = 0;
diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 9c7be6f..abe68f4 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -1228,7 +1228,7 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
uint16_t tx_last;
uint16_t slen;
uint64_t buf_dma_addr;
- union i40e_tx_offload tx_offload = { .data = 0 };
+ union i40e_tx_offload tx_offload = {0};
txq = tx_queue;
sw_ring =
[dpdk-dev] mempool deleting and cache_size
On 16/04/15 11:26, Gonzalez Monroy, Sergio wrote: > On 16/04/2015 10:22, Marc Sune wrote: >> >> >> On 16/04/15 11:03, Gonzalez Monroy, Sergio wrote: >>> On 15/04/2015 20:24, Stephen Hemminger wrote: On Wed, 15 Apr 2015 20:15:18 +0100 Zoltan Kiss wrote: > Hi, > > I have two questions regarding mempools: > > - the first is trivial: how do you delete them? Can you? I can't > see a > function to do that, and none of the examples are doing such > thing. When > exactly it get deleted? You can't delete them. They live in hugepage area and are persistent. Correctly written code looks for them by name and reuses existing pool if it is big enough. >>> FYI, I'm looking into such functionality and also delete/destroy >>> mempools (although still no plan on implementation). >>> >> >> Also the memzones behind, or will be "lost/leaked" after a mempool >> destruction? >> >> Marc >> >>> Sergio >> > Sorry, my bad. > I did mean to say 'delete/destroy memzones' :) Good, That would make the KNI memzone pool not necessary anymore: http://article.gmane.org/gmane.comp.networking.dpdk.devel/6890/ If your patch gets accepted I will adapt that. Marc > > Sergio
[dpdk-dev] mempool deleting and cache_size
Hi, On 15/04/15 20:15, Zoltan Kiss wrote: > Hi, > > I have two questions regarding mempools: > > - the first is trivial: how do you delete them? Can you? I can't see a > function to do that, and none of the examples are doing such thing. When > exactly it get deleted? > - during creation, cache_size have one requirement: it has to be smaller > than RTE_MEMPOOL_CACHE_MAX_SIZE. And one recommendation: "n modulo > cache_size == 0". Is there any more guideline to determine that number? > E.g. now I'm using the biggest number which fits the above two conditions. > > Regards, > > Zoltan Thanks for all the answers for the first one, but does anyone has an idea for the second one? Zoli
[dpdk-dev] [PATCH 0/2] PCI cleanups
On Thu, Apr 16, 2015 at 04:23:38PM -0700, Stephen Hemminger wrote: > More places where PCI code should be using const but wasn't > > Stephen Hemminger (2): > pci: make device_id tables const > pci: allow const for rte_pci_addr > > app/test/virtual_pmd.c | 3 +-- > lib/librte_eal/common/eal_common_pci.c | 4 ++-- > lib/librte_eal/common/include/rte_pci.h | 9 + > lib/librte_eal/linuxapp/eal/eal_pci.c | 8 > lib/librte_pmd_bond/rte_eth_bond_api.c | 12 +--- > lib/librte_pmd_e1000/em_ethdev.c| 2 +- > lib/librte_pmd_e1000/igb_ethdev.c | 4 ++-- > lib/librte_pmd_enic/enic_ethdev.c | 2 +- > lib/librte_pmd_fm10k/fm10k_ethdev.c | 2 +- > lib/librte_pmd_i40e/i40e_ethdev.c | 2 +- > lib/librte_pmd_i40e/i40e_ethdev_vf.c| 2 +- > lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 4 ++-- > lib/librte_pmd_mlx4/mlx4.c | 2 +- > lib/librte_pmd_virtio/virtio_ethdev.c | 2 +- > lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 2 +- > 15 files changed, 29 insertions(+), 31 deletions(-) > > -- > 2.1.4 > > For the series Acked-by: Neil Horman
[dpdk-dev] [PATCH v3 1/2] mk: fix build with gcc 4.4 and clang
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, April 16, 2015 11:11 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 1/2] mk: fix build with gcc 4.4 and clang Acked-by: John McNamara
[dpdk-dev] [PATCH v3 2/2] use simple zero initializers
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, April 16, 2015 11:11 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 2/2] use simple zero initializers Acked-by: John McNamara
[dpdk-dev] help on exception path for ivshmem guest
Hi, I'm trying to reproduce the exception path example, but in a ivshmem guest machine. To avoid memory corruption, I can't call rte_pktmbuf_alloc and rte_pktmbuf_free from the guest. When I get packets from the host, it is easy to send them to the tap interface. But How to take packets from tap and put on the tx ring? Or how to put it on a mbuf struct without call those functions, and then push to the ring? Is there a way to do that? -- Rafael D. Vencioneck
[dpdk-dev] [RFC PATCH 0/4] pktdev
Hi all, to continue this discussion a bit more, here is my, slightly different, slant on what a pktdev abstraction may look like. The primary objective I had in mind when drafting this is to provide the minimal abstraction that can be *easily* used as a common device abstraction for existing (and future) device types to be passed to dataplane code. The patchset demonstrates this by defining a minimal interface for pktdev - since I firmly believe the interface should be as small as possible - and then showing how that common interface can be used to unify rings and ethdevs under a common API for the datapath. I believe any attempt to unify things much beyond this to the control plane or setup phase is not worth doing - at least not initially - as at init time the code always needs to be aware of the underlying resource type in order to configure it properly for dataplane use. The overall objective I look to achieve is illustrated by the final patch in the series, which is a sample app where the same code is used for all cores, irrespective of the underlying device type. To get to that point, patch 1 defines the minimal API - just RX and TX. The .c file in the library is empty for simplicity, though I would see some functionality moving there when/if it makes sense e.g. the callback support from ethdev, as is done in Keith's patchset. Patch 2 then makes very minimal changes to ethdev to allow ethdevs to be used as pktdevs, and to make use of the pktdev functions when appropriate Patch 3 was, for me, the key test for this implementation - how hard was it to make an rte_ring usable as a pktdev too. Two single-line functions for RX/TX and a separate "converter" function proved to be all that was necessary here - and I believe simpler solutions may be possible too, as the extra structures allocated on conversion could be merged into the rte_ring structure itself and initialized on ring creation if we prefer that option. It is hoped/presumed that wrapping other structures, such as KNI, may prove to be just as easily done. [Not attempted yet - left as an exercise for the reader :-)]. Now, in terms of pktdev vs ethdev, there is nothing in this proposal that cannot also be done using ethdev AFAIK. However, pktdev as outlined here should make the process far easier than trying to create a full PMD for something. All NIC specific functions, including things like stop/start, are stripped out, as they don't make sense for an rte_ring or other software objects. Also, the other thing this provides is that we can move away from just using port ids. Instead in the same way as we now reference rings/mempools/KNIs etc via pointer, we can do the same with ethernet ports as pktdevs on the data path. There was discussion previously on moving beyond 8-bit port ids. If we look to use ethdev as a common abstraction, I feel that change will soon have to be made causing a large amount of code churn. Bruce Richardson (4): Add example pktdev implementation Make ethdev explicitly a subclass of pktdev add support for a ring to be a pktdev example app showing pktdevs used in a chain config/common_bsdapp | 5 + config/common_linuxapp | 5 + examples/pktdev/Makefile | 57 +++ examples/pktdev/basicfwd.c | 222 + lib/Makefile | 1 + lib/librte_ether/rte_ethdev.h | 26 ++--- lib/librte_pktdev/Makefile | 56 +++ lib/librte_pktdev/rte_pktdev.c | 35 +++ lib/librte_pktdev/rte_pktdev.h | 144 ++ lib/librte_ring/rte_ring.c | 41 lib/librte_ring/rte_ring.h | 3 + 11 files changed, 582 insertions(+), 13 deletions(-) create mode 100644 examples/pktdev/Makefile create mode 100644 examples/pktdev/basicfwd.c create mode 100644 lib/librte_pktdev/Makefile create mode 100644 lib/librte_pktdev/rte_pktdev.c create mode 100644 lib/librte_pktdev/rte_pktdev.h -- 2.1.0
[dpdk-dev] [RFC PATCH 3/4] add support for a ring to be a pktdev
Add a new public API function, and two internal wrapper functions so we
can use ring as a pktdev.
---
lib/librte_ring/rte_ring.c | 41 +
lib/librte_ring/rte_ring.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
index 84ad3d3..bc5dd09 100644
--- a/lib/librte_ring/Makefile
+++ b/lib/librte_ring/Makefile
@@ -47,6 +47,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h
# this lib needs eal and rte_malloc
-DEPDIRS-$(CONFIG_RTE_LIBRTE_RING) += lib/librte_eal lib/librte_malloc
+DEPDIRS-$(CONFIG_RTE_LIBRTE_RING) += lib/librte_eal lib/librte_malloc
lib/librte_pktdev
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index c9e59d4..424da20 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -86,6 +86,7 @@
#include
#include
#include
+#include
#include "rte_ring.h"
@@ -208,6 +208,47 @@ rte_ring_create(const char *name, unsigned count, int
socket_id,
return r;
}
+static uint16_t
+dev_rx(void *r, struct rte_mbuf **pkts, uint16_t max_pkts)
+{
+ return rte_ring_dequeue_burst(r, (void *)pkts, max_pkts);
+}
+
+static uint16_t
+dev_tx(void *r, struct rte_mbuf **pkts, uint16_t max_pkts)
+{
+ return rte_ring_enqueue_burst(r, (void *)pkts, max_pkts);
+}
+
+#define rte_ring_dev_data rte_pkt_dev_data
+
+struct rte_pkt_dev *
+rte_ring_get_dev(struct rte_ring *r)
+{
+ struct ring_as_pktdev {
+ RTE_PKT_DEV_HDR(rte_ring_dev);
+ struct rte_ring_dev_data dev_data;
+ void *ring;
+ } *p;
+ if (r == NULL ||
+ (p = rte_zmalloc(NULL, sizeof(*p), 0)) == NULL)
+ return NULL;
+
+ p->ring = r;
+ p->rx_pkt_burst = dev_rx;
+ p->tx_pkt_burst = dev_tx;
+ p->data = &p->dev_data;
+
+ snprintf(p->dev_data.name, sizeof(p->dev_data.name), "%s", r->name);
+ p->dev_data.nb_rx_queues = 1;
+ p->dev_data.nb_tx_queues = 1;
+ p->dev_data.rx_queues = &p->ring;
+ p->dev_data.tx_queues = &p->ring;
+
+ return (void *)p;
+}
+
+
/*
* change the high water mark. If *count* is 0, water marking is
* disabled
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af6..c2f28be 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -301,6 +302,10 @@ int rte_ring_init(struct rte_ring *r, const char *name,
unsigned count,
struct rte_ring *rte_ring_create(const char *name, unsigned count,
int socket_id, unsigned flags);
+struct rte_pkt_dev;
+
+struct rte_pkt_dev *rte_ring_get_dev(struct rte_ring *r);
+
/**
* Change the high water mark.
*
--
2.1.0
[dpdk-dev] [RFC PATCH 1/4] Add example pktdev implementation
This commit demonstrates what a minimal API for all packet handling types would look like. It simply provides the necessary parts for receiving and transmiting packets, and is based off the ethdev implementation. --- config/common_bsdapp | 5 ++ config/common_linuxapp | 5 ++ lib/Makefile | 1 + lib/librte_pktdev/Makefile | 56 lib/librte_pktdev/rte_pktdev.c | 35 ++ lib/librte_pktdev/rte_pktdev.h | 144 + 6 files changed, 246 insertions(+) create mode 100644 lib/librte_pktdev/Makefile create mode 100644 lib/librte_pktdev/rte_pktdev.c create mode 100644 lib/librte_pktdev/rte_pktdev.h diff --git a/config/common_bsdapp b/config/common_bsdapp index 8ff4dc2..d2b932c 100644 --- a/config/common_bsdapp +++ b/config/common_bsdapp @@ -132,6 +132,11 @@ CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y CONFIG_RTE_LIBRTE_KVARGS=y # +# Compile generic packet handling device library +# +CONFIG_RTE_LIBRTE_PKTDEV=y + +# # Compile generic ethernet library # CONFIG_RTE_LIBRTE_ETHER=y diff --git a/config/common_linuxapp b/config/common_linuxapp index 09a58ac..5bda416 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -129,6 +129,11 @@ CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y CONFIG_RTE_LIBRTE_KVARGS=y # +# Compile generic packet handling device library +# +CONFIG_RTE_LIBRTE_PKTDEV=y + +# # Compile generic ethernet library # CONFIG_RTE_LIBRTE_ETHER=y diff --git a/lib/Makefile b/lib/Makefile index d94355d..4db5ee0 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -32,6 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk DIRS-y += librte_compat +DIRS-$(CONFIG_RTE_LIBRTE_PKTDEV) += librte_pktdev DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal DIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += librte_malloc DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring diff --git a/lib/librte_pktdev/Makefile b/lib/librte_pktdev/Makefile new file mode 100644 index 000..2d3b3a1 --- /dev/null +++ b/lib/librte_pktdev/Makefile @@ -0,0 +1,56 @@ +# BSD LICENSE +# +# Copyright(c) 2015 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 = libpktdev.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +EXPORT_MAP := rte_pktdev_version.map + +LIBABIVER := 1 + +SRCS-y += rte_pktdev.c + +# +# Export include files +# +SYMLINK-y-include += rte_pktdev.h + +# this lib depends upon no others: +DEPDIRS-y += + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pktdev/rte_pktdev.c b/lib/librte_pktdev/rte_pktdev.c new file mode 100644 index 000..4c32d86 --- /dev/null +++ b/lib/librte_pktdev/rte_pktdev.c @@ -0,0 +1,36 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2015 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
[dpdk-dev] [RFC PATCH 2/4] Make ethdev explicitly a subclass of pktdev
This patch allows us to take an ethdev port id and get from it a generic
pktdev object that we can call using the pktdev routines, if we like.
Change the actual rx/tx calls in the ethdev api to call the pktdev
versions - which becuase of inlining will work the same as before, with no
impact.
---
lib/librte_ether/rte_ethdev.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 21aa359..4986d6b 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -178,6 +178,7 @@ extern "C" {
#include
#include
#include
+#include
#include "rte_ether.h"
#include "rte_eth_ctrl.h"
@@ -1446,9 +1447,7 @@ enum rte_eth_dev_type {
* process, while the actual configuration data for the device is shared.
*/
struct rte_eth_dev {
- eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
- eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
- struct rte_eth_dev_data *data; /**< Pointer to device data */
+ RTE_PKT_DEV_HDR(rte_eth_dev);
const struct eth_driver *driver;/**< Driver for this device */
const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
struct rte_pci_device *pci_dev; /**< PCI info. supplied by probing */
@@ -1486,13 +1485,7 @@ struct rte_eth_dev_sriov {
* processes in a multi-process configuration.
*/
struct rte_eth_dev_data {
- char name[RTE_ETH_NAME_MAX_LEN]; /**< Unique identifier name */
-
- void **rx_queues; /**< Array of pointers to RX queues. */
- void **tx_queues; /**< Array of pointers to TX queues. */
- uint16_t nb_rx_queues; /**< Number of RX queues. */
- uint16_t nb_tx_queues; /**< Number of TX queues. */
-
+ RTE_PKT_DEV_DATA_HDR;
struct rte_eth_dev_sriov sriov;/**< SRIOV data */
void *dev_private; /**< PMD-specific private data */
@@ -2298,6 +2291,12 @@ extern int rte_eth_dev_get_vlan_offload(uint8_t port_id);
*/
extern int rte_eth_dev_set_vlan_pvid(uint8_t port_id, uint16_t pvid, int on);
+static inline struct rte_pkt_dev *
+rte_eth_get_dev(uint8_t port_id)
+{
+ return (void *)&rte_eth_devices[port_id];
+}
+
/**
*
* Retrieve a burst of input packets from a receive queue of an Ethernet
@@ -2392,8 +2391,8 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
dev = &rte_eth_devices[port_id];
- int16_t nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
- rx_pkts, nb_pkts);
+ int16_t nb_rx = rte_pkt_rx_burst(rte_eth_get_dev(port_id), queue_id,
+ rx_pkts, nb_pkts);
#ifdef RTE_ETHDEV_RXTX_CALLBACKS
struct rte_eth_rxtx_callback *cb = dev->post_rx_burst_cbs[queue_id];
@@ -2547,7 +2546,8 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
}
#endif
- return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts,
nb_pkts);
+ return rte_pkt_tx_burst(rte_eth_get_dev(port_id), queue_id,
+ tx_pkts, nb_pkts);
}
#endif
--
2.1.0
[dpdk-dev] [RFC PATCH 4/4] example app showing pktdevs used in a chain
This is a trivial example showing code which is using ethdevs and rings in a neutral manner, with the same piece of pipeline code passing mbufs along a chain without ever having to query its source or destination type. --- examples/pktdev/Makefile | 57 examples/pktdev/basicfwd.c | 222 + 2 files changed, 279 insertions(+) create mode 100644 examples/pktdev/Makefile create mode 100644 examples/pktdev/basicfwd.c diff --git a/examples/pktdev/Makefile b/examples/pktdev/Makefile new file mode 100644 index 000..4a5d99f --- /dev/null +++ b/examples/pktdev/Makefile @@ -0,0 +1,57 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +ifeq ($(RTE_SDK),) +$(error "Please define RTE_SDK environment variable") +endif + +# Default target, can be overridden by command line or environment +RTE_TARGET ?= x86_64-native-linuxapp-gcc + +include $(RTE_SDK)/mk/rte.vars.mk + +# binary name +APP = basicfwd + +# all source are stored in SRCS-y +SRCS-y := basicfwd.c + +CFLAGS += $(WERROR_FLAGS) + +# workaround for a gcc bug with noreturn attribute +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) +CFLAGS_main.o += -Wno-return-type +endif + +EXTRA_CFLAGS += -O3 -g -Wfatal-errors + +include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/pktdev/basicfwd.c b/examples/pktdev/basicfwd.c new file mode 100644 index 000..e06bcfe --- /dev/null +++ b/examples/pktdev/basicfwd.c @@ -0,0 +1,222 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2015 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 +#include +#include +#include +#include +#include +#include + +#define RX_RING_SIZE 128 +#define TX_RING_SIZE 512 + +#def
[dpdk-dev] [PATCH 0/2] functions with useless return
Fix a couple of cases (there are more) where functions always return 0, by changing them to be void. Stephen Hemminger (2): log: rte_openlog_stream should be void eal: pci probe and adjust_config should be void lib/librte_eal/common/eal_common_log.c | 3 +-- lib/librte_eal/common/eal_common_options.c | 3 +-- lib/librte_eal/common/eal_common_pci.c | 7 ++- lib/librte_eal/common/eal_options.h| 2 +- lib/librte_eal/common/include/rte_log.h| 5 + lib/librte_eal/common/include/rte_pci.h| 6 +- lib/librte_eal/linuxapp/eal/eal.c | 6 ++ 7 files changed, 9 insertions(+), 23 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH 1/2] log: rte_openlog_stream should be void
Function always returned 0 and no one was checking anyway.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/common/eal_common_log.c | 3 +--
lib/librte_eal/common/include/rte_log.h | 5 +
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_log.c
b/lib/librte_eal/common/eal_common_log.c
index ff44d23..3802f9c 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -158,14 +158,13 @@ rte_log_set_history(int enable)
}
/* Change the stream that will be used by logging system */
-int
+void
rte_openlog_stream(FILE *f)
{
if (f == NULL)
rte_logs.file = default_log_stream;
else
rte_logs.file = f;
- return 0;
}
/* Set global log level */
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index f83a0d9..888ee19 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -110,11 +110,8 @@ extern FILE *eal_default_log_stream;
*
* @param f
* Pointer to the stream.
- * @return
- * - 0 on success.
- * - Negative on error.
*/
-int rte_openlog_stream(FILE *f);
+void rte_openlog_stream(FILE *f);
/**
* Set the global log level.
--
2.1.4
[dpdk-dev] [PATCH 2/2] eal: pci probe and adjust_config should be void
This functions always returned 0 and therefore should be void.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/common/eal_common_options.c | 3 +--
lib/librte_eal/common/eal_common_pci.c | 7 ++-
lib/librte_eal/common/eal_options.h| 2 +-
lib/librte_eal/common/include/rte_pci.h| 6 +-
lib/librte_eal/linuxapp/eal/eal.c | 6 ++
5 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 8fcb1ab..f47b401 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -794,7 +794,7 @@ eal_parse_common_option(int opt, const char *optarg,
return 0;
}
-int
+void
eal_adjust_config(struct internal_config *internal_cfg)
{
int i;
@@ -812,7 +812,6 @@ eal_adjust_config(struct internal_config *internal_cfg)
for (i = 0; i < RTE_MAX_NUMA_NODES; i++)
internal_cfg->memory += internal_cfg->socket_mem[i];
- return 0;
}
int
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 808b87b..93c8e84 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -223,7 +223,7 @@ err_return:
* all registered drivers that have a matching entry in its id_table
* for discovered devices.
*/
-int
+void
rte_eal_pci_probe(void)
{
struct rte_pci_device *dev = NULL;
@@ -252,12 +252,10 @@ rte_eal_pci_probe(void)
" cannot be used\n", dev->addr.domain,
dev->addr.bus,
dev->addr.devid, dev->addr.function);
}
-
- return 0;
}
/* dump one device */
-static int
+static void
pci_dump_one_device(FILE *f, struct rte_pci_device *dev)
{
int i;
@@ -273,7 +271,6 @@ pci_dump_one_device(FILE *f, struct rte_pci_device *dev)
dev->mem_resource[i].phys_addr,
dev->mem_resource[i].len);
}
- return 0;
}
/* dump devices on the bus */
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index f6714d9..59a0f39 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -89,7 +89,7 @@ extern const struct option eal_long_options[];
int eal_parse_common_option(int opt, const char *argv,
struct internal_config *conf);
-int eal_adjust_config(struct internal_config *internal_cfg);
+void eal_adjust_config(struct internal_config *internal_cfg);
int eal_check_common_options(struct internal_config *internal_cfg);
void eal_common_usage(void);
enum rte_proc_type_t eal_proc_type_detect(void);
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 785852d..052d3da 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -327,12 +327,8 @@ int rte_eal_pci_scan(void);
* Scan the content of the PCI bus, and call the probe() function for
* all registered drivers that have a matching entry in its id_table
* for discovered devices.
- *
- * @return
- * - 0 on success.
- * - Negative on error.
*/
-int rte_eal_pci_probe(void);
+void rte_eal_pci_probe(void);
#ifdef RTE_LIBRTE_EAL_HOTPLUG
/**
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index bd770cf..e2a5468 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -621,8 +621,7 @@ eal_parse_args(int argc, char **argv)
}
}
- if (eal_adjust_config(&internal_config) != 0)
- return -1;
+ eal_adjust_config(&internal_config);
/* sanity checks */
if (eal_check_common_options(&internal_config) != 0) {
@@ -842,8 +841,7 @@ rte_eal_init(int argc, char **argv)
rte_eal_mp_wait_lcore();
/* Probe & Initialize PCI devices */
- if (rte_eal_pci_probe())
- rte_panic("Cannot probe PCI\n");
+ rte_eal_pci_probe();
return fctret;
}
--
2.1.4
[dpdk-dev] [PATCH 0/2] functions with useless return
On Fri, Apr 17, 2015 at 08:35:32AM -0700, Stephen Hemminger wrote: > Fix a couple of cases (there are more) where functions > always return 0, by changing them to be void. > > Stephen Hemminger (2): > log: rte_openlog_stream should be void > eal: pci probe and adjust_config should be void > > lib/librte_eal/common/eal_common_log.c | 3 +-- > lib/librte_eal/common/eal_common_options.c | 3 +-- > lib/librte_eal/common/eal_common_pci.c | 7 ++- > lib/librte_eal/common/eal_options.h| 2 +- > lib/librte_eal/common/include/rte_log.h| 5 + > lib/librte_eal/common/include/rte_pci.h| 6 +- > lib/librte_eal/linuxapp/eal/eal.c | 6 ++ > 7 files changed, 9 insertions(+), 23 deletions(-) > > -- > 2.1.4 > > Series Acked-by: Neil Horman
[dpdk-dev] [PATCH] hash: update jhash function with the latest available
> -Original Message-
> From: Richardson, Bruce
> Sent: Thursday, April 16, 2015 3:01 PM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] hash: update jhash function with the latest
> available
>
> On Thu, Apr 16, 2015 at 02:26:59PM +0100, Pablo de Lara wrote:
> > Jenkins hash function was developed originally in 1996,
> > and was integrated in first versions of DPDK.
> > The function has been improved in 2006,
> > achieving up to 60% better performance, compared to the original one.
> >
> > Check out: http://burtleburtle.net/bob/c/lookup3.c
> >
> > This patch integrates that code in the rte_jhash library,
> > adding also a new function rte_jhash_word2,
> > that returns two different hash values, for a single key.
> >
>
> Should the addition of the new functionality not be a separate patch from
> the
> update to the existing code?
True, actually, I miss one extra function (2 in total).
> Also, do the new functions return the exact same values as the previous
> versions,
> just faster?
The new functions return different values from the previous version
AND faster (some cases, MUCH faster)
[...]
> > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > + case 12:
> > + c += k[2]; b += k[1]; a += k[0]; break;
> > + case 11:
> > + c += k[2]&0xff; b += k[1]; a += k[0]; break;
> > + case 10:
> > + c += k[2]&0x; b += k[1]; a += k[0]; break;
> > + case 9:
> > + c += k[2]&0xff; b += k[1]; a += k[0]; break;
> > + case 8:
> > + b += k[1]; a += k[0]; break;
> > + case 7:
> > + b += k[1]&0xff; a += k[0]; break;
> > + case 6:
> > + b += k[1]&0x; a += k[0]; break;
> > + case 5:
> > + b += k[1]&0xff; a += k[0]; break;
> > + case 4:
> > + a += k[0]; break;
> > + case 3:
> > + a += k[0]&0xff; break;
> > + case 2:
> > + a += k[0]&0x; break;
> > + case 1:
> > + a += k[0]&0xff; break;
> > +#else
> > + case 12:
> > + c += k[2]; b += k[1]; a += k[0]; break;
> > + case 11:
> > + c += k[2]&0xff00; b += k[1]; a += k[0]; break;
> > + case 10:
> > + c += k[2]&0x; b += k[1]; a += k[0]; break;
> > + case 9:
> > + c += k[2]&0xff00; b += k[1]; a += k[0]; break;
> > + case 8:
> > + b += k[1]; a += k[0]; break;
> > + case 7:
> > + b += k[1]&0xff00; a += k[0]; break;
> > + case 6:
> > + b += k[1]&0x; a += k[0]; break;
> > + case 5:
> > + b += k[1]&0xff00; a += k[0]; break;
> > + case 4:
> > + a += k[0]; break;
> > + case 3:
> > + a += k[0]&0xff00; break;
> > + case 2:
> > + a += k[0]&0x; break;
> > + case 1:
> > + a += k[0]&0xff00; break;
> > +#endif
>
> Only the constants seem different in this block. Can we get rid of the
> #ifdefs using rte_XX_to_cpu() calls instead?
Will add that in next version.
>
> > + /* zero length strings require no mixing */
> > + case 0:
> > + return c;
> > + };
> > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > + } else if ((u.i & 0x1) == 0) {
> > + /* read 16-bit chunks */
> > + const uint16_t *k = (const uint16_t *)key;
> > + const uint8_t *k8;
> > +
> > + /* all but last block: aligned reads and different mixing */
> > + while (length > 12) {
> > + a += k[0] + (((uint32_t)k[1])<<16);
> > + b += k[2] + (((uint32_t)k[3])<<16);
> > + c += k[4] + (((uint32_t)k[5])<<16);
> > +
> > + __rte_jhash_mix(a, b, c);
> > +
> > + k += 6;
> > + length -= 12;
> > + }
> > +
> > + /* handle the last (probably partial) block */
> > + k8 = (const uint8_t *)k;
> > + switch (length) {
> > + case 12:
> > + c += k[4]+(((uint32_t)k[5])<<16);
> > + b += k[2]+(((uint32_t)k[3])<<16);
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 11:
> > + /* fall through */
> > + c += ((uint32_t)k8[10])<<16;
> > + case 10:
> > + c += k[4];
> > + b += k[2]+(((uint32_t)k[3])<<16);
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 9:
> > + /* fall through */
> > +
[dpdk-dev] [RFC PATCH 0/4] pktdev
On Fri, Apr 17, 2015 at 04:16:40PM +0100, Bruce Richardson wrote: > Hi all, > > to continue this discussion a bit more, here is my, slightly different, slant > on what a pktdev abstraction may look like. > > The primary objective I had in mind when drafting this is to provide the > minimal abstraction that can be *easily* used as a common device abstraction > for > existing (and future) device types to be passed to dataplane code. The > patchset > demonstrates this by defining a minimal interface for pktdev - since I firmly > believe the interface should be as small as possible - and then showing how > that > common interface can be used to unify rings and ethdevs under a common API > for the > datapath. I believe any attempt to unify things much beyond this to the > control > plane or setup phase is not worth doing - at least not initially - as at > init time the code always needs to be aware of the underlying resource type in > order to configure it properly for dataplane use. > > The overall objective I look to achieve is illustrated by the final patch in > the series, which is a sample app where the same code is used for all cores, > irrespective of the underlying device type. > > To get to that point, patch 1 defines the minimal API - just RX and TX. The .c > file in the library is empty for simplicity, though I would see some > functionality moving there when/if it makes sense e.g. the callback support > from ethdev, as is done in Keith's patchset. > Patch 2 then makes very minimal changes to ethdev to allow ethdevs to be used > as pktdevs, and to make use of the pktdev functions when appropriate > Patch 3 was, for me, the key test for this implementation - how hard was it to > make an rte_ring usable as a pktdev too. Two single-line functions for RX/TX > and a separate "converter" function proved to be all that was necessary here - > and I believe simpler solutions may be possible too, as the extra structures > allocated on conversion could be merged into the rte_ring structure itself and > initialized on ring creation if we prefer that option. It is hoped/presumed > that > wrapping other structures, such as KNI, may prove to be just as easily done. > [Not attempted yet - left as an exercise for the reader :-)]. > > Now, in terms of pktdev vs ethdev, there is nothing in this proposal that > cannot also be done using ethdev AFAIK. However, pktdev as outlined here > should make the process far easier than trying to create a full PMD for > something. > All NIC specific functions, including things like stop/start, are stripped > out, > as they don't make sense for an rte_ring or other software objects. > Also, the other thing this provides is that we can move away from just using > port ids. Instead in the same way as we now reference rings/mempools/KNIs etc > via pointer, we can do the same with ethernet ports as pktdevs on the data > path. > There was discussion previously on moving beyond 8-bit port ids. If we look to > use ethdev as a common abstraction, I feel that change will soon have to be > made > causing a large amount of code churn. > This is the thing that I think we are really disagreeing on here. The ease of use increase. As you claim above, theres nothing you can do with a pktdev that you can't do with an ethdev, so why not just use an ethdev? Its no more difficult, the API already exists and contains checks so that any ethdev method that is unimplemented just return EOPNOTSUPP. Its a well understood model, just use it. Neil
[dpdk-dev] [RFC PATCH 3/4] add support for a ring to be a pktdev
On Fri, Apr 17, 2015 at 04:16:43PM +0100, Bruce Richardson wrote:
> Add a new public API function, and two internal wrapper functions so we
> can use ring as a pktdev.
> ---
> lib/librte_ring/rte_ring.c | 41 +
> lib/librte_ring/rte_ring.h | 3 +++
> 2 files changed, 44 insertions(+)
>
> diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
> index 84ad3d3..bc5dd09 100644
> --- a/lib/librte_ring/Makefile
> +++ b/lib/librte_ring/Makefile
> @@ -47,6 +47,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
> SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h
>
> # this lib needs eal and rte_malloc
> -DEPDIRS-$(CONFIG_RTE_LIBRTE_RING) += lib/librte_eal lib/librte_malloc
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_RING) += lib/librte_eal lib/librte_malloc
> lib/librte_pktdev
>
> include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
> index c9e59d4..424da20 100644
> --- a/lib/librte_ring/rte_ring.c
> +++ b/lib/librte_ring/rte_ring.c
> @@ -86,6 +86,7 @@
> #include
> #include
> #include
> +#include
>
> #include "rte_ring.h"
>
> @@ -208,6 +208,47 @@ rte_ring_create(const char *name, unsigned count, int
> socket_id,
> return r;
> }
>
> +static uint16_t
> +dev_rx(void *r, struct rte_mbuf **pkts, uint16_t max_pkts)
> +{
> + return rte_ring_dequeue_burst(r, (void *)pkts, max_pkts);
> +}
> +
> +static uint16_t
> +dev_tx(void *r, struct rte_mbuf **pkts, uint16_t max_pkts)
> +{
> + return rte_ring_enqueue_burst(r, (void *)pkts, max_pkts);
> +}
> +
> +#define rte_ring_dev_data rte_pkt_dev_data
> +
> +struct rte_pkt_dev *
> +rte_ring_get_dev(struct rte_ring *r)
> +{
> + struct ring_as_pktdev {
> + RTE_PKT_DEV_HDR(rte_ring_dev);
> + struct rte_ring_dev_data dev_data;
> + void *ring;
> + } *p;
> + if (r == NULL ||
> + (p = rte_zmalloc(NULL, sizeof(*p), 0)) == NULL)
> + return NULL;
> +
> + p->ring = r;
> + p->rx_pkt_burst = dev_rx;
> + p->tx_pkt_burst = dev_tx;
> + p->data = &p->dev_data;
> +
> + snprintf(p->dev_data.name, sizeof(p->dev_data.name), "%s", r->name);
> + p->dev_data.nb_rx_queues = 1;
> + p->dev_data.nb_tx_queues = 1;
> + p->dev_data.rx_queues = &p->ring;
> + p->dev_data.tx_queues = &p->ring;
> +
> + return (void *)p;
> +}
> +
> +
So, yeah, you have the ability to get a new ethdev out of the ring api here,
thats great. But to do it, you've created an additional API call point. I
don't think thats a reasonable trade off. If you had just registered a PMD,
with minimal methods (rx and tx), you might have had a little more code
involved, but for that additional code you would have bought yourself all the
infrastructure that ethdevs provide, like the ability to allocate and register
them at exeution time administratively (with the --vdev option). You saved
yourself a bit of code here, but lost the ability to do all the other things
that you might want to do with ring ethdevs.
Neil
[dpdk-dev] [RFC PATCH 0/4] pktdev
On 17/04/15 17:16, Bruce Richardson wrote:
> Hi all,
>
> to continue this discussion a bit more, here is my, slightly different, slant
> on what a pktdev abstraction may look like.
>
> The primary objective I had in mind when drafting this is to provide the
> minimal abstraction that can be *easily* used as a common device abstraction
> for
> existing (and future) device types to be passed to dataplane code. The
> patchset
> demonstrates this by defining a minimal interface for pktdev - since I firmly
> believe the interface should be as small as possible - and then showing how
> that
> common interface can be used to unify rings and ethdevs under a common API
> for the
> datapath. I believe any attempt to unify things much beyond this to the
> control
> plane or setup phase is not worth doing - at least not initially - as at
> init time the code always needs to be aware of the underlying resource type in
> order to configure it properly for dataplane use.
>
> The overall objective I look to achieve is illustrated by the final patch in
> the series, which is a sample app where the same code is used for all cores,
> irrespective of the underlying device type.
>
> To get to that point, patch 1 defines the minimal API - just RX and TX. The .c
> file in the library is empty for simplicity, though I would see some
> functionality moving there when/if it makes sense e.g. the callback support
> from ethdev, as is done in Keith's patchset.
> Patch 2 then makes very minimal changes to ethdev to allow ethdevs to be used
> as pktdevs, and to make use of the pktdev functions when appropriate
> Patch 3 was, for me, the key test for this implementation - how hard was it to
> make an rte_ring usable as a pktdev too. Two single-line functions for RX/TX
> and a separate "converter" function proved to be all that was necessary here -
> and I believe simpler solutions may be possible too, as the extra structures
> allocated on conversion could be merged into the rte_ring structure itself and
> initialized on ring creation if we prefer that option. It is hoped/presumed
> that
> wrapping other structures, such as KNI, may prove to be just as easily done.
> [Not attempted yet - left as an exercise for the reader :-)].
>
> Now, in terms of pktdev vs ethdev, there is nothing in this proposal that
> cannot also be done using ethdev AFAIK. However, pktdev as outlined here
> should make the process far easier than trying to create a full PMD for
> something.
> All NIC specific functions, including things like stop/start, are stripped
> out,
> as they don't make sense for an rte_ring or other software objects.
> Also, the other thing this provides is that we can move away from just using
> port ids. Instead in the same way as we now reference rings/mempools/KNIs etc
> via pointer, we can do the same with ethernet ports as pktdevs on the data
> path.
> There was discussion previously on moving beyond 8-bit port ids. If we look to
> use ethdev as a common abstraction, I feel that change will soon have to be
> made
> causing a large amount of code churn.
Hi Richard,
First thank you both for taking the time to look at this. I did not not
reply to Keith because you Richard summarized most of my concerns.
I had a brief look to this second proposal. It is more aligned to what I
had in mind. But still I feel it is slightly too complicated. I don't
like much the necessary (in your approach) MACRO-like pkt_dev_data
struct. It is also slightly inconvenient that the user has to do:
+ struct rte_pkt_dev *in = rte_eth_get_dev(0);
+ struct rte_pkt_dev *out = rte_ring_get_dev(
+ rte_ring_create(name, 4096, rte_socket_id(),
0));
What about something like (~pseudo-code):
rte_pkt_dev_data.h:
enum rte_pkt_dev_type{
RTE_PKT_DEV_ETH,
RTE_PKT_DEV_RING,
RTE_PKT_DEV_KNI,
//Keep adding as more PMDs are supported
};
//This struct may be redundant if there is nothing more
struct rte_pkt_dev_data{
enum rte_pkt_dev_type;
//Placeholder, maybe we need more...
};
//Make RX/TX pktdev APIs more readable, but not really needed
typedef void pkt_dev_t;
(In all PMDs and e.g. KNI and RINGs):
struct rte_eth_dev {
struct rte_pkt_dev_data pkt_dev;// <++
eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
struct rte_eth_dev_data *data; /**< Pointer to device data */
/...
rte_pkt_dev.h:
#include
//Include PMD (and non-PMD) TX/RX headers...
static inline uint16_t
rte_pkt_tx_burst(pkt_dev_t* dev, uint16_t queue_id,
struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
switch (((struct rte_pkt_dev_data*)dev)->type){
case RTE_PKT_DEV_ETH:
struct rte_eth_dev* eth_dev = (struct rte_eth_dev*)pkt_dev;
[dpdk-dev] [RFC PATCH 0/4] pktdev
Hi Marc and Bruce,
On 4/17/15, 1:49 PM, "Marc Sune" wrote:
>
>
>On 17/04/15 17:16, Bruce Richardson wrote:
>> Hi all,
>>
>> to continue this discussion a bit more, here is my, slightly different,
>>slant
>> on what a pktdev abstraction may look like.
>>
>> The primary objective I had in mind when drafting this is to provide the
>> minimal abstraction that can be *easily* used as a common device
>>abstraction for
>> existing (and future) device types to be passed to dataplane code. The
>>patchset
>> demonstrates this by defining a minimal interface for pktdev - since I
>>firmly
>> believe the interface should be as small as possible - and then showing
>>how that
>> common interface can be used to unify rings and ethdevs under a common
>>API for the
>> datapath. I believe any attempt to unify things much beyond this to the
>>control
>> plane or setup phase is not worth doing - at least not initially - as at
>> init time the code always needs to be aware of the underlying resource
>>type in
>> order to configure it properly for dataplane use.
>>
>> The overall objective I look to achieve is illustrated by the final
>>patch in
>> the series, which is a sample app where the same code is used for all
>>cores,
>> irrespective of the underlying device type.
>>
>> To get to that point, patch 1 defines the minimal API - just RX and TX.
>>The .c
>> file in the library is empty for simplicity, though I would see some
>> functionality moving there when/if it makes sense e.g. the callback
>>support
>> from ethdev, as is done in Keith's patchset.
>> Patch 2 then makes very minimal changes to ethdev to allow ethdevs to
>>be used
>> as pktdevs, and to make use of the pktdev functions when appropriate
>> Patch 3 was, for me, the key test for this implementation - how hard
>>was it to
>> make an rte_ring usable as a pktdev too. Two single-line functions for
>>RX/TX
>> and a separate "converter" function proved to be all that was necessary
>>here -
>> and I believe simpler solutions may be possible too, as the extra
>>structures
>> allocated on conversion could be merged into the rte_ring structure
>>itself and
>> initialized on ring creation if we prefer that option. It is
>>hoped/presumed that
>> wrapping other structures, such as KNI, may prove to be just as easily
>>done.
>> [Not attempted yet - left as an exercise for the reader :-)].
>>
>> Now, in terms of pktdev vs ethdev, there is nothing in this proposal
>>that
>> cannot also be done using ethdev AFAIK. However, pktdev as outlined here
>> should make the process far easier than trying to create a full PMD for
>>something.
>> All NIC specific functions, including things like stop/start, are
>>stripped out,
>> as they don't make sense for an rte_ring or other software objects.
>> Also, the other thing this provides is that we can move away from just
>>using
>> port ids. Instead in the same way as we now reference
>>rings/mempools/KNIs etc
>> via pointer, we can do the same with ethernet ports as pktdevs on the
>>data path.
>> There was discussion previously on moving beyond 8-bit port ids. If we
>>look to
>> use ethdev as a common abstraction, I feel that change will soon have
>>to be made
>> causing a large amount of code churn.
>
>Hi Richard,
>
>First thank you both for taking the time to look at this. I did not not
>reply to Keith because you Richard summarized most of my concerns.
>
>I had a brief look to this second proposal. It is more aligned to what I
>had in mind. But still I feel it is slightly too complicated. I don't
>like much the necessary (in your approach) MACRO-like pkt_dev_data
>struct. It is also slightly inconvenient that the user has to do:
>
>+ struct rte_pkt_dev *in = rte_eth_get_dev(0);
>
>+ struct rte_pkt_dev *out = rte_ring_get_dev(
>+ rte_ring_create(name, 4096, rte_socket_id(),
>0));
>
>
>
>What about something like (~pseudo-code):
>
>rte_pkt_dev_data.h:
>
>enum rte_pkt_dev_type{
> RTE_PKT_DEV_ETH,
> RTE_PKT_DEV_RING,
> RTE_PKT_DEV_KNI,
> //Keep adding as more PMDs are supported
>};
>
>
>//This struct may be redundant if there is nothing more
>struct rte_pkt_dev_data{
> enum rte_pkt_dev_type;
> //Placeholder, maybe we need more...
>};
>
>//Make RX/TX pktdev APIs more readable, but not really needed
>typedef void pkt_dev_t;
>
>(In all PMDs and e.g. KNI and RINGs):
>
> struct rte_eth_dev {
> struct rte_pkt_dev_data pkt_dev;//
><++
> eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
> eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function.
>*/
> struct rte_eth_dev_data *data; /**< Pointer to device data */
> /...
>
>rte_pkt_dev.h:
>
> #include
> //Include PMD (and non-PMD) TX/RX headers...
>
>static inline uint16_t
>rte_pkt_tx_burst(pkt_dev_t* dev, uint16_t queue_id,
> struct rte_mbuf **tx_pkts, uint16
