* [PATCH v2 32/32] app/testpmd: fix invalid port ID
From: Wenzhuo Lu @ 2016-12-07 3:32 UTC (permalink / raw)
To: dev; +Cc: Wenzhuo Lu, Chen Jing D(Mark)
In-Reply-To: <1481081535-37448-1-git-send-email-wenzhuo.lu@intel.com>
Some CLIs don't check the input port ID, it
may cause segmentation fault (core dumped).
Fixes: 425781ff5afe ("app/testpmd: add ixgbe VF management")
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Signed-off-by: Chen Jing D(Mark) <jing.d.chen@intel.com>
---
app/test-pmd/cmdline.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index e1a7e02..be0c424 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10829,6 +10829,9 @@ struct cmd_vf_vlan_anti_spoof_result {
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
struct rte_eth_dev_info dev_info;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
memset(&dev_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(res->port_id, &dev_info);
@@ -10930,6 +10933,9 @@ struct cmd_vf_mac_anti_spoof_result {
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
struct rte_eth_dev_info dev_info;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
memset(&dev_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(res->port_id, &dev_info);
@@ -11031,6 +11037,9 @@ struct cmd_vf_vlan_stripq_result {
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
struct rte_eth_dev_info dev_info;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
memset(&dev_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(res->port_id, &dev_info);
@@ -11129,6 +11138,9 @@ struct cmd_vf_vlan_insert_result {
int ret;
struct rte_eth_dev_info dev_info;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
memset(&dev_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(res->port_id, &dev_info);
@@ -11218,6 +11230,9 @@ struct cmd_tx_loopback_result {
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
struct rte_eth_dev_info dev_info;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
memset(&dev_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(res->port_id, &dev_info);
@@ -11307,6 +11322,9 @@ struct cmd_all_queues_drop_en_result {
int ret = 0;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
ret = rte_pmd_ixgbe_set_all_queues_drop_en(res->port_id, is_on);
switch (ret) {
case 0:
@@ -11390,6 +11408,9 @@ struct cmd_vf_split_drop_en_result {
int ret;
int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
ret = rte_pmd_ixgbe_set_vf_split_drop_en(res->port_id, res->vf_id,
is_on);
switch (ret) {
@@ -11474,6 +11495,9 @@ struct cmd_set_vf_mac_addr_result {
struct cmd_set_vf_mac_addr_result *res = parsed_result;
int ret;
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+
ret = rte_pmd_ixgbe_set_vf_mac_addr(res->port_id, res->vf_id,
&res->mac_addr);
switch (ret) {
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] vhost: optimize vhost memcpy
From: Wang, Zhihong @ 2016-12-07 6:11 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev@dpdk.org, Thomas Monjalon
In-Reply-To: <20161205103709.GL24403@yliu-dev.sh.intel.com>
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Monday, December 5, 2016 6:37 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas.monjalon@6wind.com>
> Subject: Re: [PATCH] vhost: optimize vhost memcpy
>
> On Mon, Dec 05, 2016 at 10:27:00AM +0000, Wang, Zhihong wrote:
> > > I like this function a lot, since it's really simple and straightforward!
> > > Moreover, it performs better.
> > >
> > > But, I don't quite like how this function is proposed:
> > >
> > > - rte_movX are more like internal help functions that should be used only
> > > in corresponding rte_memcpy.h file.
> > >
> > > - It's a good optimization, however, it will not benefit for other use
> > > cases, though vhost is the most typical case here.
> > >
> > > - The optimization proves to be good for X86, but think there is no
> > > guarantee it may behave well for other platforms, say ARM.
> > >
> > > I still would suggest you to go this way: move this function into x86's
> > > rte_memcpy.h and call it when the data is well aligned.
> >
> >
> > Do you mean to add something like rte_memcpy_aligned() in
> > lib/librte_eal/common/include/generic/rte_memcpy.h?
>
> Yes, but this one is not supposed to be exported as a public API.
> It should be called inside rte_memcpy (when data is well aligned).
> In this way, only rte_memcpy is exposed, and nothing else should
> be changed.
Yes I agree this is a better way to introduce this patch, I'll send out v2.
>
> --yliu
> >
> > I thought of this way before, and didn't choose it because it requires
> > changes in eal. But it would be a clean solution, I'd certainly like
> > to implement it this way if people are okay with it.
> >
> >
> > Thanks
> > Zhihong
> >
> >
> > >
> > > --yliu
^ permalink raw reply
* Re: [PATCH 1/8] drivers/common/dpaa2: Run time assembler for Descriptor formation
From: Akhil Goyal @ 2016-12-07 6:24 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, declan.doherty@intel.com,
pablo.de.lara.guarch@intel.com, Hemant Agrawal, Horia Geantă
In-Reply-To: <5589636.gHNnFhEcxp@xps13>
-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Sent: Wednesday, December 07, 2016 1:53 AM
To: Akhil Goyal <akhil.goyal@nxp.com>; Horia Geantă <horia.geanta@nxp.com>
Cc: dev@dpdk.org; declan.doherty@intel.com; pablo.de.lara.guarch@intel.com; Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [PATCH 1/8] drivers/common/dpaa2: Run time assembler for Descriptor formation
2016-12-05 18:25, Akhil Goyal:
> FLib is a library which helps in making the descriptors which is
> understood by NXP's SEC hardware.
> This patch provides header files for command words which can be used
> for descritptor formation.
It seems this code is old. Does it exist as a standalone library somewhere?
Where was it hosted before duplicating it in DPDK?
Why do you want to have a common directory drivers/common/dpaa2/flib instead of a sub-directory in the crypto driver?
[Akhil] This is not really a library. This is a set of header files which is required for compilation. We have 2 other cypto drivers (for different platforms viz: Non-DPAA and DPAA1_QORIQ) which uses the same flib. So we put it in common directory. We plan to send patches for other drivers in the upcoming releases.
^ permalink raw reply
* Re: [PATCH 09/32] lib/ether: add rte_device in rte_eth_dev
From: Hemant Agrawal @ 2016-12-07 6:41 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <dcc47c4e-7388-bd61-2d67-0376270e8693@intel.com>
On 12/7/2016 1:18 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> lib/librte_ether/rte_ethdev.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
>> index 3c45a1f..6f5673f 100644
>> --- a/lib/librte_ether/rte_ethdev.h
>> +++ b/lib/librte_ether/rte_ethdev.h
>> @@ -1626,6 +1626,7 @@ 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 */
>> + struct rte_device *device;
>
> I believe this change should not be part of a PMD patchset. This change
> is more generic than the PMD.
>
> Won't Shreyansh's patch already do this?
I agree that this patch is not a fit for this PMD patchset, Shreyansh's
patch is not yet doing it. He will be taking care of it next.
So till Shreyansh provide the support, we need it.
>
>> 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 */
>>
>
>
^ permalink raw reply
* Re: [PATCH 10/32] net/dpaa2: introducing dpaa2 bus driver for fsl-mc bus
From: Hemant Agrawal @ 2016-12-07 6:57 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <5858af6b-8fba-02f0-9a1d-0210ef113920@intel.com>
On 12/7/2016 1:19 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>> The DPAA2 bus driver is a rte_bus driver which scans the fsl-mc bus.
>>
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> drivers/net/Makefile | 2 +-
>> drivers/net/dpaa2/Makefile | 60 ++++++++++++++
>> drivers/net/dpaa2/dpaa2_bus.c | 99 +++++++++++++++++++++++
>> drivers/net/dpaa2/rte_dpaa2.h | 121 ++++++++++++++++++++++++++++
>> drivers/net/dpaa2/rte_pmd_dpaa2_version.map | 4 +
>> mk/rte.app.mk | 1 +
>> 6 files changed, 286 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/net/dpaa2/Makefile
>> create mode 100644 drivers/net/dpaa2/dpaa2_bus.c
>> create mode 100644 drivers/net/dpaa2/rte_dpaa2.h
>> create mode 100644 drivers/net/dpaa2/rte_pmd_dpaa2_version.map
>>
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
>> index bc93230..2bcf67b 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -55,7 +55,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD) += thunderx
>> DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
>> DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
>> DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
>> -
>> +DIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += dpaa2
>
> Add as alphabetically sorted manner please.
>
>> ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
>> DIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += vhost
>> endif # $(CONFIG_RTE_LIBRTE_VHOST)
>> diff --git a/drivers/net/dpaa2/Makefile b/drivers/net/dpaa2/Makefile
>> new file mode 100644
>> index 0000000..a99ce22
>> --- /dev/null
>> +++ b/drivers/net/dpaa2/Makefile
>> @@ -0,0 +1,60 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright (c) 2016 NXP. 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 NXP nor the names of its
>> +# contributors may be used to endorse or promote products derived
>> +# from this software without specific prior written permission.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> +
>> +include $(RTE_SDK)/mk/rte.vars.mk
>> +
>> +#
>> +# library name
>> +#
>> +LIB = librte_pmd_dpaa2.a
>> +
>> +CFLAGS += -O3
>> +CFLAGS += $(WERROR_FLAGS)
>> +
>> +CFLAGS += -I$(RTE_SDK)/drivers/net/dpaa2
>> +CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/
>> +CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal
>
> Last two shouldn't be required.
>
>> +
>> +# versioning export map
>> +EXPORT_MAP := rte_pmd_dpaa2_version.map
>> +
>> +# library version
>> +LIBABIVER := 1
>> +
>> +
>> +# Interfaces with DPDK
>> +SRCS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += dpaa2_bus.c
>> +
>> +# library dependencies
>> +DEPDIRS-y += lib/librte_eal
>> +DEPDIRS-y += drivers/common/dpaa/mc
>> +DEPDIRS-y += drivers/common/dpaa/qbman
>
> Again for consistency, DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) +=
>
agree, will fix it in v2
>> +
>> +include $(RTE_SDK)/mk/rte.lib.mk
>> diff --git a/drivers/net/dpaa2/dpaa2_bus.c b/drivers/net/dpaa2/dpaa2_bus.c
>> new file mode 100644
>> index 0000000..571066c
>> --- /dev/null
>> +++ b/drivers/net/dpaa2/dpaa2_bus.c
>> @@ -0,0 +1,99 @@
>> +/*-
>> + * BSD LICENSE
>> + *
>> + * Copyright (c) 2016 NXP. 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 NXP 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 <string.h>
>> +#include <dirent.h>
>> +
>> +#include <rte_log.h>
>> +#include <rte_bus.h>
>> +#include <rte_dpaa2.h>
>> +#include <rte_eal_memconfig.h>
>> +#include <rte_malloc.h>
>> +#include <rte_devargs.h>
>> +#include <rte_memcpy.h>
>> +#include <rte_ethdev.h>
>> +
>> +#include "eal_filesystem.h"
>> +#include "eal_private.h"
>> +
>> +void
>> +rte_dpaa2_register(struct rte_dpaa2_driver *driver)
>> +{
>> + struct rte_bus *bus;
>> +
>> + bus = rte_eal_get_bus("dpaa2");
>> + if (!bus) {
>> + RTE_LOG(ERR, EAL, "DPAA2 bus not registered\n");
>> + return;
>> + }
>> +
>> + rte_eal_bus_add_driver(bus, &driver->driver);
>> +}
>> +
>> +void
>> +rte_dpaa2_unregister(struct rte_dpaa2_driver *driver)
>> +{
>> + struct rte_bus *bus;
>> +
>> + bus = driver->driver.bus;
>> + if (!bus) {
>> + RTE_LOG(ERR, EAL, "Unable to find bus for device\n");
>> + return;
>> + }
>> +
>> + rte_eal_bus_remove_driver(&driver->driver);
>> +}
>> +
>> +int rte_dpaa2_probe(struct rte_driver *driver __rte_unused,
>> + struct rte_device *device __rte_unused)
>> +{
>> + return 0;
>> +}
>> +
>> +int rte_dpaa2_scan(struct rte_bus *bus_d __rte_unused)
>> +{
>> + return 0;
>> +}
>> +
>> +int rte_dpaa2_match(struct rte_driver *driver __rte_unused,
>> + struct rte_device *device __rte_unused)
>> +{
>> + return 0;
>> +}
>> +
>> +struct rte_bus dpaa2_bus = {
>> + .scan = rte_dpaa2_scan,
>> + .match = rte_dpaa2_match,
>> + .probe = rte_dpaa2_probe,
>> +};
>> +
>> +RTE_REGISTER_BUS(dpaa2, dpaa2_bus);
>> diff --git a/drivers/net/dpaa2/rte_dpaa2.h b/drivers/net/dpaa2/rte_dpaa2.h
>> new file mode 100644
>> index 0000000..b36eed8
>> --- /dev/null
>> +++ b/drivers/net/dpaa2/rte_dpaa2.h
>> @@ -0,0 +1,121 @@
>> +/*-
>> + * BSD LICENSE
>> + *
>> + * Copyright (c) 2016 NXP. 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 NXP 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_DPAA2_H_
>> +#define _RTE_DPAA2_H_
>> +
>> +/**
>> + * @file
>> + *
>> + * RTE DPAA2 Interface
>> + */
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <limits.h>
>> +#include <errno.h>
>> +#include <sys/queue.h>
>> +#include <stdint.h>
>> +#include <inttypes.h>
>> +
>> +#include <rte_debug.h>
>> +#include <rte_interrupts.h>
>> +#include <rte_dev.h>
>> +
>> +
>> +struct rte_dpaa2_driver;
>> +/**
>> + * A structure describing a DPAA2 device.
>> + */
>> +struct rte_dpaa2_device {
>> + TAILQ_ENTRY(rte_dpaa2_device) next; /**< Next probed DPAA2 device. */
>> + struct rte_device device; /**< Inherit core device */
>> + uint16_t dev_type; /**< Device Type */
>> + uint16_t object_id; /**< DPAA2 Object ID */
>> + struct rte_intr_handle intr_handle; /**< Interrupt handle */
>> + struct rte_dpaa2_driver *driver; /**< Associated driver */
>> +};
>> +
>> +/**
>> + * A structure describing a DPAA2 driver.
>> + */
>> +struct rte_dpaa2_driver {
>> + TAILQ_ENTRY(rte_dpaa2_driver) next; /**< Next in list. */
>> + struct rte_driver driver; /**< Inherit core driver. */
>> + uint32_t drv_flags; /**< Flags contolling handling of device. */
>> +};
>> +
>> +/**
>> + * Register a DPAA2 driver.
>> + *
>> + * @param driver
>> + * A pointer to a rte_dpaa2_driver structure describing the driver
>> + * to be registered.
>> + */
>> +void rte_dpaa2_register(struct rte_dpaa2_driver *driver);
>> +
>> +/**
>> + * Unregister a DPAA2 driver.
>> + *
>> + * @param driver
>> + * A pointer to a rte_dpaa2_driver structure describing the driver
>> + * to be unregistered.
>> + */
>> +void rte_dpaa2_unregister(struct rte_dpaa2_driver *driver);
>> +
>> +/**
>> + *
>> + */
>> +int rte_dpaa2_probe(struct rte_driver *driver, struct rte_device *device);
>> +int rte_dpaa2_match(struct rte_driver *driver, struct rte_device *device);
>> +int rte_dpaa2_scan(struct rte_bus *bus);
>
> Shouldn't these functions be static?
agree, will fix it in v2
>
>> +
>> +/** Helper for DPAA2 device registration from driver (eth, crypto) instance */
>> +#define RTE_PMD_REGISTER_DPAA2(nm, dpaa2_drv) \
>> +RTE_INIT(dpaa2initfn_ ##nm); \
>> +static void dpaa2initfn_ ##nm(void) \
>> +{\
>> + (dpaa2_drv).driver.name = RTE_STR(nm);\
>> + rte_dpaa2_register(&dpaa2_drv); \
>> +} \
>> +RTE_PMD_EXPORT_NAME(nm, __COUNTER__)
>> +
>> +
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +
>> +#endif /* _RTE_DPAA2_H_ */
>> diff --git a/drivers/net/dpaa2/rte_pmd_dpaa2_version.map b/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
>> new file mode 100644
>> index 0000000..31eca32
>> --- /dev/null
>> +++ b/drivers/net/dpaa2/rte_pmd_dpaa2_version.map
>> @@ -0,0 +1,4 @@
>> +DPDK_17.02 {
>> +
>> + local: *;
>> +};
>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>> index f75f0e2..9e1c17c 100644
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -101,6 +101,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
>>
>> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += -lrte_pmd_bond
>> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += -lrte_pmd_xenvirt -lxenstore
>> +_LDLIBS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += -lrte_pmd_dpaa2 -ldpaa2_mc -ldpaa2_qbman
>
> This should go within no shared library case (below), in a sorted manner
> please.
>
ok, will fix it in v2
> btw, for shared compilation, PMDs loaded dynamically, as plugins. For
> dpaa case, there will be multiple libraries, not if it will work with
> multiple -d params for each lib, it worth testing.
>
I will look into it.
>>
>> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
>> # plugins (link only if static libraries)
>>
>
>
^ permalink raw reply
* Re: [PATCH 11/32] net/dpaa2: add dpaa2 vfio support
From: Hemant Agrawal @ 2016-12-07 7:00 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, bruce.richardson, shreyansh.jain
In-Reply-To: <4516168.6vIN5TbTdY@xps13>
On 12/7/2016 2:34 AM, Thomas Monjalon wrote:
> 2016-12-04 23:47, Hemant Agrawal:
>> Add support for using VFIO for dpaa2 based fsl-mc bus.
>
> Why do we need so much special code for interfacing VFIO on fsl-mc?
> Can you reuse some code from EAL VFIO?
>
fsl-mc VFIO scans the objects. So, it is slightly different.
Even though I have tried to minimize changes and re-use the code from
EAL VFIO. It is still refactoring work, which we will take up little later.
^ permalink raw reply
* Re: [PATCH] vhost: allow for many vhost user ports
From: Yuanhan Liu @ 2016-12-07 7:43 UTC (permalink / raw)
To: Jan Wickbom; +Cc: huawei.xie@intel.com, dev@dpdk.org, Patrik Andersson R
In-Reply-To: <AM4PR0701MB214617221B10D1390754E5F194820@AM4PR0701MB2146.eurprd07.prod.outlook.com>
On Tue, Dec 06, 2016 at 11:42:36AM +0000, Jan Wickbom wrote:
> > > @@ -189,7 +206,7 @@
> > > pfdset->fd[i].fd = -1;
> > > pfdset->fd[i].rcb = pfdset-
> > >fd[i].wcb = NULL;
> > > pfdset->fd[i].dat = NULL;
> > > - pfdset->num--;
> > > + (void) fdset_adjust_num(pfdset);
> >
> > Unncessary cast.
>
> I'd like to keep the cast. The function returns int and it's nice to show we deliberately
> don't care.
I know your point, but it's not needed.
> No strong opinion though, but we should do the same everywhere. Please
> see below.
>
> >
> > > i = -1;
> > > }
> > > pthread_mutex_unlock(&pfdset->fd_mutex);
> > > @@ -211,12 +228,12 @@
> > >
> > > pfdset->fd[index].fd = -1;
> > > pfdset->fd[index].rcb = pfdset->fd[index].wcb = NULL;
> > > - pfdset->fd[index].dat = NULL;
> > > - pfdset->num--;
> > > + (void) fdset_adjust_num(pfdset);
>
> If we remove the cast above, we should remove this one as well.
Yes.
--yliu
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Andrew Rybchenko @ 2016-12-07 7:55 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon, dev, Jan Medala, Jakub Palider,
Netanel Belgazal, Evgeny Schemeilin, Alejandro Lucero,
Yuanhan Liu, Yong Wang, Hemant Agrawal
Cc: Tomasz Kulasek, konstantin.ananyev
In-Reply-To: <2dfc10d2-bb19-1385-aa01-97e44a3db139@intel.com>
On 12/06/2016 06:53 PM, Ferruh Yigit wrote:
> On 11/28/2016 11:03 AM, Thomas Monjalon wrote:
>> We need attention of every PMD developers on this thread.
>>
>> Reminder of what Konstantin suggested:
>> "
>> - if the PMD supports TX offloads AND
>> - if to be able use any of these offloads the upper layer SW would have to:
>> * modify the contents of the packet OR
>> * obey HW specific restrictions
>> then it is a PMD developer responsibility to provide tx_prep() that would implement
>> expected modifications of the packet contents and restriction checks.
>> Otherwise, tx_prep() implementation is not required and can be safely set to NULL.
>> "
>>
>> I copy/paste also my previous conclusion:
>>
>> Before txprep, there is only one API: the application must prepare the
>> packets checksum itself (get_psd_sum in testpmd).
>> With txprep, the application have 2 choices: keep doing the job itself
>> or call txprep which calls a PMD-specific function.
>> The question is: does non-Intel drivers need a checksum preparation for TSO?
>> Will it behave well if txprep does nothing in these drivers?
>>
>> When looking at the code, most of drivers handle the TSO flags.
>> But it is hard to know whether they rely on the pseudo checksum or not.
>>
>> git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' drivers/net/
>>
>> drivers/net/bnxt/bnxt_txr.c
>> drivers/net/cxgbe/sge.c
>> drivers/net/e1000/em_rxtx.c
>> drivers/net/e1000/igb_rxtx.c
>> drivers/net/ena/ena_ethdev.c
>> drivers/net/enic/enic_rxtx.c
>> drivers/net/fm10k/fm10k_rxtx.c
>> drivers/net/i40e/i40e_rxtx.c
>> drivers/net/ixgbe/ixgbe_rxtx.c
>> drivers/net/mlx4/mlx4.c
>> drivers/net/mlx5/mlx5_rxtx.c
>> drivers/net/nfp/nfp_net.c
>> drivers/net/qede/qede_rxtx.c
>> drivers/net/thunderx/nicvf_rxtx.c
>> drivers/net/virtio/virtio_rxtx.c
>> drivers/net/vmxnet3/vmxnet3_rxtx.c
>>
>> Please, we need a comment for each driver saying
>> "it is OK, we do not need any checksum preparation for TSO"
>> or
>> "yes we have to implement tx_prepare or TSO will not work in this mode"
>>
> Still waiting response from PMDs:
> - ena
> - nfp
> - virtio
>
> Waiting clarification for preparation requirements:
> - vmxnet3
>
> Also including new PMDs to the thread:
> - sfc
The patch which adds TSO support is
http://dpdk.org/dev/patchwork/patch/17417/
We use l2/l3/l4 header length. We do NOT use prepared pseudo header
checksum and
HW does NOT need it.
Andrew.
> - dpaa2
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Yuanhan Liu @ 2016-12-07 8:11 UTC (permalink / raw)
To: Ferruh Yigit, Olivier Matz
Cc: Thomas Monjalon, dev, Jan Medala, Jakub Palider, Netanel Belgazal,
Evgeny Schemeilin, Alejandro Lucero, Yong Wang, Andrew Rybchenko,
Hemant Agrawal, Tomasz Kulasek, konstantin.ananyev
In-Reply-To: <2dfc10d2-bb19-1385-aa01-97e44a3db139@intel.com>
On Tue, Dec 06, 2016 at 03:53:42PM +0000, Ferruh Yigit wrote:
> > Please, we need a comment for each driver saying
> > "it is OK, we do not need any checksum preparation for TSO"
> > or
> > "yes we have to implement tx_prepare or TSO will not work in this mode"
> >
Sorry for late. For virtio, I think it's not a must. The checksum stuff
has been handled inside the Tx function. However, we may could move it
to tx_prepare, which would actually recover the performance lost
introduced while enabling TSO for the non-TSO case.
--yliu
^ permalink raw reply
* Does DPDK 1.7.1 support jumboframes for VMXNET3
From: Kanika Singhal @ 2016-12-07 8:18 UTC (permalink / raw)
To: dev
Hi,
I am a new to DPDK.
My product is using DPDK 1.6 and it does not support jumbo frames for
VMXNET3.
I have to upgrade to 1.7.1, but i am not able to find info on whether the
jumbo frame support is being added for VMXNET3 or not.
I can see some jumbo frame related patches being posted for vmxnet3
Do I need to apply the patches in 1.7.1 to make jumbo work/Is there any
DPDK version which supports jumbo?
Thanks,
Kanika
^ permalink raw reply
* Re: [PATCH 1/8] drivers/common/dpaa2: Run time assembler for Descriptor formation
From: Thomas Monjalon @ 2016-12-07 8:33 UTC (permalink / raw)
To: Akhil Goyal
Cc: dev, declan.doherty, pablo.de.lara.guarch, Hemant Agrawal,
Horia Geantă
In-Reply-To: <DB5PR0401MB17681276E03FC9DD87C16FB9E6850@DB5PR0401MB1768.eurprd04.prod.outlook.com>
2016-12-07 06:24, Akhil Goyal:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> 2016-12-05 18:25, Akhil Goyal:
> > FLib is a library which helps in making the descriptors which is
> > understood by NXP's SEC hardware.
> > This patch provides header files for command words which can be used
> > for descritptor formation.
>
> It seems this code is old. Does it exist as a standalone library somewhere?
> Where was it hosted before duplicating it in DPDK?
>
> Why do you want to have a common directory drivers/common/dpaa2/flib instead of a sub-directory in the crypto driver?
>
> [Akhil] This is not really a library. This is a set of header files which is required for compilation. We have 2 other cypto drivers (for different platforms viz: Non-DPAA and DPAA1_QORIQ) which uses the same flib. So we put it in common directory. We plan to send patches for other drivers in the upcoming releases.
Please Akhil, could you answer to the three questions?
^ permalink raw reply
* Re: [PATCH 11/32] net/dpaa2: add dpaa2 vfio support
From: Thomas Monjalon @ 2016-12-07 8:38 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: dev, bruce.richardson, shreyansh.jain
In-Reply-To: <b0db98e6-793a-b2d5-02bb-3d0a9fc5f30e@nxp.com>
2016-12-07 12:30, Hemant Agrawal:
> On 12/7/2016 2:34 AM, Thomas Monjalon wrote:
> > 2016-12-04 23:47, Hemant Agrawal:
> >> Add support for using VFIO for dpaa2 based fsl-mc bus.
> >
> > Why do we need so much special code for interfacing VFIO on fsl-mc?
> > Can you reuse some code from EAL VFIO?
> >
>
> fsl-mc VFIO scans the objects. So, it is slightly different.
>
> Even though I have tried to minimize changes and re-use the code from
> EAL VFIO. It is still refactoring work, which we will take up little later.
Do you mean you could re-use some EAL code but do not want to do it now?
It sounds like something heard too many times earlier (from others).
The experience tells we must not wait to do things right.
^ permalink raw reply
* [PATCH v2] eal: optimize aligned rte_memcpy
From: Zhihong Wang @ 2016-12-07 1:31 UTC (permalink / raw)
To: dev; +Cc: yuanhan.liu, thomas.monjalon, lei.a.yao, Zhihong Wang
In-Reply-To: <1480641582-56186-1-git-send-email-zhihong.wang@intel.com>
This patch optimizes rte_memcpy for well aligned cases, where both
dst and src addr are aligned to maximum MOV width. It introduces a
dedicated function called rte_memcpy_aligned to handle the aligned
cases with simplified instruction stream. The existing rte_memcpy
is renamed as rte_memcpy_generic. The selection between them 2 is
done at the entry of rte_memcpy.
The existing rte_memcpy is for generic cases, it handles unaligned
copies and make store aligned, it even makes load aligned for micro
architectures like Ivy Bridge. However alignment handling comes at
a price: It adds extra load/store instructions, which can cause
complications sometime.
DPDK Vhost memcpy with Mergeable Rx Buffer feature as an example:
The copy is aligned, and remote, and there is header write along
which is also remote. In this case the memcpy instruction stream
should be simplified, to reduce extra load/store, therefore reduce
the probability of load/store buffer full caused pipeline stall, to
let the actual memcpy instructions be issued and let H/W prefetcher
goes to work as early as possible.
This patch is tested on Ivy Bridge, Haswell and Skylake, it provides
up to 20% gain for Virtio Vhost PVP traffic, with packet size ranging
from 64 to 1500 bytes.
The test can also be conducted without NIC, by setting loopback
traffic between Virtio and Vhost. For example, modify the macro
TXONLY_DEF_PACKET_LEN to the requested packet size in testpmd.h,
rebuild and start testpmd in both host and guest, then "start" on
one side and "start tx_first 32" on the other.
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
---
.../common/include/arch/x86/rte_memcpy.h | 81 +++++++++++++++++++++-
1 file changed, 78 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
index b3bfc23..b9785e8 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
@@ -69,6 +69,8 @@ rte_memcpy(void *dst, const void *src, size_t n) __attribute__((always_inline));
#ifdef RTE_MACHINE_CPUFLAG_AVX512F
+#define ALIGNMENT_MASK 0x3F
+
/**
* AVX512 implementation below
*/
@@ -189,7 +191,7 @@ rte_mov512blocks(uint8_t *dst, const uint8_t *src, size_t n)
}
static inline void *
-rte_memcpy(void *dst, const void *src, size_t n)
+rte_memcpy_generic(void *dst, const void *src, size_t n)
{
uintptr_t dstu = (uintptr_t)dst;
uintptr_t srcu = (uintptr_t)src;
@@ -308,6 +310,8 @@ COPY_BLOCK_128_BACK63:
#elif defined RTE_MACHINE_CPUFLAG_AVX2
+#define ALIGNMENT_MASK 0x1F
+
/**
* AVX2 implementation below
*/
@@ -387,7 +391,7 @@ rte_mov128blocks(uint8_t *dst, const uint8_t *src, size_t n)
}
static inline void *
-rte_memcpy(void *dst, const void *src, size_t n)
+rte_memcpy_generic(void *dst, const void *src, size_t n)
{
uintptr_t dstu = (uintptr_t)dst;
uintptr_t srcu = (uintptr_t)src;
@@ -499,6 +503,8 @@ COPY_BLOCK_128_BACK31:
#else /* RTE_MACHINE_CPUFLAG */
+#define ALIGNMENT_MASK 0x0F
+
/**
* SSE & AVX implementation below
*/
@@ -677,7 +683,7 @@ __extension__ ({ \
})
static inline void *
-rte_memcpy(void *dst, const void *src, size_t n)
+rte_memcpy_generic(void *dst, const void *src, size_t n)
{
__m128i xmm0, xmm1, xmm2, xmm3, xmm4, xmm5, xmm6, xmm7, xmm8;
uintptr_t dstu = (uintptr_t)dst;
@@ -821,6 +827,75 @@ COPY_BLOCK_64_BACK15:
#endif /* RTE_MACHINE_CPUFLAG */
+static inline void *
+rte_memcpy_aligned(void *dst, const void *src, size_t n)
+{
+ void *ret = dst;
+
+ /* Copy size <= 16 bytes */
+ if (n < 16) {
+ if (n & 0x01) {
+ *(uint8_t *)dst = *(const uint8_t *)src;
+ src = (const uint8_t *)src + 1;
+ dst = (uint8_t *)dst + 1;
+ }
+ if (n & 0x02) {
+ *(uint16_t *)dst = *(const uint16_t *)src;
+ src = (const uint16_t *)src + 1;
+ dst = (uint16_t *)dst + 1;
+ }
+ if (n & 0x04) {
+ *(uint32_t *)dst = *(const uint32_t *)src;
+ src = (const uint32_t *)src + 1;
+ dst = (uint32_t *)dst + 1;
+ }
+ if (n & 0x08)
+ *(uint64_t *)dst = *(const uint64_t *)src;
+
+ return ret;
+ }
+
+ /* Copy 16 <= size <= 32 bytes */
+ if (n <= 32) {
+ rte_mov16((uint8_t *)dst, (const uint8_t *)src);
+ rte_mov16((uint8_t *)dst - 16 + n,
+ (const uint8_t *)src - 16 + n);
+
+ return ret;
+ }
+
+ /* Copy 32 < size <= 64 bytes */
+ if (n <= 64) {
+ rte_mov32((uint8_t *)dst, (const uint8_t *)src);
+ rte_mov32((uint8_t *)dst - 32 + n,
+ (const uint8_t *)src - 32 + n);
+
+ return ret;
+ }
+
+ /* Copy 64 bytes blocks */
+ for (; n >= 64; n -= 64) {
+ rte_mov64((uint8_t *)dst, (const uint8_t *)src);
+ dst = (uint8_t *)dst + 64;
+ src = (const uint8_t *)src + 64;
+ }
+
+ /* Copy whatever left */
+ rte_mov64((uint8_t *)dst - 64 + n,
+ (const uint8_t *)src - 64 + n);
+
+ return ret;
+}
+
+static inline void *
+rte_memcpy(void *dst, const void *src, size_t n)
+{
+ if (!(((uintptr_t)dst | (uintptr_t)src) & ALIGNMENT_MASK))
+ return rte_memcpy_aligned(dst, src, n);
+ else
+ return rte_memcpy_generic(dst, src, n);
+}
+
#ifdef __cplusplus
}
#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/4] eal/common: introduce rte_memset and related test
From: Yang, Zhiyong @ 2016-12-07 9:28 UTC (permalink / raw)
To: Maxime Coquelin, dev@dpdk.org
Cc: yuanhan.liu@linux.intel.com, Richardson, Bruce,
Ananyev, Konstantin, Pierre Pfister (ppfister)
In-Reply-To: <e354fc0a-14b5-0f59-d95b-7b8fd6f47b7a@redhat.com>
Hi, Maxime:
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Tuesday, December 6, 2016 4:30 PM
> To: Yang, Zhiyong <zhiyong.yang@intel.com>; dev@dpdk.org
> Cc: yuanhan.liu@linux.intel.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Pierre Pfister (ppfister)
> <ppfister@cisco.com>
> Subject: Re: [dpdk-dev] [PATCH 0/4] eal/common: introduce rte_memset
> and related test
>
>
>
> On 12/06/2016 07:33 AM, Yang, Zhiyong wrote:
> > Hi， Maxime:
> >
> >> -----Original Message-----
> >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> >> Sent: Friday, December 2, 2016 6:01 PM
> >> To: Yang, Zhiyong <zhiyong.yang@intel.com>; dev@dpdk.org
> >> Cc: yuanhan.liu@linux.intel.com; Richardson, Bruce
> >> <bruce.richardson@intel.com>; Ananyev, Konstantin
> >> <konstantin.ananyev@intel.com>
> >> Subject: Re: [dpdk-dev] [PATCH 0/4] eal/common: introduce rte_memset
> >> and related test
> >>
> >> Hi Zhiyong,
> >>
> >> On 12/05/2016 09:26 AM, Zhiyong Yang wrote:
> >>> DPDK code has met performance drop badly in some case when calling
> >>> glibc function memset. Reference to discussions about memset in
> >>> http://dpdk.org/ml/archives/dev/2016-October/048628.html
> >>> It is necessary to introduce more high efficient function to fix it.
> >>> One important thing about rte_memset is that we can get clear
> >>> control on what instruction flow is used.
> >>>
> >>> This patchset introduces rte_memset to bring more high efficient
> >>> implementation, and will bring obvious perf improvement, especially
> >>> for small N bytes in the most application scenarios.
> >>>
> >>> Patch 1 implements rte_memset in the file rte_memset.h on IA
> >>> platform The file supports three types of instruction sets including
> >>> sse & avx (128bits), avx2(256bits) and avx512(512bits). rte_memset
> >>> makes use of vectorization and inline function to improve the perf
> >>> on IA. In addition, cache line and memory alignment are fully taken
> >>> into
> >> consideration.
> >>>
> >>> Patch 2 implements functional autotest to validates the function
> >>> whether to work in a right way.
> >>>
> >>> Patch 3 implements performance autotest separately in cache and
> memory.
> >>>
> >>> Patch 4 Using rte_memset instead of copy_virtio_net_hdr can bring
> >>> 3%~4% performance improvements on IA platform from virtio/vhost
> >>> non-mergeable loopback testing.
> >>>
> >>> Zhiyong Yang (4):
> >>> eal/common: introduce rte_memset on IA platform
> >>> app/test: add functional autotest for rte_memset
> >>> app/test: add performance autotest for rte_memset
> >>> lib/librte_vhost: improve vhost perf using rte_memset
> >>>
> >>> app/test/Makefile | 3 +
> >>> app/test/test_memset.c | 158 +++++++++
> >>> app/test/test_memset_perf.c | 348
> +++++++++++++++++++
> >>> doc/guides/rel_notes/release_17_02.rst | 11 +
> >>> .../common/include/arch/x86/rte_memset.h | 376
> >> +++++++++++++++++++++
> >>> lib/librte_eal/common/include/generic/rte_memset.h | 51 +++
> >>> lib/librte_vhost/virtio_net.c | 18 +-
> >>> 7 files changed, 958 insertions(+), 7 deletions(-) create mode
> >>> 100644 app/test/test_memset.c create mode 100644
> >>> app/test/test_memset_perf.c create mode 100644
> >>> lib/librte_eal/common/include/arch/x86/rte_memset.h
> >>> create mode 100644
> >> lib/librte_eal/common/include/generic/rte_memset.h
> >>>
> >>
> >> Thanks for the series, idea looks good to me.
> >>
> >> Wouldn't be worth to also use rte_memset in Virtio PMD (not
> >> compiled/tested)? :
> >>
> >
> > I think rte_memset maybe can bring some benefit here, but , I'm not
> > clear how to enter the branch and test it. :)
>
> Indeed, you will need Pierre's patch:
> [dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set
>
> Thanks,
> Maxime
> >
Thank you Maxime.
I can see a little, but not obviously performance improvement here.
You know, memset(hdr, 0, head_size); only consumes fewer cycles for virtio pmd.
head_size only 10 or 12 bytes.
I optimize rte_memset perf further for N=8~15 bytes.
The main purpose of Introducing rte_memset is that we can use it
to avoid perf drop issue instead of glibc memset on some platform, I think.
> >
> >> diff --git a/drivers/net/virtio/virtio_rxtx.c
> >> b/drivers/net/virtio/virtio_rxtx.c
> >> index 22d97a4..a5f70c4 100644
> >> --- a/drivers/net/virtio/virtio_rxtx.c
> >> +++ b/drivers/net/virtio/virtio_rxtx.c
> >> @@ -287,7 +287,7 @@ virtqueue_enqueue_xmit(struct virtnet_tx *txvq,
> >> struct rte_mbuf *cookie,
> >> rte_pktmbuf_prepend(cookie, head_size);
> >> /* if offload disabled, it is not zeroed below, do it now */
> >> if (offload == 0)
> >> - memset(hdr, 0, head_size);
> >> + rte_memset(hdr, 0, head_size);
> >> } else if (use_indirect) {
> >> /* setup tx ring slot to point to indirect
> >> * descriptor list stored in reserved region.
> >>
> >> Cheers,
> >> Maxime
^ permalink raw reply
* Re: [PATCH 0/4] eal/common: introduce rte_memset and related test
From: Yuanhan Liu @ 2016-12-07 9:37 UTC (permalink / raw)
To: Yang, Zhiyong
Cc: Maxime Coquelin, dev@dpdk.org, Richardson, Bruce,
Ananyev, Konstantin, Pierre Pfister (ppfister)
In-Reply-To: <E182254E98A5DA4EB1E657AC7CB9BD2A3EB4CDD0@BGSMSX101.gar.corp.intel.com>
On Wed, Dec 07, 2016 at 09:28:17AM +0000, Yang, Zhiyong wrote:
> > >> Wouldn't be worth to also use rte_memset in Virtio PMD (not
> > >> compiled/tested)? :
> > >>
> > >
> > > I think rte_memset maybe can bring some benefit here, but , I'm not
> > > clear how to enter the branch and test it. :)
> >
> > Indeed, you will need Pierre's patch:
> > [dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set
I will apply it shortly.
> > Thanks,
> > Maxime
> > >
> Thank you Maxime.
> I can see a little, but not obviously performance improvement here.
Are you you have run into that code piece? FYI, you have to enable
virtio 1.0 explicitly, which is disabled by deafault.
> You know, memset(hdr, 0, head_size); only consumes fewer cycles for virtio pmd.
> head_size only 10 or 12 bytes.
> I optimize rte_memset perf further for N=8~15 bytes.
> The main purpose of Introducing rte_memset is that we can use it
> to avoid perf drop issue instead of glibc memset on some platform, I think.
For this case (as well as the 4th patch), it's more about making sure
rte_memset is inlined.
--yliu
^ permalink raw reply
* Re: [PATCH v2] doc: introduce PVP reference benchmark
From: Yuanhan Liu @ 2016-12-07 9:39 UTC (permalink / raw)
To: Maxime Coquelin
Cc: thomas.monjalon, john.mcnamara, zhiyong.yang, ktraynor, dev
In-Reply-To: <20161206122440.12039-1-maxime.coquelin@redhat.com>
On Tue, Dec 06, 2016 at 01:24:40PM +0100, Maxime Coquelin wrote:
> Having reference benchmarks is important in order to obtain
> reproducible performance figures.
>
> This patch describes required steps to configure a PVP setup
> using testpmd in both host and guest.
>
> Not relying on external vSwitch ease integration in a CI loop by
> not being impacted by DPDK API changes.
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Thanks for the doc!
--yliu
^ permalink raw reply
* Re: [PATCH v2] virtio: tx with can_push when VERSION_1 is set
From: Yuanhan Liu @ 2016-12-07 9:42 UTC (permalink / raw)
To: Pierre Pfister (ppfister); +Cc: dev@dpdk.org, Maxime Coquelin
In-Reply-To: <C1042323-AA70-46AF-B4D2-24A470ED8DB9@cisco.com>
On Wed, Nov 30, 2016 at 09:18:42AM +0000, Pierre Pfister (ppfister) wrote:
> Current virtio driver advertises VERSION_1 support,
> but does not handle device's VERSION_1 support when
> sending packets (it looks for ANY_LAYOUT feature,
> which is absent).
>
> This patch enables 'can_push' in tx path when VERSION_1
> is advertised by the device.
>
> This significantly improves small packets forwarding rate
> towards devices advertising VERSION_1 feature.
>
> Signed-off-by: Pierre Pfister <ppfister@cisco.com>
Applied to dpdk-next-virtio.
Thanks.
--yliu
^ permalink raw reply
* Re: [PATCH 0/4] eal/common: introduce rte_memset and related test
From: Yang, Zhiyong @ 2016-12-07 9:43 UTC (permalink / raw)
To: Yuanhan Liu
Cc: Maxime Coquelin, dev@dpdk.org, Richardson, Bruce,
Ananyev, Konstantin, Pierre Pfister (ppfister)
In-Reply-To: <20161207093742.GF31182@yliu-dev.sh.intel.com>
Hi, yuanhan:
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Wednesday, December 7, 2016 5:38 PM
> To: Yang, Zhiyong <zhiyong.yang@intel.com>
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>; dev@dpdk.org;
> Richardson, Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Pierre Pfister (ppfister)
> <ppfister@cisco.com>
> Subject: Re: [dpdk-dev] [PATCH 0/4] eal/common: introduce rte_memset
> and related test
>
> On Wed, Dec 07, 2016 at 09:28:17AM +0000, Yang, Zhiyong wrote:
> > > >> Wouldn't be worth to also use rte_memset in Virtio PMD (not
> > > >> compiled/tested)? :
> > > >>
> > > >
> > > > I think rte_memset maybe can bring some benefit here, but , I'm
> > > > not clear how to enter the branch and test it. :)
> > >
> > > Indeed, you will need Pierre's patch:
> > > [dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set
>
> I will apply it shortly.
>
> > > Thanks,
> > > Maxime
> > > >
> > Thank you Maxime.
> > I can see a little, but not obviously performance improvement here.
>
> Are you you have run into that code piece? FYI, you have to enable virtio 1.0
> explicitly, which is disabled by deafault.
Yes. I use the patch from Pierre and set offload = 0 ;
Thanks
Zhiyong
>
> > You know, memset(hdr, 0, head_size); only consumes fewer cycles for
> virtio pmd.
> > head_size only 10 or 12 bytes.
> > I optimize rte_memset perf further for N=8~15 bytes.
> > The main purpose of Introducing rte_memset is that we can use it to
> > avoid perf drop issue instead of glibc memset on some platform, I think.
>
> For this case (as well as the 4th patch), it's more about making sure
> rte_memset is inlined.
>
> --yliu
^ permalink raw reply
* Re: [PATCH 0/4] eal/common: introduce rte_memset and related test
From: Yuanhan Liu @ 2016-12-07 9:48 UTC (permalink / raw)
To: Yang, Zhiyong
Cc: Maxime Coquelin, dev@dpdk.org, Richardson, Bruce,
Ananyev, Konstantin, Pierre Pfister (ppfister)
In-Reply-To: <E182254E98A5DA4EB1E657AC7CB9BD2A3EB4CE07@BGSMSX101.gar.corp.intel.com>
On Wed, Dec 07, 2016 at 09:43:06AM +0000, Yang, Zhiyong wrote:
> > On Wed, Dec 07, 2016 at 09:28:17AM +0000, Yang, Zhiyong wrote:
> > > > >> Wouldn't be worth to also use rte_memset in Virtio PMD (not
> > > > >> compiled/tested)? :
> > > > >>
> > > > >
> > > > > I think rte_memset maybe can bring some benefit here, but , I'm
> > > > > not clear how to enter the branch and test it. :)
> > > >
> > > > Indeed, you will need Pierre's patch:
> > > > [dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set
> >
> > I will apply it shortly.
> >
> > > > Thanks,
> > > > Maxime
> > > > >
> > > Thank you Maxime.
> > > I can see a little, but not obviously performance improvement here.
> >
> > Are you you have run into that code piece? FYI, you have to enable virtio 1.0
> > explicitly, which is disabled by deafault.
>
> Yes. I use the patch from Pierre and set offload = 0 ;
I meant virtio 1.0. Have you added following options for the QEMU virtio-net
device?
disable-modern=false
--yliu
^ permalink raw reply
* Re: [PATCH 00/13] Introducing EAL Bus-Device-Driver Model
From: Shreyansh Jain @ 2016-12-07 9:55 UTC (permalink / raw)
To: David Marchand; +Cc: dev@dpdk.org, Thomas Monjalon
In-Reply-To: <CALwxeUtqnNpm=KuR3Qtb2PNUghAc=e9TKQqm4Uh8pvgZ4EmriA@mail.gmail.com>
Hello David,
On Wednesday 07 December 2016 02:22 AM, David Marchand wrote:
> "Big patchset and a lot of things to look at.
>
> Here is a first look at it.
Thanks for comments.
>
> On Sun, Dec 4, 2016 at 11:11 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> In continuation to the RFC posted on 17/Nov [9],
>> A series of patches is being posted which attempts to create:
>> 1. A basic bus model
>> `- define rte_bus and associated methods/helpers
>> `- test infrastructure to test the Bus infra
>> 2. Changes in EAL to support PCI as a bus
>> `- a "pci" bus is registered
>> `- existing scan/match/probe are modified to allow for bus integration
>> `- PCI Device and Driver list, which were global entities, have been
>> moved to rte_bus->[device/driver]_list
>>
>> I have sanity tested this patch over a XeonD X552 available with me, as
>> well as part of PoC for verifying NXP's DPAA2 PMD (being pushed out in a
>> separate series). Exhaustive testing is still pending.
>
> I saw some checkpatch issues for patch 1 (I would ignore this one) and
> 4 (please check).
Yes, for Patch 1 I too ignored the warnings.
For Patch 4, there are 3 warnings, of which first 2 were reported by
checkpatch tool before I sent out. Surprisingly, I didn't see the third
one when I ran the tool in my environment.
I will fix them (those which I can) in v2.
>
>
>> :: Brief about Patch Layout ::
>>
>> 0001: Container_of patch from [3]
>
>> 0002~0003: Introducing the basic Bus model and associated test case
>> 0005: Support insertion of device rather than addition to tail
>
> Patch 2 and 5 could be squashed.
I deliberately kept them separate. I intent to extend the Patch 5 for
hotplugging. But, if I don't end up adding support for that in this
series, I will merge these two.
> The constructor priority stuff seems unneeded as long as we use
> explicit reference to a global (or local, did not check) bus symbol
> rather than a runtime lookup.
I didn't understand your point here.
IMO, constructor priority (or some other way to handle this) is
important. I faced this issue while verifying it at my end when the
drivers were getting registered before the bus.
Can you elaborate more on '..use explicit reference to a global...'?
>
>
>> 0004: Add scan and match callbacks for the Bus and updated test case
>
> Why do you push back the bus object in the 'scan' method ?
> This method is bus specific which means that the code "knows" the
> object registered with the callback.
This 'knows' is the grey area for me.
The bus (for example, PCI) after scanning needs to call
rte_eal_bus_add_device() to link the device in bus's device_list.
Two options:
1. Have a global reference to "pci" bus (rte_bus) somewhere in eal_pci.c
2. Call rte_eal_get_bus() every time someone needs the reference.
3. C++ style, 'this->'.
I have taken the 3rd path. It simplifies my code to not assume a handle
as well as not allow for reference fetch calls every now and then.
As a disadvantage: it means passing this as argument - and some cases
maintaining it as __rte_unused.
Taking (1) or (2) is not advantageous than this approach.
> Is is that you want to have a single scan method used by multiple buses ?
Yes, but only as a use case. For example, platform devices are of
various types - what if we have a south-bound bus over a platform bus.
In which case, a hierarchical bus layout is possible.
But, this is far-fetched idea for now.
>
>
>> 0006: Integrate bus scan/match with EAL, without any effective driver
>
> Hard to find a right balance in patch splittng, but patch 4 and 6 are
> linked, I would squash them into one.
Yes, it is hard and sometimes there is simply no strong rationale for
splitting or merging. This is one of those cases.
My idea was that one patch _only_ introduces Bus services (structures,
functions etc) and another should enable the calls to it from EAL.
In that sense, I still think 4 and 6 should remain separate, may be
consecutive, though.
>
>
>> 0007: rte_pci_driver->probe replaced with rte_driver->probe
>
> This patch is too big, please separate in two patches: eal changes
> then ethdev/driver changes.
I don't think that can be done. One change is incomplete without the other.
Changes to all files are only for rte_pci_driver->probe to
rte_driver->probe movement. EAL changes is to allow
rte_eth_dev_pci_probe function after such a change as rte_driver->probe
has different arguments as compared to rte_pci_driver->probe. The
patches won't compile if I split.
Am I missing something?
> I almost missed that mlx4 has been broken : you moved the drv_flags
> from the mlx4 pci driver to rte_driver.
Oh! This is indeed my mistake. I will fix this right away.
>
> Why do you push back the driver object in the 'probe' method ? (idem
> rte_bus->scan).
I am assuming you are referring to rte_driver->probe().
This is being done so that implementations (specific to drivers on a
particular bus) can start extracting the rte_xxx_driver, if need be.
For example, for e1000/em_ethdev.c, rte_driver->probe() have been set to
rte_eth_dev_pci_probe() which requires rte_pci_driver to work with. In
absence of the rte_driver object, this function cannot call
rte_pci_driver->probe (for example) for driver specific operations.
>
>
>> 0008: Integrate probe of drivers with EAL
>
> This patch does nothing about "remove" while its title talks about it.
Yes, that is a mistake on my part. I will fix this.
>
> + What about hotplug code ? I suppose this is for later.
I am still working on it. Maybe, with the current set, if there is some
agreement over the overall changes, I would be more confident on this
next level of changes.
>
>
>> 0009: Split the existing PCI probe into match and probe
>
> You don't need to expose rte_eal_pci_match_default() (and I am not
> sure what the "default" means here).
> This method should be internal to the pci bus object ?
1) Yes, rte_eal_pci_match_default isn't really a 'default' I will remove
that.
2) Yes, there is no need to expose it.
One trivial reason I took this liberty was so that I can put my
implementation for PCI bus in ${RTE_SDK}/drivers/bus/pci/* rather than
current ${RTE_SDK}/lib/librte_eal/linuxapp/eal_pci.c
And similarly if there are other PCI-like implementations which would
like to have their own bus rather than using PCI bus.
But, I can remove this (from Map as well)
>
>
>> 0010: Make PCI probe/match work on rte_driver/device rather than
>> rte_pci_device/rte_pci_driver
>> 0011: Patch from Ben [8], part of series [2]
>
>
>> 0012~0013: Enable Scan/Match/probe on Bus from EAL and remove unused
>> functions and lists
>
> Same thing as earlier in the series, you don't need to check for the bus object.
> The pci bus code can't be called if the bus was not registered and
> consequently, you are sure that the pci bus object is the pci_bus
> symbol.
Hm. Ok. I will remove this.
I was doing this for two reasons 1) somehow I found drivers getting
registered *before* bus and for debugging that. and 2) it made me avoid
segfaults because of my wrong code.
Anyways, it was only a debugging level change.
>
>
>
> Regards,
>
Thanks for your review. I still look forward to more discussion on
overall approach and if there are holes which I can't see (for example,
hotplugging).
Regards,
Shreyansh
^ permalink raw reply
* Re: [PATCH 00/32] NXP DPAA2 PMD
From: Hemant Agrawal @ 2016-12-07 9:53 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: thomas.monjalon, bruce.richardson, shreyansh.jain
In-Reply-To: <32d28626-8f6e-a12e-7e98-433e81355c18@intel.com>
On 12/7/2016 1:18 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:16 PM, Hemant Agrawal wrote:
>> The patch series adds NXP’s QorIQ-Layerscape DPAA2 Architecture based
>> network SoC PMD. This version of the driver supports NXP LS208xA,
>> LS204xA and LS108x families Network SoCs.
>>
>> DPAA2, or Data Path Acceleration Architecture, is a hardware architecture
>> designed for high-speed network packet processing. It uses a bus name
>> ‘fsl-mc’, part of Linux Kernel Staging tree [2], for resource management.
>>
>> A brief description of architecture is given below; detailed description
>> is part of the documentation in the patches itself.
>>
>> DPAA2 contains hardware component called the Management Complex (or MC).
>> It manages the DPAA2 hardware resources. The MC provides an object-based
>> abstraction for software drivers to use the DPAA2 hardware.
>>
>> Some of the key objects are:
>> - DPNI, which refers to the network interface object.
>> - DPBP, which refers to HW based memory pool object
>> - DPIO, refers to processing context for accessing QBMAN
>>
>> Besides the MC, DPAA2 also includes a Hardware based Queue and Buffer Manager
>> called QBMAN. Prime responsibility of QBMAN is to allow lockless access to
>> software/user-space to the queues and buffers implemented in the hardware.
>>
>> The patch series could be logically structured into following sub-areas:
>> 1. (Patch 0001) DPAA2 Architecture overview document
>> 2. (Patches 0002-0007) Common dpaa2 hw accelerator drivers for MC and QBMAN.
>> 3. (Patch 0008) Enabling crc in armv8 core machine type
>> 4. (Patch 0009) Adding rte_device in rte_eth_dev
>> 5. (Patches 0010-0013) introduce DPAA2 bus and VFIO routines
>> 6. (Patches 0014-0017) dpio and dpbp object drivers
>> 7. (Patches 0018-0027) Support for DPAA2 Ethernet Device (ethdev)
>> 8. (Patches 0028-0032) Additional functionality in DPAA2 ethdev.
>>
>> The following design decisions are made during development:
>>
>> 1. DPAA2 implements a new bus called "dpaa2" and some common accelerator drivers.
>> These drivers will be shared with dpaa2 based crypto drivers.
>> - For this, patch series from Shreyansh [1] has been used for creating a
>> bus handler.
>> - For the purpose of this bus, rte_dpaa2_device/rte_dpaa2_driver might
>> also be required but they are not part of the first patch series.
>> Currently, rte_device/driver are being directly used as a PoC.
>>
>> 2. DPAA2 implements the HW mempool offload with DPBP object.
>> - The new pool is being configured using compile time option and pool name
>> as "dpaa2".
>>
>> 3. It maintains per lcore DPIO objects and affine the DPIO instance to the
>> processing threads accessing the QBMAN HW.
>>
>> Prerequisites:
>> - For running the PMD, NXP's SoC (board) and SDK (software/BSP) is required.
>> Information about obtaining relevant software is available in the docs
>> as part of the patch.
>> - At present the series has limited support for Ethernet functions. But,
>> more functionality would be made available in a phased manner.
>> - This PMD has been validated over the Bus Model [1] and SoC Patchset [3]
>
> Just to clarify this patchset depends other patchset, although mentioned
> above, it is good to have links for dependent patches:
>
> Dependencies:
>
> - [4]
>
> [4] http://dpdk.org/dev/patchwork/patch/17620/
Thanks for pointing. I missed it.
>
>>
>>
>> [1] http://dpdk.org/ml/archives/dev/2016-December/051349.html
>> [2] https://www.kernel.org/doc/readme/drivers-staging-fsl-mc-README.txt
>> [3] http://dpdk.org/ml/archives/dev/2016-October/048949.html
>>
>>
>> Hemant Agrawal (32):
>> doc: add dpaa2 nic details
>> drivers/common: introducing dpaa2 mc driver
>> drivers/common/dpaa2: add mc dpni object support
>> drivers/common/dpaa2: add mc dpio object support
>> drivers/common/dpaa2: add mc dpbp object support
>> drivers/common/dpaa2: add mc dpseci object support
>> drivers/common/dpaa2: adding qbman driver
>> mk/dpaa2: add the crc support to the machine type
>> lib/ether: add rte_device in rte_eth_dev
>> net/dpaa2: introducing dpaa2 bus driver for fsl-mc bus
>> net/dpaa2: add dpaa2 vfio support
>> net/dpaa2: vfio scan for net and sec device
>> net/dpaa2: add debug log macros
>> net/dpaa2: dpio object driver
>> net/dpaa2: dpio routine to affine to crypto threads
>> net/dpaa2: dpio add support to check SOC type
>> net/dpaa2: dpbp based mempool hw offload driver
>> net/dpaa2: introducing dpaa2 pmd driver
>> net/dpaa2: adding eth ops to dpaa2
>> net/dpaa2: add queue configuration support
>> net/dpaa2: add rss flow distribution
>> net/dpaa2: configure mac address at init
>> net/dpaa2: attach the buffer pool to dpni
>> net/dpaa2: add support for l3 and l4 checksum offload
>> net/dpaa2: add support for promiscuous mode
>> net/dpaa2: add mtu config support
>> net/dpaa2: add packet rx and tx support
>> net/dpaa2: add support for physical address usages
>> net/dpaa2: rx packet parsing and packet type support
>> net/dpaa2: frame queue based dq storage alloc
>> net/dpaa2: add support for non hw buffer pool packet transmit
>> net/dpaa2: enable stashing for LS2088A devices
>>
>> config/defconfig_arm64-dpaa2-linuxapp-gcc | 15 +-
>> doc/guides/nics/dpaa2.rst | 537 +++++++
>> doc/guides/nics/features/dpaa2.ini | 16 +
>> doc/guides/nics/index.rst | 1 +
>> drivers/Makefile | 1 +
>> drivers/common/Makefile | 36 +
>> drivers/common/dpaa2/Makefile | 37 +
>> drivers/common/dpaa2/mc/Makefile | 57 +
>> drivers/common/dpaa2/mc/dpaa2_mc_version.map | 4 +
>> drivers/common/dpaa2/mc/dpbp.c | 230 +++
>> drivers/common/dpaa2/mc/dpio.c | 272 ++++
>> drivers/common/dpaa2/mc/dpni.c | 667 +++++++++
>> drivers/common/dpaa2/mc/dpseci.c | 527 +++++++
>> drivers/common/dpaa2/mc/fsl_dpbp.h | 220 +++
>> drivers/common/dpaa2/mc/fsl_dpbp_cmd.h | 76 +
>> drivers/common/dpaa2/mc/fsl_dpio.h | 275 ++++
>> drivers/common/dpaa2/mc/fsl_dpio_cmd.h | 114 ++
>> drivers/common/dpaa2/mc/fsl_dpkg.h | 177 +++
>> drivers/common/dpaa2/mc/fsl_dpni.h | 1076 ++++++++++++++
>> drivers/common/dpaa2/mc/fsl_dpni_cmd.h | 301 ++++
>> drivers/common/dpaa2/mc/fsl_dpseci.h | 661 +++++++++
>> drivers/common/dpaa2/mc/fsl_dpseci_cmd.h | 248 ++++
>> drivers/common/dpaa2/mc/fsl_mc_cmd.h | 231 +++
>> drivers/common/dpaa2/mc/fsl_mc_sys.h | 98 ++
>> drivers/common/dpaa2/mc/fsl_net.h | 480 +++++++
>> drivers/common/dpaa2/mc/mc_sys.c | 126 ++
>> drivers/common/dpaa2/qbman/Makefile | 55 +
>> drivers/common/dpaa2/qbman/dpaa2_qbman_version.map | 4 +
>> drivers/common/dpaa2/qbman/include/compat.h | 550 ++++++++
>> .../common/dpaa2/qbman/include/fsl_qbman_base.h | 157 +++
>> .../common/dpaa2/qbman/include/fsl_qbman_portal.h | 1089 +++++++++++++++
>> drivers/common/dpaa2/qbman/qbman_portal.c | 1476 ++++++++++++++++++++
>> drivers/common/dpaa2/qbman/qbman_portal.h | 269 ++++
>> drivers/common/dpaa2/qbman/qbman_private.h | 164 +++
>> drivers/common/dpaa2/qbman/qbman_sys.h | 375 +++++
>> drivers/common/dpaa2/qbman/qbman_sys_decl.h | 69 +
>> drivers/net/Makefile | 2 +-
>> drivers/net/dpaa2/Makefile | 73 +
>> drivers/net/dpaa2/base/dpaa2_hw_dpbp.c | 367 +++++
>> drivers/net/dpaa2/base/dpaa2_hw_dpbp.h | 101 ++
>> drivers/net/dpaa2/base/dpaa2_hw_dpio.c | 513 +++++++
>> drivers/net/dpaa2/base/dpaa2_hw_dpio.h | 76 +
>> drivers/net/dpaa2/base/dpaa2_hw_dpni.c | 343 +++++
>> drivers/net/dpaa2/base/dpaa2_hw_dpni.h | 86 ++
>> drivers/net/dpaa2/base/dpaa2_hw_dpni_annot.h | 256 ++++
>> drivers/net/dpaa2/base/dpaa2_hw_pvt.h | 235 ++++
>> drivers/net/dpaa2/dpaa2_bus.c | 170 +++
>> drivers/net/dpaa2/dpaa2_ethdev.c | 723 ++++++++++
>> drivers/net/dpaa2/dpaa2_ethdev.h | 41 +
>> drivers/net/dpaa2/dpaa2_logs.h | 77 +
>> drivers/net/dpaa2/dpaa2_rxtx.c | 419 ++++++
>> drivers/net/dpaa2/dpaa2_vfio.c | 561 ++++++++
>> drivers/net/dpaa2/dpaa2_vfio.h | 74 +
>> drivers/net/dpaa2/rte_dpaa2.h | 121 ++
>> drivers/net/dpaa2/rte_pmd_dpaa2_version.map | 4 +
>> lib/librte_ether/rte_ethdev.h | 1 +
>> mk/machine/dpaa2/rte.vars.mk | 5 +-
>> mk/rte.app.mk | 1 +
>> 58 files changed, 14936 insertions(+), 4 deletions(-)
>> create mode 100644 doc/guides/nics/dpaa2.rst
>> create mode 100644 doc/guides/nics/features/dpaa2.ini
>> create mode 100644 drivers/common/Makefile
>> create mode 100644 drivers/common/dpaa2/Makefile
>> create mode 100644 drivers/common/dpaa2/mc/Makefile
>> create mode 100644 drivers/common/dpaa2/mc/dpaa2_mc_version.map
>> create mode 100644 drivers/common/dpaa2/mc/dpbp.c
>> create mode 100644 drivers/common/dpaa2/mc/dpio.c
>> create mode 100644 drivers/common/dpaa2/mc/dpni.c
>> create mode 100644 drivers/common/dpaa2/mc/dpseci.c
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpbp.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpbp_cmd.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpio.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpio_cmd.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpkg.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpni.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpni_cmd.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpseci.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_dpseci_cmd.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_mc_cmd.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_mc_sys.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_net.h
>> create mode 100644 drivers/common/dpaa2/mc/mc_sys.c
>> create mode 100644 drivers/common/dpaa2/qbman/Makefile
>> create mode 100644 drivers/common/dpaa2/qbman/dpaa2_qbman_version.map
>> create mode 100644 drivers/common/dpaa2/qbman/include/compat.h
>> create mode 100644 drivers/common/dpaa2/qbman/include/fsl_qbman_base.h
>> create mode 100644 drivers/common/dpaa2/qbman/include/fsl_qbman_portal.h
>> create mode 100644 drivers/common/dpaa2/qbman/qbman_portal.c
>> create mode 100644 drivers/common/dpaa2/qbman/qbman_portal.h
>> create mode 100644 drivers/common/dpaa2/qbman/qbman_private.h
>> create mode 100644 drivers/common/dpaa2/qbman/qbman_sys.h
>> create mode 100644 drivers/common/dpaa2/qbman/qbman_sys_decl.h
>> create mode 100644 drivers/net/dpaa2/Makefile
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpbp.c
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpbp.h
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpio.c
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpio.h
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpni.c
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpni.h
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpni_annot.h
>> create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_pvt.h
>> create mode 100644 drivers/net/dpaa2/dpaa2_bus.c
>> create mode 100644 drivers/net/dpaa2/dpaa2_ethdev.c
>> create mode 100644 drivers/net/dpaa2/dpaa2_ethdev.h
>> create mode 100644 drivers/net/dpaa2/dpaa2_logs.h
>> create mode 100644 drivers/net/dpaa2/dpaa2_rxtx.c
>> create mode 100644 drivers/net/dpaa2/dpaa2_vfio.c
>> create mode 100644 drivers/net/dpaa2/dpaa2_vfio.h
>> create mode 100644 drivers/net/dpaa2/rte_dpaa2.h
>> create mode 100644 drivers/net/dpaa2/rte_pmd_dpaa2_version.map
>>
>
>
^ permalink raw reply
* Re: [PATCH 18/32] net/dpaa2: introducing dpaa2 pmd driver
From: Hemant Agrawal @ 2016-12-07 9:55 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit; +Cc: dev, bruce.richardson, shreyansh.jain
In-Reply-To: <2956951.cEfl6HOu1U@xps13>
On 12/7/2016 2:38 AM, Thomas Monjalon wrote:
> 2016-12-06 19:49, Ferruh Yigit:
>> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>>> + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
>>> + eth_dev->data->dev_private = rte_zmalloc(
>>> + "ethdev private structure",
>>> + eth_drv->dev_private_size,
>>> + RTE_CACHE_LINE_SIZE);
>>> + if (eth_dev->data->dev_private == NULL)
>>> + rte_panic("Cannot allocate memzone for private port"
>>> + " data\n");
>>
>> Should this error kill all app, or return an error for this PMD that is
>> probed.
>
> It cannot be a question :)
> rte_panic() inside libs or drivers is forbidden (and existing ones must
> be removed).
>
I will change it to return an error.
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Ferruh Yigit @ 2016-12-07 9:57 UTC (permalink / raw)
To: Yong Wang, Ananyev, Konstantin, Thomas Monjalon
Cc: Harish Patil, dev@dpdk.org, Rahul Lakkireddy, Stephen Hurd,
Jan Medala, Jakub Palider, John Daley, Adrien Mazarguil,
Alejandro Lucero, Rasesh Mody, Jacob, Jerin, Yuanhan Liu,
Kulasek, TomaszX, olivier.matz@6wind.com
In-Reply-To: <BY2PR05MB2359E2D5220CACCC5A377D8DAF820@BY2PR05MB2359.namprd05.prod.outlook.com>
On 12/6/2016 6:25 PM, Yong Wang wrote:
>> -----Original Message-----
>> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
>> Sent: Sunday, December 4, 2016 4:11 AM
>> To: Yong Wang <yongwang@vmware.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>
>> Cc: Harish Patil <harish.patil@qlogic.com>; dev@dpdk.org; Rahul Lakkireddy
>> <rahul.lakkireddy@chelsio.com>; Stephen Hurd
>> <stephen.hurd@broadcom.com>; Jan Medala <jan@semihalf.com>; Jakub
>> Palider <jpa@semihalf.com>; John Daley <johndale@cisco.com>; Adrien
>> Mazarguil <adrien.mazarguil@6wind.com>; Alejandro Lucero
>> <alejandro.lucero@netronome.com>; Rasesh Mody
>> <rasesh.mody@qlogic.com>; Jacob, Jerin <Jerin.Jacob@cavium.com>;
>> Yuanhan Liu <yuanhan.liu@linux.intel.com>; Kulasek, TomaszX
>> <tomaszx.kulasek@intel.com>; olivier.matz@6wind.com
>> Subject: RE: [dpdk-dev] [PATCH v12 0/6] add Tx preparation
>>
>> Hi
>>
>>
>>
>>>>
>>
>>>> 2016-11-30 17:42, Ananyev, Konstantin:
>>
>>>>>>> Please, we need a comment for each driver saying
>>
>>>>>>> "it is OK, we do not need any checksum preparation for TSO"
>>
>>>>>>> or
>>
>>>>>>> "yes we have to implement tx_prepare or TSO will not work in this
>>
>>>> mode"
>>
>>>>>>>
>>
>>>>>>
>>
>>>>>> qede PMD doesn’t currently support TSO yet, it only supports Tx
>>
>>>> TCP/UDP/IP
>>
>>>>>> csum offloads.
>>
>>>>>> So Tx preparation isn’t applicable. So as of now -
>>
>>>>>> "it is OK, we do not need any checksum preparation for TSO"
>>
>>>>>
>>
>>>>> Thanks for the answer.
>>
>>>>> Though please note that it not only for TSO.
>>
>>>>
>>
>>>> Oh yes, sorry, my wording was incorrect.
>>
>>>> We need to know if any checksum preparation is needed prior
>>
>>>> offloading its final computation to the hardware or driver.
>>
>>>> So the question applies to TSO and simple checksum offload.
>>
>>>>
>>
>>>> We are still waiting answers for
>>
>>>> bnxt, cxgbe, ena, nfp, thunderx, virtio and vmxnet3.
>>
>>>
>>
>>> The case for a virtual device is a little bit more complicated as packets
>> offloaded from a virtual device can eventually be delivered to
>>
>>> another virtual NIC or different physical NICs that have different offload
>> requirements. In ESX, the hypervisor will enforce that the packets
>>
>>> offloaded will be something that the hardware expects. The contract for
>> vmxnet3 is that the guest needs to fill in pseudo header checksum
>>
>>> for both l4 checksum only and TSO + l4 checksum offload cases.
>>
>>
>>
>> Ok, so at first glance that looks to me very similar to Intel HW requirements.
>>
>> Could you confirm would rte_net_intel_cksum_prepare()
>>
>> also work for vmxnet3 or some extra modifications are required?
>>
>> You can look at it here: https://urldefense.proofpoint.com/v2/url?u=http-
>> 3A__dpdk.org_dev_patchwork_patch_17184_&d=DgIGaQ&c=uilaK90D4TOV
>> oH58JNXRgQ&r=v4BBYIqiDq552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=NS
>> 4zOl2je_tyGhnOJMSnu37HmJxOZf-1KLYcVsu8iYY&s=dL-NOC-
>> 18HclXUURQzuyW5Udw4NY13pKMndYvfgCfbA&e= .
>>
>> Note that for Intel HW the rules for pseudo-header csum calculation
>>
>> differ for TSO and non-TSO case.
>>
>> For TSO length inside pseudo-header are set to 0, while for non-tso case
>>
>> It should be set to L3 payload length.
>>
>> Is it the same for vmxnet3 or no?
>>
>> Thanks
>>
>> Konstantin
>>
>
> Yes and this is the same for vmxnet3.
>
This means vmxnet3 PMD also should be updated, right? Should that update
be part of tx_prep patchset? Or separate patch?
>>>
>>
>>>>> This is for any TX offload for which the upper layer SW would have
>>
>>>>> to modify the contents of the packet.
>>
>>>>> Though as I can see for qede neither PKT_TX_IP_CKSUM or
>>
>>>> PKT_TX_TCP_CKSUM
>>
>>>>> exhibits any extra requirements for the user.
>>
>>>>> Is that correct?
>>
>>
>
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Ananyev, Konstantin @ 2016-12-07 10:03 UTC (permalink / raw)
To: Yigit, Ferruh, Yong Wang, Thomas Monjalon
Cc: Harish Patil, dev@dpdk.org, Rahul Lakkireddy, Stephen Hurd,
Jan Medala, Jakub Palider, John Daley, Adrien Mazarguil,
Alejandro Lucero, Rasesh Mody, Jacob, Jerin, Yuanhan Liu,
Kulasek, TomaszX, olivier.matz@6wind.com
In-Reply-To: <8b0acf96-cba9-6c91-92c4-93674052e995@intel.com>
Hi Ferruh,
>
> On 12/6/2016 6:25 PM, Yong Wang wrote:
> >> -----Original Message-----
> >> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> >> Sent: Sunday, December 4, 2016 4:11 AM
> >> To: Yong Wang <yongwang@vmware.com>; Thomas Monjalon
> >> <thomas.monjalon@6wind.com>
> >> Cc: Harish Patil <harish.patil@qlogic.com>; dev@dpdk.org; Rahul Lakkireddy
> >> <rahul.lakkireddy@chelsio.com>; Stephen Hurd
> >> <stephen.hurd@broadcom.com>; Jan Medala <jan@semihalf.com>; Jakub
> >> Palider <jpa@semihalf.com>; John Daley <johndale@cisco.com>; Adrien
> >> Mazarguil <adrien.mazarguil@6wind.com>; Alejandro Lucero
> >> <alejandro.lucero@netronome.com>; Rasesh Mody
> >> <rasesh.mody@qlogic.com>; Jacob, Jerin <Jerin.Jacob@cavium.com>;
> >> Yuanhan Liu <yuanhan.liu@linux.intel.com>; Kulasek, TomaszX
> >> <tomaszx.kulasek@intel.com>; olivier.matz@6wind.com
> >> Subject: RE: [dpdk-dev] [PATCH v12 0/6] add Tx preparation
> >>
> >> Hi
> >>
> >>
> >>
> >>>>
> >>
> >>>> 2016-11-30 17:42, Ananyev, Konstantin:
> >>
> >>>>>>> Please, we need a comment for each driver saying
> >>
> >>>>>>> "it is OK, we do not need any checksum preparation for TSO"
> >>
> >>>>>>> or
> >>
> >>>>>>> "yes we have to implement tx_prepare or TSO will not work in this
> >>
> >>>> mode"
> >>
> >>>>>>>
> >>
> >>>>>>
> >>
> >>>>>> qede PMD doesn’t currently support TSO yet, it only supports Tx
> >>
> >>>> TCP/UDP/IP
> >>
> >>>>>> csum offloads.
> >>
> >>>>>> So Tx preparation isn’t applicable. So as of now -
> >>
> >>>>>> "it is OK, we do not need any checksum preparation for TSO"
> >>
> >>>>>
> >>
> >>>>> Thanks for the answer.
> >>
> >>>>> Though please note that it not only for TSO.
> >>
> >>>>
> >>
> >>>> Oh yes, sorry, my wording was incorrect.
> >>
> >>>> We need to know if any checksum preparation is needed prior
> >>
> >>>> offloading its final computation to the hardware or driver.
> >>
> >>>> So the question applies to TSO and simple checksum offload.
> >>
> >>>>
> >>
> >>>> We are still waiting answers for
> >>
> >>>> bnxt, cxgbe, ena, nfp, thunderx, virtio and vmxnet3.
> >>
> >>>
> >>
> >>> The case for a virtual device is a little bit more complicated as packets
> >> offloaded from a virtual device can eventually be delivered to
> >>
> >>> another virtual NIC or different physical NICs that have different offload
> >> requirements. In ESX, the hypervisor will enforce that the packets
> >>
> >>> offloaded will be something that the hardware expects. The contract for
> >> vmxnet3 is that the guest needs to fill in pseudo header checksum
> >>
> >>> for both l4 checksum only and TSO + l4 checksum offload cases.
> >>
> >>
> >>
> >> Ok, so at first glance that looks to me very similar to Intel HW requirements.
> >>
> >> Could you confirm would rte_net_intel_cksum_prepare()
> >>
> >> also work for vmxnet3 or some extra modifications are required?
> >>
> >> You can look at it here: https://urldefense.proofpoint.com/v2/url?u=http-
> >> 3A__dpdk.org_dev_patchwork_patch_17184_&d=DgIGaQ&c=uilaK90D4TOV
> >> oH58JNXRgQ&r=v4BBYIqiDq552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=NS
> >> 4zOl2je_tyGhnOJMSnu37HmJxOZf-1KLYcVsu8iYY&s=dL-NOC-
> >> 18HclXUURQzuyW5Udw4NY13pKMndYvfgCfbA&e= .
> >>
> >> Note that for Intel HW the rules for pseudo-header csum calculation
> >>
> >> differ for TSO and non-TSO case.
> >>
> >> For TSO length inside pseudo-header are set to 0, while for non-tso case
> >>
> >> It should be set to L3 payload length.
> >>
> >> Is it the same for vmxnet3 or no?
> >>
> >> Thanks
> >>
> >> Konstantin
> >>
> >
> > Yes and this is the same for vmxnet3.
> >
>
> This means vmxnet3 PMD also should be updated, right?
Yes, that's right.
>Should that update
> be part of tx_prep patchset? Or separate patch?
Another question I suppose is who will do the actual patch for vmxnet3.
Yong, are you ok to do the patch for vmxnet3, or prefer us to do that?
Please note, that in both cases will need your help in testing/reviewing it.
Konstantin
>
> >>>
> >>
> >>>>> This is for any TX offload for which the upper layer SW would have
> >>
> >>>>> to modify the contents of the packet.
> >>
> >>>>> Though as I can see for qede neither PKT_TX_IP_CKSUM or
> >>
> >>>> PKT_TX_TCP_CKSUM
> >>
> >>>>> exhibits any extra requirements for the user.
> >>
> >>>>> Is that correct?
> >>
> >>
> >
^ permalink raw reply
* Re: [PATCH 11/32] net/dpaa2: add dpaa2 vfio support
From: Hemant Agrawal @ 2016-12-07 10:04 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, bruce.richardson, shreyansh.jain
In-Reply-To: <2366721.OpDVYN8WCp@xps13>
On 12/7/2016 2:08 PM, Thomas Monjalon wrote:
> 2016-12-07 12:30, Hemant Agrawal:
>> On 12/7/2016 2:34 AM, Thomas Monjalon wrote:
>>> 2016-12-04 23:47, Hemant Agrawal:
>>>> Add support for using VFIO for dpaa2 based fsl-mc bus.
>>>
>>> Why do we need so much special code for interfacing VFIO on fsl-mc?
>>> Can you reuse some code from EAL VFIO?
>>>
>>
>> fsl-mc VFIO scans the objects. So, it is slightly different.
>>
>> Even though I have tried to minimize changes and re-use the code from
>> EAL VFIO. It is still refactoring work, which we will take up little later.
>
> Do you mean you could re-use some EAL code but do not want to do it now?
> It sounds like something heard too many times earlier (from others).
> The experience tells we must not wait to do things right.
>
I meant that I was able to use some of the EAL VFIO functions. There are
some changes which I am planning to propose in eal vfio and in our driver.
I will do it in subsequent patchsets of current series shortly.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox