Re: [dpdk-dev] [PATCH v2] eventdev: promote adapter functions as stable
> -Original Message-
> From: jer...@marvell.com
> Sent: Friday, April 19, 2019 5:41 PM
> To: dev@dpdk.org; Thomas Monjalon ; Jerin Jacob
> ; Mattias Rönnblom ;
> Van Haaren, Harry ; Gujjar, Abhinandan S
> ; Rao, Nikhil ; Carrillo,
> Erik G
> Cc: pbhagavat...@marvell.com; hemant.agra...@nxp.com;
> nipun.gu...@nxp.com; Ma, Liang J
> Subject: [dpdk-dev] [PATCH v2] eventdev: promote adapter functions as stable
>
> From: Jerin Jacob
>
> Promote the adapter functions and rte_event_port_unlinks_in_progress()
> as stable as it's been added for a while now and multiple drivers and test
> application like test-eventdev has been tested using the adapter APIs.
>
> Cc: nikhil@intel.com
> Cc: erik.g.carri...@intel.com
> Cc: abhinandan.guj...@intel.com
> Cc: pbhagavat...@marvell.com
> Cc: hemant.agra...@nxp.com
> Cc: nipun.gu...@nxp.com
> Cc: harry.van.haa...@intel.com
> Cc: mattias.ronnb...@ericsson.com
> Cc: liang.j...@intel.com
>
> Signed-off-by: Jerin Jacob
> ---
>
> allow experimental api still set to true for following drivers.
>
> drivers/event/sw - due to usage of rte_service_may_be_active() API
> drivers/event/dpaa[2] - due to usage of rte_mem_iova2virt() API
>
>
> v2:
> - Remove @warning EXPERIMENTAL from API(Erik)
>
> ---
> MAINTAINERS | 8 +-
> app/test-eventdev/Makefile| 1 -
> app/test-eventdev/meson.build | 1 -
> drivers/event/dsw/Makefile| 1 -
> drivers/event/dsw/meson.build | 1 -
> drivers/event/octeontx/Makefile | 1 -
> drivers/event/octeontx/meson.build| 1 -
> examples/eventdev_pipeline/Makefile | 2 -
> examples/eventdev_pipeline/meson.build| 1 -
> .../rte_event_crypto_adapter.c| 22 ++---
> .../rte_event_crypto_adapter.h| 73 +++-
> .../rte_event_eth_rx_adapter.h| 50 +--
> .../rte_event_eth_tx_adapter.c| 22 ++---
> .../rte_event_eth_tx_adapter.h| 76 -
> lib/librte_eventdev/rte_event_timer_adapter.c | 20 ++---
> lib/librte_eventdev/rte_event_timer_adapter.h | 83 +++
> lib/librte_eventdev/rte_eventdev.c| 8 +-
> lib/librte_eventdev/rte_eventdev.h| 14 +---
> lib/librte_eventdev/rte_eventdev_version.map | 4 +-
> 19 files changed, 85 insertions(+), 304 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a08583471..9c14f7e19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -398,28 +398,28 @@ F: lib/librte_eventdev/
> F: drivers/event/skeleton/
> F: app/test/test_eventdev.c
>
> -Eventdev Ethdev Rx Adapter API - EXPERIMENTAL
> +Eventdev Ethdev Rx Adapter API
> M: Nikhil Rao
> T: git://dpdk.org/next/dpdk-next-eventdev
> F: lib/librte_eventdev/*eth_rx_adapter*
> F: app/test/test_event_eth_rx_adapter.c
> F: doc/guides/prog_guide/event_ethernet_rx_adapter.rst
>
> -Eventdev Ethdev Tx Adapter API - EXPERIMENTAL
> +Eventdev Ethdev Tx Adapter API
> M: Nikhil Rao
> T: git://dpdk.org/next/dpdk-next-eventdev
> F: lib/librte_eventdev/*eth_tx_adapter*
> F: app/test/test_event_eth_tx_adapter.c
> F: doc/guides/prog_guide/event_ethernet_tx_adapter.rst
>
> -Eventdev Timer Adapter API - EXPERIMENTAL
> +Eventdev Timer Adapter API
> M: Erik Gabriel Carrillo
> T: git://dpdk.org/next/dpdk-next-eventdev
> F: lib/librte_eventdev/*timer_adapter*
> F: app/test/test_event_timer_adapter.c
> F: doc/guides/prog_guide/event_timer_adapter.rst
>
> -Eventdev Crypto Adapter API - EXPERIMENTAL
> +Eventdev Crypto Adapter API
> M: Abhinandan Gujjar
> T: git://dpdk.org/next/dpdk-next-eventdev
> F: lib/librte_eventdev/*crypto_adapter*
> diff --git a/app/test-eventdev/Makefile b/app/test-eventdev/Makefile index
> cb659110e..e600e21c4 100644
> --- a/app/test-eventdev/Makefile
> +++ b/app/test-eventdev/Makefile
> @@ -6,7 +6,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
>
> APP = dpdk-test-eventdev
>
> -CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> CFLAGS += $(WERROR_FLAGS)
>
> diff --git a/app/test-eventdev/meson.build b/app/test-eventdev/meson.build
> index a81dcd131..7ff2b786c 100644
> --- a/app/test-eventdev/meson.build
> +++ b/app/test-eventdev/meson.build
> @@ -1,7 +1,6 @@
> # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017 Cavium, Inc
>
> -allow_experimental_apis = true
> sources = files('evt_main.c',
> 'evt_options.c',
> 'evt_test.c',
> diff --git a/drivers/event/dsw/Makefile b/drivers/event/dsw/Makefile index
> 490ed0b98..922fe2e42 100644
> --- a/drivers/event/dsw/Makefile
> +++ b/drivers/event/dsw/Makefile
> @@ -5,7 +5,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
>
> LIB = librte_pmd_dsw_event.a
>
> -CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> CFLAGS += $(WERROR_FLAGS)
> ifneq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
> diff --git a/drivers/event/dsw/meson.build b/drivers/event/dsw/meson.build
> i
Re: [dpdk-dev] [PATCH v6 0/3] lib/rcu: add RCU library supporting QSBR mechanism
17/04/2019 06:13, Honnappa Nagarahalli: > Dharmik Thakkar (1): > test/rcu_qsbr: add API and functional tests > > Honnappa Nagarahalli (2): > rcu: add RCU library supporting QSBR mechanism > doc/rcu: add lib_rcu documentation Sorry I cannot merge this library in DPDK 19.05-rc2 because of several issues: - 32-bit compilation is broken because of %lx/%lu instead of PRI?64 - shared link is broken because of rcu_log_type not exported - some public symbols (variable, macros, functions) are not prefixed with rte I am not sure about getting it later in 19.05, it may be too late to merge a new library.
Re: [dpdk-dev] [PATCH] eal: promote some experimental functions as stable
18/04/2019 12:02, Kevin Traynor: > On 18/04/2019 01:30, Thomas Monjalon wrote: > > The function rte_eal_cleanup() was introduced more than one year ago, > > in DPDK 18.02. It is no longer experimental, allowing > > pdump, proc-info and hotplug_mp apps to not need any experimental API. > > > > The function rte_ctrl_thread_create() was introduced one year ago > > in DPDK 18.05. It is no longer experimental, allowing > > KNI PMD and TEP example to not need any experimental API. > > > > The functions rte_socket_count() and rte_socket_id_by_idx() were > > introduced one year ago in DPDK 18.05. They are no longer experimental. > > > > The function rte_dev_is_probed() was introduced half a year ago > > in DPDK 18.11. It is no longer experimental. > > > > Signed-off-by: Thomas Monjalon > > Acked-by: Kevin Traynor Applied
Re: [dpdk-dev] [RFC v2 2/2] eal: introduce random generator function with upper bound
On 2019-04-20 23:08, Wiles, Keith wrote:
+uint64_t __rte_experimental
+rte_rand_max(uint64_t upper_bound)
+{
+ uint8_t zeros;
+ uint64_t mask = ~((uint64_t)0);
+ uint64_t res;
+
+ if (upper_bound < 2)
+ return 0;
+
+ zeros = __builtin_clzll(upper_bound);
+ mask >>= zeros;
+
+ do {
+ res = rte_rand() & mask;
+ } while (unlikely(res >= upper_bound));
My concern here is the numbers of times this loop could be executed as the
upper bound could be just over a power of 2 and it is a large number meaning
the number of values above upper max and the power of 2 could be huge. Am I
looking this loop correctly. If my thought process is correct it could take a
long time to get a value less tha n upper max, correct?
If the number of values over the limit is huge, so is the value range
below it.
If every thing aligns in a bad way it could be a large number of loops and
cause all kinds of problems. What could be done here or is this a non-issue?
Formally, the execution has no upper bound, but in practice I think this
is a non-issue.
The cycle cost of an iteration of the loop (including the rte_rand()
call) is ~10 cc. With the worst-case upper_limit, the probability of
having to redo the rte_rand() call is ~0.5, for every iteration. This is
with a pseudo-random number generator featuring an uniform distribution.
Let's assume we care about determinism, and we have a system which
suffers a catastrophic failure if the rte_rand_max() latency is more
than 10k clock cycles. The system performs 10M rte_rand_max() calls per
second.
The probability of this system running for a year without any
rte_rand_max()-related crashes is:
0.9970568598526
So crashes due to excessive rte_rand_max() latency may occur, but this
risk is dwarfed by that of the system being hit by an asteroid.
(Btw, I doubt even the people in our sales force have seen that many
nines before.)
From a performance point of view, the high-loop-count cases are rare
enough not to pose a serious threat. For example, being forced to redo
rte_rand() more than five times is only a ~3% risk.
Re: [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances
> > > What happened to this patchset? > > This is definitely an improvement. We must remove rte_panic from libs. > Arnon, are you still available to rebase this patchset in preparation > of 19.08? Or someone else? > > What are the required API breakages? I see one in ethdev which requires > a deprecation notice to be sent for publishing in 19.05. > > Is there more rte_panic to remove? > > > Hi, I should be able to address this for 19.08, at least the straight forward parts. I need to touch base again with this patchset later this week, to see what changed since then, and see what deprecation notices are required. I would like to address the ones that are a direct part of the initialization sequence, and mostly change functions and their callers from void to return a value that propagates upwards. The 2nd kind under lib that I wanted to remove at the time are the ones that live in threads and I would not like to handle them now. Given a 3rd kind that is found inside PMDs that may panic during callbacks, the former poses a similar challenge of managing the device state after a panic event which is not trivial, and tmho deserves either a separate patchset or a defeat recognition. In this respect , In addition to removing the ones from the initialization sequence, I would like to revive my original proposal to add a callback registration to the panic event. As I do not expect all the PMD callback panics to disappear completely, I still need to allow the running process to do some kind of orderly tear-down to other modules when possible. Does this sound ok for 19.08?
Re: [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances
21/04/2019 21:16, Arnon Warshavsky: > Hi, > I should be able to address this for 19.08, at least the straight forward > parts. > I need to touch base again with this patchset later this week, > to see what changed since then, and see what deprecation notices are > required. > I would like to address the ones that are a direct part of the > initialization sequence, > and mostly change functions and their callers from void to return a value > that propagates upwards. > The 2nd kind under lib that I wanted to remove at the time are the ones > that live in threads and I would not like to handle them now. > Given a 3rd kind that is found inside PMDs that may panic during callbacks, > the former poses a similar challenge of managing the device state after a > panic event which is not trivial, > and tmho deserves either a separate patchset or a defeat recognition. > > In this respect , In addition to removing the ones from the initialization > sequence, > I would like to revive my original proposal to add a callback registration > to the panic event. > As I do not expect all the PMD callback panics to disappear completely, > I still need to allow the running process to do some kind of orderly > tear-down to other modules when possible. > > Does this sound ok for 19.08? That would be great to get some progress in 19.08. Do not hesitate to split in several patchsets, getting easy ones first and open discussions other ones.
Re: [dpdk-dev] [PATCH v6 0/3] use IPv4 addresses reserved for testing
10/04/2019 19:41, Stephen Hemminger: > Stephen Hemminger (3): > app/testpmd: add ability to set Tx IP and UDP parameters > examples/l3fwd: use reserved IPv4/IPv6 addresses > examples/l3fwd: format the IP addresses for printing Applied, thanks
[dpdk-dev] [PATCH] net/iavf: fix stats reset
stats_reset has been missed when support stats in iavf driver.
This patch add statistics reset function.
Fixes: f4a41a6953af ("net/avf: support stats")
Cc: sta...@dpdk.org
Signed-off-by: Qiming Yang
---
drivers/net/iavf/iavf.h| 6
drivers/net/iavf/iavf_ethdev.c | 75 ++
2 files changed, 81 insertions(+)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index e6e3e8d..f1bc99c 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -6,6 +6,7 @@
#define _IAVF_ETHDEV_H_
#include
+#include "base/iavf_type.h"
#define IAVF_AQ_LEN 32
#define IAVF_AQ_BUF_SZ4096
@@ -58,6 +59,10 @@
#define IAVF_ETH_OVERHEAD \
(ETHER_HDR_LEN + ETHER_CRC_LEN + IAVF_VLAN_TAG_SIZE * 2)
+#define IAVF_32_BIT_WIDTH (CHAR_BIT * 4)
+#define IAVF_48_BIT_WIDTH (CHAR_BIT * 6)
+#define IAVF_48_BIT_MASK RTE_LEN2MASK(IAVF_48_BIT_WIDTH, uint64_t)
+
struct iavf_adapter;
struct iavf_rx_queue;
struct iavf_tx_queue;
@@ -71,6 +76,7 @@ struct iavf_vsi {
uint16_t max_macaddrs; /* Maximum number of MAC addresses */
uint16_t base_vector;
uint16_t msix_intr; /* The MSIX interrupt binds to VSI */
+ struct virtchnl_eth_stats eth_stats_offset;
};
/* TODO: is that correct to assume the max number to be 16 ?*/
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 846e604..86a3395 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -42,6 +42,7 @@ static void iavf_dev_info_get(struct rte_eth_dev *dev,
static const uint32_t *iavf_dev_supported_ptypes_get(struct rte_eth_dev *dev);
static int iavf_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
+static void iavf_dev_stats_reset(struct rte_eth_dev *dev);
static void iavf_dev_promiscuous_enable(struct rte_eth_dev *dev);
static void iavf_dev_promiscuous_disable(struct rte_eth_dev *dev);
static void iavf_dev_allmulticast_enable(struct rte_eth_dev *dev);
@@ -89,6 +90,7 @@ static const struct eth_dev_ops iavf_eth_dev_ops = {
.dev_supported_ptypes_get = iavf_dev_supported_ptypes_get,
.link_update= iavf_dev_link_update,
.stats_get = iavf_dev_stats_get,
+ .stats_reset= iavf_dev_stats_reset,
.promiscuous_enable = iavf_dev_promiscuous_enable,
.promiscuous_disable= iavf_dev_promiscuous_disable,
.allmulticast_enable= iavf_dev_allmulticast_enable,
@@ -977,16 +979,71 @@ iavf_dev_set_default_mac_addr(struct rte_eth_dev *dev,
return 0;
}
+static void
+iavf_stat_update_48(uint64_t *offset,
+ uint64_t *stat)
+{
+ if (*stat >= *offset)
+ *stat = *stat - *offset;
+ else
+ *stat = (uint64_t)((*stat +
+ ((uint64_t)1 << IAVF_48_BIT_WIDTH)) - *offset);
+
+ *stat &= IAVF_48_BIT_MASK;
+}
+
+static void
+iavf_stat_update_32(uint64_t *offset,
+ uint64_t *stat)
+{
+ if (*stat >= *offset)
+ *stat = (uint64_t)(*stat - *offset);
+ else
+ *stat = (uint64_t)((*stat +
+ ((uint64_t)1 << IAVF_32_BIT_WIDTH)) - *offset);
+}
+
+static void
+iavf_update_stats(struct iavf_vsi *vsi,
+ struct virtchnl_eth_stats *nes)
+{
+ struct virtchnl_eth_stats *oes = &vsi->eth_stats_offset;
+
+ iavf_stat_update_48(&oes->rx_bytes,
+ &nes->rx_bytes);
+ iavf_stat_update_48(&oes->rx_unicast,
+ &nes->rx_unicast);
+ iavf_stat_update_48(&oes->rx_multicast,
+ &nes->rx_multicast);
+ iavf_stat_update_48(&oes->rx_broadcast,
+ &nes->rx_broadcast);
+ iavf_stat_update_32(&oes->rx_discards,
+ &nes->rx_discards);
+ iavf_stat_update_48(&oes->tx_bytes,
+ &nes->tx_bytes);
+ iavf_stat_update_48(&oes->tx_unicast,
+ &nes->tx_unicast);
+ iavf_stat_update_48(&oes->tx_multicast,
+ &nes->tx_multicast);
+ iavf_stat_update_48(&oes->tx_broadcast,
+ &nes->tx_broadcast);
+ iavf_stat_update_32(&oes->tx_errors, &nes->tx_errors);
+ iavf_stat_update_32(&oes->tx_discards, &nes->tx_discards);
+}
+
static int
iavf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
+ struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
+ struct iavf_vsi *vsi = &vf->vsi;
struct virtchnl_eth_stats *pstats = NULL;
int ret;
ret = iavf_query_stats(adapter, &pstats);
if (ret == 0) {
+ iavf_update_stats(vsi
Re: [dpdk-dev] [RFC v2 2/2] eal: introduce random generator function with upper bound
Sent from my iPhone
> On Apr 21, 2019, at 2:05 PM, Mattias Rönnblom
> wrote:
>
> On 2019-04-20 23:08, Wiles, Keith wrote:
>
>>> +uint64_t __rte_experimental
>>> +rte_rand_max(uint64_t upper_bound)
>>> +{
>>> +uint8_t zeros;
>>> +uint64_t mask = ~((uint64_t)0);
>>> +uint64_t res;
>>> +
>>> +if (upper_bound < 2)
>>> +return 0;
>>> +
>>> +zeros = __builtin_clzll(upper_bound);
>>> +mask >>= zeros;
>>> +
>>> +do {
>>> +res = rte_rand() & mask;
>>> +} while (unlikely(res >= upper_bound));
>> My concern here is the numbers of times this loop could be executed as the
>> upper bound could be just over a power of 2 and it is a large number meaning
>> the number of values above upper max and the power of 2 could be huge. Am I
>> looking this loop correctly. If my thought process is correct it could take
>> a long time to get a value less tha n upper max, correct?
>
> If the number of values over the limit is huge, so is the value range below
> it.
>
>> If every thing aligns in a bad way it could be a large number of loops and
>> cause all kinds of problems. What could be done here or is this a non-issue?
>
> Formally, the execution has no upper bound, but in practice I think this is a
> non-issue.
>
> The cycle cost of an iteration of the loop (including the rte_rand() call) is
> ~10 cc. With the worst-case upper_limit, the probability of having to redo
> the rte_rand() call is ~0.5, for every iteration. This is with a
> pseudo-random number generator featuring an uniform distribution.
>
> Let's assume we care about determinism, and we have a system which suffers a
> catastrophic failure if the rte_rand_max() latency is more than 10k clock
> cycles. The system performs 10M rte_rand_max() calls per second.
>
> The probability of this system running for a year without any
> rte_rand_max()-related crashes is:
> 0.9970568598526
>
> So crashes due to excessive rte_rand_max() latency may occur, but this risk
> is dwarfed by that of the system being hit by an asteroid.
>
> (Btw, I doubt even the people in our sales force have seen that many nines
> before.)
>
> From a performance point of view, the high-loop-count cases are rare enough
> not to pose a serious threat. For example, being forced to redo rte_rand()
> more than five times is only a ~3% risk.
Even a few loops can have an effect on performance when we are talking about
micro-seconds plus it leads to indeterminate results. The numbers you reported
here are interesting, but I would be happier if you added a limit to the loop.
If you state the likely hood of doing 5 loops is only 3% then adding a loop
limit would be reasonable, right?
[dpdk-dev] [PATCH v4] kni: add IOVA va support for kni
From: Kiran Kumar K
With current KNI implementation kernel module will work only in
IOVA=PA mode. This patch will add support for kernel module to work
with IOVA=VA mode.
The idea is to get the physical address from iova address using
api iommu_iova_to_phys. Using this API, we will get the physical
address from iova address and later use phys_to_virt API to
convert the physical address to kernel virtual address.
With this approach we have compared the performance with IOVA=PA
and there is no difference observed. Seems like kernel is the
overhead.
This approach will not work with the kernel versions less than 4.4.0
because of API compatibility issues.
Signed-off-by: Kiran Kumar K
---
V4 changes:
* Fixed build issues with older kernel versions
* This approach will only work with kernel above 4.4.0
V3 Changes:
* Add new approach to work kni with IOVA=VA mode using
iommu_iova_to_phys API.
kernel/linux/kni/kni_dev.h| 4 +
kernel/linux/kni/kni_misc.c | 63 ---
kernel/linux/kni/kni_net.c| 76 +++
lib/librte_eal/linux/eal/eal.c| 9 ---
.../linux/eal/include/rte_kni_common.h| 1 +
lib/librte_kni/rte_kni.c | 2 +
6 files changed, 122 insertions(+), 33 deletions(-)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index df46aa70e..9c4944921 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#define KNI_KTHREAD_RESCHEDULE_INTERVAL 5 /* us */
@@ -39,6 +40,9 @@ struct kni_dev {
/* kni list */
struct list_head list;
+ uint8_t iova_mode;
+ struct iommu_domain *domain;
+
struct net_device_stats stats;
int status;
uint16_t group_id; /* Group ID of a group of KNI devices */
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 31845e10f..9e90af31b 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -306,10 +306,12 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
struct rte_kni_device_info dev_info;
struct net_device *net_dev = NULL;
struct kni_dev *kni, *dev, *n;
+ struct pci_dev *pci = NULL;
+ struct iommu_domain *domain = NULL;
+ phys_addr_t phys_addr;
#ifdef RTE_KNI_KMOD_ETHTOOL
struct pci_dev *found_pci = NULL;
struct net_device *lad_dev = NULL;
- struct pci_dev *pci = NULL;
#endif
pr_info("Creating kni...\n");
@@ -368,15 +370,56 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
strncpy(kni->name, dev_info.name, RTE_KNI_NAMESIZE);
/* Translate user space info into kernel space info */
- kni->tx_q = phys_to_virt(dev_info.tx_phys);
- kni->rx_q = phys_to_virt(dev_info.rx_phys);
- kni->alloc_q = phys_to_virt(dev_info.alloc_phys);
- kni->free_q = phys_to_virt(dev_info.free_phys);
-
- kni->req_q = phys_to_virt(dev_info.req_phys);
- kni->resp_q = phys_to_virt(dev_info.resp_phys);
- kni->sync_va = dev_info.sync_va;
- kni->sync_kva = phys_to_virt(dev_info.sync_phys);
+
+ if (dev_info.iova_mode) {
+#if KERNEL_VERSION(4, 4, 0) > LINUX_VERSION_CODE
+ (void)pci;
+ pr_err("Kernel version is not supported\n");
+ return -EINVAL;
+#else
+ pci = pci_get_device(dev_info.vendor_id,
+dev_info.device_id, NULL);
+ while (pci) {
+ if ((pci->bus->number == dev_info.bus) &&
+ (PCI_SLOT(pci->devfn) == dev_info.devid) &&
+ (PCI_FUNC(pci->devfn) == dev_info.function)) {
+ domain = iommu_get_domain_for_dev(&pci->dev);
+ break;
+ }
+ pci = pci_get_device(dev_info.vendor_id,
+dev_info.device_id, pci);
+ }
+#endif
+ kni->domain = domain;
+ phys_addr = iommu_iova_to_phys(domain, dev_info.tx_phys);
+ kni->tx_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.rx_phys);
+ kni->rx_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.alloc_phys);
+ kni->alloc_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.free_phys);
+ kni->free_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.req_phys);
+ kni->req_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.resp_phys);
+ kni->resp_q = phys_to_virt(phys_addr);
+ kni->sync_va = dev_info.sync_va;
+ phys_addr = io
Re: [dpdk-dev] [PATCH v2] eventdev: promote adapter functions as stable
Acked-by: Hemant Agrawal
[dpdk-dev] [PATCH v5] kni: add IOVA va support for kni
From: Kiran Kumar K
With current KNI implementation kernel module will work only in
IOVA=PA mode. This patch will add support for kernel module to work
with IOVA=VA mode.
The idea is to get the physical address from iova address using
api iommu_iova_to_phys. Using this API, we will get the physical
address from iova address and later use phys_to_virt API to
convert the physical address to kernel virtual address.
With this approach we have compared the performance with IOVA=PA
and there is no difference observed. Seems like kernel is the
overhead.
This approach will not work with the kernel versions less than 4.4.0
because of API compatibility issues.
Signed-off-by: Kiran Kumar K
---
V5 changes:
* Fixed build issue with 32b build
V4 changes:
* Fixed build issues with older kernel versions
* This approach will only work with kernel above 4.4.0
V3 Changes:
* Add new approach to work kni with IOVA=VA mode using
iommu_iova_to_phys API.
kernel/linux/kni/kni_dev.h| 4 +
kernel/linux/kni/kni_misc.c | 63 ---
kernel/linux/kni/kni_net.c| 76 +++
lib/librte_eal/linux/eal/eal.c| 9 ---
.../linux/eal/include/rte_kni_common.h| 1 +
lib/librte_kni/rte_kni.c | 2 +
6 files changed, 122 insertions(+), 33 deletions(-)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index df46aa70e..9c4944921 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#define KNI_KTHREAD_RESCHEDULE_INTERVAL 5 /* us */
@@ -39,6 +40,9 @@ struct kni_dev {
/* kni list */
struct list_head list;
+ uint8_t iova_mode;
+ struct iommu_domain *domain;
+
struct net_device_stats stats;
int status;
uint16_t group_id; /* Group ID of a group of KNI devices */
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 31845e10f..9e90af31b 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -306,10 +306,12 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
struct rte_kni_device_info dev_info;
struct net_device *net_dev = NULL;
struct kni_dev *kni, *dev, *n;
+ struct pci_dev *pci = NULL;
+ struct iommu_domain *domain = NULL;
+ phys_addr_t phys_addr;
#ifdef RTE_KNI_KMOD_ETHTOOL
struct pci_dev *found_pci = NULL;
struct net_device *lad_dev = NULL;
- struct pci_dev *pci = NULL;
#endif
pr_info("Creating kni...\n");
@@ -368,15 +370,56 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
strncpy(kni->name, dev_info.name, RTE_KNI_NAMESIZE);
/* Translate user space info into kernel space info */
- kni->tx_q = phys_to_virt(dev_info.tx_phys);
- kni->rx_q = phys_to_virt(dev_info.rx_phys);
- kni->alloc_q = phys_to_virt(dev_info.alloc_phys);
- kni->free_q = phys_to_virt(dev_info.free_phys);
-
- kni->req_q = phys_to_virt(dev_info.req_phys);
- kni->resp_q = phys_to_virt(dev_info.resp_phys);
- kni->sync_va = dev_info.sync_va;
- kni->sync_kva = phys_to_virt(dev_info.sync_phys);
+
+ if (dev_info.iova_mode) {
+#if KERNEL_VERSION(4, 4, 0) > LINUX_VERSION_CODE
+ (void)pci;
+ pr_err("Kernel version is not supported\n");
+ return -EINVAL;
+#else
+ pci = pci_get_device(dev_info.vendor_id,
+dev_info.device_id, NULL);
+ while (pci) {
+ if ((pci->bus->number == dev_info.bus) &&
+ (PCI_SLOT(pci->devfn) == dev_info.devid) &&
+ (PCI_FUNC(pci->devfn) == dev_info.function)) {
+ domain = iommu_get_domain_for_dev(&pci->dev);
+ break;
+ }
+ pci = pci_get_device(dev_info.vendor_id,
+dev_info.device_id, pci);
+ }
+#endif
+ kni->domain = domain;
+ phys_addr = iommu_iova_to_phys(domain, dev_info.tx_phys);
+ kni->tx_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.rx_phys);
+ kni->rx_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.alloc_phys);
+ kni->alloc_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.free_phys);
+ kni->free_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.req_phys);
+ kni->req_q = phys_to_virt(phys_addr);
+ phys_addr = iommu_iova_to_phys(domain, dev_info.resp_phys);
+ kni->resp_q = phys_to_virt(phys_addr);
+ kni->sync_va = d
Re: [dpdk-dev] [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped for inline crypto
Hi Bernard,
>
> Hi Akhil,
>
>
>
> > Subject: RE: [PATCH v4 1/2] examples/ipsec-secgw: fix 1st packet dropped
> > for inline crypto
>
>
> > > + if (sa->type ==
> > RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) {
> > > + ctx = (struct rte_security_ctx *)
> > > + rte_eth_dev_get_sec_ctx(sa->portid);
> >
> > This is breaking the lookaside mode. Ctx was retrieved using the ipsec_ctx-
> > >tbl struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> > rte_cryptodev_get_sec_ctx(
> > ipsec_ctx->tbl[cdev_id_qp].id);
> >
> > I am looking into it, but I don't have time left to get it integrated in
> > RC2. So
> > this has to be pushed to RC3
>
>
>
> Unfortunately we do not have the HW to test this feature.
> What HW are you using to test this?
>
> Having looked at the code previously
> ipsec_ctx->tbl[cdev_id_qp].id turned out to be the port_id.
>
> So we had expected it to work.
>
> We will need your help with this.
I am looking into this. Will let you know when I get the fix.
>
> Regards,
>
> Bernard.
Re: [dpdk-dev] [PATCH] net/ice: fix coverity issues
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
Sent: Thursday, April 18, 2019 9:31 AM
To: dev@dpdk.org
Cc: Lu, Wenzhuo ; sta...@dpdk.org
Subject: [dpdk-dev] [PATCH] net/ice: fix coverity issues
Fix the issues reported by Coverity check, "Null-checking vsi suggests that it
may be null, but it has already been dereferenced on all paths leading to the
check."
Fixes: e0dcf94a0d7f ("net/ice: support VLAN ops")
Fixes: ff963bfa7cb1 ("net/ice: support RSS")
Cc: sta...@dpdk.org
Signed-off-by: Wenzhuo Lu
---
drivers/net/ice/ice_ethdev.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
0946b19..5cca4a8 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -645,12 +645,14 @@ struct ice_xstats_name_off {
struct ice_fltr_list_entry *v_list_itr = NULL;
struct ice_vlan_filter *f;
struct LIST_HEAD_TYPE list_head;
- struct ice_hw *hw = ICE_VSI_TO_HW(vsi);
+ struct ice_hw *hw;
int ret = 0;
if (!vsi || vlan_id > ETHER_MAX_VLAN_ID)
return -EINVAL;
+ hw = ICE_VSI_TO_HW(vsi);
+
/* If it's added and configured, return. */
f = ice_find_vlan_filter(vsi, vlan_id);
if (f) {
@@ -710,7 +712,7 @@ struct ice_xstats_name_off {
struct ice_fltr_list_entry *v_list_itr = NULL;
struct ice_vlan_filter *f;
struct LIST_HEAD_TYPE list_head;
- struct ice_hw *hw = ICE_VSI_TO_HW(vsi);
+ struct ice_hw *hw;
int ret = 0;
/**
@@ -720,6 +722,8 @@ struct ice_xstats_name_off {
if (!vsi || vlan_id == 0 || vlan_id > ETHER_MAX_VLAN_ID)
return -EINVAL;
+ hw = ICE_VSI_TO_HW(vsi);
+
/* Can't find it, return an error */
f = ice_find_vlan_filter(vsi, vlan_id);
if (!f)
@@ -2553,13 +2557,16 @@ static int ice_macaddr_set(struct rte_eth_dev *dev,
static int ice_set_rss_lut(struct ice_vsi *vsi, uint8_t *lut, uint16_t
lut_size) {
- struct ice_pf *pf = ICE_VSI_TO_PF(vsi);
- struct ice_hw *hw = ICE_VSI_TO_HW(vsi);
+ struct ice_pf *pf;
+ struct ice_hw *hw;
int ret;
if (!vsi || !lut)
return -EINVAL;
+ pf = ICE_VSI_TO_PF(vsi);
+ hw = ICE_VSI_TO_HW(vsi);
+
if (pf->flags & ICE_FLAG_RSS_AQ_CAPABLE) {
ret = ice_aq_set_rss_lut(hw, vsi->idx, TRUE,
lut, lut_size);
--
1.9.3
Acked-by: Qiming Yang
