Re: [dpdk-dev] [PATCH v3] net/tap: fix flow and port commands
Hi,
Your reasons to keep *dev in pmd_internals are good enough for me!
The rest of the patch looks fine.
Acked-by: Pascal Mazon
On 17/09/2017 00:32, Ophir Munk wrote:
> This commit fixes two bugs related to tap devices. The first bug occurs
> when executing in testpmd the following flow rule assuming tap device has
> 4 rx and tx pair queues
> "flow create 0 ingress pattern eth / end actions queue index 5 / end"
> This command will report on success and will print ""Flow rule #0 created"
> although it should have failed as queue index number 5 does not exist
>
> The second bug occurs when executing in testpmd "port start all" following
> a port configuration. Assuming 1 pair of rx and tx queues an error is
> reported: "Fail to start port 0"
>
> Before this commit a fixed max number (16) of rx and tx queue pairs were
> created on startup where the file descriptors (fds) of rx and tx pairs were
> identical. As a result in the first bug queue index 5 existed because the
> tap device was created with 16 rx and tx queue pairs regardless of the
> configured number of queues. In the second bug when tap device was started
> tx fd was closed before opening it and executing ioctl() on it. However
> closing the sole fd of the device caused ioctl to fail with "No such
> device".
>
> This commit creates the configured number of rx and tx queue pairs (up to
> max 16) and assigns a unique fd to each queue. It was written to solve the
> first bug and was found as the right fix for the second bug as well.
>
> Fixes: 02f96a0a82d1 ("net/tap: add TUN/TAP device PMD")
> Fixes: bf7b7f437b49 ("net/tap: create netdevice during probing")
> Fixes: de96fe68ae95 ("net/tap: add basic flow API patterns and actions")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ophir Munk
> ---
> In reply to Pascal Mazon review meesage-id:
> <0e18a611-3b35-6624-013b-59c72f713...@6wind.com>
>
> drivers/net/tap/rte_eth_tap.c | 139
> +++---
> drivers/net/tap/rte_eth_tap.h | 2 +-
> drivers/net/tap/tap_flow.c| 3 +-
> 3 files changed, 108 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 9acea83..d926d4b 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -603,8 +603,31 @@ enum ioctl_mode {
> }
>
> static int
> -tap_dev_configure(struct rte_eth_dev *dev __rte_unused)
> +tap_dev_configure(struct rte_eth_dev *dev)
> {
> + if (dev->data->nb_rx_queues > RTE_PMD_TAP_MAX_QUEUES) {
> + RTE_LOG(ERR, PMD,
> + "%s: number of rx queues %d exceeds max num of queues
> %d\n",
> + dev->device->name,
> + dev->data->nb_rx_queues,
> + RTE_PMD_TAP_MAX_QUEUES);
> + return -1;
> + }
> + if (dev->data->nb_tx_queues > RTE_PMD_TAP_MAX_QUEUES) {
> + RTE_LOG(ERR, PMD,
> + "%s: number of tx queues %d exceeds max num of queues
> %d\n",
> + dev->device->name,
> + dev->data->nb_tx_queues,
> + RTE_PMD_TAP_MAX_QUEUES);
> + return -1;
> + }
> +
> + RTE_LOG(INFO, PMD, "%s: %p: TX configured queues number: %u\n",
> + dev->device->name, (void *)dev, dev->data->nb_tx_queues);
> +
> + RTE_LOG(INFO, PMD, "%s: %p: RX configured queues number: %u\n",
> + dev->device->name, (void *)dev, dev->data->nb_rx_queues);
> +
> return 0;
> }
>
> @@ -650,8 +673,8 @@ enum ioctl_mode {
> dev_info->if_index = internals->if_index;
> dev_info->max_mac_addrs = 1;
> dev_info->max_rx_pktlen = (uint32_t)ETHER_MAX_VLAN_FRAME_LEN;
> - dev_info->max_rx_queues = internals->nb_queues;
> - dev_info->max_tx_queues = internals->nb_queues;
> + dev_info->max_rx_queues = RTE_PMD_TAP_MAX_QUEUES;
> + dev_info->max_tx_queues = RTE_PMD_TAP_MAX_QUEUES;
> dev_info->min_rx_bufsize = 0;
> dev_info->pci_dev = NULL;
> dev_info->speed_capa = tap_dev_speed_capa();
> @@ -673,9 +696,9 @@ enum ioctl_mode {
> unsigned long rx_nombuf = 0, ierrors = 0;
> const struct pmd_internals *pmd = dev->data->dev_private;
>
> - imax = (pmd->nb_queues < RTE_ETHDEV_QUEUE_STAT_CNTRS) ?
> - pmd->nb_queues : RTE_ETHDEV_QUEUE_STAT_CNTRS;
> -
> + /* rx queue statistics */
> + imax = (dev->data->nb_rx_queues < RTE_ETHDEV_QUEUE_STAT_CNTRS) ?
> + dev->data->nb_rx_queues : RTE_ETHDEV_QUEUE_STAT_CNTRS;
> for (i = 0; i < imax; i++) {
> tap_stats->q_ipackets[i] = pmd->rxq[i].stats.ipackets;
> tap_stats->q_ibytes[i] = pmd->rxq[i].stats.ibytes;
> @@ -683,7 +706,13 @@ enum ioctl_mode {
> rx_bytes_total += tap_stats->q_ibytes[i];
> rx_nombuf += pmd->rxq[i].stats.rx_nombuf;
> ierrors += pmd->rxq[i].stats.ierrors;
> + }
>
> + /* tx queue statistics */
> + imax = (dev->data->nb
[dpdk-dev] [PATCH] igb_uio: use the UIO_IRQ_NONE instead of 0.
From: Tonghao Zhang
This is not bugfix, but it's convenient to help developer
to review and maintain the igbuio codes.
Signed-off-by: Tonghao Zhang
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 07a19a3..bca22ee 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -446,7 +446,7 @@ struct rte_uio_pci_dev {
/* fall back to no IRQ */
case RTE_INTR_MODE_NONE:
udev->mode = RTE_INTR_MODE_NONE;
- udev->info.irq = 0;
+ udev->info.irq = UIO_IRQ_NONE;
break;
default:
--
1.8.3.1
Re: [dpdk-dev] [PATCH v4 2/3] ethdev: introduce Tx queue offloads API
On 09/17/2017 09:54 AM, Shahaf Shuler wrote:
Introduce a new API to configure Tx offloads.
In the new API, offloads are divided into per-port and per-queue
offloads. The PMD reports capability for each of them.
Offloads are enabled using the existing DEV_TX_OFFLOAD_* flags.
To enable per-port offload, the offload should be set on both device
configuration and queue configuration. To enable per-queue offload, the
offloads can be set only on queue configuration.
In addition the Tx offloads will be disabled by default and be
enabled per application needs. This will much simplify PMD management of
the different offloads.
Applications should set the ETH_TXQ_FLAGS_IGNORE flag on txq_flags
field in order to move to the new API.
The old Tx offloads API is kept for the meanwhile, in order to enable a
smooth transition for PMDs and application to the new API.
Signed-off-by: Shahaf Shuler
---
doc/guides/nics/features.rst | 33 ++-
lib/librte_ether/rte_ethdev.c | 67 +-
lib/librte_ether/rte_ethdev.h | 38 -
3 files changed, 128 insertions(+), 10 deletions(-)
<...>
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 6a2af355a..0a75b1b1e 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
<...>
@@ -744,6 +759,12 @@ struct rte_eth_txconf {
uint32_t txq_flags; /**< Set flags for the Tx queue */
uint8_t tx_deferred_start; /**< Do not start queue with
rte_eth_dev_start(). */
+ /**
+* Per-queue Tx offloads to be set using DEV_TX_OFFLOAD_* flags.
+* Only offloads set on tx_queue_offload_capa field on rte_eth_dev_info
+* structure are allowed to be set.
It contradicts to the statements that:
- tx_queue_offload_capa is per-queue offloads only
- to enable per-port offload, the offload should be set on both device
configuration and
queue configuration.
Similar is applicable to Rx offloads as well.
+*/
+ uint64_t offloads;
};
/**
<...>
Re: [dpdk-dev] [PATCH v4 3/3] doc: add details on ethdev offloads API
On 09/17/2017 09:54 AM, Shahaf Shuler wrote:
Add the programmers guide details on the new offloads API introduced
by commits:
commit f649472cad9d ("ethdev: introduce Rx queue offloads API")
commit ecb46b66cda5 ("ethdev: introduce Tx queue offloads API")
Signed-off-by: Shahaf Shuler
---
doc/guides/prog_guide/poll_mode_drv.rst | 17 +
1 file changed, 17 insertions(+)
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
b/doc/guides/prog_guide/poll_mode_drv.rst
index 8922e39f4..03092ae98 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
<...>
+To enable per-port offload, the offload should be set on both device
configuration and queue setup. In case of a mixed configuration the queue setup
shell return with error.
Typo "shell"
Re: [dpdk-dev] [PATCH v4 0/3] ethdev new offloads API
On 09/17/2017 09:54 AM, Shahaf Shuler wrote: Tx offloads configuration is per queue. Tx offloads are enabled by default, and can be disabled using ETH_TXQ_FLAGS_NO* flags. This behaviour is not consistent with the Rx side where the Rx offloads configuration is per port. Rx offloads are disabled by default and enabled according to bit field in rte_eth_rxmode structure. Moreover, considering more Tx and Rx offloads will be added over time, the cost of managing them all inside the PMD will be tremendous, as the PMD will need to check the matching for the entire offload set for each mbuf it handles. In addition, on the current approach each Rx offload added breaks the ABI compatibility as it requires to add entries to existing bit-fields. The series address above issues by defining a new offloads API. In the new API, offloads are divided into per-port and per-queue offloads, with a corresponding capability for each. The offloads are disabled by default. Each offload can be enabled or disabled using the existing DEV_TX_OFFLOADS_* or DEV_RX_OFFLOADS_* flags. Such API will enable to easily add or remove offloads, without breaking the ABI compatibility. In order to provide a smooth transition between the APIs the following actions were taken: * The old offloads API is kept for the meanwhile. * Helper function which copy from old to new API were added to ethdev, enabling the PMD to support only one of the APIs. As I understand there is an API to copy from a new to old API as well, allowing applications to use the new API and work fine with PMD which supports an old API only. Per discussion made on the RFC of this series [1], the integration plan which was decided is to do the transition in two phases: * ethdev API will move on 17.11. * Apps and examples will move on 18.02. This to enable PMD maintainers sufficient time to adopt the new API. [1] http://dpdk.org/ml/archives/dev/2017-August/072643.html on v4: - Added another patch for documentation. - Fixed ETH_TXQ_FLAGS_IGNORE flag override. - clarify the description of DEV_TX_OFFLOAD_MBUF_FAST_FREE offload. on v3: - Introduce the DEV_TX_OFFLOAD_MBUF_FAST_FREE to act as an equivalent for the no refcnt and single mempool flags. - Fix features documentation. - Fix comment style. on v2: - Taking new approach of dividing offloads into per-queue and per-port one. - Postpone the Tx/Rx public struct renaming to 18.02 - squash the helper functions into the Rx/Tx offloads intro patches. Shahaf Shuler (3): ethdev: introduce Rx queue offloads API ethdev: introduce Tx queue offloads API doc: add details on ethdev offloads API doc/guides/nics/features.rst| 66 +--- doc/guides/prog_guide/poll_mode_drv.rst | 17 ++ lib/librte_ether/rte_ethdev.c | 223 +-- lib/librte_ether/rte_ethdev.h | 89 ++- 4 files changed, 355 insertions(+), 40 deletions(-) Series-reviewed-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH 05/11] lib/librte_mbuf: add security crypto flags and mbuf fields
Hi Olivier,
On 9/14/2017 11:27 AM, Akhil Goyal wrote:
>
> From: Boris Pismenny
>
> add security crypto flags and update mbuf fields to support
> IPsec crypto offload for transmitted packets, and to indicate
> crypto result for received packets.
>
> Signed-off-by: Aviad Yehezkel
> Signed-off-by: Boris Pismenny
> Signed-off-by: Radu Nicolau
> ---
> lib/librte_mbuf/rte_mbuf.c | 6 ++
> lib/librte_mbuf/rte_mbuf.h | 32 +---
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 26a62b8..bbd42a6 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -323,6 +323,8 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
> case PKT_RX_QINQ_STRIPPED: return "PKT_RX_QINQ_STRIPPED";
> case PKT_RX_LRO: return "PKT_RX_LRO";
> case PKT_RX_TIMESTAMP: return "PKT_RX_TIMESTAMP";
> + case PKT_RX_SEC_OFFLOAD: return "PKT_RX_SECURITY_OFFLOAD";
> + case PKT_RX_SEC_OFFLOAD_FAILED: return
> "PKT_RX_SECURITY_OFFLOAD_FAILED";
> default: return NULL;
> }
> }
> @@ -358,6 +360,8 @@ rte_get_rx_ol_flag_list(uint64_t mask, char *buf,
> size_t buflen)
> { PKT_RX_QINQ_STRIPPED, PKT_RX_QINQ_STRIPPED, NULL },
> { PKT_RX_LRO, PKT_RX_LRO, NULL },
> { PKT_RX_TIMESTAMP, PKT_RX_TIMESTAMP, NULL },
> + { PKT_RX_SEC_OFFLOAD, PKT_RX_SEC_OFFLOAD, NULL },
> + { PKT_RX_SEC_OFFLOAD_FAILED,
> PKT_RX_SEC_OFFLOAD_FAILED, NULL },
> };
> const char *name;
> unsigned int i;
> @@ -410,6 +414,7 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
> case PKT_TX_TUNNEL_GENEVE: return "PKT_TX_TUNNEL_GENEVE";
> case PKT_TX_TUNNEL_MPLSINUDP: return
> "PKT_TX_TUNNEL_MPLSINUDP";
> case PKT_TX_MACSEC: return "PKT_TX_MACSEC";
> + case PKT_TX_SEC_OFFLOAD: return "PKT_TX_SECURITY_OFFLOAD";
> default: return NULL;
> }
> }
> @@ -443,6 +448,7 @@ rte_get_tx_ol_flag_list(uint64_t mask, char *buf,
> size_t buflen)
> { PKT_TX_TUNNEL_MPLSINUDP, PKT_TX_TUNNEL_MASK,
> "PKT_TX_TUNNEL_NONE" },
> { PKT_TX_MACSEC, PKT_TX_MACSEC, NULL },
> + { PKT_TX_SEC_OFFLOAD, PKT_TX_SEC_OFFLOAD, NULL },
> };
> const char *name;
> unsigned int i;
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index eaed7ee..9ce61ae 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -189,11 +189,26 @@ extern "C" {
> */
> #define PKT_RX_TIMESTAMP (1ULL << 17)
>
> +/**
> + * Indicate that security offload processing was applied on the RX packet.
> + */
> +#define PKT_RX_SEC_OFFLOAD (1ULL << 18)
> +
> +/**
> + * Indicate that security offload processing failed on the RX packet.
> + */
> +#define PKT_RX_SEC_OFFLOAD_FAILED (1ULL << 19)
> +
> /* add new RX flags here */
>
> /* add new TX flags here */
>
> /**
> + * Request security offload processing on the TX packet.
> + */
> +#define PKT_TX_SEC_OFFLOAD (1ULL << 43)
> +
> +/**
> * Offload the MACsec. This flag must be set by the application to enable
> * this offload feature for a packet to be transmitted.
> */
> @@ -316,7 +331,8 @@ extern "C" {
> PKT_TX_QINQ_PKT |\
> PKT_TX_VLAN_PKT |\
> PKT_TX_TUNNEL_MASK | \
> - PKT_TX_MACSEC)
> + PKT_TX_MACSEC | \
> + PKT_TX_SEC_OFFLOAD)
>
> #define __RESERVED (1ULL << 61) /**< reserved for future mbuf use
> */
>
> @@ -456,8 +472,18 @@ struct rte_mbuf {
> uint32_t l3_type:4; /**< (Outer) L3 type. */
> uint32_t l4_type:4; /**< (Outer) L4 type. */
> uint32_t tun_type:4; /**< Tunnel type. */
> - uint32_t inner_l2_type:4; /**< Inner L2 type. */
> - uint32_t inner_l3_type:4; /**< Inner L3 type. */
> + RTE_STD_C11
> + union {
> + uint8_t inner_esp_next_proto;
> +
> + __extension__
> + struct {
> + uint8_t inner_l2_type:4;
> + /**< Inner L2 type. */
> + uint8_t inner_l3_type:4;
> + /**< Inner L3 type. */
> + };
> + };
> uint32_t inner_l4_type:4; /**< Inner L4 type. */
> };
> };
What do you think about this change to mbuf?
It doesn't increase the mbuf size and it replaces some fields that have no
meaning
in IPsec encapsulations (inner L2 and L3) with a meaningful field of the correct
size (inner_esp_next_proto - 8 bytes).
We later use this for IPsec offload on both Tx and Rx to indicate the packet
format.
Re: [dpdk-dev] [PATCH 06/11] ethdev: extend ethdev to support security APIs
-Original Message-
> Date: Thu, 14 Sep 2017 13:56:46 +0530
> From: Akhil Goyal
> To: dev@dpdk.org
> CC: declan.dohe...@intel.com, pablo.de.lara.gua...@intel.com,
> hemant.agra...@nxp.com, radu.nico...@intel.com, bor...@mellanox.com,
> avia...@mellanox.com, tho...@monjalon.net, sandeep.ma...@nxp.com,
> jerin.ja...@caviumnetworks.com
> Subject: [PATCH 06/11] ethdev: extend ethdev to support security APIs
> X-Mailer: git-send-email 2.9.3
>
> From: Declan Doherty
> /**
> @@ -907,6 +912,7 @@ struct rte_eth_conf {
> #define DEV_RX_OFFLOAD_QINQ_STRIP 0x0020
> #define DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM 0x0040
> #define DEV_RX_OFFLOAD_MACSEC_STRIP 0x0080
> +#define DEV_RX_OFFLOAD_SECURITY 0x0100
>
> /**
> * TX offload capabilities of a device.
> @@ -926,6 +932,11 @@ struct rte_eth_conf {
> #define DEV_TX_OFFLOAD_GENEVE_TNL_TSO 0x1000/**< Used for
> tunneling packet. */
> #define DEV_TX_OFFLOAD_MACSEC_INSERT0x2000
> #define DEV_TX_OFFLOAD_MT_LOCKFREE 0x4000
> +#define DEV_TX_OFFLOAD_SECURITY 0x8000
For the documentation side, Sharing the same views as Shahaf's
> +#define DEV_TX_OFFLOAD_SEC_NEED_MDATA 0x0001
If i understand correctly, it is more of a fixup if driver needs.I guess
we can change to negative logic reflect it as offload.
> +#define DEV_TX_OFFLOAD_IPSEC_CRYPTO_HW_TRAILER 0x0002
> +#define DEV_TX_OFFLOAD_IPSEC_CRYPTO_TSO0x0004
> +#define DEV_TX_OFFLOAD_IPSEC_CRYPTO_CKSUM 0x0008
> /**< Multiple threads can invoke rte_eth_tx_burst() concurrently on the same
> * tx queue without SW lock.
> */
The above text should come after DEV_TX_OFFLOAD_MT_LOCKFREE(Position got
changed in this patch)
> @@ -1651,6 +1662,9 @@ struct rte_eth_dev {
> enum rte_eth_dev_state state; /**< Flag indicating the port state */
> } __rte_cache_aligned;
>
Re: [dpdk-dev] vmxnet3 ethernet driver
On 9/14/2017 12:32 PM, Mukunda Naresh wrote:
> Hi All,
>
> Need your inputs on below functions.
>
> Vmxnet3 driver in dpdk does not have the whitelist filter for unicast mac
> addresses. So addition/removal of MAC addresses using
> rte_eth_dev_mac_addr_add and rte_eth_dev_mac_addr_remove will always fail
> in case of vmxnet3. These functions will always return -95 (or -ENOTSUP).
Hi Mukunda,
mac_addr_set seems added in v16.04 [1] to vmxnet3,
but mac_addr_add & mac_addr_remove are still missing, a patch is welcome
to add those features.
[1]
Commit: 139f39a97859 ("vmxnet3: support setting MAC address")
<...>
Re: [dpdk-dev] [PATCH v5] net/mlx5: support upstream rdma-core
Hi Ferruh, Sunday, September 17, 2017 10:32 AM, Shachar Beiser: > > On 9/14/2017 2:34 PM, Shachar Beiser wrote: > > > This removes the dependency on specific Mellanox OFED libraries by > > > using the upstream rdma-core and linux upstream community code. > > > > Would you mind mentioning what is the difference between "specific > > Mellanox OFED libraries" and "upstream rdma-core"? If not in the > > documentation, at least in mail list for interested people? > > > > Does it make sense to put this update into release notes? Regarding the release notes. I will send later a patch which updates the release notes including also other features being added.
[dpdk-dev] [PATCH v4 0/4] net/softnic: sw fall-back pmd for traffic mgmt and others
The SoftNIC PMD is intended to provide SW fall-back options for specific ethdev APIs in a generic way to the NICs not supporting those features. Currently, the only implemented ethdev API is Traffic Management (TM), but other ethdev APIs such as rte_flow, traffic metering & policing, etc can be easily implemented. Overview: * Generic: The SoftNIC PMD works with any "hard" PMD that implements the ethdev API. It does not change the "hard" PMD in any way. * Creation: For any given "hard" ethdev port, the user can decide to create an associated "soft" ethdev port to drive the "hard" port. The "soft" port is a virtual device that can be created at app start-up through EAL vdev arg or later through the virtual device API. * Configuration: The app explicitly decides which features are to be enabled on the "soft" port and which features are still to be used from the "hard" port. The app continues to explicitly configure both the "hard" and the "soft" ports after the creation of the "soft" port. * RX/TX: The app reads packets from/writes packets to the "soft" port instead of the "hard" port. The RX and TX queues of the "soft" port are thread safe, as any ethdev. * Execution: The "soft" port is a feature-rich NIC implemented by the CPU, so the run function of the "soft" port has to be executed by the CPU in order to get packets moving between "hard" port and the app. * Meets the NFV vision: The app should be (almost) agnostic about the NIC implementation (different vendors/models, HW-SW mix), the app should not require changes to use different NICs, the app should use the same API for all NICs. If a NIC does not implement a specific feature, the HW should be augmented with SW to meet the functionality while still preserving the same API. Traffic Management SW fall-back overview: * Implements the ethdev traffic management API (rte_tm.h). * Based on the existing librte_sched DPDK library. Example: Create "soft" port for "hard" port ":04:00.1", enable the TM feature with default settings: --vdev 'net_softnic0,hard_name=:04:00.1,soft_tm=on' Q1: Why generic name, if only TM is supported (for now)? A1: The intention is to have SoftNIC PMD implement many other (all?) ethdev APIs under a single "ideal" ethdev, hence the generic name. The initial motivation is TM API, but the mechanism is generic and can be used for many other ethdev APIs. Somebody looking to provide SW fall-back for other ethdev API is likely to end up inventing the same, hence it would be good to consolidate all under a single PMD and have the user explicitly enable/disable the features it needs for each "soft" device. Q2: Are there any performance requirements for SoftNIC? A2: Yes, performance should be great/decent for every feature, otherwise the SW fall-back is unusable, thus useless. Q3: Why not change the "hard" device (and keep a single device) instead of creating a new "soft" device (and thus having two devices)? A3: This is not possible with the current librte_ether ethdev implementation. The ethdev->dev_ops are defined as constant structure, so it cannot be changed per device (nor per PMD). The new ops also need memory space to store their context data structures, which requires updating the ethdev->data->dev_private of the existing device; at best, maybe a resize of ethdev->data->dev_private could be done, assuming that librte_ether will introduce a way to find out its size, but this cannot be done while device is running. Other side effects might exist, as the changes are very intrusive, plus it likely needs more changes in librte_ether. Q4: Why not call the SW fall-back dev_ops directly in librte_ether for devices which do not support the specific feature? If the device supports the capability, let's call its dev_ops, otherwise call the SW fall-back dev_ops. A4: First, similar reasons to Q&A3. This fixes the need to change ethdev->dev_ops of the device, but it does not do anything to fix the other significant issue of where to store the context data structures needed by the SW fall-back functions (which, in this approach, are called implicitly by librte_ether). Second, the SW fall-back options should not be restricted arbitrarily by the librte_ether library, the decision should belong to the app. For example, the TM SW fall-back should not be limited to only librte_sched, which (like any SW fall-back) is limited to a specific hierarchy and feature set, it cannot do any possible hierarchy. If alternatives exist, the one to use should be picked by the app, not by the ethdev layer. Q5: Why is the app required to continue to configure both the "hard" and the "soft" devices even after the "soft" device has been created? Why not hiding the "hard" device under the "soft" device and have the "soft" device configure the "hard" device under the hood? A5: Th
[dpdk-dev] [PATCH v4 2/4] net/softnic: add traffic management support
Add ethdev Traffic Management API support to SoftNIC PMD.
Signed-off-by: Cristian Dumitrescu
Signed-off-by: Jasvinder Singh
---
v3 changes:
- add more confguration parameters (tm rate, tm queue sizes)
drivers/net/softnic/Makefile| 1 +
drivers/net/softnic/rte_eth_softnic.c | 252 +++-
drivers/net/softnic/rte_eth_softnic.h | 16 ++
drivers/net/softnic/rte_eth_softnic_internals.h | 106 +-
drivers/net/softnic/rte_eth_softnic_tm.c| 181 +
5 files changed, 553 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/softnic/rte_eth_softnic_tm.c
diff --git a/drivers/net/softnic/Makefile b/drivers/net/softnic/Makefile
index c2f42ef..8b848a9 100644
--- a/drivers/net/softnic/Makefile
+++ b/drivers/net/softnic/Makefile
@@ -47,6 +47,7 @@ LIBABIVER := 1
# all source are stored in SRCS-y
#
SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += rte_eth_softnic.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += rte_eth_softnic_tm.c
#
# Export include files
diff --git a/drivers/net/softnic/rte_eth_softnic.c
b/drivers/net/softnic/rte_eth_softnic.c
index 792e7ea..28b5155 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "rte_eth_softnic.h"
#include "rte_eth_softnic_internals.h"
@@ -49,10 +50,29 @@
#define PRIV_TO_HARD_DEV(p)\
(&rte_eth_devices[p->hard.port_id])
+#define PMD_PARAM_SOFT_TM "soft_tm"
+#define PMD_PARAM_SOFT_TM_RATE "soft_tm_rate"
+#define PMD_PARAM_SOFT_TM_NB_QUEUES"soft_tm_nb_queues"
+#define PMD_PARAM_SOFT_TM_QSIZE0 "soft_tm_qsize0"
+#define PMD_PARAM_SOFT_TM_QSIZE1 "soft_tm_qsize1"
+#define PMD_PARAM_SOFT_TM_QSIZE2 "soft_tm_qsize2"
+#define PMD_PARAM_SOFT_TM_QSIZE3 "soft_tm_qsize3"
+#define PMD_PARAM_SOFT_TM_ENQ_BSZ "soft_tm_enq_bsz"
+#define PMD_PARAM_SOFT_TM_DEQ_BSZ "soft_tm_deq_bsz"
+
#define PMD_PARAM_HARD_NAME"hard_name"
#define PMD_PARAM_HARD_TX_QUEUE_ID "hard_tx_queue_id"
static const char *pmd_valid_args[] = {
+ PMD_PARAM_SOFT_TM,
+ PMD_PARAM_SOFT_TM_RATE,
+ PMD_PARAM_SOFT_TM_NB_QUEUES,
+ PMD_PARAM_SOFT_TM_QSIZE0,
+ PMD_PARAM_SOFT_TM_QSIZE1,
+ PMD_PARAM_SOFT_TM_QSIZE2,
+ PMD_PARAM_SOFT_TM_QSIZE3,
+ PMD_PARAM_SOFT_TM_ENQ_BSZ,
+ PMD_PARAM_SOFT_TM_DEQ_BSZ,
PMD_PARAM_HARD_NAME,
PMD_PARAM_HARD_TX_QUEUE_ID,
NULL
@@ -157,6 +177,13 @@ pmd_dev_start(struct rte_eth_dev *dev)
{
struct pmd_internals *p = dev->data->dev_private;
+ if (tm_used(dev)) {
+ int status = tm_start(p);
+
+ if (status)
+ return status;
+ }
+
dev->data->dev_link.link_status = ETH_LINK_UP;
if (p->params.soft.intrusive) {
@@ -172,7 +199,12 @@ pmd_dev_start(struct rte_eth_dev *dev)
static void
pmd_dev_stop(struct rte_eth_dev *dev)
{
+ struct pmd_internals *p = dev->data->dev_private;
+
dev->data->dev_link.link_status = ETH_LINK_DOWN;
+
+ if (tm_used(dev))
+ tm_stop(p);
}
static void
@@ -293,6 +325,77 @@ rte_pmd_softnic_run_default(struct rte_eth_dev *dev)
return 0;
}
+static __rte_always_inline int
+rte_pmd_softnic_run_tm(struct rte_eth_dev *dev)
+{
+ struct pmd_internals *p = dev->data->dev_private;
+
+ /* Persistent context: Read Only (update not required) */
+ struct rte_sched_port *sched = p->soft.tm.sched;
+ struct rte_mbuf **pkts_enq = p->soft.tm.pkts_enq;
+ struct rte_mbuf **pkts_deq = p->soft.tm.pkts_deq;
+ uint32_t enq_bsz = p->params.soft.tm.enq_bsz;
+ uint32_t deq_bsz = p->params.soft.tm.deq_bsz;
+ uint16_t nb_tx_queues = dev->data->nb_tx_queues;
+
+ /* Persistent context: Read - Write (update required) */
+ uint32_t txq_pos = p->soft.tm.txq_pos;
+ uint32_t pkts_enq_len = p->soft.tm.pkts_enq_len;
+ uint32_t flush_count = p->soft.tm.flush_count;
+
+ /* Not part of the persistent context */
+ uint32_t pkts_deq_len, pos;
+ uint16_t i;
+
+ /* Soft device TXQ read, TM enqueue */
+ for (i = 0; i < nb_tx_queues; i++) {
+ struct rte_ring *txq = dev->data->tx_queues[txq_pos];
+
+ /* Read TXQ burst to packet enqueue buffer */
+ pkts_enq_len += rte_ring_sc_dequeue_burst(txq,
+ (void **)&pkts_enq[pkts_enq_len],
+ enq_bsz,
+ NULL);
+
+ /* Increment TXQ */
+ txq_pos++;
+ if (txq_pos >= nb_tx_queues)
+ txq_pos = 0;
+
+ /* T
[dpdk-dev] [PATCH v4 1/4] net/softnic: add softnic PMD
Add SoftNIC PMD to provide SW fall-back for ethdev APIs. Signed-off-by: Cristian Dumitrescu Signed-off-by: Jasvinder Singh --- v4 changes: - Implemented feedback from Ferruh [1] - rename map file to rte_pmd_eth_softnic_version.map - add release notes library version info - doxygen: fix hooks in doc/api/doxy-api-index.md - add doxygen comment for rte_pmd_softnic_run() - free device name memory - remove soft_dev param in pmd_ethdev_register() - fix checkpatch warnings v3 changes: - rebase to dpdk17.08 release v2 changes: - fix build errors - rebased to TM APIs v6 plus dpdk master [1] Ferruh�s feedback on v3: http://dpdk.org/ml/archives/dev/2017-September/074576.html MAINTAINERS| 5 + config/common_base | 5 + doc/api/doxy-api-index.md | 3 +- doc/api/doxy-api.conf | 1 + doc/guides/rel_notes/release_17_11.rst | 6 + drivers/net/Makefile | 5 + drivers/net/softnic/Makefile | 56 ++ drivers/net/softnic/rte_eth_softnic.c | 595 + drivers/net/softnic/rte_eth_softnic.h | 67 +++ drivers/net/softnic/rte_eth_softnic_internals.h| 114 .../net/softnic/rte_pmd_eth_softnic_version.map| 7 + mk/rte.app.mk | 5 +- 12 files changed, 867 insertions(+), 2 deletions(-) create mode 100644 drivers/net/softnic/Makefile create mode 100644 drivers/net/softnic/rte_eth_softnic.c create mode 100644 drivers/net/softnic/rte_eth_softnic.h create mode 100644 drivers/net/softnic/rte_eth_softnic_internals.h create mode 100644 drivers/net/softnic/rte_pmd_eth_softnic_version.map diff --git a/MAINTAINERS b/MAINTAINERS index a0cd75e..b6b738d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -511,6 +511,11 @@ M: Gaetan Rivet F: drivers/net/failsafe/ F: doc/guides/nics/fail_safe.rst +Softnic PMD +M: Jasvinder Singh +M: Cristian Dumitrescu +F: drivers/net/softnic + Crypto Drivers -- diff --git a/config/common_base b/config/common_base index 5e97a08..1a0c77d 100644 --- a/config/common_base +++ b/config/common_base @@ -273,6 +273,11 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=y CONFIG_RTE_LIBRTE_SFC_EFX_DEBUG=n # +# Compile SOFTNIC PMD +# +CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y + +# # Compile software PMD backed by SZEDATA2 device # CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index 19e0d4f..626ab51 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -55,7 +55,8 @@ The public API headers are grouped by topics: [KNI](@ref rte_kni.h), [ixgbe] (@ref rte_pmd_ixgbe.h), [i40e] (@ref rte_pmd_i40e.h), - [crypto_scheduler] (@ref rte_cryptodev_scheduler.h) + [crypto_scheduler] (@ref rte_cryptodev_scheduler.h), + [softnic](@ref rte_eth_softnic.h) - **memory**: [memseg] (@ref rte_memory.h), diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index 823554f..b27755d 100644 --- a/doc/api/doxy-api.conf +++ b/doc/api/doxy-api.conf @@ -32,6 +32,7 @@ PROJECT_NAME= DPDK INPUT = doc/api/doxy-api-index.md \ drivers/crypto/scheduler \ drivers/net/bonding \ + drivers/net/softnic \ drivers/net/i40e \ drivers/net/ixgbe \ lib/librte_eal/common/include \ diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst index 170f4f9..d5a760b 100644 --- a/doc/guides/rel_notes/release_17_11.rst +++ b/doc/guides/rel_notes/release_17_11.rst @@ -41,6 +41,11 @@ New Features Also, make sure to start the actual text at the margin. = +* **Added SoftNIC PMD.** + + Added new SoftNIC PMD. This virtual device offers applications a software + fallback support for traffic management. + Resolved Issues --- @@ -170,6 +175,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_pipeline.so.3 librte_pmd_bond.so.1 librte_pmd_ring.so.2 + + librte_pmd_softnic.so.1 librte_port.so.3 librte_power.so.1 librte_reorder.so.1 diff --git a/drivers/net/Makefile b/drivers/net/Makefile index d33c959..b552a51 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -110,4 +110,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += vhost endif # $(CONFIG_RTE_LIBRTE_VHOST) DEPDIRS-vhost = $(core-libs) librte_vhost +ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) +DIRS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += softnic +endif # $(CONFIG_RTE_LIBRTE_SCHED) +DEPDIRS-softnic = $(core-libs) librte_sched + include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/drivers/net/so
[dpdk-dev] [PATCH v4 3/4] net/softnic: add TM capabilities ops
Implement ethdev TM capability APIs in SoftNIC PMD.
Signed-off-by: Cristian Dumitrescu
Signed-off-by: Jasvinder Singh
---
drivers/net/softnic/rte_eth_softnic.c | 12 +-
drivers/net/softnic/rte_eth_softnic_internals.h | 32 ++
drivers/net/softnic/rte_eth_softnic_tm.c| 500
3 files changed, 543 insertions(+), 1 deletion(-)
diff --git a/drivers/net/softnic/rte_eth_softnic.c
b/drivers/net/softnic/rte_eth_softnic.c
index 28b5155..d0b5550 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include "rte_eth_softnic.h"
#include "rte_eth_softnic_internals.h"
@@ -224,6 +225,15 @@ pmd_link_update(struct rte_eth_dev *dev __rte_unused,
return 0;
}
+static int
+pmd_tm_ops_get(struct rte_eth_dev *dev, void *arg)
+{
+ *(const struct rte_tm_ops **)arg =
+ (tm_enabled(dev)) ? &pmd_tm_ops : NULL;
+
+ return 0;
+}
+
static const struct eth_dev_ops pmd_ops = {
.dev_configure = pmd_dev_configure,
.dev_start = pmd_dev_start,
@@ -233,7 +243,7 @@ static const struct eth_dev_ops pmd_ops = {
.dev_infos_get = pmd_dev_infos_get,
.rx_queue_setup = pmd_rx_queue_setup,
.tx_queue_setup = pmd_tx_queue_setup,
- .tm_ops_get = NULL,
+ .tm_ops_get = pmd_tm_ops_get,
};
static uint16_t
diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h
b/drivers/net/softnic/rte_eth_softnic_internals.h
index f9e2177..5e93f71 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "rte_eth_softnic.h"
@@ -137,8 +138,26 @@ enum tm_node_level {
TM_NODE_LEVEL_MAX,
};
+/* TM Node */
+struct tm_node {
+ TAILQ_ENTRY(tm_node) node;
+ uint32_t node_id;
+ uint32_t parent_node_id;
+ uint32_t priority;
+ uint32_t weight;
+ uint32_t level;
+ struct tm_node *parent_node;
+ struct rte_tm_node_params params;
+ struct rte_tm_node_stats stats;
+ uint32_t n_children;
+};
+
+TAILQ_HEAD(tm_node_list, tm_node);
+
/* TM Hierarchy Specification */
struct tm_hierarchy {
+ struct tm_node_list nodes;
+
uint32_t n_tm_nodes[TM_NODE_LEVEL_MAX];
};
@@ -191,6 +210,11 @@ struct pmd_rx_queue {
} hard;
};
+/**
+ * Traffic Management (TM) Operation
+ */
+extern const struct rte_tm_ops pmd_tm_ops;
+
int
tm_params_check(struct pmd_params *params, uint32_t hard_rate);
@@ -207,6 +231,14 @@ void
tm_stop(struct pmd_internals *p);
static inline int
+tm_enabled(struct rte_eth_dev *dev)
+{
+ struct pmd_internals *p = dev->data->dev_private;
+
+ return (p->params.soft.flags & PMD_FEATURE_TM);
+}
+
+static inline int
tm_used(struct rte_eth_dev *dev)
{
struct pmd_internals *p = dev->data->dev_private;
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c
b/drivers/net/softnic/rte_eth_softnic_tm.c
index bb28798..a552006 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -179,3 +179,503 @@ tm_stop(struct pmd_internals *p)
if (p->soft.tm.sched)
rte_sched_port_free(p->soft.tm.sched);
}
+
+static struct tm_node *
+tm_node_search(struct rte_eth_dev *dev, uint32_t node_id)
+{
+ struct pmd_internals *p = dev->data->dev_private;
+ struct tm_node_list *nl = &p->soft.tm.h.nodes;
+ struct tm_node *n;
+
+ TAILQ_FOREACH(n, nl, node)
+ if (n->node_id == node_id)
+ return n;
+
+ return NULL;
+}
+
+static uint32_t
+tm_level_get_max_nodes(struct rte_eth_dev *dev, enum tm_node_level level)
+{
+ struct pmd_internals *p = dev->data->dev_private;
+ uint32_t n_queues_max = p->params.soft.tm.nb_queues;
+ uint32_t n_tc_max = n_queues_max / RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS;
+ uint32_t n_pipes_max = n_tc_max / RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE;
+ uint32_t n_subports_max = n_pipes_max;
+ uint32_t n_root_max = 1;
+
+ switch (level) {
+ case TM_NODE_LEVEL_PORT:
+ return n_root_max;
+ case TM_NODE_LEVEL_SUBPORT:
+ return n_subports_max;
+ case TM_NODE_LEVEL_PIPE:
+ return n_pipes_max;
+ case TM_NODE_LEVEL_TC:
+ return n_tc_max;
+ case TM_NODE_LEVEL_QUEUE:
+ default:
+ return n_queues_max;
+ }
+}
+
+#ifdef RTE_SCHED_RED
+#define WRED_SUPPORTED 1
+#else
+#define WRED_SUPPORTED 0
+#endif
+
+#define STATS_MASK_DEFAULT \
+ (RTE_TM_STATS_N_PKTS | \
+ RTE_TM_STATS_N_BYTES | \
+ RTE_TM_STATS_N_PKTS_GREEN_DROPPED | \
[dpdk-dev] [PATCH v4 4/4] net/softnic: add TM hierarchy related ops
Implement ethdev TM hierarchy related APIs in SoftNIC PMD.
Signed-off-by: Cristian Dumitrescu
Signed-off-by: Jasvinder Singh
---
drivers/net/softnic/rte_eth_softnic_internals.h | 41 +
drivers/net/softnic/rte_eth_softnic_tm.c| 2776 ++-
2 files changed, 2813 insertions(+), 4 deletions(-)
diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h
b/drivers/net/softnic/rte_eth_softnic_internals.h
index 5e93f71..317cb08 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -138,6 +138,36 @@ enum tm_node_level {
TM_NODE_LEVEL_MAX,
};
+/* TM Shaper Profile */
+struct tm_shaper_profile {
+ TAILQ_ENTRY(tm_shaper_profile) node;
+ uint32_t shaper_profile_id;
+ uint32_t n_users;
+ struct rte_tm_shaper_params params;
+};
+
+TAILQ_HEAD(tm_shaper_profile_list, tm_shaper_profile);
+
+/* TM Shared Shaper */
+struct tm_shared_shaper {
+ TAILQ_ENTRY(tm_shared_shaper) node;
+ uint32_t shared_shaper_id;
+ uint32_t n_users;
+ uint32_t shaper_profile_id;
+};
+
+TAILQ_HEAD(tm_shared_shaper_list, tm_shared_shaper);
+
+/* TM WRED Profile */
+struct tm_wred_profile {
+ TAILQ_ENTRY(tm_wred_profile) node;
+ uint32_t wred_profile_id;
+ uint32_t n_users;
+ struct rte_tm_wred_params params;
+};
+
+TAILQ_HEAD(tm_wred_profile_list, tm_wred_profile);
+
/* TM Node */
struct tm_node {
TAILQ_ENTRY(tm_node) node;
@@ -147,6 +177,8 @@ struct tm_node {
uint32_t weight;
uint32_t level;
struct tm_node *parent_node;
+ struct tm_shaper_profile *shaper_profile;
+ struct tm_wred_profile *wred_profile;
struct rte_tm_node_params params;
struct rte_tm_node_stats stats;
uint32_t n_children;
@@ -156,8 +188,16 @@ TAILQ_HEAD(tm_node_list, tm_node);
/* TM Hierarchy Specification */
struct tm_hierarchy {
+ struct tm_shaper_profile_list shaper_profiles;
+ struct tm_shared_shaper_list shared_shapers;
+ struct tm_wred_profile_list wred_profiles;
struct tm_node_list nodes;
+ uint32_t n_shaper_profiles;
+ uint32_t n_shared_shapers;
+ uint32_t n_wred_profiles;
+ uint32_t n_nodes;
+
uint32_t n_tm_nodes[TM_NODE_LEVEL_MAX];
};
@@ -170,6 +210,7 @@ struct tm_internals {
* sense to keep the hierarchy frozen after the port is started.
*/
struct tm_hierarchy h;
+ int hierarchy_frozen;
/** Blueprints */
struct tm_params params;
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c
b/drivers/net/softnic/rte_eth_softnic_tm.c
index a552006..8014fbd 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -86,6 +86,79 @@ tm_params_check(struct pmd_params *params, uint32_t
hard_rate)
return 0;
}
+static void
+tm_hierarchy_init(struct pmd_internals *p)
+{
+ memset(&p->soft.tm.h, 0, sizeof(p->soft.tm.h));
+
+ /* Initialize shaper profile list */
+ TAILQ_INIT(&p->soft.tm.h.shaper_profiles);
+
+ /* Initialize shared shaper list */
+ TAILQ_INIT(&p->soft.tm.h.shared_shapers);
+
+ /* Initialize wred profile list */
+ TAILQ_INIT(&p->soft.tm.h.wred_profiles);
+
+ /* Initialize TM node list */
+ TAILQ_INIT(&p->soft.tm.h.nodes);
+}
+
+static void
+tm_hierarchy_uninit(struct pmd_internals *p)
+{
+ /* Remove all nodes*/
+ for ( ; ; ) {
+ struct tm_node *tm_node;
+
+ tm_node = TAILQ_FIRST(&p->soft.tm.h.nodes);
+ if (tm_node == NULL)
+ break;
+
+ TAILQ_REMOVE(&p->soft.tm.h.nodes, tm_node, node);
+ free(tm_node);
+ }
+
+ /* Remove all WRED profiles */
+ for ( ; ; ) {
+ struct tm_wred_profile *wred_profile;
+
+ wred_profile = TAILQ_FIRST(&p->soft.tm.h.wred_profiles);
+ if (wred_profile == NULL)
+ break;
+
+ TAILQ_REMOVE(&p->soft.tm.h.wred_profiles, wred_profile, node);
+ free(wred_profile);
+ }
+
+ /* Remove all shared shapers */
+ for ( ; ; ) {
+ struct tm_shared_shaper *shared_shaper;
+
+ shared_shaper = TAILQ_FIRST(&p->soft.tm.h.shared_shapers);
+ if (shared_shaper == NULL)
+ break;
+
+ TAILQ_REMOVE(&p->soft.tm.h.shared_shapers, shared_shaper, node);
+ free(shared_shaper);
+ }
+
+ /* Remove all shaper profiles */
+ for ( ; ; ) {
+ struct tm_shaper_profile *shaper_profile;
+
+ shaper_profile = TAILQ_FIRST(&p->soft.tm.h.shaper_profiles);
+ if (shaper_profile == NULL)
+ break;
+
+ TAILQ_REMOVE(&p->soft.tm.h.shaper_profiles,
+ shaper_profile, node);
+ free(shaper_profi
Re: [dpdk-dev] [PATCH v5] net/mlx5: support upstream rdma-core
On 9/17/2017 8:31 AM, Shachar Beiser wrote:
>
>
>> -Original Message-
>> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
>> Sent: Thursday, September 14, 2017 4:47 PM
>> To: Shachar Beiser ; dev@dpdk.org
>> Cc: Adrien Mazarguil ; Nélio Laranjeiro
>>
>> Subject: Re: [dpdk-dev] [PATCH v5] net/mlx5: support upstream rdma-core
>>
>> On 9/14/2017 2:34 PM, Shachar Beiser wrote:
>>> This removes the dependency on specific Mellanox OFED libraries by
>>> using the upstream rdma-core and linux upstream community code.
>>
>> Would you mind mentioning what is the difference between "specific
>> Mellanox OFED libraries" and "upstream rdma-core"? If not in the
>> documentation, at least in mail list for interested people?
>>
>> Does it make sense to put this update into release notes?
>>
>> Thanks,
>> ferruh
>>
>
> Hi Ferruh,
>
> Both packages, rdma-core upstream & Mellanox OFED are Linux user-space
> packages :
> 1. Rdma-core is the Linux upstream user-space package.
> 2. Mellanox OFED is the Mellanox's Linux user-space package.
> The difference is the APIs . We shall explain that difference in the
> release notes .
The difference can be too much detail for release notes, I believe it is
good to mention in release notes the dependency requirement change, as
above commit log.
But this commit log can have the detail.
>
> -Shachar Beiser.
>
>>>
>>> ---
>>> I have squashed :
>>> [PATCH v2 3/3] “net/mlx5: fix interrupt enable return”
>>>
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
>> k
>>>
>> .org%2Fdev%2Fpatchwork%2Fpatch%2F28380%2F&data=02%7C01%7Cshach
>> arbe%40m
>>>
>> ellanox.com%7Cc79d7690cb454f8dd41508d4fb771dea%7Ca652971c7d2e4d9b
>> a6a4d
>>>
>> 149256f461b%7C0%7C0%7C636409936407431479&sdata=T5wgSUeCx1tzM9Z
>> UnBAauNt
>>> iG4djfIpOJZOj%2FWM6v4Y%3D&reserved=0
>>> into this patch
>>>
>>> a. Compile with rdma-core commit f11292efd541 ("Merge pull request
>>> #202") b. Tested with linux kernel 4.13-rc4 c. For performance testing
>>> recommended to wait till kernel 4.14
>>>
>>> Signed-off-by: Shachar Beiser
>>
>> <...>
>
Re: [dpdk-dev] [PATCH] net/bonding: strengthen the judgment of lacp packets
On 30/08/2017 4:46 AM, ZengGanghui wrote: When the nic does not support vlan rx offload may be wrong, resulting in lacp packets will not be processed. Signed-off-by: ZengGanghui --- ... Acked-by: Declan Doherty
Re: [dpdk-dev] [PATCH] doc: announce ABI change for ring structure
On Mon, Sep 11, 2017 at 03:39:13PM +0200, Olivier Matz wrote: > As discussed on the mailing list, the alignment constraint of > the ring structure can be relaxed. > > Link: http://dpdk.org/dev/patchwork/patch/25039 > Link: http://dpdk.org/dev/patchwork/patch/26103 > > Signed-off-by: Olivier Matz > --- Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH] doc: announce ABI change for ring structure
> -Original Message- > From: Olivier Matz [mailto:olivier.m...@6wind.com] > Sent: Monday, September 11, 2017 2:39 PM > To: dev@dpdk.org > Cc: Richardson, Bruce ; Mcnamara, John > ; Verkamp, Daniel ; > Ananyev, Konstantin > Subject: [PATCH] doc: announce ABI change for ring structure > > As discussed on the mailing list, the alignment constraint of the ring > structure can be relaxed. > > Link: http://dpdk.org/dev/patchwork/patch/25039 > Link: http://dpdk.org/dev/patchwork/patch/26103 > > Signed-off-by: Olivier Matz Acked-by: John McNamara
Re: [dpdk-dev] [PATCH] doc: announce ABI change for ring structure
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz > Sent: Monday, September 11, 2017 2:39 PM > To: dev@dpdk.org > Cc: Richardson, Bruce ; Mcnamara, John > ; Verkamp, Daniel > ; Ananyev, Konstantin > > Subject: [dpdk-dev] [PATCH] doc: announce ABI change for ring structure > > As discussed on the mailing list, the alignment constraint of the ring > structure > can be relaxed. > > Link: http://dpdk.org/dev/patchwork/patch/25039 > Link: http://dpdk.org/dev/patchwork/patch/26103 > > Signed-off-by: Olivier Matz Acked-by: Anatoly Burakov
[dpdk-dev] [PATCH v2 00/14] Move PCI away from the EAL
Hi all, Here is a new version of the PCI bus move out of the EAL. The EAL PCI implementation is divided in two parts: - librte_pci: library offering helpers to handle PCI objects - librte_bus_pci: bus driver for PCI devices This allows other libraries / tools to use PCI elements (location, mappings, parsing operations, etc) without forcing a dependency on a bus driver. The latter should not have to export helpers that others might need. It is focused on defining the rte_pci_device, rte_pci_driver objects and their handling. The cryptodev library has hard dependencies on rte_pci_devices (used by generic probe function). Other similar libs (ether and eventdev) avoided the issue by inlining such functions and expecting users to include the relevant headers once the PCI bus has already been built. @Declan: I proposed a solution that would avoid inlining those functions, which does not feel right. Let me know what you think of it or if you think of a better solution. I think it would be best to have cryptodev completely independent from PCI / vdev as far as the lib in concerned (the vdev bus will move as well). v2: + Made rte_eal_using_phys_addrs common to both linux and bsd interfaces. + Added documentation of EAL API changes in release note. + Fixed a few rebase-related mistakes. + Fixed parallel build race condition reported by Luca Boccassi. + Grouped together commits breaking compilation: -> pci: introduce PCI lib and bus -> lib: include rte_bus_pci -> drivers: include rte_bus_pci -> test: include rte_bus_pci -> app/testpmd: include rte_bus_pci -> cryptodev: move PCI specific helpers to drivers/crypto Until all of them have been applied, compilation is broken. I am currently wondering whether merging some of them might be sensible. + Not included in this series: Several filesystem-related functions are currently private to the EAL and directly linked. This is not good, but the solution seems to be to have a new lib offering an FS abstraction. This seems an overreach for this patchset and should probably come in a second step. Gaetan Rivet (14): eal: expose rte_eal_using_phys_addrs ethdev: remove useless PCI dependency bus: properly include rte_debug eal: remove references to PCI pci: introduce PCI lib and bus lib: include rte_bus_pci drivers: include rte_bus_pci test: include rte_bus_pci app/testpmd: include rte_bus_pci cryptodev: move PCI specific helpers to drivers/crypto pci: avoid inlining functions pci: avoid over-complicated macro pci: deprecate misnamed functions doc: add notes on EAL PCI API update app/test-pmd/testpmd.h | 1 + config/common_base | 10 + doc/guides/rel_notes/deprecation.rst | 10 + doc/guides/rel_notes/release_17_11.rst | 28 + drivers/Makefile | 2 +- drivers/bus/Makefile | 2 + drivers/bus/pci/Makefile | 59 ++ drivers/bus/pci/bsd/Makefile | 32 + drivers/bus/pci/bsd/rte_pci.c| 671 + drivers/bus/pci/include/rte_bus_pci.h| 387 drivers/bus/pci/linux/Makefile | 37 ++ drivers/bus/pci/linux/rte_pci.c | 723 +++ drivers/bus/pci/linux/rte_pci_init.h | 97 +++ drivers/bus/pci/linux/rte_pci_uio.c | 568 ++ drivers/bus/pci/linux/rte_pci_vfio.c | 675 + drivers/bus/pci/linux/rte_vfio_mp_sync.c | 425 + drivers/bus/pci/private.h| 174 ++ drivers/bus/pci/rte_bus_pci_version.map | 21 + drivers/bus/pci/rte_pci_common.c | 543 + drivers/bus/pci/rte_pci_common_uio.c | 235 drivers/crypto/Makefile | 4 +- drivers/crypto/pci/Makefile | 52 ++ drivers/crypto/pci/rte_cryptodev_pci.c | 128 drivers/crypto/pci/rte_cryptodev_pci.h | 94 +++ drivers/crypto/pci/rte_cryptodev_pci_version.map | 7 + drivers/crypto/qat/qat_qp.c | 1 + drivers/event/octeontx/ssovf_probe.c | 1 + drivers/net/ark/ark_ethdev.c | 1 + drivers/net/avp/avp_ethdev.c | 2 + drivers/net/bnxt/bnxt.h | 1 + drivers/net/bonding/rte_eth_bond_args.c | 1 + drivers/net/cxgbe/base/adapter.h | 1 + drivers/net/cxgbe/cxgbe_ethdev.c | 1 + drivers/net/e1000/em_ethdev.c| 1 + drivers/net/e1000/igb_ethdev.c | 1 + drivers/net/e1000/igb_pf.c | 1 + drivers/net/ena/ena_ethdev.h | 1 + drivers/net/enic/base/vnic_dev.h
[dpdk-dev] [PATCH v2 01/14] eal: expose rte_eal_using_phys_addrs
This function was previously private to the EAL layer.
Other subsystems requires it, such as the PCI bus.
In order not to force other components to include stdbool, which is
incompatible with several NIC drivers, the return type has
been changed from bool to int.
Signed-off-by: Gaetan Rivet
---
lib/librte_eal/bsdapp/eal/eal_memory.c | 6 ++
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/eal_private.h | 11 ---
lib/librte_eal/common/include/rte_memory.h | 11 +++
lib/librte_eal/linuxapp/eal/eal_memory.c| 2 +-
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
6 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c
b/lib/librte_eal/bsdapp/eal/eal_memory.c
index 3614da8..65c96b0 100644
--- a/lib/librte_eal/bsdapp/eal/eal_memory.c
+++ b/lib/librte_eal/bsdapp/eal/eal_memory.c
@@ -192,3 +192,9 @@ rte_eal_hugepage_attach(void)
close(fd_hugepage);
return -1;
}
+
+int
+rte_eal_using_phys_addrs(void)
+{
+ return 0;
+}
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 47a09ea..cff7d18 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -200,6 +200,7 @@ DPDK_17.08 {
rte_bus_find;
rte_bus_find_by_device;
rte_bus_find_by_name;
+ rte_eal_using_phys_addrs;
rte_log_get_level;
} DPDK_17.05;
diff --git a/lib/librte_eal/common/eal_private.h
b/lib/librte_eal/common/eal_private.h
index 597d82e..10a7078 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -333,17 +333,6 @@ int rte_eal_hugepage_init(void);
int rte_eal_hugepage_attach(void);
/**
- * Returns true if the system is able to obtain
- * physical addresses. Return false if using DMA
- * addresses through an IOMMU.
- *
- * Drivers based on uio will not load unless physical
- * addresses are obtainable. It is only possible to get
- * physical addresses when running as a privileged user.
- */
-bool rte_eal_using_phys_addrs(void);
-
-/**
* Find a bus capable of identifying a device.
*
* @param str
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index 4aa5d1f..5568931 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -195,6 +195,17 @@ unsigned rte_memory_get_nchannel(void);
*/
unsigned rte_memory_get_nrank(void);
+/**
+ * Drivers based on uio will not load unless physical
+ * addresses are obtainable. It is only possible to get
+ * physical addresses when running as a privileged user.
+ *
+ * @return
+ * 1 if the system is able to obtain physical addresses.
+ * 0 if using DMA addresses through an IOMMU.
+ */
+int rte_eal_using_phys_addrs(void);
+
#ifdef RTE_LIBRTE_XEN_DOM0
/**< Internal use only - should DOM0 memory mapping be used */
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 5279128..af8719b 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1542,7 +1542,7 @@ rte_eal_hugepage_attach(void)
return -1;
}
-bool
+int
rte_eal_using_phys_addrs(void)
{
return phys_addrs_available;
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 8c08b8d..f866b70 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -205,6 +205,7 @@ DPDK_17.08 {
rte_bus_find;
rte_bus_find_by_device;
rte_bus_find_by_name;
+ rte_eal_using_phys_addrs;
rte_log_get_level;
} DPDK_17.05;
--
2.1.4
[dpdk-dev] [PATCH v2 02/14] ethdev: remove useless PCI dependency
Signed-off-by: Gaetan Rivet --- lib/librte_ether/rte_ethdev.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index a88916f..c5b0b17 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -47,7 +47,6 @@ #include #include #include -#include #include #include #include -- 2.1.4
[dpdk-dev] [PATCH v2 04/14] eal: remove references to PCI
Signed-off-by: Gaetan Rivet --- lib/librte_eal/bsdapp/eal/eal.c | 1 - lib/librte_eal/common/eal_private.h | 132 --- lib/librte_eal/linuxapp/eal/eal.c| 1 - lib/librte_eal/linuxapp/eal/eal_interrupts.c | 1 - 4 files changed, 135 deletions(-) diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c index 5fa5988..b7c045f 100644 --- a/lib/librte_eal/bsdapp/eal/eal.c +++ b/lib/librte_eal/bsdapp/eal/eal.c @@ -66,7 +66,6 @@ #include #include #include -#include #include #include #include diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h index 10a7078..fc504ef 100644 --- a/lib/librte_eal/common/eal_private.h +++ b/lib/librte_eal/common/eal_private.h @@ -36,7 +36,6 @@ #include #include -#include /** * Initialize the memzone subsystem (private to eal). @@ -109,137 +108,6 @@ int rte_eal_timer_init(void); */ int rte_eal_log_init(const char *id, int facility); -struct rte_pci_driver; -struct rte_pci_device; - -/** - * Find the name of a PCI device. - */ -void pci_name_set(struct rte_pci_device *dev); - -/** - * Add a PCI device to the PCI Bus (append to PCI Device list). This function - * also updates the bus references of the PCI Device (and the generic device - * object embedded within. - * - * @param pci_dev - * PCI device to add - * @return void - */ -void rte_pci_add_device(struct rte_pci_device *pci_dev); - -/** - * Insert a PCI device in the PCI Bus at a particular location in the device - * list. It also updates the PCI Bus reference of the new devices to be - * inserted. - * - * @param exist_pci_dev - * Existing PCI device in PCI Bus - * @param new_pci_dev - * PCI device to be added before exist_pci_dev - * @return void - */ -void rte_pci_insert_device(struct rte_pci_device *exist_pci_dev, - struct rte_pci_device *new_pci_dev); - -/** - * Remove a PCI device from the PCI Bus. This sets to NULL the bus references - * in the PCI device object as well as the generic device object. - * - * @param pci_device - * PCI device to be removed from PCI Bus - * @return void - */ -void rte_pci_remove_device(struct rte_pci_device *pci_device); - -/** - * Update a pci device object by asking the kernel for the latest information. - * - * This function is private to EAL. - * - * @param addr - * The PCI Bus-Device-Function address to look for - * @return - * - 0 on success. - * - negative on error. - */ -int pci_update_device(const struct rte_pci_addr *addr); - -/** - * Unbind kernel driver for this device - * - * This function is private to EAL. - * - * @return - * 0 on success, negative on error - */ -int pci_unbind_kernel_driver(struct rte_pci_device *dev); - -/** - * Map the PCI resource of a PCI device in virtual memory - * - * This function is private to EAL. - * - * @return - * 0 on success, negative on error - */ -int pci_uio_map_resource(struct rte_pci_device *dev); - -/** - * Unmap the PCI resource of a PCI device - * - * This function is private to EAL. - */ -void pci_uio_unmap_resource(struct rte_pci_device *dev); - -/** - * Allocate uio resource for PCI device - * - * This function is private to EAL. - * - * @param dev - * PCI device to allocate uio resource - * @param uio_res - * Pointer to uio resource. - * If the function returns 0, the pointer will be filled. - * @return - * 0 on success, negative on error - */ -int pci_uio_alloc_resource(struct rte_pci_device *dev, - struct mapped_pci_resource **uio_res); - -/** - * Free uio resource for PCI device - * - * This function is private to EAL. - * - * @param dev - * PCI device to free uio resource - * @param uio_res - * Pointer to uio resource. - */ -void pci_uio_free_resource(struct rte_pci_device *dev, - struct mapped_pci_resource *uio_res); - -/** - * Map device memory to uio resource - * - * This function is private to EAL. - * - * @param dev - * PCI device that has memory information. - * @param res_idx - * Memory resource index of the PCI device. - * @param uio_res - * uio resource that will keep mapping information. - * @param map_idx - * Mapping information index of the uio resource. - * @return - * 0 on success, negative on error - */ -int pci_uio_map_resource_by_index(struct rte_pci_device *dev, int res_idx, - struct mapped_pci_resource *uio_res, int map_idx); - /** * Init tail queues for non-EAL library structures. This is to allow * the rings, mempools, etc. lists to be shared among multiple processes diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c index 48f12f4..f72da15 100644 --- a/lib/librte_eal/linuxapp/eal/eal.c +++ b/lib/librte_eal/linuxapp/eal/eal.c @@ -71,7 +71,6 @@ #include #include #include -#include #include #include #include diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
[dpdk-dev] [PATCH v2 03/14] bus: properly include rte_debug
Signed-off-by: Gaetan Rivet --- lib/librte_eal/common/eal_common_bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/librte_eal/common/eal_common_bus.c b/lib/librte_eal/common/eal_common_bus.c index 08bec2d..9d1be8a 100644 --- a/lib/librte_eal/common/eal_common_bus.c +++ b/lib/librte_eal/common/eal_common_bus.c @@ -35,6 +35,7 @@ #include #include +#include #include "eal_private.h" -- 2.1.4
[dpdk-dev] [PATCH v2 07/14] drivers: include rte_bus_pci
Devices and drivers are now defined within the bus-specific PCI header. Update drivers. Signed-off-by: Gaetan Rivet --- drivers/bus/pci/bsd/rte_pci.c| 1 + drivers/bus/pci/linux/rte_pci.c | 1 + drivers/bus/pci/linux/rte_pci_uio.c | 1 + drivers/bus/pci/linux/rte_pci_vfio.c | 1 + drivers/bus/pci/linux/rte_vfio_mp_sync.c | 1 + drivers/bus/pci/private.h| 1 + drivers/bus/pci/rte_pci_common.c | 1 + drivers/bus/pci/rte_pci_common_uio.c | 1 + drivers/crypto/qat/qat_qp.c | 1 + drivers/event/octeontx/ssovf_probe.c | 1 + drivers/net/ark/ark_ethdev.c | 1 + drivers/net/avp/avp_ethdev.c | 2 ++ drivers/net/bnxt/bnxt.h | 1 + drivers/net/bonding/rte_eth_bond_args.c | 1 + drivers/net/cxgbe/base/adapter.h | 1 + drivers/net/cxgbe/cxgbe_ethdev.c | 1 + drivers/net/e1000/em_ethdev.c| 1 + drivers/net/e1000/igb_ethdev.c | 1 + drivers/net/e1000/igb_pf.c | 1 + drivers/net/ena/ena_ethdev.h | 1 + drivers/net/enic/base/vnic_dev.h | 4 +++- drivers/net/enic/enic_ethdev.c | 1 + drivers/net/enic/enic_main.c | 1 + drivers/net/i40e/i40e_ethdev.c | 1 + drivers/net/i40e/i40e_ethdev_vf.c| 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.h | 1 + drivers/net/mlx5/mlx5.c | 1 + drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/sfc/sfc.h| 1 + drivers/net/sfc/sfc_ethdev.c | 1 + drivers/net/thunderx/nicvf_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/virtio/virtio_pci.h | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + 35 files changed, 38 insertions(+), 1 deletion(-) diff --git a/drivers/bus/pci/bsd/rte_pci.c b/drivers/bus/pci/bsd/rte_pci.c index 5bd0f4b..6c7ab81 100644 --- a/drivers/bus/pci/bsd/rte_pci.c +++ b/drivers/bus/pci/bsd/rte_pci.c @@ -57,6 +57,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/pci/linux/rte_pci.c b/drivers/bus/pci/linux/rte_pci.c index c2ac82b..ba32d8b 100644 --- a/drivers/bus/pci/linux/rte_pci.c +++ b/drivers/bus/pci/linux/rte_pci.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/pci/linux/rte_pci_uio.c b/drivers/bus/pci/linux/rte_pci_uio.c index eed6d0f..1f0dacd 100644 --- a/drivers/bus/pci/linux/rte_pci_uio.c +++ b/drivers/bus/pci/linux/rte_pci_uio.c @@ -47,6 +47,7 @@ #include #include +#include #include #include #include diff --git a/drivers/bus/pci/linux/rte_pci_vfio.c b/drivers/bus/pci/linux/rte_pci_vfio.c index 81b67c9..ab63423 100644 --- a/drivers/bus/pci/linux/rte_pci_vfio.c +++ b/drivers/bus/pci/linux/rte_pci_vfio.c @@ -42,6 +42,7 @@ #include #include +#include #include #include diff --git a/drivers/bus/pci/linux/rte_vfio_mp_sync.c b/drivers/bus/pci/linux/rte_vfio_mp_sync.c index 2c1654d..d24eba1 100644 --- a/drivers/bus/pci/linux/rte_vfio_mp_sync.c +++ b/drivers/bus/pci/linux/rte_vfio_mp_sync.c @@ -50,6 +50,7 @@ #include #include +#include #include #include diff --git a/drivers/bus/pci/private.h b/drivers/bus/pci/private.h index 7ff1fc4..fdc2c81 100644 --- a/drivers/bus/pci/private.h +++ b/drivers/bus/pci/private.h @@ -37,6 +37,7 @@ #include #include #include +#include struct rte_pci_driver; struct rte_pci_device; diff --git a/drivers/bus/pci/rte_pci_common.c b/drivers/bus/pci/rte_pci_common.c index c37b85b..459ae42 100644 --- a/drivers/bus/pci/rte_pci_common.c +++ b/drivers/bus/pci/rte_pci_common.c @@ -45,6 +45,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/pci/rte_pci_common_uio.c b/drivers/bus/pci/rte_pci_common_uio.c index 4365660..544c606 100644 --- a/drivers/bus/pci/rte_pci_common_uio.c +++ b/drivers/bus/pci/rte_pci_common_uio.c @@ -40,6 +40,7 @@ #include #include +#include #include #include #include diff --git a/drivers/crypto/qat/qat_qp.c b/drivers/crypto/qat/qat_qp.c index 5048d21..a22d6ef 100644 --- a/drivers/crypto/qat/qat_qp.c +++ b/drivers/crypto/qat/qat_qp.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include diff --git a/drivers/event/octeontx/ssovf_probe.c b/drivers/event/octeontx/ssovf_probe.c index e1c0c6d..1cac4bc 100644 --- a/drivers/event/octeontx/ssovf_probe.c +++ b/drivers/event/octeontx/ssovf_probe.c @@ -35,6 +35,7 @@ #include #include #include +#include #include "ssovf_evdev.h" diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c index 6db362b..78a4d79 100644 --- a/drivers/net/ark/ark_ethdev.c +++ b/drivers/net/ark/ark_ethdev.c @@ -35,6 +35,7 @@ #include #include +#include #include #include diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_eth
[dpdk-dev] [PATCH v2 06/14] lib: include rte_bus_pci
Devices and drivers are now defined within the bus-specific PCI header.
Update the libraries, as structuraly unsound as it may be.
Signed-off-by: Gaetan Rivet
---
lib/librte_ether/rte_ethdev_pci.h | 1 +
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev_pci.h
b/lib/librte_ether/rte_ethdev_pci.h
index 56b1072..722075e 100644
--- a/lib/librte_ether/rte_ethdev_pci.h
+++ b/lib/librte_ether/rte_ethdev_pci.h
@@ -36,6 +36,7 @@
#include
#include
+#include
#include
/**
diff --git a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
index b6bd731..ade32b5 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
@@ -50,6 +50,7 @@ extern "C" {
#include
#include
#include
+#include
#include "rte_eventdev_pmd.h"
--
2.1.4
[dpdk-dev] [PATCH v2 09/14] app/testpmd: include rte_bus_pci
Devices and drivers are now defined within the bus-specific PCI header. Update applications. Signed-off-by: Gaetan Rivet --- app/test-pmd/testpmd.h | 1 + 1 file changed, 1 insertion(+) diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index 1d1ee75..d0613b5 100644 --- a/app/test-pmd/testpmd.h +++ b/app/test-pmd/testpmd.h @@ -35,6 +35,7 @@ #define _TESTPMD_H_ #include +#include #include #define RTE_PORT_ALL(~(portid_t)0x0) -- 2.1.4
[dpdk-dev] [PATCH v2 10/14] cryptodev: move PCI specific helpers to drivers/crypto
Those helpers rely on the PCI bus driver implementation. Other similar libraries relied on the bus-specifics being handled in inlined functions, to be compiled on demand by drivers, once the proper PCI dependency has been settled. This seems unsafe. Move the PCI-specific helpers out of the lib directory to the drivers/crypto directory, properly following the dependency hierarchy. Signed-off-by: Gaetan Rivet Cc: Declan Doherty --- This issue is seen by the vdev bus as well: [PATCH 04/12] vdev: move to drivers/bus http://dpdk.org/ml/archives/dev/2017-August/073740.html drivers/Makefile | 2 +- drivers/crypto/Makefile | 4 +- drivers/crypto/pci/Makefile | 52 + drivers/crypto/pci/rte_cryptodev_pci.c | 128 +++ drivers/crypto/pci/rte_cryptodev_pci.h | 94 + drivers/crypto/pci/rte_cryptodev_pci_version.map | 7 ++ lib/librte_cryptodev/Makefile| 1 - lib/librte_cryptodev/rte_cryptodev_pci.h | 92 lib/librte_cryptodev/rte_cryptodev_pmd.c | 94 - lib/librte_cryptodev/rte_cryptodev_version.map | 2 - 10 files changed, 285 insertions(+), 191 deletions(-) create mode 100644 drivers/crypto/pci/Makefile create mode 100644 drivers/crypto/pci/rte_cryptodev_pci.c create mode 100644 drivers/crypto/pci/rte_cryptodev_pci.h create mode 100644 drivers/crypto/pci/rte_cryptodev_pci_version.map delete mode 100644 lib/librte_cryptodev/rte_cryptodev_pci.h diff --git a/drivers/Makefile b/drivers/Makefile index 7fef66d..a5d3fa0 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -37,7 +37,7 @@ DEPDIRS-mempool := bus DIRS-y += net DEPDIRS-net := bus mempool DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto -DEPDIRS-crypto := mempool +DEPDIRS-crypto := bus mempool DIRS-$(CONFIG_RTE_LIBRTE_EVENTDEV) += event DEPDIRS-event := bus diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 7a719b9..cfd6cb6 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -33,6 +33,8 @@ include $(RTE_SDK)/mk/rte.vars.mk core-libs := librte_eal librte_mbuf librte_mempool librte_ring librte_cryptodev +DIRS-$(CONFIG_RTE_LIBRTE_PCI_BUS) += pci +DEPDIRS-pci = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_GCM) += aesni_gcm DEPDIRS-aesni_gcm = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb @@ -42,7 +44,7 @@ DEPDIRS-armv8 = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPENSSL) += openssl DEPDIRS-openssl = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += qat -DEPDIRS-qat = $(core-libs) +DEPDIRS-qat = $(core-libs) librte_cryptodev_pci DIRS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += scheduler DEPDIRS-scheduler = $(core-libs) librte_kvargs librte_reorder DIRS-$(CONFIG_RTE_LIBRTE_PMD_SNOW3G) += snow3g diff --git a/drivers/crypto/pci/Makefile b/drivers/crypto/pci/Makefile new file mode 100644 index 000..da819f2 --- /dev/null +++ b/drivers/crypto/pci/Makefile @@ -0,0 +1,52 @@ +# BSD LICENSE +# +# Copyright(c) 2017 6WIND S.A. 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 6WIND S.A. 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_cryptodev_pci.a + +# library version +LIBABIVER := 1 + +# build flags +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +# library source files +SRCS-y += rte_cryptodev_pci.c + +# export include files +SYMLINK-y-include +
[dpdk-dev] [PATCH v2 08/14] test: include rte_bus_pci
Devices and drivers are now defined within the bus-specific PCI header. Update test applications. Signed-off-by: Gaetan Rivet --- test/test/test_kni.c| 1 + test/test/virtual_pmd.c | 1 + 2 files changed, 2 insertions(+) diff --git a/test/test/test_kni.c b/test/test/test_kni.c index db17fdf..b2f05ec 100644 --- a/test/test/test_kni.c +++ b/test/test/test_kni.c @@ -42,6 +42,7 @@ #include #include #include +#include #include #include diff --git a/test/test/virtual_pmd.c b/test/test/virtual_pmd.c index 9d46ad5..72e784a 100644 --- a/test/test/virtual_pmd.c +++ b/test/test/virtual_pmd.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include -- 2.1.4
[dpdk-dev] [PATCH v2 11/14] pci: avoid inlining functions
Parsing operations should not happen in performance critical sections.
Headers should not propose implementations unless duly required.
Signed-off-by: Gaetan Rivet
---
lib/librte_pci/include/rte_pci.h | 69 --
lib/librte_pci/rte_pci.c | 65 +++
lib/librte_pci/rte_pci_version.map | 4 +++
3 files changed, 75 insertions(+), 63 deletions(-)
diff --git a/lib/librte_pci/include/rte_pci.h b/lib/librte_pci/include/rte_pci.h
index 3858e80..09a609a 100644
--- a/lib/librte_pci/include/rte_pci.h
+++ b/lib/librte_pci/include/rte_pci.h
@@ -126,19 +126,6 @@ struct mapped_pci_resource {
/** mapped pci device list */
TAILQ_HEAD(mapped_pci_res_list, mapped_pci_resource);
-/**< Internal use only - Macro used by pci addr parsing functions **/
-#define GET_PCIADDR_FIELD(in, fd, lim, dlm) \
-do { \
- unsigned long val; \
- char *end; \
- errno = 0; \
- val = strtoul((in), &end, 16); \
- if (errno != 0 || end[0] != (dlm) || val > (lim)) \
- return -EINVAL; \
- (fd) = (typeof (fd))val;\
- (in) = end + 1; \
-} while(0)
-
/**
* Utility function to produce a PCI Bus-Device-Function value
* given a string representation. Assumes that the BDF is provided without
@@ -152,15 +139,7 @@ do {
\
* @return
* 0 on success, negative on error.
*/
-static inline int
-eal_parse_pci_BDF(const char *input, struct rte_pci_addr *dev_addr)
-{
- dev_addr->domain = 0;
- GET_PCIADDR_FIELD(input, dev_addr->bus, UINT8_MAX, ':');
- GET_PCIADDR_FIELD(input, dev_addr->devid, UINT8_MAX, '.');
- GET_PCIADDR_FIELD(input, dev_addr->function, UINT8_MAX, 0);
- return 0;
-}
+int eal_parse_pci_BDF(const char *input, struct rte_pci_addr *dev_addr);
/**
* Utility function to produce a PCI Bus-Device-Function value
@@ -174,16 +153,7 @@ eal_parse_pci_BDF(const char *input, struct rte_pci_addr
*dev_addr)
* @return
* 0 on success, negative on error.
*/
-static inline int
-eal_parse_pci_DomBDF(const char *input, struct rte_pci_addr *dev_addr)
-{
- GET_PCIADDR_FIELD(input, dev_addr->domain, UINT16_MAX, ':');
- GET_PCIADDR_FIELD(input, dev_addr->bus, UINT8_MAX, ':');
- GET_PCIADDR_FIELD(input, dev_addr->devid, UINT8_MAX, '.');
- GET_PCIADDR_FIELD(input, dev_addr->function, UINT8_MAX, 0);
- return 0;
-}
-#undef GET_PCIADDR_FIELD
+int eal_parse_pci_DomBDF(const char *input, struct rte_pci_addr *dev_addr);
/**
* Utility function to write a pci device name, this device name can later be
@@ -197,17 +167,9 @@ eal_parse_pci_DomBDF(const char *input, struct
rte_pci_addr *dev_addr)
* @param size
* The output buffer size
*/
-static inline void
-rte_pci_device_name(const struct rte_pci_addr *addr,
- char *output, size_t size)
-{
- RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
- RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
- addr->domain, addr->bus,
- addr->devid, addr->function) >= 0);
-}
+void rte_pci_device_name(const struct rte_pci_addr *addr,
+char *output, size_t size);
-/* Compare two PCI device addresses. */
/**
* Utility function to compare two PCI device addresses.
*
@@ -220,27 +182,8 @@ rte_pci_device_name(const struct rte_pci_addr *addr,
* Positive on addr is greater than addr2.
* Negative on addr is less than addr2, or error.
*/
-static inline int
-rte_eal_compare_pci_addr(const struct rte_pci_addr *addr,
-const struct rte_pci_addr *addr2)
-{
- uint64_t dev_addr, dev_addr2;
-
- if ((addr == NULL) || (addr2 == NULL))
- return -1;
-
- dev_addr = ((uint64_t)addr->domain << 24) |
- (addr->bus << 16) | (addr->devid << 8) | addr->function;
- dev_addr2 = ((uint64_t)addr2->domain << 24) |
- (addr2->bus << 16) | (addr2->devid << 8) | addr2->function;
-
- if (dev_addr > dev_addr2)
- return 1;
- else if (dev_addr < dev_addr2)
- return -1;
- else
- return 0;
-}
+int rte_eal_compare_pci_addr(const struct rte_pci_addr *addr,
+const struct rte_pci_addr *addr2);
/**
* Map a particular resource from a file.
diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c
index 9dfdd3f..8584b55 100644
--- a/lib/librte_pci/rte_pci.c
+++ b/lib/librte_pci/rte_pci.c
@@ -53,6 +53,71 @@
#include "rte_pci.h"
+/* Macro used by pci addr parsing functions. **/
+#d
[dpdk-dev] [PATCH v2 13/14] pci: deprecate misnamed functions
Rename misnamed functions and describe the change in a deprecation
notice.
Signed-off-by: Gaetan Rivet
---
doc/guides/rel_notes/deprecation.rst | 10 ++
lib/librte_pci/include/rte_pci.h | 63
lib/librte_pci/rte_pci.c | 26 +++
lib/librte_pci/rte_pci_version.map | 4 +++
4 files changed, 103 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 3362f33..1828e57 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -120,3 +120,13 @@ Deprecation Notices
The non-"do-sig" versions of the hash tables will be removed
(including the ``signature_offset`` parameter)
and the "do-sig" versions renamed accordingly.
+
+* pci: Several exposed functions are misnamed.
+ The following functions are deprecated starting from v17.11 and are replaced:
+
+ - ``eal_parse_pci_BDF`` replaced by ``pci_parse_BDF``
+ - ``eal_parse_pci_DomBDF`` replaced by ``pci_parse_DomBDF``
+ - ``rte_eal_compare_pci_addr`` replaced by ``pci_addr_cmp``
+ - ``rte_pci_device_name`` replaced by ``pci_device_name``
+
+ The functions are only renamed. Their behavior is not affected.
diff --git a/lib/librte_pci/include/rte_pci.h b/lib/librte_pci/include/rte_pci.h
index 09a609a..224cea0 100644
--- a/lib/librte_pci/include/rte_pci.h
+++ b/lib/librte_pci/include/rte_pci.h
@@ -127,6 +127,7 @@ struct mapped_pci_resource {
TAILQ_HEAD(mapped_pci_res_list, mapped_pci_resource);
/**
+ * @deprecated
* Utility function to produce a PCI Bus-Device-Function value
* given a string representation. Assumes that the BDF is provided without
* a domain prefix (i.e. domain returned is always 0)
@@ -143,6 +144,22 @@ int eal_parse_pci_BDF(const char *input, struct
rte_pci_addr *dev_addr);
/**
* Utility function to produce a PCI Bus-Device-Function value
+ * given a string representation. Assumes that the BDF is provided without
+ * a domain prefix (i.e. domain returned is always 0)
+ *
+ * @param input
+ * The input string to be parsed. Should have the format XX:XX.X
+ * @param dev_addr
+ * The PCI Bus-Device-Function address to be returned. Domain will always
be
+ * returned as 0
+ * @return
+ * 0 on success, negative on error.
+ */
+int pci_parse_BDF(const char *input, struct rte_pci_addr *dev_addr);
+
+/**
+ * @deprecated
+ * Utility function to produce a PCI Bus-Device-Function value
* given a string representation. Assumes that the BDF is provided including
* a domain prefix.
*
@@ -156,6 +173,21 @@ int eal_parse_pci_BDF(const char *input, struct
rte_pci_addr *dev_addr);
int eal_parse_pci_DomBDF(const char *input, struct rte_pci_addr *dev_addr);
/**
+ * Utility function to produce a PCI Bus-Device-Function value
+ * given a string representation. Assumes that the BDF is provided including
+ * a domain prefix.
+ *
+ * @param input
+ * The input string to be parsed. Should have the format :XX:XX.X
+ * @param dev_addr
+ * The PCI Bus-Device-Function address to be returned
+ * @return
+ * 0 on success, negative on error.
+ */
+int pci_parse_DomBDF(const char *input, struct rte_pci_addr *dev_addr);
+
+/**
+ * @deprecated
* Utility function to write a pci device name, this device name can later be
* used to retrieve the corresponding rte_pci_addr using eal_parse_pci_*
* BDF helpers.
@@ -171,6 +203,22 @@ void rte_pci_device_name(const struct rte_pci_addr *addr,
char *output, size_t size);
/**
+ * Utility function to write a pci device name, this device name can later be
+ * used to retrieve the corresponding rte_pci_addr using eal_parse_pci_*
+ * BDF helpers.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address
+ * @param output
+ * The output buffer string
+ * @param size
+ * The output buffer size
+ */
+void pci_device_name(const struct rte_pci_addr *addr,
+char *output, size_t size);
+
+/**
+ * @deprecated
* Utility function to compare two PCI device addresses.
*
* @param addr
@@ -186,6 +234,21 @@ int rte_eal_compare_pci_addr(const struct rte_pci_addr
*addr,
const struct rte_pci_addr *addr2);
/**
+ * Utility function to compare two PCI device addresses.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address to compare
+ * @param addr2
+ * The PCI Bus-Device-Function address to compare
+ * @return
+ * 0 on equal PCI address.
+ * Positive on addr is greater than addr2.
+ * Negative on addr is less than addr2, or error.
+ */
+int pci_addr_cmp(const struct rte_pci_addr *addr,
+const struct rte_pci_addr *addr2);
+
+/**
* Map a particular resource from a file.
*
* @param requested_addr
diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c
index cbb5359..54ce10d 100644
--- a/lib/librte_pci/rte_pci.c
+++ b/lib/librte_pci/rte_pci.c
@@ -73,6 +73,12 @@ get_u8_pciaddr_field(const char
[dpdk-dev] [PATCH v2 12/14] pci: avoid over-complicated macro
Using a macro helps writing the code to the detriment of the reader in
this case. This is backward. Write once, read many.
The few LOCs gained is not worth the opacity of the implementation.
Signed-off-by: Gaetan Rivet
---
lib/librte_pci/rte_pci.c | 65 ++--
1 file changed, 46 insertions(+), 19 deletions(-)
diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c
index 8584b55..cbb5359 100644
--- a/lib/librte_pci/rte_pci.c
+++ b/lib/librte_pci/rte_pci.c
@@ -53,36 +53,63 @@
#include "rte_pci.h"
-/* Macro used by pci addr parsing functions. **/
-#define GET_PCIADDR_FIELD(in, fd, lim, dlm) \
-do {\
- unsigned long val; \
- char *end; \
- errno = 0; \
- val = strtoul((in), &end, 16); \
- if (errno != 0 || end[0] != (dlm) || val > (lim)) \
- return -EINVAL; \
- (fd) = (typeof (fd))val;\
- (in) = end + 1; \
-} while(0)
+static inline const char *
+get_u8_pciaddr_field(const char *in, void *_u8, char dlm)
+{
+ unsigned long val;
+ uint8_t *u8 = _u8;
+ char *end;
+
+ errno = 0;
+ val = strtoul(in, &end, 16);
+ if (errno != 0 || end[0] != dlm || val > UINT8_MAX) {
+ errno = errno ? errno : EINVAL;
+ return NULL;
+ }
+ *u8 = (uint8_t)val;
+ return end + 1;
+}
int
eal_parse_pci_BDF(const char *input, struct rte_pci_addr *dev_addr)
{
+ const char *in = input;
+
dev_addr->domain = 0;
- GET_PCIADDR_FIELD(input, dev_addr->bus, UINT8_MAX, ':');
- GET_PCIADDR_FIELD(input, dev_addr->devid, UINT8_MAX, '.');
- GET_PCIADDR_FIELD(input, dev_addr->function, UINT8_MAX, 0);
+ in = get_u8_pciaddr_field(in, &dev_addr->bus, ':');
+ if (in == NULL)
+ return -EINVAL;
+ in = get_u8_pciaddr_field(in, &dev_addr->devid, '.');
+ if (in == NULL)
+ return -EINVAL;
+ in = get_u8_pciaddr_field(in, &dev_addr->function, '\0');
+ if (in == NULL)
+ return -EINVAL;
return 0;
}
int
eal_parse_pci_DomBDF(const char *input, struct rte_pci_addr *dev_addr)
{
- GET_PCIADDR_FIELD(input, dev_addr->domain, UINT16_MAX, ':');
- GET_PCIADDR_FIELD(input, dev_addr->bus, UINT8_MAX, ':');
- GET_PCIADDR_FIELD(input, dev_addr->devid, UINT8_MAX, '.');
- GET_PCIADDR_FIELD(input, dev_addr->function, UINT8_MAX, 0);
+ const char *in = input;
+ unsigned long val;
+ char *end;
+
+ errno = 0;
+ val = strtoul(in, &end, 16);
+ if (errno != 0 || end[0] != ':' || val > UINT16_MAX)
+ return -EINVAL;
+ dev_addr->domain = (uint16_t)val;
+ in = end + 1;
+ in = get_u8_pciaddr_field(in, &dev_addr->bus, ':');
+ if (in == NULL)
+ return -EINVAL;
+ in = get_u8_pciaddr_field(in, &dev_addr->devid, '.');
+ if (in == NULL)
+ return -EINVAL;
+ in = get_u8_pciaddr_field(in, &dev_addr->function, '\0');
+ if (in == NULL)
+ return -EINVAL;
return 0;
}
--
2.1.4
[dpdk-dev] [PATCH v2 14/14] doc: add notes on EAL PCI API update
Add a section related to EAL API changes to 17.11 release notes. Signed-off-by: Gaetan Rivet --- doc/guides/rel_notes/release_17_11.rst | 28 1 file changed, 28 insertions(+) diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst index 8bf91bd..d5546ba 100644 --- a/doc/guides/rel_notes/release_17_11.rst +++ b/doc/guides/rel_notes/release_17_11.rst @@ -130,6 +130,34 @@ API Changes * Rework start and stop APIs into ``rte_service_runstate_set`` * Added API to set runstate of service implementation to indicate readyness +* **PCI bus API moved outside of the EAL** + + The PCI bus previously implemented within the EAL has been moved. + A first part has been added as an RTE library providing PCI helpers to + parse device locations or other such utilities. + A second part consisting in the actual bus driver has been moved to its + proper subdirectory, without changing its functionalities. + + As such, several PCI-related functions are not proposed by the EAL anymore: + + * rte_pci_detach + * rte_pci_dump + * rte_pci_ioport_map + * rte_pci_ioport_read + * rte_pci_ioport_unmap + * rte_pci_ioport_write + * rte_pci_map_device + * rte_pci_probe + * rte_pci_probe_one + * rte_pci_read_config + * rte_pci_register + * rte_pci_scan + * rte_pci_unmap_device + * rte_pci_unregister + * rte_pci_write_config + + These functions are made available either as part of ``librte_pci`` or + ``librte_bus_pci``. ABI Changes --- -- 2.1.4
Re: [dpdk-dev] [PATCH 0/2] have crypto drivers use a standard map file name format
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, September 14, 2017 5:02 PM
> To: De Lara Guarch, Pablo ; Doherty,
> Declan ; jerin.ja...@caviumnetworks.com
> Cc: dev@dpdk.org; Richardson, Bruce
> Subject: [dpdk-dev] [PATCH 0/2] have crypto drivers use a standard map file
> name format
>
> rename some of the version.map files that don't match the standard naming
> convention. For future meson build system, this will save us having to specify
> for each driver what the filename of its map file is.
>
> Bruce Richardson (2):
> crypto/aesni_mb: rename map file to standard name
> crypto/armv8: rename map file to standard name
>
> drivers/crypto/aesni_mb/Makefile| 2
> +-
> .../{rte_pmd_aesni_version.map => rte_pmd_aesni_mb_version.map}
> | 0
> drivers/crypto/armv8/Makefile | 2
> +-
> .../armv8/{rte_armv8_pmd_version.map => rte_pmd_armv8_version.map}
> | 0
> 4 files changed, 2 insertions(+), 2 deletions(-) rename
> drivers/crypto/aesni_mb/{rte_pmd_aesni_version.map =>
> rte_pmd_aesni_mb_version.map} (100%) rename
> drivers/crypto/armv8/{rte_armv8_pmd_version.map =>
> rte_pmd_armv8_version.map} (100%)
>
> --
> 2.13.5
Series Acked by: Fan Zhang
Re: [dpdk-dev] [PATCH v2 1/2] app/crypto-perf: add nb-desc parameter
> -Original Message- > From: Burakov, Anatoly > Sent: Tuesday, September 12, 2017 10:36 AM > To: dev@dpdk.org > Cc: Doherty, Declan ; De Lara Guarch, Pablo > > Subject: [PATCH v2 1/2] app/crypto-perf: add nb-desc parameter > > This parameter makes number of cryptodev descriptors adjustable and > defaults to earlier hardcoded default of 2048. > > Signed-off-by: Anatoly Burakov Reviewed-by: Pablo de Lara
Re: [dpdk-dev] [PATCH v3 1/2] net/mlx5: replace network to host macros
> -Original Message-
> From: Yongseok Koh
> Sent: Friday, September 15, 2017 11:50 PM
> To: Shachar Beiser
> Cc: dev@dpdk.org; Adrien Mazarguil ; Nélio
> Laranjeiro
> Subject: Re: [dpdk-dev] [PATCH v3 1/2] net/mlx5: replace network to host
> macros
>
>
> > On Sep 14, 2017, at 6:43 AM, Shachar Beiser
> wrote:
> >
> > Signed-off-by: Shachar Beiser
> > ---
> [...]
> > @@ -550,7 +553,8 @@
> > max_wqe -= n;
> > if (tso) {
> > uint32_t inl =
> > - htonl(copy_b |
> MLX5_INLINE_SEG);
> > + rte_cpu_to_be_32(copy_b |
> > +MLX5_INLINE_SEG);
> Wrong indentation.
>
Since there is a constrain of 80 characters a line , this indentation was
accepted by
Nélio .
> [...]
> > @@ -605,8 +605,8 @@ int mlx5_tx_queue_setup(struct rte_eth_dev *,
> uint16_t, uint16_t, unsigned int,
> > uint64_t *dst = (uint64_t *)((uintptr_t)txq->bf_reg);
> > volatile uint64_t *src = ((volatile uint64_t *)wqe);
> >
> > - rte_io_wmb();
> > - *txq->qp_db = htonl(txq->wqe_ci);
> > + rte_wmb();
> Look like a mistake when rebasing. This should not be touched by this patch.
>
> > + *txq->qp_db = rte_cpu_to_be_32(txq->wqe_ci);
> > /* Ensure ordering between DB record and BF copy. */
> > rte_wmb();
> > *dst = *src;
>
Yes , this is true. There is a fix for this issue in the coming patch:
[dpdk-dev,v4,1/2] net/mlx5: replace network to host macros
http://dpdk.org/dev/patchwork/patch/28804/
> --
> Thanks,
> Yongseok
>
Re: [dpdk-dev] [PATCH v7 1/9] eal/pci: export match function
Hi Ferruh,
On Wednesday 06 September 2017 09:09 PM, Ferruh Yigit wrote:
> On 8/31/2017 4:26 AM, Santosh Shukla wrote:
>> Export rte_pci_match() function as it needed in the followup patch.
>>
>> Signed-off-by: Santosh Shukla
>> Signed-off-by: Jerin Jacob
>> Acked-by: Maxime Coquelin
>> ---
>> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 7 +++
>> lib/librte_eal/common/eal_common_pci.c | 10 +-
>> lib/librte_eal/common/include/rte_pci.h | 15 +++
>> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 7 +++
>> 4 files changed, 30 insertions(+), 9 deletions(-)
>>
>> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
>> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
>> index aac6fd776..c819e3084 100644
>> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
>> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
>> @@ -237,3 +237,10 @@ EXPERIMENTAL {
>> rte_service_unregister;
>>
>> } DPDK_17.08;
>> +
>> +DPDK_17.11 {
>> +global:
>> +
>> +rte_pci_match;
>> +
>> +} DPDK_17.08;
> Is updating .map file required? As far as I can see rte_pci_match()
> calls are within the same library, and no need to expose the API out of
> library.
>
> <...>
>
Its used in file eal/eal_pci.c in following patch.
Thanks.
Re: [dpdk-dev] [PATCH] bonding: fix wrong slaves capacity check
On 27/07/2017 1:00 PM, Tomasz Kulasek wrote:
For fortville NIC bond_ethdev_8023ad_flow_verify fails when action queue
index indicates unavailable queue before slaves configuration.
This fix verifies flow settings for queue 0, which is always available,
and checks if slaves max queue number capacity meets requirements.
Fixes: 112891cd27e5 ("net/bonding: add dedicated HW queues for LACP control")
Signed-off-by: Tomasz Kulasek
---
...
Acked-by: Declan Doherty
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > 13/09/2017 23:42, Ananyev, Konstantin: > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > Konstantin, I would like your opinion about the proposal below. > > > It is about making on the fly configuration more generic. > > > You say it is possible to configure VLAN on the fly, > > > and I think we should make it possible for other offload features. > > > > It would be a good thing, but I don't think it is possible for all offloads. > > For some of them you still have to stop the queue(port) first. > > > > Also I am not sure what exactly do you propose? > > Is that something like that: > > - wipe existing offload bitfileds from rte_eth_rxmode (already done by > > Shahaf) > > - Instead of uint64_t offloads inside both rte_eth_rxmode and te_eth_rxconf > > Introduce new functions: > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t offload_mask); Would be useful to have a valid mask here, to indicate what bits to use. That way, you can adjust one bit without worrying about what other bits you may change in the process. There are probably apps out there that just want to toggle a single bit on, and off, at runtime while ignoring others. Alternatively, we can have set/unset functions which enable/disable offloads, based on the mask. > > > > uint64_t rte_eth_get_port_rx_offload(portid); > > uint64_t rte_eth_set_queue_rx_offload(portid, queueid); s/set/get/ > > > > And add new fileds: > > rx_offload_port_dynamic_capa > > rx_offload_queue_dynamic_capa > > inside rte_eth_dev_info. > > > > And it would be user responsibility to call set_port/queue_rx_offload() > > somewhere before dev_start() for static offloads. > > ? > > Yes exactly. > > > If so, then it seems reasonable to me. > > Good, thank you > > Sorry I'm a bit late to the review, but the above suggestion of separate APIs for enabling offloads, seems much better than passing in the flags in structures to the existing calls. From what I see all later revisions of this patchset still use the existing flags parameter to setup calls method. Some advantages that I see of the separate APIs: * allows some settings to be set before start, and others afterwards, with an appropriate return value if dynamic config not supported. * we can get fine grained error reporting from these - the set calls can all return the mask indicating what offloads could not be applied - zero means all ok, 1 means a problem with that setting. This may be easier for the app to use than feature discovery in some cases. * for those PMDs which support configuration at a per-queue level, it can allow the user to specify the per-port settings as a default, and then override that value at the queue level, if you just want one queue different from the rest. Regards, /Bruce
Re: [dpdk-dev] [PATCH v2 01/14] eal: expose rte_eal_using_phys_addrs
Hello Gaetan,
On Monday 18 September 2017 03:01 PM, Gaetan Rivet wrote:
This function was previously private to the EAL layer.
Other subsystems requires it, such as the PCI bus.
In order not to force other components to include stdbool, which is
incompatible with several NIC drivers, the return type has
been changed from bool to int.
Signed-off-by: Gaetan Rivet
---
[...]
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 5279128..af8719b 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1542,7 +1542,7 @@ rte_eal_hugepage_attach(void)
return -1;
}
-bool
+int
rte_eal_using_phys_addrs(void)
{
return phys_addrs_available;
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 8c08b8d..f866b70 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -205,6 +205,7 @@ DPDK_17.08 {
This symbol should be added to 17.11, isn't it?
rte_bus_find;
rte_bus_find_by_device;
rte_bus_find_by_name;
+ rte_eal_using_phys_addrs;
rte_log_get_level;
} DPDK_17.05;
-
Shreyansh
[dpdk-dev] [PATCH v8 0/9] Infrastructure to detect iova mapping on the bus
v8: Includes minor review changes per v7 review comment from Anatoly. Patches rebased on Tip commit:3d2e0448eb. v7: Includes no major change, minor change detailing: - patch sqashing (Aaron suggestion) - added run_once for device_parse() and bus_scan() in eal init (Aaron suggestion) - Moved rte_eal_device_parse() up in eal initialization order. - Patches rebased on top of version: 17.11-rc0 For v6 info refer [11]. v6: Sending v5 series rebased on top of version: 17.11-rc0. v5: Introducing RTE_PCI_DRV_IOVA_AS_VA flag for autodetection of iova va mapping. If a PCI driver demand for IOVA as VA scheme then the driver can add it in the PCI driver registration function. Algorithm to select IOVA as VA for PCI bus case: 0. If no device bound then return with RTE_IOVA_DC mapping mode, else goto 1). 1. Look for device attached to vfio kdrv and has .drv_flag set to RTE_PCI_DRV_IOVA_AS_VA. 2. Look for any device attached to UIO class of driver. 3. Check for vfio-noiommu mode enabled. If 2) & 3) is false and 1) is true then select mapping scheme as RTE_IOVA_VA. Otherwise use default mapping scheme (RTE_IOVA_PA). That way, Bus can truly autodetect the iova mapping mode for a device Or a set of the device. Change History: v7 --> v8: - Replace 0 / 1 with true/false boolean values (Suggested by Anatoly). v6 --> v7: - Patches squashed per v6. - Added run_once in eal per v6. - Moved rte_eal_device_parse() up in eal init oder. v5 --> v6: - Added api info in eal's versiom.map (release DPDK_v17.11). v4 --> v5: - Change DPDK_17.08 to DPDK_17.11 in _version.map. - Reworded bus api description (suggested by Hemant). - Added reviewed-by from Maxime in v5. - Added acked-by from Hemant for pci and bus patches. v3 --> v4: - Re-introduced RTE_IOVA_DEC mode (Suggested by Hemant [5]). - Renamed flag to RTE_PCI_DRV_IOVA_AS_VA (Suggested by Maxime). - Reworded WARNING message(suggested by Maxime[7]). - Created a separate patch for rte_pci_get_iommu_class (suggested by Maxime[]). - Added VFIO_PRESENT ifdef build fix. v2 --> v3: - Removed rte_mempool_virt2phy (suggested by Olivier [4]) v1 --> v2: - Removed override eal option i.e. (--iova-mode=<>) Because we have means to truly autodetect the iova mode. - Introduced RTE_PCI_DRV_NEED_IOVA_VA drv_flag (Suggested by Maxime [3]). - Using NEED_IOVA_VA drv_flag in autodetection logic. - Removed Linux version check macro in vfio code, As per Maxime feedback. - Moved rte_pci_match API from local to global. Patch Summary: 1) 1nd: declare rte_pci_match api in pci header. Required for autodetection in follow up patches. 2) 2nd - 3rd - 4th : autodetection mapping infrastructure for Linux/bsdapp. 3) 5th: iova mode helper API. 4) 6th: Infra to detect iova mode. 5) 7th: make vfio mapping iova aware. 6) 8th - 9th : Check for IOVA_VA mode in below APIs - rte_mem_virt2phy - rte_malloc_virt2phy Test History: - Tested for x86/XL710 40G NIC card for both modes (iova_va/pa). - Tested for arm64/thunderx vNIC Integrated NIC for both modes - Tested for arm64/Octeontx integrated NICs for only Iova_va mode(It supports only one mode.) - Ran standalone tests like mempool_autotest, mbuf_autotest. - Verified for Doxygen. Work History: For v1, Refer [1]. For v2, Refer [2]. For v3, Refer [9]. For v4, refer [10]. for v6, refer [11]. Checkpatch result: * None Thanks., [1] https://www.mail-archive.com/dev@dpdk.org/msg67438.html [2] https://www.mail-archive.com/dev@dpdk.org/msg70674.html [3] https://www.mail-archive.com/dev@dpdk.org/msg70279.html [4] https://www.mail-archive.com/dev@dpdk.org/msg70692.html [5] http://dpdk.org/ml/archives/dev/2017-July/071282.html [6] http://dpdk.org/ml/archives/dev/2017-July/070951.html [7] http://dpdk.org/ml/archives/dev/2017-July/070941.html [8] http://dpdk.org/ml/archives/dev/2017-July/070952.html [9] http://dpdk.org/ml/archives/dev/2017-July/070918.html [10] http://dpdk.org/ml/archives/dev/2017-July/071754.html [11] http://dpdk.org/ml/archives/dev/2017-August/072871.html Santosh Shukla (9): eal/pci: export match function eal/pci: get iommu class linuxapp/eal_pci: get iommu class bus: get iommu class eal: introduce iova mode helper api eal: auto detect iova mode linuxapp/eal_vfio: honor iova mode before mapping linuxapp/eal_memory: honor iova mode in virt2phy eal/rte_malloc: honor iova mode in virt2phy lib/librte_eal/bsdapp/eal/eal.c | 33 ++--- lib/librte_eal/bsdapp/eal/eal_pci.c | 10 +++ lib/librte_eal/bsdapp/eal/rte_eal_version.map | 10 +++ lib/librte_eal/common/eal_common_bus.c | 23 ++ lib/librte_eal/common/eal_common_pci.c | 11 +-- lib/librte_eal/common/include/rte_bus.h | 35 + lib/librte_eal/common/include/rte_eal.h | 12 lib/librte_eal/common/include/rte_pci.h | 28 lib/librte_eal/common/rte_malloc.c | 9 ++- lib/librte_eal/linuxapp/eal/eal.c
[dpdk-dev] [PATCH v8 1/9] eal/pci: export match function
Export rte_pci_match() function as it needed in the followup patch.
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Acked-by: Maxime Coquelin
Reviewed-by: Anatoly Burakov
---
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 7 +++
lib/librte_eal/common/eal_common_pci.c | 10 +-
lib/librte_eal/common/include/rte_pci.h | 15 +++
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 7 +++
4 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 47a09ea7f..cfbf8fbd0 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -238,3 +238,10 @@ EXPERIMENTAL {
rte_service_start_with_defaults;
} DPDK_17.08;
+
+DPDK_17.11 {
+ global:
+
+ rte_pci_match;
+
+} DPDK_17.08;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 52fd38cdd..3b7d0a0ee 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -150,16 +150,8 @@ pci_unmap_resource(void *requested_addr, size_t size)
/*
* Match the PCI Driver and Device using the ID Table
- *
- * @param pci_drv
- * PCI driver from which ID table would be extracted
- * @param pci_dev
- * PCI device to match against the driver
- * @return
- * 1 for successful match
- * 0 for unsuccessful match
*/
-static int
+int
rte_pci_match(const struct rte_pci_driver *pci_drv,
const struct rte_pci_device *pci_dev)
{
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 8b123391c..eab84c7a4 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -366,6 +366,21 @@ int rte_pci_scan(void);
int
rte_pci_probe(void);
+/*
+ * Match the PCI Driver and Device using the ID Table
+ *
+ * @param pci_drv
+ * PCI driver from which ID table would be extracted
+ * @param pci_dev
+ * PCI device to match against the driver
+ * @return
+ * 1 for successful match
+ * 0 for unsuccessful match
+ */
+int
+rte_pci_match(const struct rte_pci_driver *pci_drv,
+ const struct rte_pci_device *pci_dev);
+
/**
* Map the PCI device resources in user space virtual memory address
*
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 8c08b8d1e..287cc75cd 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -243,3 +243,10 @@ EXPERIMENTAL {
rte_service_start_with_defaults;
} DPDK_17.08;
+
+DPDK_17.11 {
+ global:
+
+ rte_pci_match;
+
+} DPDK_17.08;
--
2.14.1
[dpdk-dev] [PATCH v8 2/9] eal/pci: get iommu class
Introducing rte_pci_get_iommu_class API which helps to get iommu class
of PCI device on the bus and returns preferred iova mapping mode for
PCI bus.
Patch also add rte_pci_get_iommu_class definition for bsdapp,
in bsdapp case - api returns default iova mode.
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
---
v6 --> v7:
- squashed v6 series patch [02/12] & [03/12] (Aaron comment).
lib/librte_eal/bsdapp/eal/eal_pci.c | 10 ++
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/include/rte_bus.h | 10 ++
lib/librte_eal/common/include/rte_pci.h | 11 +++
4 files changed, 32 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 04eacdcc7..e2c252320 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -403,6 +403,16 @@ rte_pci_scan(void)
return -1;
}
+/*
+ * Get iommu class of pci devices on the bus.
+ */
+enum rte_iova_mode
+rte_pci_get_iommu_class(void)
+{
+ /* Supports only RTE_KDRV_NIC_UIO */
+ return RTE_IOVA_PA;
+}
+
int
pci_update_device(const struct rte_pci_addr *addr)
{
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index cfbf8fbd0..c6ffd9399 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -243,5 +243,6 @@ DPDK_17.11 {
global:
rte_pci_match;
+ rte_pci_get_iommu_class;
} DPDK_17.08;
diff --git a/lib/librte_eal/common/include/rte_bus.h
b/lib/librte_eal/common/include/rte_bus.h
index c79368d3c..9e40687e5 100644
--- a/lib/librte_eal/common/include/rte_bus.h
+++ b/lib/librte_eal/common/include/rte_bus.h
@@ -55,6 +55,16 @@ extern "C" {
/** Double linked list of buses */
TAILQ_HEAD(rte_bus_list, rte_bus);
+
+/**
+ * IOVA mapping mode.
+ */
+enum rte_iova_mode {
+ RTE_IOVA_DC = 0,/* Don't care mode */
+ RTE_IOVA_PA = (1 << 0),
+ RTE_IOVA_VA = (1 << 1)
+};
+
/**
* Bus specific scan for devices attached on the bus.
* For each bus object, the scan would be responsible for finding devices and
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index eab84c7a4..0e36de093 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -381,6 +381,17 @@ int
rte_pci_match(const struct rte_pci_driver *pci_drv,
const struct rte_pci_device *pci_dev);
+
+/**
+ * Get iommu class of PCI devices on the bus.
+ * And return their preferred iova mapping mode.
+ *
+ * @return
+ * - enum rte_iova_mode.
+ */
+enum rte_iova_mode
+rte_pci_get_iommu_class(void);
+
/**
* Map the PCI device resources in user space virtual memory address
*
--
2.14.1
[dpdk-dev] [PATCH v8 3/9] linuxapp/eal_pci: get iommu class
Get iommu class of PCI device on the bus and returns preferred iova
mapping mode for that bus.
Patch also introduces RTE_PCI_DRV_IOVA_AS_VA drv flag.
Flag used when driver needs to operate in iova=va mode.
Algorithm for iova scheme selection for PCI bus:
0. If no device bound then return with RTE_IOVA_DC mapping mode,
else goto 1).
1. Look for device attached to vfio kdrv and has .drv_flag set
to RTE_PCI_DRV_IOVA_AS_VA.
2. Look for any device attached to UIO class of driver.
3. Check for vfio-noiommu mode enabled.
If 2) & 3) is false and 1) is true then select
mapping scheme as RTE_IOVA_VA. Otherwise use default
mapping scheme (RTE_IOVA_PA).
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
Acked-by: Hemant Agrawal
Reviewed-by: Anatoly Burakov
---
v7 --> v8:
- Replaced 0/1 with false/true boolean value (Suggested by Anatoly)
v6 --> v7:
- squashed v6 series patch no [01/12] & [05/12]..
i.e.. moved RTE_PCI_DRV_IOVA_AS_VA flag into this patch. (Aaron comment).
lib/librte_eal/common/include/rte_pci.h | 2 +
lib/librte_eal/linuxapp/eal/eal_pci.c | 96 +
lib/librte_eal/linuxapp/eal/eal_vfio.c | 19 +
lib/librte_eal/linuxapp/eal/eal_vfio.h | 4 ++
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
5 files changed, 122 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 0e36de093..a67d77f22 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -202,6 +202,8 @@ struct rte_pci_bus {
#define RTE_PCI_DRV_INTR_RMV 0x0010
/** Device driver needs to keep mapped resources if unsupported dev detected */
#define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
+/** Device driver supports iova as va */
+#define RTE_PCI_DRV_IOVA_AS_VA 0X0040
/**
* A structure describing a PCI mapping.
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 8951ce742..2971f1d4f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -45,6 +45,7 @@
#include "eal_filesystem.h"
#include "eal_private.h"
#include "eal_pci_init.h"
+#include "eal_vfio.h"
/**
* @file
@@ -487,6 +488,101 @@ rte_pci_scan(void)
return -1;
}
+/*
+ * Is pci device bound to any kdrv
+ */
+static inline int
+pci_device_is_bound(void)
+{
+ struct rte_pci_device *dev = NULL;
+ int ret = 0;
+
+ FOREACH_DEVICE_ON_PCIBUS(dev) {
+ if (dev->kdrv == RTE_KDRV_UNKNOWN ||
+ dev->kdrv == RTE_KDRV_NONE) {
+ continue;
+ } else {
+ ret = 1;
+ break;
+ }
+ }
+ return ret;
+}
+
+/*
+ * Any one of the device bound to uio
+ */
+static inline int
+pci_device_bound_uio(void)
+{
+ struct rte_pci_device *dev = NULL;
+
+ FOREACH_DEVICE_ON_PCIBUS(dev) {
+ if (dev->kdrv == RTE_KDRV_IGB_UIO ||
+ dev->kdrv == RTE_KDRV_UIO_GENERIC) {
+ return 1;
+ }
+ }
+ return 0;
+}
+
+/*
+ * Any one of the device has iova as va
+ */
+static inline int
+pci_device_has_iova_va(void)
+{
+ struct rte_pci_device *dev = NULL;
+ struct rte_pci_driver *drv = NULL;
+
+ FOREACH_DRIVER_ON_PCIBUS(drv) {
+ if (drv && drv->drv_flags & RTE_PCI_DRV_IOVA_AS_VA) {
+ FOREACH_DEVICE_ON_PCIBUS(dev) {
+ if (dev->kdrv == RTE_KDRV_VFIO &&
+ rte_pci_match(drv, dev))
+ return 1;
+ }
+ }
+ }
+ return 0;
+}
+
+/*
+ * Get iommu class of PCI devices on the bus.
+ */
+enum rte_iova_mode
+rte_pci_get_iommu_class(void)
+{
+ bool is_bound;
+ bool is_vfio_noiommu_enabled = true;
+ bool has_iova_va;
+ bool is_bound_uio;
+
+ is_bound = pci_device_is_bound();
+ if (!is_bound)
+ return RTE_IOVA_DC;
+
+ has_iova_va = pci_device_has_iova_va();
+ is_bound_uio = pci_device_bound_uio();
+#ifdef VFIO_PRESENT
+ is_vfio_noiommu_enabled = vfio_noiommu_is_enabled() == true ?
+ true : false;
+#endif
+
+ if (has_iova_va && !is_bound_uio && !is_vfio_noiommu_enabled)
+ return RTE_IOVA_VA;
+
+ if (has_iova_va) {
+ RTE_LOG(WARNING, EAL, "Some devices want iova as va but pa will
be used because.. ");
+ if (is_vfio_noiommu_enabled)
+ RTE_LOG(WARNING, EAL, "vfio-noiommu mode configured\n");
+ if (is_bound_uio)
+ RTE_LOG(WARNING, EAL, "few device bound to UIO\n");
+ }
+
+ return RTE_IOVA_PA;
+}
+
/* Read PCI config space. */
int rte_pci_read_config(const struct rte_pci_device *d
[dpdk-dev] [PATCH v8 4/9] bus: get iommu class
API(rte_bus_get_iommu_class) helps to automatically detect and select
appropriate iova mapping scheme for iommu capable device on that bus.
Algorithm for iova scheme selection for bus:
0. Iterate through bus_list.
1. Collect each bus iova mode value and update into 'mode' var.
2. Mode selection scheme is:
if mode == 0 then iova mode is _pa,
if mode == 1 then iova mode is _pa,
if mode == 2 then iova mode is _va,
if mode == 3 then iova mode ia _pa.
So mode !=2 will be default iova mode (_pa).
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
Acked-by: Hemant Agrawal
Reviewed-by: Anatoly Burakov
---
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/eal_common_bus.c | 23 +++
lib/librte_eal/common/eal_common_pci.c | 1 +
lib/librte_eal/common/include/rte_bus.h | 25 +
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
5 files changed, 51 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index c6ffd9399..3466eaf20 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -244,5 +244,6 @@ DPDK_17.11 {
rte_pci_match;
rte_pci_get_iommu_class;
+ rte_bus_get_iommu_class;
} DPDK_17.08;
diff --git a/lib/librte_eal/common/eal_common_bus.c
b/lib/librte_eal/common/eal_common_bus.c
index 08bec2d93..a30a8982e 100644
--- a/lib/librte_eal/common/eal_common_bus.c
+++ b/lib/librte_eal/common/eal_common_bus.c
@@ -222,3 +222,26 @@ rte_bus_find_by_device_name(const char *str)
c[0] = '\0';
return rte_bus_find(NULL, bus_can_parse, name);
}
+
+
+/*
+ * Get iommu class of devices on the bus.
+ */
+enum rte_iova_mode
+rte_bus_get_iommu_class(void)
+{
+ int mode = RTE_IOVA_DC;
+ struct rte_bus *bus;
+
+ TAILQ_FOREACH(bus, &rte_bus_list, next) {
+
+ if (bus->get_iommu_class)
+ mode |= bus->get_iommu_class();
+ }
+
+ if (mode != RTE_IOVA_VA) {
+ /* Use default IOVA mode */
+ mode = RTE_IOVA_PA;
+ }
+ return mode;
+}
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 3b7d0a0ee..0f0e4b93b 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -564,6 +564,7 @@ struct rte_pci_bus rte_pci_bus = {
.plug = pci_plug,
.unplug = pci_unplug,
.parse = pci_parse,
+ .get_iommu_class = rte_pci_get_iommu_class,
},
.device_list = TAILQ_HEAD_INITIALIZER(rte_pci_bus.device_list),
.driver_list = TAILQ_HEAD_INITIALIZER(rte_pci_bus.driver_list),
diff --git a/lib/librte_eal/common/include/rte_bus.h
b/lib/librte_eal/common/include/rte_bus.h
index 9e40687e5..70a291a4d 100644
--- a/lib/librte_eal/common/include/rte_bus.h
+++ b/lib/librte_eal/common/include/rte_bus.h
@@ -178,6 +178,20 @@ struct rte_bus_conf {
enum rte_bus_scan_mode scan_mode; /**< Scan policy. */
};
+
+/**
+ * Get common iommu class of the all the devices on the bus. The bus may
+ * check that those devices are attached to iommu driver.
+ * If no devices are attached to the bus. The bus may return with don't care
+ * (_DC) value.
+ * Otherwise, The bus will return appropriate _pa or _va iova mode.
+ *
+ * @return
+ * enum rte_iova_mode value.
+ */
+typedef enum rte_iova_mode (*rte_bus_get_iommu_class_t)(void);
+
+
/**
* A structure describing a generic bus.
*/
@@ -191,6 +205,7 @@ struct rte_bus {
rte_bus_unplug_t unplug; /**< Remove single device from driver */
rte_bus_parse_t parse; /**< Parse a device name */
struct rte_bus_conf conf;/**< Bus configuration */
+ rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
};
/**
@@ -290,6 +305,16 @@ struct rte_bus *rte_bus_find_by_device(const struct
rte_device *dev);
*/
struct rte_bus *rte_bus_find_by_name(const char *busname);
+
+/**
+ * Get the common iommu class of devices bound on to buses available in the
+ * system. The default mode is PA.
+ *
+ * @return
+ * enum rte_iova_mode value.
+ */
+enum rte_iova_mode rte_bus_get_iommu_class(void);
+
/**
* Helper for Bus registration.
* The constructor has higher priority than PMD constructors.
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index a8c8ea4f4..9115aa3e9 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -249,5 +249,6 @@ DPDK_17.11 {
rte_pci_match;
rte_pci_get_iommu_class;
+ rte_bus_get_iommu_class;
} DPDK_17.08;
--
2.14.1
[dpdk-dev] [PATCH v8 5/9] eal: introduce iova mode helper api
Introducing rte_eal_iova_mode() helper API. This API
used by non-eal library for detecting iova mode.
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
---
lib/librte_eal/bsdapp/eal/eal.c | 6 ++
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/include/rte_eal.h | 12
lib/librte_eal/linuxapp/eal/eal.c | 6 ++
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
5 files changed, 26 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 5fa598842..07e72203f 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -119,6 +119,12 @@ rte_eal_get_configuration(void)
return &rte_config;
}
+enum rte_iova_mode
+rte_eal_iova_mode(void)
+{
+ return rte_eal_get_configuration()->iova_mode;
+}
+
/* parse a sysfs (or other) file containing one integer value */
int
eal_parse_sysfs_value(const char *filename, unsigned long *val)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 3466eaf20..6bed74dff 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -245,5 +245,6 @@ DPDK_17.11 {
rte_pci_match;
rte_pci_get_iommu_class;
rte_bus_get_iommu_class;
+ rte_eal_iova_mode;
} DPDK_17.08;
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index 0e7363d77..932dc1a96 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -45,6 +45,7 @@
#include
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -87,6 +88,9 @@ struct rte_config {
/** Primary or secondary configuration */
enum rte_proc_type_t process_type;
+ /** PA or VA mapping mode */
+ enum rte_iova_mode iova_mode;
+
/**
* Pointer to memory configuration, which may be shared across multiple
* DPDK instances
@@ -287,6 +291,14 @@ static inline int rte_gettid(void)
return RTE_PER_LCORE(_thread_id);
}
+/**
+ * Get the iova mode
+ *
+ * @return
+ * enum rte_iova_mode value.
+ */
+enum rte_iova_mode rte_eal_iova_mode(void);
+
#define RTE_INIT(func) \
static void __attribute__((constructor, used)) func(void)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 48f12f44c..febbafdb3 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -128,6 +128,12 @@ rte_eal_get_configuration(void)
return &rte_config;
}
+enum rte_iova_mode
+rte_eal_iova_mode(void)
+{
+ return rte_eal_get_configuration()->iova_mode;
+}
+
/* parse a sysfs (or other) file containing one integer value */
int
eal_parse_sysfs_value(const char *filename, unsigned long *val)
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 9115aa3e9..8e49bf5fa 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -250,5 +250,6 @@ DPDK_17.11 {
rte_pci_match;
rte_pci_get_iommu_class;
rte_bus_get_iommu_class;
+ rte_eal_iova_mode;
} DPDK_17.08;
--
2.14.1
[dpdk-dev] [PATCH v8 6/9] eal: auto detect iova mode
For auto detection purpose:
* Below calls moved up in the eal initialization order:
- eal_option_device_parse
- rte_bus_scan
Based on the result of rte_bus_scan_iommu_class - select iova
mapping mode.
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
Reviewed-by: Anatoly Burakov
---
v6 --> v7:
- Moved eal_option_device_parse() up in then order of eal init.
- Added run_once. (aaron suggestion).
- squashed v6 series patch no. [08/12] & [09/12] into one patch (Aaron
comment)
lib/librte_eal/bsdapp/eal/eal.c | 27 ---
lib/librte_eal/linuxapp/eal/eal.c | 27 ---
2 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 07e72203f..f003f4c04 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -541,6 +541,22 @@ rte_eal_init(int argc, char **argv)
return -1;
}
+ if (eal_option_device_parse()) {
+ rte_errno = ENODEV;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
+
+ if (rte_bus_scan()) {
+ rte_eal_init_alert("Cannot scan the buses for devices\n");
+ rte_errno = ENODEV;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
+
+ /* autodetect the iova mapping mode (default is iova_pa) */
+ rte_eal_get_configuration()->iova_mode = rte_bus_get_iommu_class();
+
if (internal_config.no_hugetlbfs == 0 &&
internal_config.process_type != RTE_PROC_SECONDARY &&
eal_hugepage_info_init() < 0) {
@@ -620,17 +636,6 @@ rte_eal_init(int argc, char **argv)
rte_config.master_lcore, thread_id, cpuset,
ret == 0 ? "" : "...");
- if (eal_option_device_parse()) {
- rte_errno = ENODEV;
- return -1;
- }
-
- if (rte_bus_scan()) {
- rte_eal_init_alert("Cannot scan the buses for devices\n");
- rte_errno = ENODEV;
- return -1;
- }
-
RTE_LCORE_FOREACH_SLAVE(i) {
/*
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index febbafdb3..f4901ffb6 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -798,6 +798,22 @@ rte_eal_init(int argc, char **argv)
return -1;
}
+ if (eal_option_device_parse()) {
+ rte_errno = ENODEV;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
+
+ if (rte_bus_scan()) {
+ rte_eal_init_alert("Cannot scan the buses for devices\n");
+ rte_errno = ENODEV;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
+
+ /* autodetect the iova mapping mode (default is iova_pa) */
+ rte_eal_get_configuration()->iova_mode = rte_bus_get_iommu_class();
+
if (internal_config.no_hugetlbfs == 0 &&
internal_config.process_type != RTE_PROC_SECONDARY &&
internal_config.xen_dom0_support == 0 &&
@@ -895,17 +911,6 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- if (eal_option_device_parse()) {
- rte_errno = ENODEV;
- return -1;
- }
-
- if (rte_bus_scan()) {
- rte_eal_init_alert("Cannot scan the buses for devices\n");
- rte_errno = ENODEV;
- return -1;
- }
-
RTE_LCORE_FOREACH_SLAVE(i) {
/*
--
2.14.1
[dpdk-dev] [PATCH v8 7/9] linuxapp/eal_vfio: honor iova mode before mapping
Check iova mode and accordingly map iova to pa or va. Signed-off-by: Santosh Shukla Signed-off-by: Jerin Jacob Reviewed-by: Maxime Coquelin Acked-by: Anatoly Burakov --- lib/librte_eal/linuxapp/eal/eal_vfio.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/librte_eal/linuxapp/eal/eal_vfio.c index c8a97b7e7..b32cd09a2 100644 --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c @@ -706,7 +706,10 @@ vfio_type1_dma_map(int vfio_container_fd) dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map); dma_map.vaddr = ms[i].addr_64; dma_map.size = ms[i].len; - dma_map.iova = ms[i].phys_addr; + if (rte_eal_iova_mode() == RTE_IOVA_VA) + dma_map.iova = dma_map.vaddr; + else + dma_map.iova = ms[i].phys_addr; dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE; ret = ioctl(vfio_container_fd, VFIO_IOMMU_MAP_DMA, &dma_map); @@ -792,7 +795,10 @@ vfio_spapr_dma_map(int vfio_container_fd) dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map); dma_map.vaddr = ms[i].addr_64; dma_map.size = ms[i].len; - dma_map.iova = ms[i].phys_addr; + if (rte_eal_iova_mode() == RTE_IOVA_VA) + dma_map.iova = dma_map.vaddr; + else + dma_map.iova = ms[i].phys_addr; dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE; -- 2.14.1
[dpdk-dev] [PATCH v8 8/9] linuxapp/eal_memory: honor iova mode in virt2phy
Check iova mode and accordingly return phy addr.
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
Reviewed-by: Anatoly Burakov
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 52791282f..2d9d7c2dc 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -139,6 +139,9 @@ rte_mem_virt2phy(const void *virtaddr)
int page_size;
off_t offset;
+ if (rte_eal_iova_mode() == RTE_IOVA_VA)
+ return (uintptr_t)virtaddr;
+
/* when using dom0, /proc/self/pagemap always returns 0, check in
* dpdk memory by browsing the memsegs */
if (rte_xen_dom0_supported()) {
--
2.14.1
[dpdk-dev] [PATCH v8 9/9] eal/rte_malloc: honor iova mode in virt2phy
Check iova mode and accordingly return phy addr.
Signed-off-by: Santosh Shukla
Signed-off-by: Jerin Jacob
Reviewed-by: Maxime Coquelin
Reviewed-by: Anatoly Burakov
---
lib/librte_eal/common/rte_malloc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/rte_malloc.c
b/lib/librte_eal/common/rte_malloc.c
index 5c0627bf4..d65c05a4d 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -251,10 +251,17 @@ rte_malloc_set_limit(__rte_unused const char *type,
phys_addr_t
rte_malloc_virt2phy(const void *addr)
{
+ phys_addr_t paddr;
const struct malloc_elem *elem = malloc_elem_from_data(addr);
if (elem == NULL)
return RTE_BAD_PHYS_ADDR;
if (elem->ms->phys_addr == RTE_BAD_PHYS_ADDR)
return RTE_BAD_PHYS_ADDR;
- return elem->ms->phys_addr + ((uintptr_t)addr -
(uintptr_t)elem->ms->addr);
+
+ if (rte_eal_iova_mode() == RTE_IOVA_VA)
+ paddr = (uintptr_t)addr;
+ else
+ paddr = elem->ms->phys_addr +
+ ((uintptr_t)addr - (uintptr_t)elem->ms->addr);
+ return paddr;
}
--
2.14.1
Re: [dpdk-dev] [PATCH v2 1/3] crypto/aesni_mb: add DES support
On 9/15/2017 3:09 AM, Pablo de Lara wrote:
The Multi-buffer library now supports DES-CBC
and DES-DOCSISBPI algorithms, so this commit
extends adds support for them in the PMD.
Signed-off-by: Pablo de Lara
Acked-by: Fan Zhang
---
doc/guides/cryptodevs/aesni_mb.rst | 2 +
doc/guides/cryptodevs/features/aesni_mb.ini| 3 ++
doc/guides/rel_notes/release_17_11.rst | 7 +++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 74 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 42 +++
test/test/test_cryptodev.c | 42 +++
test/test/test_cryptodev_des_test_vectors.h| 24 ++---
7 files changed, 163 insertions(+), 31 deletions(-)
+#include
+
#include
#include
#include
@@ -188,6 +190,7 @@ aesni_mb_set_session_cipher_parameters(const struct
aesni_mb_op_fns *mb_ops,
struct aesni_mb_session *sess,
const struct rte_crypto_sym_xform *xform)
{
+ uint8_t is_aes;
Nitpicking: Maybe initialize with zero and remove is_aes = 0; from the
switch body?
aes_keyexp_t aes_keyexp_fn;
if (xform == NULL) {
@@ -217,45 +220,70 @@ aesni_mb_set_session_cipher_parameters(const struct
aesni_mb_op_fns *mb_ops,
switch (xform->cipher.algo) {
case RTE_CRYPTO_CIPHER_AES_CBC:
sess->cipher.mode = CBC;
+ is_aes = 1;
break;
case RTE_CRYPTO_CIPHER_AES_CTR:
sess->cipher.mode = CNTR;
+ is_aes = 1;
break;
case RTE_CRYPTO_CIPHER_AES_DOCSISBPI:
sess->cipher.mode = DOCSIS_SEC_BPI;
+ is_aes = 1;
break;
- default:
- MB_LOG_ERR("Unsupported cipher mode parameter");
- return -ENOTSUP;
- }
-
- /* Check key length and choose key expansion function */
- switch (xform->cipher.key.length) {
- case AES_128_BYTES:
- sess->cipher.key_length_in_bytes = AES_128_BYTES;
- aes_keyexp_fn = mb_ops->aux.keyexp.aes128;
+ case RTE_CRYPTO_CIPHER_DES_CBC:
+ sess->cipher.mode = DES;
+ is_aes = 0;
break;
- case AES_192_BYTES:
- sess->cipher.key_length_in_bytes = AES_192_BYTES;
- aes_keyexp_fn = mb_ops->aux.keyexp.aes192;
- break;
- case AES_256_BYTES:
- sess->cipher.key_length_in_bytes = AES_256_BYTES;
- aes_keyexp_fn = mb_ops->aux.keyexp.aes256;
+ case RTE_CRYPTO_CIPHER_DES_DOCSISBPI:
+ sess->cipher.mode = DOCSIS_DES;
+ is_aes = 0;
break;
default:
- MB_LOG_ERR("Invalid cipher key length");
- return -EINVAL;
+ MB_LOG_ERR("Unsupported cipher mode parameter");
+ return -ENOTSUP;
}
Reviewed-by: Radu Nicolau
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
> -Original Message- > From: Richardson, Bruce > Sent: Monday, September 18, 2017 11:32 AM > To: Thomas Monjalon > Cc: Ananyev, Konstantin ; > step...@networkplumber.org; dev@dpdk.org; Shahaf Shuler > > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new > offloads API > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > 13/09/2017 23:42, Ananyev, Konstantin: > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > Konstantin, I would like your opinion about the proposal below. > > > > It is about making on the fly configuration more generic. > > > > You say it is possible to configure VLAN on the fly, > > > > and I think we should make it possible for other offload features. > > > > > > It would be a good thing, but I don't think it is possible for all > > > offloads. > > > For some of them you still have to stop the queue(port) first. > > > > > > Also I am not sure what exactly do you propose? > > > Is that something like that: > > > - wipe existing offload bitfileds from rte_eth_rxmode (already done by > > > Shahaf) > > > - Instead of uint64_t offloads inside both rte_eth_rxmode and > > > te_eth_rxconf > > > Introduce new functions: > > > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t offload_mask); > Would be useful to have a valid mask here, to indicate what bits to use. > That way, you can adjust one bit without worrying about what other bits > you may change in the process. There are probably apps out there that > just want to toggle a single bit on, and off, at runtime while ignoring > others. > Alternatively, we can have set/unset functions which enable/disable > offloads, based on the mask. My thought was that people would do: uint64_t offload = rte_eth_get_port_rx_offload(port); offload |= RX_OFFLOAD_X; offload &= ~RX_OFFLOAD_Y; rte_eth_set_port_rx_offload(port, offload); In that case, I think we don't really need a mask. > > > > > > > uint64_t rte_eth_get_port_rx_offload(portid); > > > uint64_t rte_eth_set_queue_rx_offload(portid, queueid); > s/set/get/ > > > > > > And add new fileds: > > > rx_offload_port_dynamic_capa > > > rx_offload_queue_dynamic_capa > > > inside rte_eth_dev_info. > > > > > > And it would be user responsibility to call set_port/queue_rx_offload() > > > somewhere before dev_start() for static offloads. > > > ? > > > > Yes exactly. > > > > > If so, then it seems reasonable to me. > > > > Good, thank you > > > > > Sorry I'm a bit late to the review, but the above suggestion of separate > APIs for enabling offloads, seems much better than passing in the flags > in structures to the existing calls. From what I see all later revisions > of this patchset still use the existing flags parameter to setup calls > method. > > Some advantages that I see of the separate APIs: > * allows some settings to be set before start, and others afterwards, > with an appropriate return value if dynamic config not supported. > * we can get fine grained error reporting from these - the set calls can > all return the mask indicating what offloads could not be applied - > zero means all ok, 1 means a problem with that setting. This may be > easier for the app to use than feature discovery in some cases. > * for those PMDs which support configuration at a per-queue level, it > can allow the user to specify the per-port settings as a default, and > then override that value at the queue level, if you just want one queue > different from the rest. I think we all in favor to have a separate API here. Though from the discussion we had at latest TB, I am not sure it is doable in 17.11 timeframe. Konstantin
Re: [dpdk-dev] [PATCH v2 0/3] performance enhancements for QAT driver
> -Original Message- > From: Burakov, Anatoly > Sent: Tuesday, September 12, 2017 10:31 AM > To: dev@dpdk.org > Cc: Trahe, Fiona ; Griffin, John > ; Jain, Deepak K ; De > Lara Guarch, Pablo > Subject: [PATCH v2 0/3] performance enhancements for QAT driver > > A few performance enhancements for QAT crypto driver. These include: > - Removing reliance on atomics on hot path > - This adds a new limitation, making queue pairs single-threaded > - Coalesce RX and TX CSR writes > > v2: added cover letter > fixed commit messages > fixed documentation > > Anatoly Burakov (3): > crypto/qat: remove atomics > crypto/qat: enable RX head writes coalescing > crypto/qat: enable TX tail writes coalescing > > doc/guides/cryptodevs/qat.rst | 1 + > doc/guides/rel_notes/release_17_11.rst | 8 > drivers/crypto/qat/qat_crypto.c| 84 +- > > drivers/crypto/qat/qat_crypto.h| 15 +- > drivers/crypto/qat/qat_qp.c| 4 +- > 5 files changed, 88 insertions(+), 24 deletions(-) > > -- > 2.7.4 Applied to dpdk-next-crypto. Thanks, Pablo
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > > -Original Message- > > From: Richardson, Bruce > > Sent: Monday, September 18, 2017 11:32 AM > > To: Thomas Monjalon > > Cc: Ananyev, Konstantin ; > > step...@networkplumber.org; dev@dpdk.org; Shahaf Shuler > > > > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new > > offloads API > > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > It is about making on the fly configuration more generic. > > > > > You say it is possible to configure VLAN on the fly, > > > > > and I think we should make it possible for other offload features. > > > > > > > > It would be a good thing, but I don't think it is possible for all > > > > offloads. > > > > For some of them you still have to stop the queue(port) first. > > > > > > > > Also I am not sure what exactly do you propose? > > > > Is that something like that: > > > > - wipe existing offload bitfileds from rte_eth_rxmode (already done by > > > > Shahaf) > > > > - Instead of uint64_t offloads inside both rte_eth_rxmode and > > > > te_eth_rxconf > > > > Introduce new functions: > > > > > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t > > > > offload_mask); > > Would be useful to have a valid mask here, to indicate what bits to use. > > That way, you can adjust one bit without worrying about what other bits > > you may change in the process. There are probably apps out there that > > just want to toggle a single bit on, and off, at runtime while ignoring > > others. > > Alternatively, we can have set/unset functions which enable/disable > > offloads, based on the mask. > > My thought was that people would do: > > uint64_t offload = rte_eth_get_port_rx_offload(port); > offload |= RX_OFFLOAD_X; > offload &= ~RX_OFFLOAD_Y; > rte_eth_set_port_rx_offload(port, offload); > > In that case, I think we don't really need a mask. > Sure, that can work, I'm not concerned either way. Overall, I think my slight preference would be to have set/unset, enable/disable functions to make it clear what is happening, rather than having to worry about the complete set each time. uint64_t rte_eth_port_rx_offload_enable(port_id, offload_mask) uint64_t rte_eth_port_rx_offload_disable(port_id, offload_mask) each returning the bits failing (or bits changed if you like, but I prefer bits failing as return value, since it means 0 == no_error). /Bruce
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > > -Original Message- > > From: Richardson, Bruce > > Sent: Monday, September 18, 2017 11:32 AM > > To: Thomas Monjalon > > Cc: Ananyev, Konstantin ; > > step...@networkplumber.org; dev@dpdk.org; Shahaf Shuler > > > > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new > > offloads API > > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > It is about making on the fly configuration more generic. > > > > > You say it is possible to configure VLAN on the fly, > > > > > and I think we should make it possible for other offload features. > > > > > > > > It would be a good thing, but I don't think it is possible for all > > > > offloads. > > > > For some of them you still have to stop the queue(port) first. > > > > > > > > Also I am not sure what exactly do you propose? > > > > Is that something like that: > > > > - wipe existing offload bitfileds from rte_eth_rxmode (already done by > > > > Shahaf) > > > > - Instead of uint64_t offloads inside both rte_eth_rxmode and > > > > te_eth_rxconf > > > > Introduce new functions: > > > > > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t > > > > offload_mask); > > Would be useful to have a valid mask here, to indicate what bits to use. > > That way, you can adjust one bit without worrying about what other bits > > you may change in the process. There are probably apps out there that > > just want to toggle a single bit on, and off, at runtime while ignoring > > others. > > Alternatively, we can have set/unset functions which enable/disable > > offloads, based on the mask. > > My thought was that people would do: > > uint64_t offload = rte_eth_get_port_rx_offload(port); > offload |= RX_OFFLOAD_X; > offload &= ~RX_OFFLOAD_Y; > rte_eth_set_port_rx_offload(port, offload); > > In that case, I think we don't really need a mask. > > > > > > > > > > > uint64_t rte_eth_get_port_rx_offload(portid); > > > > uint64_t rte_eth_set_queue_rx_offload(portid, queueid); > > s/set/get/ > > > > > > > > And add new fileds: > > > > rx_offload_port_dynamic_capa > > > > rx_offload_queue_dynamic_capa > > > > inside rte_eth_dev_info. > > > > > > > > And it would be user responsibility to call set_port/queue_rx_offload() > > > > somewhere before dev_start() for static offloads. > > > > ? > > > > > > Yes exactly. > > > > > > > If so, then it seems reasonable to me. > > > > > > Good, thank you > > > > > > > > Sorry I'm a bit late to the review, but the above suggestion of separate > > APIs for enabling offloads, seems much better than passing in the flags > > in structures to the existing calls. From what I see all later revisions > > of this patchset still use the existing flags parameter to setup calls > > method. > > > > Some advantages that I see of the separate APIs: > > * allows some settings to be set before start, and others afterwards, > > with an appropriate return value if dynamic config not supported. > > * we can get fine grained error reporting from these - the set calls can > > all return the mask indicating what offloads could not be applied - > > zero means all ok, 1 means a problem with that setting. This may be > > easier for the app to use than feature discovery in some cases. > > * for those PMDs which support configuration at a per-queue level, it > > can allow the user to specify the per-port settings as a default, and > > then override that value at the queue level, if you just want one queue > > different from the rest. > > I think we all in favor to have a separate API here. > Though from the discussion we had at latest TB, I am not sure it is doable > in 17.11 timeframe. Ok, so does that imply no change in this release, and that the existing set is to be ignored? /Bruce
Re: [dpdk-dev] [PATCH 1/3] build: rename pkgconfig to libdpdk.pc
On Fri, Sep 15, 2017 at 06:36:10PM +0100, luca.bocca...@gmail.com wrote: > From: Luca Boccassi > > In Debian and Ubuntu we have been shipping a pkgconfig file for DPDK > for more than a year now, and the filename is libdpdk.pc. > A few downstream projects, like OVS and Collectd, have adopted the > use of libdpdk.pc in their build systems as well. > In order to maintain backward compatibility, rename the file from > DPDK.pc to libdpdk.pc. > > Signed-off-by: Luca Boccassi > --- I find the 'lib' bit strange, but if that is what is already out there, then we should keep it for compatibility. In future, we might create two pkgconfig files to transition over to a new name, but to start with lets use what is being looked for by our dependencies. Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
> -Original Message- > From: Richardson, Bruce > Sent: Monday, September 18, 2017 12:05 PM > To: Ananyev, Konstantin > Cc: Thomas Monjalon ; step...@networkplumber.org; > dev@dpdk.org; Shahaf Shuler > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new > offloads API > > On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > > > > > -Original Message- > > > From: Richardson, Bruce > > > Sent: Monday, September 18, 2017 11:32 AM > > > To: Thomas Monjalon > > > Cc: Ananyev, Konstantin ; > > > step...@networkplumber.org; dev@dpdk.org; Shahaf Shuler > > > > > > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the > > > new offloads API > > > > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > > It is about making on the fly configuration more generic. > > > > > > You say it is possible to configure VLAN on the fly, > > > > > > and I think we should make it possible for other offload features. > > > > > > > > > > It would be a good thing, but I don't think it is possible for all > > > > > offloads. > > > > > For some of them you still have to stop the queue(port) first. > > > > > > > > > > Also I am not sure what exactly do you propose? > > > > > Is that something like that: > > > > > - wipe existing offload bitfileds from rte_eth_rxmode (already done > > > > > by Shahaf) > > > > > - Instead of uint64_t offloads inside both rte_eth_rxmode and > > > > > te_eth_rxconf > > > > > Introduce new functions: > > > > > > > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > > > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t > > > > > offload_mask); > > > Would be useful to have a valid mask here, to indicate what bits to use. > > > That way, you can adjust one bit without worrying about what other bits > > > you may change in the process. There are probably apps out there that > > > just want to toggle a single bit on, and off, at runtime while ignoring > > > others. > > > Alternatively, we can have set/unset functions which enable/disable > > > offloads, based on the mask. > > > > My thought was that people would do: > > > > uint64_t offload = rte_eth_get_port_rx_offload(port); > > offload |= RX_OFFLOAD_X; > > offload &= ~RX_OFFLOAD_Y; > > rte_eth_set_port_rx_offload(port, offload); > > > > In that case, I think we don't really need a mask. > > > > > > > > > > > > > > > uint64_t rte_eth_get_port_rx_offload(portid); > > > > > uint64_t rte_eth_set_queue_rx_offload(portid, queueid); > > > s/set/get/ > > > > > > > > > > And add new fileds: > > > > > rx_offload_port_dynamic_capa > > > > > rx_offload_queue_dynamic_capa > > > > > inside rte_eth_dev_info. > > > > > > > > > > And it would be user responsibility to call > > > > > set_port/queue_rx_offload() > > > > > somewhere before dev_start() for static offloads. > > > > > ? > > > > > > > > Yes exactly. > > > > > > > > > If so, then it seems reasonable to me. > > > > > > > > Good, thank you > > > > > > > > > > > Sorry I'm a bit late to the review, but the above suggestion of separate > > > APIs for enabling offloads, seems much better than passing in the flags > > > in structures to the existing calls. From what I see all later revisions > > > of this patchset still use the existing flags parameter to setup calls > > > method. > > > > > > Some advantages that I see of the separate APIs: > > > * allows some settings to be set before start, and others afterwards, > > > with an appropriate return value if dynamic config not supported. > > > * we can get fine grained error reporting from these - the set calls can > > > all return the mask indicating what offloads could not be applied - > > > zero means all ok, 1 means a problem with that setting. This may be > > > easier for the app to use than feature discovery in some cases. > > > * for those PMDs which support configuration at a per-queue level, it > > > can allow the user to specify the per-port settings as a default, and > > > then override that value at the queue level, if you just want one queue > > > different from the rest. > > > > I think we all in favor to have a separate API here. > > Though from the discussion we had at latest TB, I am not sure it is doable > > in 17.11 timeframe. > > Ok, so does that imply no change in this release, and that the existing > set is to be ignored? No, my understanding the current plan is to go forward with Shahaf patches, and then apply another one (new set/get API) on top of them. Konstantin
Re: [dpdk-dev] [PATCH] net/bonding: strengthen the judgment of lacp packets
For example, when packets received from an MLX network card, the value of mbuf->vlan_tci is a random value. So that this value cannot be used to determine whether VLAN packets . We need to judgment mbuf->ol_flags first. BR. Zeng Ganghui Huawei Technologies Co., Ltd. -Original Message- From: Doherty, Declan [mailto:declan.dohe...@intel.com] Sent: Monday, September 18, 2017 5:14 PM To: zengganghui; dev@dpdk.org Subject: Re: [PATCH] net/bonding: strengthen the judgment of lacp packets On 30/08/2017 4:46 AM, ZengGanghui wrote: > When the nic does not support vlan rx offload may be wrong, resulting > in lacp packets will not be processed. > > Signed-off-by: ZengGanghui > --- ... > Acked-by: Declan Doherty
Re: [dpdk-dev] [PATCH 02/11] doc: add details of rte security
-Original Message- > Date: Thu, 14 Sep 2017 13:56:42 +0530 > From: Akhil Goyal > To: dev@dpdk.org > CC: declan.dohe...@intel.com, pablo.de.lara.gua...@intel.com, > hemant.agra...@nxp.com, radu.nico...@intel.com, bor...@mellanox.com, > avia...@mellanox.com, tho...@monjalon.net, sandeep.ma...@nxp.com, > jerin.ja...@caviumnetworks.com > Subject: [PATCH 02/11] doc: add details of rte security > X-Mailer: git-send-email 2.9.3 > +Security Library > + > + > +The security library provides a framework for management and provisioning > +of security protocol operations offloaded to hardware based devices. The > +library defines generic APIs to create and free security sessions which can > +support complete protocol offload as well as inline crypto operation with > +NIC or crypto devices. The framework currently only supports IPSEC protocol > +and it's operations, other protocols will be added in future. > + > +Design Principles > +- > + > +The security library provides an additional offload capability to existing > +crypto device and/or ethernet device. > + > +.. code-block:: console > + > + +---+ > + | rte_security | > + +---+ > + \/ > ++---++--+ > +| NIC PMD || CRYPTO PMD | > ++---++--+ > + > +Following offload types can be supported: > + > +Inline Crypto > +~ > + > +RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO: > +The crypto processing for security protocol (e.g. IPSEC) is processed > +inline during receive and transmission on NIC port. The flow based > +security action should be configured on the port. > + > +Ingress Data path - The packet is decrypted in RX path and relevant > +crypto status is set in rx descriptors. After the successful inline > +crypto processing the packet is presented to host as a regular rx packet > +but all security protocol related headers are still attached to the > +packet. e.g. In case of IPSEC, the IPSEC tunnel headers (if any), > +ESP/AH headers will remain in the packet but the received packet > +contains the decrypted data where the encrypted data was when the packet > +arrived. The driver rx path check the descriptos and and based on the s/descriptos/descriptors > +crypto status sets additional flags in the rte_mbuf.ol_flags field. > + > +.. note:: > + > +The underlying device may not support crypto processing all ingress > packet > +matching to a particular flow (e.g. fragmented packets), such packets > will > +be passed as encrypted packets. It is the responsibility of driver to ^^^ Do you mean application here instead of driver? > +process such encrypted packets using other crypto driver instance. > + > +Egress Data path - The software prepares the egress packet by adding > +relevant security protocol headers in the packets. Only the data will not be > +encryptoed by the software. The driver will accordingly configure the s/encryptoed/encrypted > +tx descriptors. The HW device will encrypt the data before sending the > +the packet out. > + > +.. note:: > + > +The underlying device may support post encryption TSO. > + > +.. code-block:: console > + > + Egress Data Path > + | > ++|+ > +| egress IPsec | > +||| > +| +--V--+ | > +| | SABD lookup | | > +| +--|--+ | s/SABD/SADB > +| +--V--+ | > +| | Tunnel| | <-- Add tunnel header to packet > +| +--|--+ | > +| +--V--+ | > +| | ESP | | <-- Add ESP header without trailer to > packet > +| | | | <-- Mark packet to be offloaded, add > trailer > +| +--|--+ |meta-data to mbuf > ++V+ > + | > ++V+ > +|L2 Stack | > ++|+ > + | > ++V+ > +| | > +| NIC PMD | <-- Set hw context for inline crypto > offload > +| | > ++|+ > + | > ++|+ > +| HW ACCELERATED | <-- Packet Encryption/Decryption and Only packet Encryption here. Right? > +|NIC | Authentication happens inline > +| | > ++|+ ^^^ I guess the "|" can be removed. > + > + > +Inline protocol offload > +~~~ > + > +RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL: > +The crypto and protocol processing for security protocol (e.g. IPSEC) > +is processed inline during receive and transmission. The flow based > +security
Re: [dpdk-dev] [PATCH 1/2] doc: add details of rte_flow security actions
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Boris Pismenny > Sent: Sunday, September 17, 2017 1:07 PM > To: dev@dpdk.org > Cc: akhil.go...@nxp.com; Doherty, Declan ; De > Lara Guarch, Pablo ; > hemant.agra...@nxp.com; Nicolau, Radu ; > bor...@mellanox.com; avia...@mellanox.com; tho...@monjalon.net; > sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com; > nelio.laranje...@6wind.com; lir...@mellanox.com > Subject: [dpdk-dev] [PATCH 1/2] doc: add details of rte_flow security > actions > > Signed-off-by: Boris Pismenny Thanks for the docs. Minor comments below. > + > +Multiple flows can be configured to use the same security session. > + > +- Non-terminating by default. This is a single bullet point list and it seems disconnected from the previous line. Maybe convert it to a sentence instead. > + > +.. _table_rte_flow_action_security This is missing a colon at the end and causes a doc build warning. > +Usage example, configure IPsec inline using INLINE_CRYPTO security > session: This doesn't seem to connect to the following paragraph. Maybe something like: The following is an example of configuring IPsec inline using the INLINE_CRYPTO security session: Reviewed-by: John McNamara
Re: [dpdk-dev] [PATCH v2 1/6] bus/fslmc: support only single group and container
On Friday 25 August 2017 03:49 PM, Shreyansh Jain wrote:
> Currently DPAA2 code doesn't support multiple groups and containers.
> Remove such provision in code to simplify code.
>
> Signed-off-by: Shreyansh Jain
> ---
Reviewed-by: Santosh Shukla
> drivers/bus/fslmc/fslmc_vfio.c | 70
> +++---
> drivers/bus/fslmc/fslmc_vfio.h | 3 +-
> 2 files changed, 26 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/bus/fslmc/fslmc_vfio.c b/drivers/bus/fslmc/fslmc_vfio.c
> index 45e5927..3423b57 100644
> --- a/drivers/bus/fslmc/fslmc_vfio.c
> +++ b/drivers/bus/fslmc/fslmc_vfio.c
> @@ -62,8 +62,6 @@
> #include "portal/dpaa2_hw_pvt.h"
> #include "portal/dpaa2_hw_dpio.h"
>
> -#define VFIO_MAX_CONTAINERS 1
> -
> #define FSLMC_VFIO_LOG(level, fmt, args...) \
> RTE_LOG(level, EAL, "%s(): " fmt "\n", __func__, ##args)
>
> @@ -71,8 +69,8 @@
> #define SYSFS_FSL_MC_DEVICES "/sys/bus/fsl-mc/devices"
>
> /* Number of VFIO containers & groups with in */
> -static struct fslmc_vfio_group vfio_groups[VFIO_MAX_GRP];
> -static struct fslmc_vfio_container vfio_containers[VFIO_MAX_CONTAINERS];
> +static struct fslmc_vfio_group vfio_group;
> +static struct fslmc_vfio_container vfio_container;
> static int container_device_fd;
> static uint32_t *msi_intr_vaddr;
> void *(*rte_mcp_ptr_list);
> @@ -90,22 +88,18 @@ rte_fslmc_object_register(struct rte_dpaa2_object *object)
> TAILQ_INSERT_TAIL(&fslmc_obj_list, object, next);
> }
>
> -static int vfio_connect_container(struct fslmc_vfio_group *vfio_group)
> +static int vfio_connect_container(void)
> {
> - struct fslmc_vfio_container *container;
> - int i, fd, ret;
> + int fd, ret;
>
> /* Try connecting to vfio container if already created */
> - for (i = 0; i < VFIO_MAX_CONTAINERS; i++) {
> - container = &vfio_containers[i];
> - if (!ioctl(vfio_group->fd, VFIO_GROUP_SET_CONTAINER,
> -&container->fd)) {
> - FSLMC_VFIO_LOG(INFO,
> - "Container pre-exists with FD[0x%x] for this group",
> - container->fd);
> - vfio_group->container = container;
> - return 0;
> - }
> + if (!ioctl(vfio_group.fd, VFIO_GROUP_SET_CONTAINER,
> + &vfio_container.fd)) {
> + FSLMC_VFIO_LOG(INFO,
> + "Container pre-exists with FD[0x%x] for this group",
> + vfio_container.fd);
> + vfio_group.container = &vfio_container;
> + return 0;
> }
>
> /* Opens main vfio file descriptor which represents the "container" */
> @@ -118,7 +112,7 @@ static int vfio_connect_container(struct fslmc_vfio_group
> *vfio_group)
> /* Check whether support for SMMU type IOMMU present or not */
> if (ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU)) {
> /* Connect group to container */
> - ret = ioctl(vfio_group->fd, VFIO_GROUP_SET_CONTAINER, &fd);
> + ret = ioctl(vfio_group.fd, VFIO_GROUP_SET_CONTAINER, &fd);
> if (ret) {
> FSLMC_VFIO_LOG(ERR, "Failed to setup group container");
> close(fd);
> @@ -137,23 +131,11 @@ static int vfio_connect_container(struct
> fslmc_vfio_group *vfio_group)
> return -EINVAL;
> }
>
> - container = NULL;
> - for (i = 0; i < VFIO_MAX_CONTAINERS; i++) {
> - if (vfio_containers[i].used)
> - continue;
> - container = &vfio_containers[i];
> - }
> - if (!container) {
> - FSLMC_VFIO_LOG(ERR, "No free container found");
> - close(fd);
> - return -ENOMEM;
> - }
> + vfio_container.used = 1;
> + vfio_container.fd = fd;
> + vfio_container.group = &vfio_group;
> + vfio_group.container = &vfio_container;
>
> - container->used = 1;
> - container->fd = fd;
> - container->group_list[container->index] = vfio_group;
> - vfio_group->container = container;
> - container->index++;
> return 0;
> }
>
> @@ -222,7 +204,7 @@ int rte_fslmc_vfio_dmamap(void)
> #endif
>
> /* SET DMA MAP for IOMMU */
> - group = &vfio_groups[0];
> + group = &vfio_group;
>
> if (!group->container) {
> FSLMC_VFIO_LOG(ERR, "Container is not connected ");
> @@ -392,7 +374,7 @@ int fslmc_vfio_process_group(void)
> char path[PATH_MAX];
> int64_t v_addr;
> int ndev_count;
> - struct fslmc_vfio_group *group = &vfio_groups[0];
> + struct fslmc_vfio_group *group = &vfio_group;
> static int process_once;
>
> /* if already done once */
> @@ -569,7 +551,7 @@ int fslmc_vfio_setup_group(void)
> {
> struct fslmc_vfio_group *group = NULL;
> int groupid;
> - int ret, i;
> + int ret;
> char *container;
>
Re: [dpdk-dev] [PATCH 2/2] ethdev: update documentation for security action
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Boris Pismenny > Sent: Sunday, September 17, 2017 1:07 PM > To: dev@dpdk.org > Cc: akhil.go...@nxp.com; Doherty, Declan ; De > Lara Guarch, Pablo ; > hemant.agra...@nxp.com; Nicolau, Radu ; > bor...@mellanox.com; avia...@mellanox.com; tho...@monjalon.net; > sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com; > nelio.laranje...@6wind.com; lir...@mellanox.com > Subject: [dpdk-dev] [PATCH 2/2] ethdev: update documentation for security > action > > Signed-off-by: Boris Pismenny Acked-by: John McNamara
Re: [dpdk-dev] [PATCH v2 14/14] doc: add notes on EAL PCI API update
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaetan Rivet > Sent: Monday, September 18, 2017 10:32 AM > To: dev@dpdk.org > Cc: Gaetan Rivet > Subject: [dpdk-dev] [PATCH v2 14/14] doc: add notes on EAL PCI API update > > Add a section related to EAL API changes to 17.11 release notes. > > Signed-off-by: Gaetan Rivet Acked-by: John McNamara
Re: [dpdk-dev] [PATCH 2/3] build: add optional arch-specific headers install path
On Fri, Sep 15, 2017 at 06:36:11PM +0100, luca.bocca...@gmail.com wrote:
> From: Luca Boccassi
>
> A subset of the dpdk headers are arch-dependent, but have common names
> and thus cause a clash in a multiarch installation.
> For example, rte_config.h is different for each target.
>
> Add a "include_subdir_arch" option to allow a user to specify a
> subdirectory for arch independent headers to fix multiarch support.
>
> Signed-off-by: Luca Boccassi
> ---
> config/meson.build | 2 +-
> lib/librte_eal/common/include/arch/x86/meson.build | 3 ++-
> meson.build| 3 ++-
> meson_options.txt | 1 +
> 4 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/config/meson.build b/config/meson.build
> index b57a7e64b..db68a08d4 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -69,4 +69,4 @@ dpdk_conf.set('RTE_MAX_NUMA_NODES',
> get_option('max_numa_nodes'))
> dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
> dpdk_conf.set('RTE_EAL_ALLOW_INV_SOCKET_ID',
> get_option('allow_invalid_socket_id'))
>
> -install_headers('rte_config.h')
> +install_headers('rte_config.h', subdir: get_option('include_subdir_arch'))
> diff --git a/lib/librte_eal/common/include/arch/x86/meson.build
> b/lib/librte_eal/common/include/arch/x86/meson.build
> index 80b5980c1..5e9c02687 100644
> --- a/lib/librte_eal/common/include/arch/x86/meson.build
> +++ b/lib/librte_eal/common/include/arch/x86/meson.build
> @@ -45,4 +45,5 @@ install_headers(
> 'rte_rtm.h',
> 'rte_rwlock.h',
> 'rte_spinlock.h',
> - 'rte_vect.h')
> + 'rte_vect.h',
> + subdir: get_option('include_subdir_arch'))
> diff --git a/meson.build b/meson.build
> index f41fb4120..134158dae 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -70,7 +70,7 @@ subdir('app')
> build_cfg = 'rte_build_config.h'
> configure_file(output: build_cfg,
> configuration: dpdk_conf,
> - install_dir: get_option('includedir'))
> + install_dir: get_option('includedir') + '/' +
> get_option('include_subdir_arch'))
Minor nit: use "join_paths()" function. Will fix on apply.
Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH 3/3] build: don't hard-code generic/exec-env install path
On Fri, Sep 15, 2017 at 06:36:12PM +0100, luca.bocca...@gmail.com wrote: > From: Luca Boccassi > > Instead of hard-coding the install path of generic and exec-env headers > use the includedir option, so that it can be correctly overridden. > > Signed-off-by: Luca Boccassi > --- Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
18/09/2017 13:04, Bruce Richardson: > On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > From: Richardson, Bruce > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > > It is about making on the fly configuration more generic. > > > > > > You say it is possible to configure VLAN on the fly, > > > > > > and I think we should make it possible for other offload features. > > > > > > > > > > It would be a good thing, but I don't think it is possible for all > > > > > offloads. > > > > > For some of them you still have to stop the queue(port) first. > > > > > > > > > > Also I am not sure what exactly do you propose? > > > > > Is that something like that: > > > > > - wipe existing offload bitfileds from rte_eth_rxmode (already done > > > > > by Shahaf) > > > > > - Instead of uint64_t offloads inside both rte_eth_rxmode and > > > > > te_eth_rxconf > > > > > Introduce new functions: > > > > > > > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > > > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t > > > > > offload_mask); > > > Would be useful to have a valid mask here, to indicate what bits to use. > > > That way, you can adjust one bit without worrying about what other bits > > > you may change in the process. There are probably apps out there that > > > just want to toggle a single bit on, and off, at runtime while ignoring > > > others. > > > Alternatively, we can have set/unset functions which enable/disable > > > offloads, based on the mask. > > > > My thought was that people would do: > > > > uint64_t offload = rte_eth_get_port_rx_offload(port); > > offload |= RX_OFFLOAD_X; > > offload &= ~RX_OFFLOAD_Y; > > rte_eth_set_port_rx_offload(port, offload); > > > > In that case, I think we don't really need a mask. > > > Sure, that can work, I'm not concerned either way. > > Overall, I think my slight preference would be to have set/unset, > enable/disable functions to make it clear what is happening, rather than > having to worry about the complete set each time. > > uint64_t rte_eth_port_rx_offload_enable(port_id, offload_mask) > uint64_t rte_eth_port_rx_offload_disable(port_id, offload_mask) > > each returning the bits failing (or bits changed if you like, but I prefer > bits failing as return value, since it means 0 == no_error). I think we need both: "get" functions + "mask" parameters in "set" functions.
Re: [dpdk-dev] [PATCH 0/3] meson: compatibility with Debian/Ubuntu
On Fri, Sep 15, 2017 at 06:36:09PM +0100, luca.bocca...@gmail.com wrote: > From: Luca Boccassi > > A couple of small fixes are needed in order to make the meson build > compatible with Debian and Ubuntu, to avoid breaking backward > compatibility for applications that depend on the packages. > > Debian and Ubuntu have been shipping a pkg-config file for more than > a year, but it is called libdpdk.pc rather than DPDK.pc. A few > downstream projects, like OVS and Collectd, have started using it in > with the former name. > To avoid breaking compatibility, rename it to libdpdk.pc. > > Furthermore, in order to avoid breaking multiarch installability, > add an option to let users install arch-specific headers in another > subdirectory of the arch-independent ones. The reason is that some of > the arch specific ones have the same filename, so there is a clash. > The new option, include_subdir_arch, is disabled by default. > > Finally a small fix to use the configure includedir rather than an > hard-coded path for exec-env and generic headers. > > Luca Boccassi (3): > build: rename pkgconfig to libdpdk.pc > build: add optional arch-specific headers install path > build: don't hard-code generic/exec-env install path > Series Applied to dpdk-next-build. Thanks, /Bruce
Re: [dpdk-dev] [PATCH v2 2/3] crypto/openssl: add support for DES-CBC
On 9/15/2017 3:09 AM, Pablo de Lara wrote: Signed-off-by: Pablo de Lara --- Acked-by: Radu Nicolau
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
18/09/2017 13:11, Ananyev, Konstantin: > From: Richardson, Bruce > > On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > From: Richardson, Bruce > > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > > > It is about making on the fly configuration more generic. > > > > > > > You say it is possible to configure VLAN on the fly, > > > > > > > and I think we should make it possible for other offload features. > > > > > > > > > > > > It would be a good thing, but I don't think it is possible for all > > > > > > offloads. > > > > > > For some of them you still have to stop the queue(port) first. [...] [technical details skipped] [...] > > > > > > If so, then it seems reasonable to me. > > > > > > > > > > Good, thank you > > > > > > > > > > > > > > Sorry I'm a bit late to the review, but the above suggestion of separate > > > > APIs for enabling offloads, seems much better than passing in the flags > > > > in structures to the existing calls. From what I see all later revisions > > > > of this patchset still use the existing flags parameter to setup calls > > > > method. > > > > > > > > Some advantages that I see of the separate APIs: > > > > * allows some settings to be set before start, and others afterwards, > > > > with an appropriate return value if dynamic config not supported. > > > > * we can get fine grained error reporting from these - the set calls can > > > > all return the mask indicating what offloads could not be applied - > > > > zero means all ok, 1 means a problem with that setting. This may be > > > > easier for the app to use than feature discovery in some cases. > > > > * for those PMDs which support configuration at a per-queue level, it > > > > can allow the user to specify the per-port settings as a default, and > > > > then override that value at the queue level, if you just want one > > > > queue > > > > different from the rest. > > > > > > I think we all in favor to have a separate API here. > > > Though from the discussion we had at latest TB, I am not sure it is doable > > > in 17.11 timeframe. > > > > Ok, so does that imply no change in this release, and that the existing > > set is to be ignored? > > No, my understanding the current plan is to go forward with Shahaf patches, > and then apply another one (new set/get API) on top of them. Yes, it is what we agreed (hope to see it in minutes). If someone can do these new patches in 17.11 timeframe, it's great! Bruce, do you want to make it a try?
Re: [dpdk-dev] [PATCH v2 3/3] app/crypto-perf: fix packet length check
On 9/15/2017 3:09 AM, Pablo de Lara wrote:
When using DES-CBC, packet size has to be multiple
of 8 bytes, but if a list of packets is provided.
the check was not correct.
Fixes: fc4600fb2520 ("app/crypto-perf: add extra option checks")
Cc: sta...@dpdk.org
Signed-off-by: Pablo de Lara
---
Acked-by: Radu Nicolau
Re: [dpdk-dev] [PATCH] eal: bus scan and probe never fail
Tested-by: Hemant Agrawal
On 8/12/2017 3:52 PM, Shreyansh Jain wrote:
Bus scan is responsible for finding devices over *all* buses.
Some of these buses might not be able to scan but that should
not prevent other buses to be scanned.
Same is the case for probing. It is possible that some devices which
were scanned didn't have a specific driver. That should not prevent
other buses from being probed.
Signed-off-by: Shreyansh Jain
---
Until now, this decision was left onto author of bus specific scan and
probe function. But, that is incorrect.
---
lib/librte_eal/common/eal_common_bus.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_bus.c
b/lib/librte_eal/common/eal_common_bus.c
index 08bec2d..58e1084 100644
--- a/lib/librte_eal/common/eal_common_bus.c
+++ b/lib/librte_eal/common/eal_common_bus.c
@@ -73,11 +73,9 @@ rte_bus_scan(void)
TAILQ_FOREACH(bus, &rte_bus_list, next) {
ret = bus->scan();
- if (ret) {
+ if (ret)
RTE_LOG(ERR, EAL, "Scan for (%s) bus failed.\n",
bus->name);
- return ret;
- }
}
return 0;
@@ -97,20 +95,16 @@ rte_bus_probe(void)
}
ret = bus->probe();
- if (ret) {
+ if (ret)
RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n",
bus->name);
- return ret;
- }
}
if (vbus) {
ret = vbus->probe();
- if (ret) {
+ if (ret)
RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n",
vbus->name);
- return ret;
- }
}
return 0;
Re: [dpdk-dev] [PATCH v2 01/14] eal: expose rte_eal_using_phys_addrs
On Mon, Sep 18, 2017 at 04:17:08PM +0530, Shreyansh Jain wrote:
> Hello Gaetan,
>
> On Monday 18 September 2017 03:01 PM, Gaetan Rivet wrote:
> >This function was previously private to the EAL layer.
> >Other subsystems requires it, such as the PCI bus.
> >
> >In order not to force other components to include stdbool, which is
> >incompatible with several NIC drivers, the return type has
> >been changed from bool to int.
> >
> >Signed-off-by: Gaetan Rivet
> >---
>
> [...]
>
> >diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> >b/lib/librte_eal/linuxapp/eal/eal_memory.c
> >index 5279128..af8719b 100644
> >--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> >+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> >@@ -1542,7 +1542,7 @@ rte_eal_hugepage_attach(void)
> > return -1;
> > }
> >-bool
> >+int
> > rte_eal_using_phys_addrs(void)
> > {
> > return phys_addrs_available;
> >diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> >b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> >index 8c08b8d..f866b70 100644
> >--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> >+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> >@@ -205,6 +205,7 @@ DPDK_17.08 {
>
> This symbol should be added to 17.11, isn't it?
>
Ah, yes indeed
> > rte_bus_find;
> > rte_bus_find_by_device;
> > rte_bus_find_by_name;
> >+rte_eal_using_phys_addrs;
> > rte_log_get_level;
> > } DPDK_17.05;
> >
> -
> Shreyansh
--
Gaëtan Rivet
6WIND
Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
On Mon, Sep 18, 2017 at 01:32:29PM +0200, Thomas Monjalon wrote: > 18/09/2017 13:11, Ananyev, Konstantin: > > From: Richardson, Bruce > > > On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > > From: Richardson, Bruce > > > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > > > > It is about making on the fly configuration more generic. > > > > > > > > You say it is possible to configure VLAN on the fly, > > > > > > > > and I think we should make it possible for other offload > > > > > > > > features. > > > > > > > > > > > > > > It would be a good thing, but I don't think it is possible for > > > > > > > all offloads. > > > > > > > For some of them you still have to stop the queue(port) first. > [...] > [technical details skipped] > [...] > > > > > > > If so, then it seems reasonable to me. > > > > > > > > > > > > Good, thank you > > > > > > > > > > > > > > > > > Sorry I'm a bit late to the review, but the above suggestion of > > > > > separate > > > > > APIs for enabling offloads, seems much better than passing in the > > > > > flags > > > > > in structures to the existing calls. From what I see all later > > > > > revisions > > > > > of this patchset still use the existing flags parameter to setup calls > > > > > method. > > > > > > > > > > Some advantages that I see of the separate APIs: > > > > > * allows some settings to be set before start, and others afterwards, > > > > > with an appropriate return value if dynamic config not supported. > > > > > * we can get fine grained error reporting from these - the set calls > > > > > can > > > > > all return the mask indicating what offloads could not be applied - > > > > > zero means all ok, 1 means a problem with that setting. This may be > > > > > easier for the app to use than feature discovery in some cases. > > > > > * for those PMDs which support configuration at a per-queue level, it > > > > > can allow the user to specify the per-port settings as a default, > > > > > and > > > > > then override that value at the queue level, if you just want one > > > > > queue > > > > > different from the rest. > > > > > > > > I think we all in favor to have a separate API here. > > > > Though from the discussion we had at latest TB, I am not sure it is > > > > doable > > > > in 17.11 timeframe. > > > > > > Ok, so does that imply no change in this release, and that the existing > > > set is to be ignored? > > > > No, my understanding the current plan is to go forward with Shahaf patches, > > and then apply another one (new set/get API) on top of them. > > Yes, it is what we agreed (hope to see it in minutes). > If someone can do these new patches in 17.11 timeframe, it's great! > Bruce, do you want to make it a try? If I have the chance, I can try, but given how short time is and that userspace is on next week, I very much doubt I'll even get it started. /Bruce
Re: [dpdk-dev] [PATCH] net/mlx5: fix TSO segment size verification
On Sun, Sep 17, 2017 at 11:12:49AM +0300, Shahaf Shuler wrote:
> TSO segment size must be larger then 0.
>
> Fixes: 3f13f8c23a7c ("net/mlx5: support hardware TSO")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Shahaf Shuler
> Acked-by: Yongseok Koh
Acked-by: Nelio Laranjeiro
--
Nélio Laranjeiro
6WIND
Re: [dpdk-dev] [PATCH v2 05/14] pci: introduce PCI lib and bus
Hello Gaetan,
On Monday 18 September 2017 03:01 PM, Gaetan Rivet wrote:
The PCI lib defines the types and methods allowing to use PCI elements.
The PCI bus implements a bus driver for PCI devices by constructing
rte_bus elements using the PCI lib.
Move the relevant code out of the EAL to their expected place.
Signed-off-by: Gaetan Rivet
---
config/common_base | 10 +
drivers/bus/Makefile| 2 +
drivers/bus/pci/Makefile| 59 ++
drivers/bus/pci/bsd/Makefile| 32 ++
drivers/bus/pci/bsd/rte_pci.c | 670 ++
drivers/bus/pci/include/rte_bus_pci.h | 387 +
drivers/bus/pci/linux/Makefile | 37 ++
drivers/bus/pci/linux/rte_pci.c | 722
drivers/bus/pci/linux/rte_pci_init.h| 97
drivers/bus/pci/linux/rte_pci_uio.c | 567 +++
drivers/bus/pci/linux/rte_pci_vfio.c| 674 ++
drivers/bus/pci/linux/rte_vfio_mp_sync.c| 424 ++
drivers/bus/pci/private.h | 173 ++
drivers/bus/pci/rte_bus_pci_version.map | 21 +
drivers/bus/pci/rte_pci_common.c| 542 ++
drivers/bus/pci/rte_pci_common_uio.c| 234
lib/Makefile| 2 +
lib/librte_eal/bsdapp/eal/Makefile | 3 -
lib/librte_eal/bsdapp/eal/eal_pci.c | 670 --
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 15 -
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_common_pci.c | 580 ---
lib/librte_eal/common/eal_common_pci_uio.c | 233
lib/librte_eal/common/include/rte_pci.h | 598
lib/librte_eal/linuxapp/eal/Makefile| 10 -
lib/librte_eal/linuxapp/eal/eal_pci.c | 722
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 97
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 567 ---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 674 --
lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c | 424 --
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 15 -
lib/librte_ether/rte_ethdev.h | 2 -
lib/librte_pci/Makefile | 48 ++
lib/librte_pci/include/rte_pci.h| 279 +
lib/librte_pci/rte_pci.c| 92 +++
lib/librte_pci/rte_pci_version.map | 8 +
mk/rte.app.mk | 3 +
37 files changed, 5084 insertions(+), 4611 deletions(-)
create mode 100644 drivers/bus/pci/Makefile
create mode 100644 drivers/bus/pci/bsd/Makefile
create mode 100644 drivers/bus/pci/bsd/rte_pci.c
create mode 100644 drivers/bus/pci/include/rte_bus_pci.h
create mode 100644 drivers/bus/pci/linux/Makefile
create mode 100644 drivers/bus/pci/linux/rte_pci.c
create mode 100644 drivers/bus/pci/linux/rte_pci_init.h
create mode 100644 drivers/bus/pci/linux/rte_pci_uio.c
create mode 100644 drivers/bus/pci/linux/rte_pci_vfio.c
create mode 100644 drivers/bus/pci/linux/rte_vfio_mp_sync.c
create mode 100644 drivers/bus/pci/private.h
create mode 100644 drivers/bus/pci/rte_bus_pci_version.map
create mode 100644 drivers/bus/pci/rte_pci_common.c
create mode 100644 drivers/bus/pci/rte_pci_common_uio.c
delete mode 100644 lib/librte_eal/bsdapp/eal/eal_pci.c
delete mode 100644 lib/librte_eal/common/eal_common_pci.c
delete mode 100644 lib/librte_eal/common/eal_common_pci_uio.c
delete mode 100644 lib/librte_eal/common/include/rte_pci.h
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci.c
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_init.h
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
create mode 100644 lib/librte_pci/Makefile
create mode 100644 lib/librte_pci/include/rte_pci.h
create mode 100644 lib/librte_pci/rte_pci.c
create mode 100644 lib/librte_pci/rte_pci_version.map
+#endif /* _PCI_PRIVATE_H_ */
diff --git a/drivers/bus/pci/rte_bus_pci_version.map
b/drivers/bus/pci/rte_bus_pci_version.map
new file mode 100644
index 000..eca49e9
--- /dev/null
+++ b/drivers/bus/pci/rte_bus_pci_version.map
@@ -0,0 +1,21 @@
+DPDK_17.08 {
You might want to bump this to 17.11.
+ global:
+
+ rte_pci_detach;
+ rte_pci_dump;
+ rte_pci_ioport_map;
+ rte_pci_ioport_read;
+ rte_pci_ioport_unmap;
+ rte_pci_ioport_write;
+ rte_pci_map_device;
+ rte_pci_probe;
+ rte_pci_probe_one;
+ rte_pci_read_config;
+ rte_pci_registe
Re: [dpdk-dev] [PATCH 12/12] examples/helloworld: do not exit automatically
> -Original Message- > From: Tan, Jianfeng > Sent: Friday, August 25, 2017 10:41 AM > To: dev@dpdk.org > Cc: Richardson, Bruce ; Ananyev, Konstantin > ; De Lara Guarch, Pablo > ; tho...@monjalon.net; > y...@fridaylinux.org; maxime.coque...@redhat.com; > mtetsu...@gmail.com; Yigit, Ferruh ; Tan, > Jianfeng > Subject: [PATCH 12/12] examples/helloworld: do not exit automatically > > Signed-off-by: Jianfeng Tan > --- > examples/helloworld/main.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/examples/helloworld/main.c b/examples/helloworld/main.c > index 8b7a2de..35b70da 100644 > --- a/examples/helloworld/main.c > +++ b/examples/helloworld/main.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -72,6 +73,8 @@ main(int argc, char **argv) > /* call it on master lcore too */ > lcore_hello(NULL); > > + while (1) sleep(5); > + > rte_eal_mp_wait_lcore(); > return 0; > } > -- > 2.7.4 I think this patch should not be in this patchset, as it looks that it does not have any relation with the other patches. Am I missing something? Pablo
Re: [dpdk-dev] [PATCH 04/12] vdev: move to drivers/bus
> -Original Message- > From: Tan, Jianfeng > Sent: Tuesday, August 29, 2017 11:48 PM > To: Gaëtan Rivet > Cc: dev@dpdk.org; Richardson, Bruce ; > Ananyev, Konstantin ; De Lara Guarch, > Pablo ; tho...@monjalon.net; > y...@fridaylinux.org; maxime.coque...@redhat.com; > mtetsu...@gmail.com; Yigit, Ferruh > Subject: Re: [dpdk-dev] [PATCH 04/12] vdev: move to drivers/bus > > Hi Gaetan, > > > On 8/29/2017 6:04 AM, Gaëtan Rivet wrote: > > On Fri, Aug 25, 2017 at 09:40:44AM +, Jianfeng Tan wrote: > >> Move the vdev bus from lib/librte_eal to drivers/bus. > >> > >> As the crypto vdev helper function refers to data structure > >> in rte_vdev.h, so we move those helper function into drivers/bus > >> too. > >> > >> Signed-off-by: Jianfeng Tan > >> --- > >> config/common_base| 5 + > >> drivers/bus/Makefile | 2 + > >> drivers/bus/vdev/Makefile | 57 + > >> drivers/bus/vdev/rte_bus_vdev_version.map | 10 + > >> drivers/bus/vdev/rte_cryptodev_vdev.c | 154 ++ > >> drivers/bus/vdev/rte_cryptodev_vdev.h | 100 + > >> drivers/bus/vdev/rte_vdev.h | 153 + > >> drivers/bus/vdev/vdev.c | 342 > ++ > >> lib/librte_cryptodev/Makefile | 2 - > >> lib/librte_cryptodev/rte_cryptodev_vdev.c | 154 -- > >> lib/librte_cryptodev/rte_cryptodev_vdev.h | 100 - > >> lib/librte_eal/bsdapp/eal/Makefile| 1 - > >> lib/librte_eal/common/Makefile| 2 +- > >> lib/librte_eal/common/eal_common_vdev.c | 342 > >> -- > > >> lib/librte_eal/common/include/rte_dev.h | 24 +-- > >> lib/librte_eal/common/include/rte_vdev.h | 131 > >> lib/librte_eal/linuxapp/eal/Makefile | 1 - > >> mk/rte.app.mk | 1 + > >> 18 files changed, 826 insertions(+), 755 deletions(-) > >> create mode 100644 drivers/bus/vdev/Makefile > >> create mode 100644 drivers/bus/vdev/rte_bus_vdev_version.map > >> create mode 100644 drivers/bus/vdev/rte_cryptodev_vdev.c > >> create mode 100644 drivers/bus/vdev/rte_cryptodev_vdev.h > >> create mode 100644 drivers/bus/vdev/rte_vdev.h > >> create mode 100644 drivers/bus/vdev/vdev.c > >> delete mode 100644 lib/librte_cryptodev/rte_cryptodev_vdev.c > >> delete mode 100644 lib/librte_cryptodev/rte_cryptodev_vdev.h > >> delete mode 100644 lib/librte_eal/common/eal_common_vdev.c > >> delete mode 100644 lib/librte_eal/common/include/rte_vdev.h > >> > >> diff --git a/config/common_base b/config/common_base > >> index 5e97a08..aca0994 100644 > >> --- a/config/common_base > >> +++ b/config/common_base > >> @@ -750,3 +750,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y > >> # Compile the eventdev application > >> # > >> CONFIG_RTE_APP_EVENTDEV=y > >> + > >> +# > >> +# Compile the vdev bus > >> +# > >> +CONFIG_RTE_LIBRTE_VDEV=y > > Why not CONFIG_RTE_LIBRTE_VDEV_BUS? > > It would seem more consistent. > > Was trying to be consistent with the directory name, drivers/bus/vdev. > Do you think that directory should also be renamed? > > > > >> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile > >> index 0224214..9b6d45e 100644 > >> --- a/drivers/bus/Makefile > >> +++ b/drivers/bus/Makefile > >> @@ -35,4 +35,6 @@ core-libs := librte_eal librte_mbuf librte_mempool > librte_ring librte_ether > >> DIRS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += fslmc > >> DEPDIRS-fslmc = $(core-libs) > >> > >> +DIRS-$(CONFIG_RTE_LIBRTE_VDEV) += vdev > >> + > >> include $(RTE_SDK)/mk/rte.subdir.mk > >> diff --git a/drivers/bus/vdev/Makefile b/drivers/bus/vdev/Makefile > >> new file mode 100644 > >> index 000..30c4813 > >> --- /dev/null > >> +++ b/drivers/bus/vdev/Makefile > >> @@ -0,0 +1,57 @@ > >> +# BSD LICENSE > >> +# > >> +# Copyright(c) 2017 Intel Corporation. All rights reserved. > >> +# All rights reserved. > >> +# > >> +# Redistribution and use in source and binary forms, with or without > >> +# modification, are permitted provided that the following conditions > >> +# are met: > >> +# > >> +# * Redistributions of source code must retain the above copyright > >> +# notice, this list of conditions and the following disclaimer. > >> +# * Redistributions in binary form must reproduce the above > copyright > >> +# notice, this list of conditions and the following disclaimer in > >> +# the documentation and/or other materials provided with the > >> +# distribution. > >> +# * Neither the name of Intel Corporation nor the names of its > >> +# contributors may be used to endorse or promote products > derived > >> +# from this software without specific prior written permission. > >> +# > >> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > CONTRIBUTORS > >> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, > BUT NOT > >> +#
Re: [dpdk-dev] [PATCH 01/12] cryptodev: remove crypto vdev init
> -Original Message- > From: Tan, Jianfeng > Sent: Friday, August 25, 2017 10:41 AM > To: dev@dpdk.org > Cc: Richardson, Bruce ; Ananyev, Konstantin > ; De Lara Guarch, Pablo > ; tho...@monjalon.net; > y...@fridaylinux.org; maxime.coque...@redhat.com; > mtetsu...@gmail.com; Yigit, Ferruh ; Tan, > Jianfeng > Subject: [PATCH 01/12] cryptodev: remove crypto vdev init > > CC: Pablo de Lara > > Signed-off-by: Jianfeng Tan Acked-by: Pablo de Lara
Re: [dpdk-dev] [PATCH 03/12] crypto: move vdev helper functions into dedicated file
> -Original Message- > From: Tan, Jianfeng > Sent: Friday, August 25, 2017 10:41 AM > To: dev@dpdk.org > Cc: Richardson, Bruce ; Ananyev, Konstantin > ; De Lara Guarch, Pablo > ; tho...@monjalon.net; > y...@fridaylinux.org; maxime.coque...@redhat.com; > mtetsu...@gmail.com; Yigit, Ferruh ; Tan, > Jianfeng > Subject: [PATCH 03/12] crypto: move vdev helper functions into dedicated > file > Title should start with "cryptodev: ..." Also, it is missing the "Signed-off" line.
Re: [dpdk-dev] [PATCH v2 05/14] pci: introduce PCI lib and bus
Hey, On Mon, Sep 18, 2017 at 05:23:23PM +0530, Shreyansh Jain wrote: > Hello Gaetan, > > On Monday 18 September 2017 03:01 PM, Gaetan Rivet wrote: > >The PCI lib defines the types and methods allowing to use PCI elements. > > > >The PCI bus implements a bus driver for PCI devices by constructing > >rte_bus elements using the PCI lib. > > > >Move the relevant code out of the EAL to their expected place. > > > >Signed-off-by: Gaetan Rivet > >--- > > config/common_base | 10 + > > drivers/bus/Makefile| 2 + > > drivers/bus/pci/Makefile| 59 ++ > > drivers/bus/pci/bsd/Makefile| 32 ++ > > drivers/bus/pci/bsd/rte_pci.c | 670 > > ++ > > drivers/bus/pci/include/rte_bus_pci.h | 387 + > > drivers/bus/pci/linux/Makefile | 37 ++ > > drivers/bus/pci/linux/rte_pci.c | 722 > > > > drivers/bus/pci/linux/rte_pci_init.h| 97 > > drivers/bus/pci/linux/rte_pci_uio.c | 567 +++ > > drivers/bus/pci/linux/rte_pci_vfio.c| 674 > > ++ > > drivers/bus/pci/linux/rte_vfio_mp_sync.c| 424 ++ > > drivers/bus/pci/private.h | 173 ++ > > drivers/bus/pci/rte_bus_pci_version.map | 21 + > > drivers/bus/pci/rte_pci_common.c| 542 ++ > > drivers/bus/pci/rte_pci_common_uio.c| 234 > > lib/Makefile| 2 + > > lib/librte_eal/bsdapp/eal/Makefile | 3 - > > lib/librte_eal/bsdapp/eal/eal_pci.c | 670 > > -- > > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 15 - > > lib/librte_eal/common/Makefile | 2 +- > > lib/librte_eal/common/eal_common_pci.c | 580 --- > > lib/librte_eal/common/eal_common_pci_uio.c | 233 > > lib/librte_eal/common/include/rte_pci.h | 598 > > lib/librte_eal/linuxapp/eal/Makefile| 10 - > > lib/librte_eal/linuxapp/eal/eal_pci.c | 722 > > > > lib/librte_eal/linuxapp/eal/eal_pci_init.h | 97 > > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 567 --- > > lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 674 > > -- > > lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c | 424 -- > > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 15 - > > lib/librte_ether/rte_ethdev.h | 2 - > > lib/librte_pci/Makefile | 48 ++ > > lib/librte_pci/include/rte_pci.h| 279 + > > lib/librte_pci/rte_pci.c| 92 +++ > > lib/librte_pci/rte_pci_version.map | 8 + > > mk/rte.app.mk | 3 + > > 37 files changed, 5084 insertions(+), 4611 deletions(-) > > create mode 100644 drivers/bus/pci/Makefile > > create mode 100644 drivers/bus/pci/bsd/Makefile > > create mode 100644 drivers/bus/pci/bsd/rte_pci.c > > create mode 100644 drivers/bus/pci/include/rte_bus_pci.h > > create mode 100644 drivers/bus/pci/linux/Makefile > > create mode 100644 drivers/bus/pci/linux/rte_pci.c > > create mode 100644 drivers/bus/pci/linux/rte_pci_init.h > > create mode 100644 drivers/bus/pci/linux/rte_pci_uio.c > > create mode 100644 drivers/bus/pci/linux/rte_pci_vfio.c > > create mode 100644 drivers/bus/pci/linux/rte_vfio_mp_sync.c > > create mode 100644 drivers/bus/pci/private.h > > create mode 100644 drivers/bus/pci/rte_bus_pci_version.map > > create mode 100644 drivers/bus/pci/rte_pci_common.c > > create mode 100644 drivers/bus/pci/rte_pci_common_uio.c > > delete mode 100644 lib/librte_eal/bsdapp/eal/eal_pci.c > > delete mode 100644 lib/librte_eal/common/eal_common_pci.c > > delete mode 100644 lib/librte_eal/common/eal_common_pci_uio.c > > delete mode 100644 lib/librte_eal/common/include/rte_pci.h > > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci.c > > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_init.h > > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c > > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c > > create mode 100644 lib/librte_pci/Makefile > > create mode 100644 lib/librte_pci/include/rte_pci.h > > create mode 100644 lib/librte_pci/rte_pci.c > > create mode 100644 lib/librte_pci/rte_pci_version.map > > > > > > >+#endif /* _PCI_PRIVATE_H_ */ > >diff --git a/drivers/bus/pci/rte_bus_pci_version.map > >b/drivers/bus/pci/rte_bus_pci_version.map > >new file mode 100644 > >index 000..eca49e9 > >--- /dev/null > >+++ b/drivers/bus/pci/rte_bus_pci_version.map > >@@ -0,0 +1,21 @@ > >+DPDK_1
Re: [dpdk-dev] [PATCH 1/3] build: rename pkgconfig to libdpdk.pc
On Mon, 2017-09-18 at 12:09 +0100, Bruce Richardson wrote: > On Fri, Sep 15, 2017 at 06:36:10PM +0100, luca.bocca...@gmail.com > wrote: > > From: Luca Boccassi > > > > In Debian and Ubuntu we have been shipping a pkgconfig file for > > DPDK > > for more than a year now, and the filename is libdpdk.pc. > > A few downstream projects, like OVS and Collectd, have adopted the > > use of libdpdk.pc in their build systems as well. > > In order to maintain backward compatibility, rename the file from > > DPDK.pc to libdpdk.pc. > > > > Signed-off-by: Luca Boccassi > > --- > > I find the 'lib' bit strange, but if that is what is already out > there, > then we should keep it for compatibility. Not sure where the original name came from, it's been like that for a few years - it might have been my fault :-) In Debian/Ubuntu libraries development headers, unversioned shared object symlinks and static archives always ship in packages named libfoo[api-ver]-dev. This is strictly enforced by policy. We have libdpdk-dev for example. Then, usually, pkg-config files follow the same naming convention, so that if you want to build against libfoo-dev you use pkg-config libfoo. This makes it nice and predictable. But IIRC it's not enforced, and not universally followed. > In future, we might create two pkgconfig files to transition over to > a > new name, but to start with lets use what is being looked for by our > dependencies. > > Acked-by: Bruce Richardson Even just a symlink should work fine, at least it does with the pkg- config I have on Debian. Should not cause issues on any implementation. -- Kind regards, Luca Boccassi
Re: [dpdk-dev] [PATCH v2 05/14] pci: introduce PCI lib and bus
On Monday 18 September 2017 05:21 PM, Gaëtan Rivet wrote:
Hey,
On Mon, Sep 18, 2017 at 05:23:23PM +0530, Shreyansh Jain wrote:
Hello Gaetan,
On Monday 18 September 2017 03:01 PM, Gaetan Rivet wrote:
The PCI lib defines the types and methods allowing to use PCI elements.
The PCI bus implements a bus driver for PCI devices by constructing
rte_bus elements using the PCI lib.
Move the relevant code out of the EAL to their expected place.
Signed-off-by: Gaetan Rivet
---
config/common_base | 10 +
drivers/bus/Makefile| 2 +
drivers/bus/pci/Makefile| 59 ++
drivers/bus/pci/bsd/Makefile| 32 ++
drivers/bus/pci/bsd/rte_pci.c | 670 ++
drivers/bus/pci/include/rte_bus_pci.h | 387 +
drivers/bus/pci/linux/Makefile | 37 ++
drivers/bus/pci/linux/rte_pci.c | 722
drivers/bus/pci/linux/rte_pci_init.h| 97
drivers/bus/pci/linux/rte_pci_uio.c | 567 +++
drivers/bus/pci/linux/rte_pci_vfio.c| 674 ++
drivers/bus/pci/linux/rte_vfio_mp_sync.c| 424 ++
drivers/bus/pci/private.h | 173 ++
drivers/bus/pci/rte_bus_pci_version.map | 21 +
drivers/bus/pci/rte_pci_common.c| 542 ++
drivers/bus/pci/rte_pci_common_uio.c| 234
lib/Makefile| 2 +
lib/librte_eal/bsdapp/eal/Makefile | 3 -
lib/librte_eal/bsdapp/eal/eal_pci.c | 670 --
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 15 -
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_common_pci.c | 580 ---
lib/librte_eal/common/eal_common_pci_uio.c | 233
lib/librte_eal/common/include/rte_pci.h | 598
lib/librte_eal/linuxapp/eal/Makefile| 10 -
lib/librte_eal/linuxapp/eal/eal_pci.c | 722
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 97
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 567 ---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 674 --
lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c | 424 --
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 15 -
lib/librte_ether/rte_ethdev.h | 2 -
lib/librte_pci/Makefile | 48 ++
lib/librte_pci/include/rte_pci.h| 279 +
lib/librte_pci/rte_pci.c| 92 +++
lib/librte_pci/rte_pci_version.map | 8 +
mk/rte.app.mk | 3 +
37 files changed, 5084 insertions(+), 4611 deletions(-)
create mode 100644 drivers/bus/pci/Makefile
create mode 100644 drivers/bus/pci/bsd/Makefile
create mode 100644 drivers/bus/pci/bsd/rte_pci.c
create mode 100644 drivers/bus/pci/include/rte_bus_pci.h
create mode 100644 drivers/bus/pci/linux/Makefile
create mode 100644 drivers/bus/pci/linux/rte_pci.c
create mode 100644 drivers/bus/pci/linux/rte_pci_init.h
create mode 100644 drivers/bus/pci/linux/rte_pci_uio.c
create mode 100644 drivers/bus/pci/linux/rte_pci_vfio.c
create mode 100644 drivers/bus/pci/linux/rte_vfio_mp_sync.c
create mode 100644 drivers/bus/pci/private.h
create mode 100644 drivers/bus/pci/rte_bus_pci_version.map
create mode 100644 drivers/bus/pci/rte_pci_common.c
create mode 100644 drivers/bus/pci/rte_pci_common_uio.c
delete mode 100644 lib/librte_eal/bsdapp/eal/eal_pci.c
delete mode 100644 lib/librte_eal/common/eal_common_pci.c
delete mode 100644 lib/librte_eal/common/eal_common_pci_uio.c
delete mode 100644 lib/librte_eal/common/include/rte_pci.h
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci.c
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_init.h
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
delete mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
create mode 100644 lib/librte_pci/Makefile
create mode 100644 lib/librte_pci/include/rte_pci.h
create mode 100644 lib/librte_pci/rte_pci.c
create mode 100644 lib/librte_pci/rte_pci_version.map
+#endif /* _PCI_PRIVATE_H_ */
diff --git a/drivers/bus/pci/rte_bus_pci_version.map
b/drivers/bus/pci/rte_bus_pci_version.map
new file mode 100644
index 000..eca49e9
--- /dev/null
+++ b/drivers/bus/pci/rte_bus_pci_version.map
@@ -0,0 +1,21 @@
+DPDK_17.08 {
You might want to bump this to 17.11.
Thanks, fixing this.
+ global:
+
+ rte_pci_detach;
+ rte_pci_dump;
+ rte_pci_ioport_map;
+ rte_pci_ioport_read;
+ rte_pci_ioport_unmap;
+
Re: [dpdk-dev] [PATCH] net/bonding: strengthen the judgment of lacp packets
On 18/09/2017 12:12 PM, zengganghui wrote: For example, when packets received from an MLX network card, the value of mbuf->vlan_tci is a random value. So that this value cannot be used to determine whether VLAN packets . We need to judgment mbuf->ol_flags first. BR. Zeng Ganghui Huawei Technologies Co., Ltd. -Original Message- From: Doherty, Declan [mailto:declan.dohe...@intel.com] Sent: Monday, September 18, 2017 5:14 PM To: zengganghui; dev@dpdk.org Subject: Re: [PATCH] net/bonding: strengthen the judgment of lacp packets On 30/08/2017 4:46 AM, ZengGanghui wrote: When the nic does not support vlan rx offload may be wrong, resulting in lacp packets will not be processed. Signed-off-by: ZengGanghui --- ... Acked-by: Declan Doherty Ok, I see your point. A LACP PDU can't be encapsulated in a VLAN packet anyway, as it is link local traffic. So a check for ol_flags & PKT_RX_VLAN_PKT != 0 should be sufficient, otherwise if the PKT_RX_VLAN_PKT flag is true the packet cannot be link local and therefore a LACP PDU. I think that it's safe to assume all PMDs must set this flag if VLAN stripping is enabled?
Re: [dpdk-dev] [PATCH] net/bonding: strengthen the judgment of lacp packets
All mbuf packets have been init to zero when pktmbuf pool create. So judgment this flag is safe, whether or not support VLAN stripping. BR. Zeng Ganghui Huawei Technologies Co., Ltd. -Original Message- From: Doherty, Declan [mailto:declan.dohe...@intel.com] Sent: Monday, September 18, 2017 8:34 PM To: zengganghui; dev@dpdk.org Subject: Re: [PATCH] net/bonding: strengthen the judgment of lacp packets On 18/09/2017 12:12 PM, zengganghui wrote: > For example, when packets received from an MLX network card, the value of > mbuf->vlan_tci is a random value. So that this value cannot be used to > determine whether VLAN packets . We need to judgment mbuf->ol_flags first. > > BR. > Zeng Ganghui > Huawei Technologies Co., Ltd. > > -Original Message- > From: Doherty, Declan [mailto:declan.dohe...@intel.com] > Sent: Monday, September 18, 2017 5:14 PM > To: zengganghui; dev@dpdk.org > Subject: Re: [PATCH] net/bonding: strengthen the judgment of lacp > packets > > On 30/08/2017 4:46 AM, ZengGanghui wrote: >> When the nic does not support vlan rx offload may be wrong, resulting >> in lacp packets will not be processed. >> >> Signed-off-by: ZengGanghui >> --- > ... >> > > Acked-by: Declan Doherty > Ok, I see your point. A LACP PDU can't be encapsulated in a VLAN packet anyway, as it is link local traffic. So a check for ol_flags & PKT_RX_VLAN_PKT != 0 should be sufficient, otherwise if the PKT_RX_VLAN_PKT flag is true the packet cannot be link local and therefore a LACP PDU. I think that it's safe to assume all PMDs must set this flag if VLAN stripping is enabled?
Re: [dpdk-dev] [PATCH 1/5] eal/x86: define architecture specific rdtsc hz
On 13-Aug-17 8:03 AM, jerin.jacob at caviumnetworks.com (Jerin Jacob) wrote: CC: Bruce Richardson CC: Konstantin Ananyev Signed-off-by: Jerin Jacob --- Acked-by: Anatoly Burakov
Re: [dpdk-dev] [PATCH] net/bonding: strengthen the judgment of lacp packets
On 18/09/2017 1:50 PM, zengganghui wrote: All mbuf packets have been init to zero when pktmbuf pool create. So judgment this flag is safe, whether or not support VLAN stripping. Ok, but is there any need to check the ol_flags for PKT_RX_VLAN_PKT or check the vlan_tci at all. I haven't come across anything in the specification which allows LACP links to be formed on top of VLANs but I may be missing something? So if the ethertype is not ETHER_TYPE_SLOW it is irrelevant whether the packet has a VLAN tag or not. Also on the basis that you could have LAG groups on top of VLANs, if the NIC doesn't support VLAN stripping/insertion then we would miss all the ingress LACP PDU at the moment now anyway, since the ethertype would be VLAN and not ETHER_TYPE_SLOW, so is_lacp_packet() would always return 0, and we would also fail to encapsulate the LACP PDU in the correct VLAN on egress as that isn't supported in the bonding implementation. BR. Zeng Ganghui Huawei Technologies Co., Ltd. -Original Message- From: Doherty, Declan [mailto:declan.dohe...@intel.com] Sent: Monday, September 18, 2017 8:34 PM To: zengganghui; dev@dpdk.org Subject: Re: [PATCH] net/bonding: strengthen the judgment of lacp packets On 18/09/2017 12:12 PM, zengganghui wrote: For example, when packets received from an MLX network card, the value of mbuf->vlan_tci is a random value. So that this value cannot be used to determine whether VLAN packets . We need to judgment mbuf->ol_flags first. BR. Zeng Ganghui Huawei Technologies Co., Ltd. -Original Message- From: Doherty, Declan [mailto:declan.dohe...@intel.com] Sent: Monday, September 18, 2017 5:14 PM To: zengganghui; dev@dpdk.org Subject: Re: [PATCH] net/bonding: strengthen the judgment of lacp packets On 30/08/2017 4:46 AM, ZengGanghui wrote: When the nic does not support vlan rx offload may be wrong, resulting in lacp packets will not be processed. Signed-off-by: ZengGanghui --- ... Acked-by: Declan Doherty Ok, I see your point. A LACP PDU can't be encapsulated in a VLAN packet anyway, as it is link local traffic. So a check for ol_flags & PKT_RX_VLAN_PKT != 0 should be sufficient, otherwise if the PKT_RX_VLAN_PKT flag is true the packet cannot be link local and therefore a LACP PDU. I think that it's safe to assume all PMDs must set this flag if VLAN stripping is enabled?
Re: [dpdk-dev] [PATCH v3] ixgbe: eliminate duplicate filterlist symbols
On 9/14/2017 2:38 PM, Ferruh Yigit wrote: On 9/14/2017 1:50 PM, David C Harton wrote: From: David Harton Some compilers generate warnings for duplicate symbols for the set of filter lists current defined in ixgbe_ethdev.h. This commits moves the definition and declaration to the source file that actually uses them and provides a function to initialize the values akin to its flush function. Signed-off-by: David Harton Reviewed-by: Ferruh Yigit (title needs to be "net/ixgbe: ...", but this can be fixed while applying) Reviewed-by: Radu Nicolau
Re: [dpdk-dev] [PATCH 01/11] lib/rte_security: add security library
-Original Message-
> Date: Thu, 14 Sep 2017 13:56:41 +0530
> From: Akhil Goyal
> To: dev@dpdk.org
> CC: declan.dohe...@intel.com, pablo.de.lara.gua...@intel.com,
> hemant.agra...@nxp.com, radu.nico...@intel.com, bor...@mellanox.com,
> avia...@mellanox.com, tho...@monjalon.net, sandeep.ma...@nxp.com,
> jerin.ja...@caviumnetworks.com
> Subject: [PATCH 01/11] lib/rte_security: add security library
> X-Mailer: git-send-email 2.9.3
>
> rte_security library provides APIs for security session
> create/free for protocol offload or offloaded crypto
> operation to ethernet device.
Overall the API semantic looks good. A few comments inlined.
I think, This patch should split as minimum two. One just the
specification header file and other one implementation.
>
> Signed-off-by: Akhil Goyal
> Signed-off-by: Boris Pismenny
> Signed-off-by: Radu Nicolau
> Signed-off-by: Declan Doherty
> ---
> +
> +#include
> +#include
> +
> +#include "rte_security.h"
> +#include "rte_security_driver.h"
> +
> +#define RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ(8)
> +
> +struct rte_security_ctx {
> + uint16_t id;
> + enum {
> + RTE_SECURITY_INSTANCE_INVALID = 0,
explicit zero is not required.
> + RTE_SECURITY_INSTANCE_VALID
> + } state;
> + void *device;
> + struct rte_security_ops *ops;
> +};
> +
> +
> +int
> +rte_security_register(uint16_t *id, void *device,
> + struct rte_security_ops *ops)
> +{
> + if (max_nb_security_instances == 0) {
> + security_instances = rte_malloc(
> + "rte_security_instances_ops",
> + sizeof(*security_instances) *
> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ, 0);
> +
> + if (security_instances == NULL)
> + return -ENOMEM;
> + max_nb_security_instances =
> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ;
> + } else if (nb_security_instances >= max_nb_security_instances) {
> + uint16_t *instances = rte_realloc(security_instances,
> + sizeof(struct rte_security_ops *) *
> + (max_nb_security_instances +
> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ), 0);
> +
> + if (instances == NULL)
> + return -ENOMEM;
> +
> + max_nb_security_instances +=
> + RTE_SECURITY_INSTANCES_BLOCK_ALLOC_SZ;
> + }
> +
> + *id = nb_security_instances++;
> +
> + security_instances[*id].id = *id;
> + security_instances[*id].state = RTE_SECURITY_INSTANCE_VALID;
> + security_instances[*id].device = device;
> + security_instances[*id].ops = ops;
This whole thing will break in multi process case where ops needs to
cloned for each process. Check the mempool library as reference.
> +
> + return 0;
> +}
> +
> +int
> +rte_security_unregister(__rte_unused uint16_t *id)
> +{
> + /* To be implemented */
This should implemented before it reaches to master.
> + return 0;
> +}
> +
> +struct rte_security_session *
> +int
> +rte_security_set_pkt_metadata(uint16_t id,
> + struct rte_security_session *sess,
> + struct rte_mbuf *m, void *params)
> +{
> + struct rte_security_ctx *instance;
> +
> + RTE_SEC_VALID_ID_OR_ERR_RET(id, -ENODEV);
> + instance = &security_instances[id];
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->set_pkt_metadata, -ENOTSUP);
Do you need all this checking for a fastpath function?
> + return instance->ops->set_pkt_metadata(instance->device,
> +sess, m, params);
> +}
> +
> +
> +/**
> + * @file rte_security.h
> + *
> + * RTE Security Common Definitions
> + *
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
Nice to have it in alphabetical order.
> +
> +/** IPSec protocol mode */
> +enum rte_security_ipsec_sa_mode {
> + RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
> + /**< IPSec Transport mode */
> + RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
> + /**< IPSec Tunnel mode */
> +};
> +
> +/** IPSec Protocol */
> +enum rte_security_ipsec_sa_protocol {
> + RTE_SECURITY_IPSEC_SA_PROTO_AH,
> + /**< AH protocol */
> + RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> + /**< ESP protocol */
> +};
> +
> +/** IPSEC tunnel type */
> +enum rte_security_ipsec_tunnel_type {
> + RTE_SECURITY_IPSEC_TUNNEL_IPV4 = 0,
Explicit zero may not be required.
> + /**< Outer header is IPv4 */
> + RTE_SECURITY_IPSEC_TUNNEL_IPV6,
> + /**< Outer header is IPv6 */
> +};
> +struct rte_security_ipsec_tunnel_param {
> + enum rte_security_ipsec_tunnel_type type;
> + /**< Tunnel type: IPv4 or IPv6 */
> +
Anonymous union, You need RTE_STD_C11 here.
> +
> +
Re: [dpdk-dev] [PATCH v4 3/3] doc: add details on ethdev offloads API
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shahaf Shuler
> Sent: Sunday, September 17, 2017 7:55 AM
> To: tho...@monjalon.net; jerin.ja...@caviumnetworks.com; Ananyev,
> Konstantin ; arybche...@solarflare.com
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v4 3/3] doc: add details on ethdev offloads API
>
> Add the programmers guide details on the new offloads API introduced by
> commits:
>
> commit f649472cad9d ("ethdev: introduce Rx queue offloads API") commit
> ecb46b66cda5 ("ethdev: introduce Tx queue offloads API")
>
> Signed-off-by: Shahaf Shuler
> ...
> +Per-Port and Per-Queue Offloads
> +^^^
> +
> +On DPDK 17.11, a new offloads API was introduced.
It is best to omit this line.
There are a number of small grammatical errors in the rest of the text.
Probably something like this would be better:
Per-Port and Per-Queue Offloads
^^^
In the DPDK offload API, offloads are divided into per-port and per-queue
offloads.
The different offloads capabilities can be queried using
``rte_eth_dev_info_get()``.
Supported offloads can be either per-port or per-queue.
Offloads are enabled using the existing ``DEV_TX_OFFLOAD_*`` or
``DEV_RX_OFFLOAD_*`` flags.
Per-port offload configuration is set using ``rte_eth_dev_configure``.
Per-queue offload configuration is set using ``rte_eth_rx_queue_setup`` and
``rte_eth_tx_queue_setup``.
To enable per-port offload, the offload should be set on both device
configuration and queue setup.
In case of a mixed configuration the queue setup shall return with an error.
To enable per-queue offload, the offload can be set only on the queue setup.
Offloads which are not enabled are disabled by default.
For an application to use the Tx offloads API it should set the
``ETH_TXQ_FLAGS_IGNORE`` flag in the ``txq_flags`` field located in
``rte_eth_txconf`` struct.
In such cases it is not required to set other flags in ``txq_flags``.
In such cases it is not required to set other bitfield offloads in the
``rxmode`` struct.
For an application to use the Rx offloads API it should set the
``ignore_offload_bitfield`` bit in the ``rte_eth_rxmode`` struct.
Reviewed-by: John McNamara
[dpdk-dev] [PATCH] event/sw: remove spare newline from error logs
This commit removes extra newline characters from SW_LOG_ERR()
messages, which cleans up the error output.
Signed-off-by: Harry van Haaren
---
Note that this patchset applies cleanly only on the updated service
cores patchset (which contained a trivial change to SW PMD). Suggesting
a rebase of next-eventdev tree before applying this - will make life easier :)
---
drivers/event/sw/sw_evdev.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index da6ac30..361df89 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -176,7 +176,7 @@ sw_port_setup(struct rte_eventdev *dev, uint8_t port_id,
dev->data->socket_id,
RING_F_SP_ENQ | RING_F_SC_DEQ | RING_F_EXACT_SZ);
if (p->rx_worker_ring == NULL) {
- SW_LOG_ERR("Error creating RX worker ring for port %d\n",
+ SW_LOG_ERR("Error creating RX worker ring for port %d",
port_id);
return -1;
}
@@ -195,7 +195,7 @@ sw_port_setup(struct rte_eventdev *dev, uint8_t port_id,
RING_F_SP_ENQ | RING_F_SC_DEQ | RING_F_EXACT_SZ);
if (p->cq_worker_ring == NULL) {
rte_event_ring_free(p->rx_worker_ring);
- SW_LOG_ERR("Error creating CQ worker ring for port %d\n",
+ SW_LOG_ERR("Error creating CQ worker ring for port %d",
port_id);
return -1;
}
@@ -360,10 +360,10 @@ sw_queue_setup(struct rte_eventdev *dev, uint8_t queue_id,
type = RTE_SCHED_TYPE_PARALLEL;
break;
case RTE_EVENT_QUEUE_CFG_ALL_TYPES:
- SW_LOG_ERR("QUEUE_CFG_ALL_TYPES not supported\n");
+ SW_LOG_ERR("QUEUE_CFG_ALL_TYPES not supported");
return -ENOTSUP;
default:
- SW_LOG_ERR("Unknown queue type %d requested\n",
+ SW_LOG_ERR("Unknown queue type %d requested",
conf->event_queue_cfg);
return -EINVAL;
}
@@ -618,13 +618,13 @@ sw_start(struct rte_eventdev *dev)
/* check a service core is mapped to this service */
if (!rte_service_runstate_get(sw->service_id))
- SW_LOG_ERR("Warning: No Service core enabled on service %s\n",
+ SW_LOG_ERR("Warning: No Service core enabled on service %s",
sw->service_name);
/* check all ports are set up */
for (i = 0; i < sw->port_count; i++)
if (sw->ports[i].rx_worker_ring == NULL) {
- SW_LOG_ERR("Port %d not configured\n", i);
+ SW_LOG_ERR("Port %d not configured", i);
return -ESTALE;
}
@@ -632,7 +632,7 @@ sw_start(struct rte_eventdev *dev)
for (i = 0; i < sw->qid_count; i++)
if (sw->qids[i].iq[0] == NULL ||
sw->qids[i].cq_num_mapped_cqs == 0) {
- SW_LOG_ERR("Queue %d not configured\n", i);
+ SW_LOG_ERR("Queue %d not configured", i);
return -ENOLINK;
}
--
2.7.4
Re: [dpdk-dev] [PATCH v5] net/mlx5: support upstream rdma-core
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Monday, September 18, 2017 12:07 PM
> To: Shachar Beiser ; dev@dpdk.org
> Cc: Adrien Mazarguil ; Nélio Laranjeiro
>
> Subject: Re: [dpdk-dev] [PATCH v5] net/mlx5: support upstream rdma-core
>
> On 9/17/2017 8:31 AM, Shachar Beiser wrote:
> >
> >
> >> -Original Message-
> >> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> >> Sent: Thursday, September 14, 2017 4:47 PM
> >> To: Shachar Beiser ; dev@dpdk.org
> >> Cc: Adrien Mazarguil ; Nélio Laranjeiro
> >>
> >> Subject: Re: [dpdk-dev] [PATCH v5] net/mlx5: support upstream
> >> rdma-core
> >>
> >> On 9/14/2017 2:34 PM, Shachar Beiser wrote:
> >>> This removes the dependency on specific Mellanox OFED libraries by
> >>> using the upstream rdma-core and linux upstream community code.
> >>
> >> Would you mind mentioning what is the difference between "specific
> >> Mellanox OFED libraries" and "upstream rdma-core"? If not in the
> >> documentation, at least in mail list for interested people?
> >>
> >> Does it make sense to put this update into release notes?
> >>
> >> Thanks,
> >> ferruh
> >>
> >
> > Hi Ferruh,
> >
> > Both packages, rdma-core upstream & Mellanox OFED are Linux user-
> space packages :
> > 1. Rdma-core is the Linux upstream user-space package.
> > 2. Mellanox OFED is the Mellanox's Linux user-space package.
> > The difference is the APIs . We shall explain that difference in the
> > release notes .
>
> The difference can be too much detail for release notes, I believe it is good
> to
> mention in release notes the dependency requirement change, as above
> commit log.
>
> But this commit log can have the detail.
I will send a new PATCHv6 with an updated commit log . That contains this
explanation above. The release notes will updated by Shahaf Shuler
separately.
>
> >
> > -Shachar Beiser.
> >
> >>>
> >>> ---
> >>> I have squashed :
> >>> [PATCH v2 3/3] “net/mlx5: fix interrupt enable return”
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> >> k
> >>>
> >>
> .org%2Fdev%2Fpatchwork%2Fpatch%2F28380%2F&data=02%7C01%7Cshach
> >> arbe%40m
> >>>
> >>
> ellanox.com%7Cc79d7690cb454f8dd41508d4fb771dea%7Ca652971c7d2e4d9b
> >> a6a4d
> >>>
> >>
> 149256f461b%7C0%7C0%7C636409936407431479&sdata=T5wgSUeCx1tzM9Z
> >> UnBAauNt
> >>> iG4djfIpOJZOj%2FWM6v4Y%3D&reserved=0
> >>> into this patch
> >>>
> >>> a. Compile with rdma-core commit f11292efd541 ("Merge pull request
> >>> #202") b. Tested with linux kernel 4.13-rc4 c. For performance
> >>> testing recommended to wait till kernel 4.14
> >>>
> >>> Signed-off-by: Shachar Beiser
> >>
> >> <...>
> >
Re: [dpdk-dev] [PATCH 06/12] eal: add channel for primary/secondary communication
Hi Jianfeng,
On Fri, Aug 25, 2017 at 09:40:46AM +, Jianfeng Tan wrote:
> Previouly, there is only one way for primary/secondary to exchange
> messages, that is, primary process writes info into some predefind
> file, and secondary process reads info out. That cannot address
> the requirements:
> a. Secondary wants to send info to primary.
> b. Sending info at any time, instead of just initialization time.
> c. Share FD with the other side.
If you can explain more about why the above three characters are required
for enabling vdev in the secondary process here, that would be better. For
example, vdev may hot plugin or remove, so the primary and the secondary
process need to exchange data bidirectionally and dynamically.
>
> This patch proposes to create a communication channel (as an unix
> socket connection) for above requirements.
Can you give more explainations about how the channel works? Like both
the primary and the secondary register actions for specific messages, and
another thread is created to listen and react incoming messages.
>
> Three new APIs are added:
>
> 1. rte_eal_primary_secondary_add_action is used to register an action,
> if the calling component wants to response the messages from the
> corresponding component in its primary process or secondary processes.
> 2. rte_eal_primary_secondary_del_action is used to unregister the
> action if the calling component does not want to response the messages.
> 3. rte_eal_primary_secondary_sendmsg is used to send a message.
>
> Signed-off-by: Jianfeng Tan
> ---
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 8 +
> lib/librte_eal/common/eal_common_proc.c | 454
>
> lib/librte_eal/common/eal_filesystem.h | 18 +
> lib/librte_eal/common/eal_private.h | 10 +
> lib/librte_eal/common/include/rte_eal.h | 74
> lib/librte_eal/linuxapp/eal/eal.c | 6 +
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 8 +
> 7 files changed, 578 insertions(+)
>
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index aac6fd7..f4ff29f 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -237,3 +237,11 @@ EXPERIMENTAL {
> rte_service_unregister;
>
> } DPDK_17.08;
> +
> +EXPERIMENTAL {
> + global:
> +
> + rte_eal_primary_secondary_add_action;
> + rte_eal_primary_secondary_del_action;
> + rte_eal_primary_secondary_sendmsg;
> +} DPDK_17.11;
> diff --git a/lib/librte_eal/common/eal_common_proc.c
> b/lib/librte_eal/common/eal_common_proc.c
> index 60526ca..fa316bf 100644
> --- a/lib/librte_eal/common/eal_common_proc.c
> +++ b/lib/librte_eal/common/eal_common_proc.c
> @@ -33,8 +33,20 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> #include
> +#include
>
> +#include "eal_private.h"
> #include "eal_filesystem.h"
> #include "eal_internal_cfg.h"
>
> @@ -59,3 +71,445 @@ rte_eal_primary_proc_alive(const char *config_file_path)
>
> return !!ret;
> }
> +
> +struct action_entry {
> + TAILQ_ENTRY(action_entry) next; /**< Next attached action entry*/
> +
> +#define MAX_ACTION_NAME_LEN 64
> + char action_name[MAX_ACTION_NAME_LEN];
> + rte_eal_primary_secondary_t *action;
> +};
> +
> +/** Double linked list of actions. */
> +TAILQ_HEAD(action_entry_list, action_entry);
> +
> +static struct action_entry_list action_entry_list =
> + TAILQ_HEAD_INITIALIZER(action_entry_list);
> +
> +static struct action_entry *
> +find_action_entry_by_name(const char *name)
> +{
> + int len = strlen(name);
> + struct action_entry *entry;
> +
> + TAILQ_FOREACH(entry, &action_entry_list, next) {
> + if (strncmp(entry->action_name, name, len) == 0)
> + break;
> + }
> +
> + return entry;
> +}
> +
> +int
> +rte_eal_primary_secondary_add_action(const char *action_name,
> + rte_eal_primary_secondary_t action)
> +{
> + struct action_entry *entry = malloc(sizeof(struct action_entry));
> +
> + if (entry == NULL)
> + return -ENOMEM;
> +
> + strncpy(entry->action_name, action_name, MAX_ACTION_NAME_LEN);
> + entry->action = action;
In struct action_entry, the type of action is 'rte_eal_primary_secondary_t *',
but you assign an object to action here.
> + TAILQ_INSERT_TAIL(&action_entry_list, entry, next);
What would happen if register two actions for a same message name?
> + return 0;
> +}
> +
> +void
> +rte_eal_primary_secondary_del_action(const char *name)
> +{
> + struct action_entry *entry = find_action_entry_by_name(name);
> +
> + TAILQ_REMOVE(&action_entry_list, entry, next);
> + free(entry);
> +}
> +
> +#define MAX_SECONDARY_PROCS 8
A simple qu
Re: [dpdk-dev] [PATCH 1/2] ring: increase maximum ring size
On 07-Sep-17 1:20 PM, Olivier Matz wrote: There is no reason to prevent ring from beeing larger than 0x0FFF. Increase the maximum size to 0x7FFF, which is the maximum possible without changing the code and the structure definition (size is stored on a uint32_t). Link: http://dpdk.org/ml/archives/dev/2017-September/074701.html Suggested-by: Venkatesh Nuthula Signed-off-by: Olivier Matz --- Checkpatch issues aside, Reviewed-by: Anatoly Burakov
Re: [dpdk-dev] [PATCH] doc: add note on hardware support deprecation
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson > Sent: Friday, September 15, 2017 2:41 PM > To: dev@dpdk.org > Cc: Richardson, Bruce > Subject: [dpdk-dev] [PATCH] doc: add note on hardware support deprecation > > Following agreement at the DPDK Technical Board meeting [1], the policy > that hardware support deprecation should be treated as though it were an > ABI break needs to be documented in the contributors guide. > > [1] http://dpdk.org/ml/archives/dev/2017-September/074613.html > > Signed-off-by: Bruce Richardson > ... > > +.. note:: > + > +Updates to the minimum HW requirements, which drop support for s/HW/hardware The next only needs to be indented 3 spaces to align with the directive. Apart from that: Acked-by: John McNamara
Re: [dpdk-dev] [PATCH v4 5/5] test/cfgfile: add new unit test
> -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Friday, September 15, 2017 3:56 PM > To: Piasecki, JacekX > Cc: dev@dpdk.org; Richardson, Bruce ; Jain, > Deepak K ; Kozak, KubaX > ; Jastrzebski, MichalX K > > Subject: Re: [dpdk-dev] [PATCH v4 5/5] test/cfgfile: add new unit test > > 04/09/2017 11:30, Bruce Richardson: > > This file is a temporary one, so: > > a) should be placed in /tmp > > b) should be removed at the end of the test. > > Jacek, do you plan to update this series in 17.11 timeframe? Hi Thomas, yes we plan to update the series. V5 should be sent tomorrow.
Re: [dpdk-dev] [PATCH 2/2] test/ring: do not mask result of enqueue or dequeue
On 07-Sep-17 1:20 PM, Olivier Matz wrote:
The define RTE_RING_SZ_MASK is the maximum size supported by the
rte_ring. The size is checked at ring creation.
There is no reason today to mask the result of
rte_ring_sp_enqueue_burst() or rte_ring_sc_dequeue_burst() with this
value. The flag RTE_RING_QUOT_EXCEED was previously included in the
returned value but it was removed in
commit 77dd3064270c ("ring: remove watermark support").
Signed-off-by: Olivier Matz
---
Reviewed-by: Anatoly Burakov
Re: [dpdk-dev] [PATCH] doc: update failsafe feature list
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Matan Azrad > Sent: Thursday, September 14, 2017 4:32 PM > To: Gaetan Rivet > Cc: dev@dpdk.org > Subject: [dpdk-dev] [PATCH] doc: update failsafe feature list > > Add supported failsafe features to feature list. > Remove stats per queue feature from failsafe feature list since > queue_stats_mapping_set dev op has not implemented yet. > > Signed-off-by: Matan Azrad Acked-by: John McNamara
[dpdk-dev] [PATCH v7] net/mlx5: support upstream rdma-core
This removes the dependency on specific Mellanox OFED libraries by
using the upstream rdma-core and linux upstream community code.
Both packages, rdma-core upstream & Mellanox OFED are Linux user-space
packages :
1. Rdma-core is the Linux upstream user-space package.(Generic)
2. Mellanox OFED is the Mellanox's Linux user-space package.(Proprietary)
The difference between the two are the APIs towards the kernel.
---
a. Compile with rdma-core commit f11292efd541 ("Merge pull request #202")
b. Tested with linux kernel 4.13-rc4
c. For performance testing recommended to wait till kernel 4.14
Signed-off-by: Shachar Beiser
---
This patch enhances the commit log of the previous patch:
http://dpdk.org/dev/patchwork/patch/28803/
An update to the release notes will be sent saperately
by Shahaf Shuler.
---
doc/guides/nics/mlx5.rst | 32 +++--
drivers/net/mlx5/Makefile| 23 ++--
drivers/net/mlx5/mlx5.c | 98 ---
drivers/net/mlx5/mlx5.h | 4 +-
drivers/net/mlx5/mlx5_ethdev.c | 4 +-
drivers/net/mlx5/mlx5_fdir.c | 103
drivers/net/mlx5/mlx5_flow.c | 230 +--
drivers/net/mlx5/mlx5_mac.c | 18 +--
drivers/net/mlx5/mlx5_prm.h | 42 ++-
drivers/net/mlx5/mlx5_rxmode.c | 18 +--
drivers/net/mlx5/mlx5_rxq.c | 228 +++---
drivers/net/mlx5/mlx5_rxtx.c | 3 +-
drivers/net/mlx5/mlx5_rxtx.h | 33 ++---
drivers/net/mlx5/mlx5_rxtx_vec_sse.c | 3 +-
drivers/net/mlx5/mlx5_txq.c | 73 ++-
drivers/net/mlx5/mlx5_vlan.c | 13 +-
mk/rte.app.mk| 2 +-
17 files changed, 504 insertions(+), 423 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index c6a196c..98cfbfc 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -297,8 +297,9 @@ DPDK and must be installed separately:
This library basically implements send/receive calls to the hardware
queues.
-- **Kernel modules** (mlnx-ofed-kernel)
+- **Kernel modules** (mlnx-ofed-kernel or linux upstream)
+ DPDK 17.11 supports rdma-corev16 , linux upstream kernel 4.14.
They provide the kernel-side Verbs API and low level device drivers that
manage actual hardware initialization and resources sharing with user
space processes.
@@ -324,9 +325,29 @@ DPDK and must be installed separately:
Both libraries are BSD and GPL licensed. Linux kernel modules are GPL
licensed.
+- **installation options**
+
+ In order to install the above , Mellanox supports two options:
+
+rmda-core + upstream kernel (recommened)
+
+
+Currently supported by DPDK:
+
+ - minimal kernel version : 4.13-rc4
+ - minimal rdma-core version: v15
+
+installation instructions can be found in :
+
+ - https://github.com/linux-rdma/rdma-core
+ - https://github.com/Mellanox/linux
+
+Mellanox OFED
+~
+
Currently supported by DPDK:
-- Mellanox OFED version: **4.1**.
+- Mellanox OFED version: **4.2**.
- firmware version:
- ConnectX-4: **12.20.1010** and above.
@@ -334,9 +355,6 @@ Currently supported by DPDK:
- ConnectX-5: **16.20.1010** and above.
- ConnectX-5 Ex: **16.20.1010** and above.
-Getting Mellanox OFED
-~
-
While these libraries and kernel modules are available on OpenFabrics
Alliance's `website
Re: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add traffic management forwarding mode
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jasvinder Singh
> Sent: Thursday, September 14, 2017 12:53 PM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ; Wu, Jingjing
>
> Subject: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add traffic management
> forwarding mode
>
> This commit extends the testpmd application with new forwarding engine
> that demonstrates the use of ethdev traffic management APIs and softnic
> PMD for QoS traffic management.
>
> In this mode, 5-level hierarchical tree of the QoS scheduler is built with the
> help of ethdev TM APIs such as shaper profile add/delete, shared shaper
> add/update, node add/delete, hierarchy commit, etc.
> The hierarchical tree has following nodes; root node(x1, level 0), subport
> node(x1, level 1), pipe node(x4096, level 2), tc node(x16348, level 3), queue
> node(x65536, level 4).
>
> During runtime, each received packet is first classified by mapping the
> packet fields information to 5-tuples (HQoS subport, pipe, traffic class,
> queue within traffic class, and color) and storing it in the packet mbuf sched
> field. After classification, each packet is sent to softnic port which
> prioritizes
> the transmission of the received packets, and accordingly sends them on to
> the output interface.
>
> To enable traffic management mode, following testpmd command is used;
>
> $ ./testpmd -c c -n 4 --vdev
> 'net_softnic0,hard_name=:06:00.1,soft_tm=on' -- -i
> --forward-mode=tm
>
> This patchset has dependency on following patch series;
> http://www.dpdk.org/dev/patchwork/patch/27517/
> http://www.dpdk.org/dev/patchwork/patch/27518/
> http://www.dpdk.org/dev/patchwork/patch/27519/
> http://www.dpdk.org/dev/patchwork/patch/27520/
>
> Signed-off-by: Jasvinder Singh
> ---
> v2 change:
> - change file name softnictm.c to tm.c
> - change forward mode name to "tm"
> - code clean up
>
> app/test-pmd/Makefile | 5 +
> app/test-pmd/testpmd.c | 11 +
> app/test-pmd/testpmd.h | 34 ++
> app/test-pmd/tm.c | 863
> +
> 4 files changed, 913 insertions(+)
> create mode 100644 app/test-pmd/tm.c
>
> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile index
> c36be19..925787f 100644
> --- a/app/test-pmd/Makefile
> +++ b/app/test-pmd/Makefile
> @@ -57,6 +57,7 @@ SRCS-y += rxonly.c
> SRCS-y += txonly.c
> SRCS-y += csumonly.c
> SRCS-y += icmpecho.c
> +SRCS-y += tm.c
> SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
>
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> @@ -81,6 +82,10 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_XENVIRT),y)
> LDLIBS += -lrte_pmd_xenvirt
> endif
>
> +ifeq ($(CONFIG_RTE_LIBRTE_PMD_SOFTNIC),y)
> +LDLIBS += -lrte_pmd_softnic
> +endif
> +
> endif
>
> CFLAGS_cmdline.o := -D_GNU_SOURCE
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 7d40139..996e982 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -167,6 +167,8 @@ struct fwd_engine * fwd_engines[] = {
> &tx_only_engine,
> &csum_fwd_engine,
> &icmp_echo_engine,
> + &softnic_tm_engine,
> + &softnic_tm_bypass_engine,
> #ifdef RTE_LIBRTE_IEEE1588
> &ieee1588_fwd_engine,
> #endif
If SCHED library is not set, I think these two modes should be disabled.
You can introduce the TM_MODE flag in testpmd.h, so you can use it everywhere.
> @@ -2044,6 +2046,15 @@ init_port_config(void)
> (rte_eth_devices[pid].data->dev_flags &
>RTE_ETH_DEV_INTR_RMV))
> port->dev_conf.intr_conf.rmv = 1;
> +
> + /* Detect softnic port */
> + if (!strcmp(port->dev_info.driver_name, "net_softnic")) {
> + memset(&port->softport, 0, sizeof(struct
> softnic_port));
> + port->softport.enable = 1;
> +
> + if (!strcmp(cur_fwd_eng->fwd_mode_name, "tm"))
> + port->softport.tm_flag = 1;
> + }
> }
> }
>
> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
> c9d7739..c8fa180 100644
> --- a/app/test-pmd/testpmd.h
> +++ b/app/test-pmd/testpmd.h
> @@ -163,6 +163,37 @@ struct port_flow {
...
> struct rte_port {
> @@ -195,6 +226,7 @@ struct rte_port {
> uint32_tmc_addr_nb; /**< nb. of addr. in mc_addr_pool
> */
> uint8_t slave_flag; /**< bonding slave port */
> struct port_flow*flow_list; /**< Associated flows. */
> + struct softnic_port softport; /**< softnic port params > */
Remove last ">".
> };
>
> /**
[dpdk-dev] [PATCH v2] doc: add note on hardware support deprecation
Following agreement at the DPDK Technical Board meeting [1], the policy that hardware support deprecation should be treated as though it were an ABI break needs to be documented in the contributors guide. [1] http://dpdk.org/ml/archives/dev/2017-September/074613.html Signed-off-by: Bruce Richardson Acked-by: John McNamara --- V2: change HW abbreviation to "hardware" and reduce indentation of note to 3 spaces only. doc/guides/contributing/versioning.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst index 8aaf370da..2ec561647 100644 --- a/doc/guides/contributing/versioning.rst +++ b/doc/guides/contributing/versioning.rst @@ -18,6 +18,8 @@ General Guidelines #. The modification of symbols can generally be managed with versioning #. The removal of symbols generally is an ABI break and requires bumping of the LIBABIVER macro +#. Updates to the minimum hardware requirements, which drop support for hardware which + was previously supported, should be treated as an ABI change. What is an ABI -- @@ -77,6 +79,13 @@ for significant reasons, such as performance enhancements. ABI breakage due to changes such as reorganizing public structure fields for aesthetic or readability purposes should be avoided. +.. note:: + + Updates to the minimum hardware requirements, which drop support for hardware + which was previously supported, should be treated as an ABI change, and + follow the relevant deprecation policy procedures as above: 3 acks and + announcement at least one release in advance. + Examples of Deprecation Notices --- -- 2.13.5
