* Re: [PATCH 01/22] ethdev: introduce generic flow API
From: Kevin Traynor @ 2016-11-30 17:47 UTC (permalink / raw)
To: Adrien Mazarguil, dev
Cc: Thomas Monjalon, Pablo de Lara, Olivier Matz, sugesh.chandra
In-Reply-To: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com>
Hi Adrien,
On 11/16/2016 04:23 PM, Adrien Mazarguil wrote:
> This new API supersedes all the legacy filter types described in
> rte_eth_ctrl.h. It is slightly higher level and as a result relies more on
> PMDs to process and validate flow rules.
>
> Benefits:
>
> - A unified API is easier to program for, applications do not have to be
> written for a specific filter type which may or may not be supported by
> the underlying device.
>
> - The behavior of a flow rule is the same regardless of the underlying
> device, applications do not need to be aware of hardware quirks.
>
> - Extensible by design, API/ABI breakage should rarely occur if at all.
>
> - Documentation is self-standing, no need to look up elsewhere.
>
> Existing filter types will be deprecated and removed in the near future.
I'd suggest to add a deprecation notice to deprecation.rst, ideally with
a target release.
>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> ---
> MAINTAINERS | 4 +
> lib/librte_ether/Makefile | 3 +
> lib/librte_ether/rte_eth_ctrl.h | 1 +
> lib/librte_ether/rte_ether_version.map | 10 +
> lib/librte_ether/rte_flow.c | 159 +++++
> lib/librte_ether/rte_flow.h | 947 ++++++++++++++++++++++++++++
> lib/librte_ether/rte_flow_driver.h | 177 ++++++
> 7 files changed, 1301 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d6bb8f8..3b46630 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -243,6 +243,10 @@ M: Thomas Monjalon <thomas.monjalon@6wind.com>
> F: lib/librte_ether/
> F: scripts/test-null.sh
>
> +Generic flow API
> +M: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> +F: lib/librte_ether/rte_flow*
> +
> Crypto API
> M: Declan Doherty <declan.doherty@intel.com>
> F: lib/librte_cryptodev/
> diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
> index efe1e5f..9335361 100644
> --- a/lib/librte_ether/Makefile
> +++ b/lib/librte_ether/Makefile
> @@ -44,6 +44,7 @@ EXPORT_MAP := rte_ether_version.map
> LIBABIVER := 5
>
> SRCS-y += rte_ethdev.c
> +SRCS-y += rte_flow.c
>
> #
> # Export include files
> @@ -51,6 +52,8 @@ SRCS-y += rte_ethdev.c
> SYMLINK-y-include += rte_ethdev.h
> SYMLINK-y-include += rte_eth_ctrl.h
> SYMLINK-y-include += rte_dev_info.h
> +SYMLINK-y-include += rte_flow.h
> +SYMLINK-y-include += rte_flow_driver.h
>
> # this lib depends upon:
> DEPDIRS-y += lib/librte_net lib/librte_eal lib/librte_mempool lib/librte_ring lib/librte_mbuf
> diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
> index fe80eb0..8386904 100644
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -99,6 +99,7 @@ enum rte_filter_type {
> RTE_ETH_FILTER_FDIR,
> RTE_ETH_FILTER_HASH,
> RTE_ETH_FILTER_L2_TUNNEL,
> + RTE_ETH_FILTER_GENERIC,
> RTE_ETH_FILTER_MAX
> };
>
> diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
> index 72be66d..b5d2547 100644
> --- a/lib/librte_ether/rte_ether_version.map
> +++ b/lib/librte_ether/rte_ether_version.map
> @@ -147,3 +147,13 @@ DPDK_16.11 {
> rte_eth_dev_pci_remove;
>
> } DPDK_16.07;
> +
> +DPDK_17.02 {
> + global:
> +
> + rte_flow_validate;
> + rte_flow_create;
> + rte_flow_destroy;
> + rte_flow_query;
> +
> +} DPDK_16.11;
> diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
> new file mode 100644
> index 0000000..064963d
> --- /dev/null
> +++ b/lib/librte_ether/rte_flow.c
> @@ -0,0 +1,159 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright 2016 6WIND S.A.
> + * Copyright 2016 Mellanox.
There's Mellanox copyright but you are the only signed-off-by - is that
right?
> + *
> + * 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 <stdint.h>
> +
> +#include <rte_errno.h>
> +#include <rte_branch_prediction.h>
> +#include "rte_ethdev.h"
> +#include "rte_flow_driver.h"
> +#include "rte_flow.h"
> +
> +/* Get generic flow operations structure from a port. */
> +const struct rte_flow_ops *
> +rte_flow_ops_get(uint8_t port_id, struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops;
> + int code;
> +
> + if (unlikely(!rte_eth_dev_is_valid_port(port_id)))
> + code = ENODEV;
> + else if (unlikely(!dev->dev_ops->filter_ctrl ||
> + dev->dev_ops->filter_ctrl(dev,
> + RTE_ETH_FILTER_GENERIC,
> + RTE_ETH_FILTER_GET,
> + &ops) ||
> + !ops))
> + code = ENOTSUP;
> + else
> + return ops;
> + rte_flow_error_set(error, code, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(code));
> + return NULL;
> +}
> +
Is it expected that the application or pmd will provide locking between
these functions if required? I think it's going to have to be the app.
> +/* Check whether a flow rule can be created on a given port. */
> +int
> +rte_flow_validate(uint8_t port_id,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item pattern[],
> + const struct rte_flow_action actions[],
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->validate))
> + return ops->validate(dev, attr, pattern, actions, error);
> + rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> + return -rte_errno;
> +}
> +
> +/* Create a flow rule on a given port. */
> +struct rte_flow *
> +rte_flow_create(uint8_t port_id,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item pattern[],
> + const struct rte_flow_action actions[],
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return NULL;
> + if (likely(!!ops->create))
> + return ops->create(dev, attr, pattern, actions, error);
> + rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> + return NULL;
> +}
> +
> +/* Destroy a flow rule on a given port. */
> +int
> +rte_flow_destroy(uint8_t port_id,
> + struct rte_flow *flow,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->destroy))
> + return ops->destroy(dev, flow, error);
> + rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> + return -rte_errno;
> +}
> +
> +/* Destroy all flow rules associated with a port. */
> +int
> +rte_flow_flush(uint8_t port_id,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->flush))
> + return ops->flush(dev, error);
> + rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> + return -rte_errno;
> +}
> +
> +/* Query an existing flow rule. */
> +int
> +rte_flow_query(uint8_t port_id,
> + struct rte_flow *flow,
> + enum rte_flow_action_type action,
> + void *data,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (!ops)
> + return -rte_errno;
> + if (likely(!!ops->query))
> + return ops->query(dev, flow, action, data, error);
> + rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> + return -rte_errno;
> +}
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> new file mode 100644
> index 0000000..211f307
> --- /dev/null
> +++ b/lib/librte_ether/rte_flow.h
> @@ -0,0 +1,947 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright 2016 6WIND S.A.
> + * Copyright 2016 Mellanox.
> + *
> + * 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.
> + */
> +
> +#ifndef RTE_FLOW_H_
> +#define RTE_FLOW_H_
> +
> +/**
> + * @file
> + * RTE generic flow API
> + *
> + * This interface provides the ability to program packet matching and
> + * associated actions in hardware through flow rules.
> + */
> +
> +#include <rte_arp.h>
> +#include <rte_ether.h>
> +#include <rte_icmp.h>
> +#include <rte_ip.h>
> +#include <rte_sctp.h>
> +#include <rte_tcp.h>
> +#include <rte_udp.h>
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Flow rule attributes.
> + *
> + * Priorities are set on two levels: per group and per rule within groups.
> + *
> + * Lower values denote higher priority, the highest priority for both levels
> + * is 0, so that a rule with priority 0 in group 8 is always matched after a
> + * rule with priority 8 in group 0.
> + *
> + * Although optional, applications are encouraged to group similar rules as
> + * much as possible to fully take advantage of hardware capabilities
> + * (e.g. optimized matching) and work around limitations (e.g. a single
> + * pattern type possibly allowed in a given group).
> + *
> + * Group and priority levels are arbitrary and up to the application, they
> + * do not need to be contiguous nor start from 0, however the maximum number
> + * varies between devices and may be affected by existing flow rules.
> + *
> + * If a packet is matched by several rules of a given group for a given
> + * priority level, the outcome is undefined. It can take any path, may be
> + * duplicated or even cause unrecoverable errors.
I get what you are trying to do here wrt supporting multiple
pmds/hardware implementations and it's a good idea to keep it flexible.
Given that the outcome is undefined, it would be nice that the
application has a way of finding the specific effects for verification
and debugging.
> + *
> + * Note that support for more than a single group and priority level is not
> + * guaranteed.
> + *
> + * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).
> + *
> + * Several pattern items and actions are valid and can be used in both
> + * directions. Those valid for only one direction are described as such.
> + *
> + * Specifying both directions at once is not recommended but may be valid in
> + * some cases, such as incrementing the same counter twice.
> + *
> + * Not specifying any direction is currently an error.
> + */
> +struct rte_flow_attr {
> + uint32_t group; /**< Priority group. */
> + uint32_t priority; /**< Priority level within group. */
> + uint32_t ingress:1; /**< Rule applies to ingress traffic. */
> + uint32_t egress:1; /**< Rule applies to egress traffic. */
> + uint32_t reserved:30; /**< Reserved, must be zero. */
> +};
> +
> +/**
> + * Matching pattern item types.
> + *
> + * Items are arranged in a list to form a matching pattern for packets.
> + * They fall in two categories:
> + *
> + * - Protocol matching (ANY, RAW, ETH, IPV4, IPV6, ICMP, UDP, TCP, SCTP,
> + * VXLAN and so on), usually associated with a specification
> + * structure. These must be stacked in the same order as the protocol
> + * layers to match, starting from L2.
> + *
> + * - Affecting how the pattern is processed (END, VOID, INVERT, PF, VF, PORT
> + * and so on), often without a specification structure. Since they are
> + * meta data that does not match packet contents, these can be specified
> + * anywhere within item lists without affecting the protocol matching
> + * items.
> + *
> + * See the description of individual types for more information. Those
> + * marked with [META] fall into the second category.
> + */
> +enum rte_flow_item_type {
> + /**
> + * [META]
> + *
> + * End marker for item lists. Prevents further processing of items,
> + * thereby ending the pattern.
> + *
> + * No associated specification structure.
> + */
> + RTE_FLOW_ITEM_TYPE_END,
> +
> + /**
> + * [META]
> + *
> + * Used as a placeholder for convenience. It is ignored and simply
> + * discarded by PMDs.
> + *
> + * No associated specification structure.
> + */
> + RTE_FLOW_ITEM_TYPE_VOID,
> +
> + /**
> + * [META]
> + *
> + * Inverted matching, i.e. process packets that do not match the
> + * pattern.
> + *
> + * No associated specification structure.
> + */
> + RTE_FLOW_ITEM_TYPE_INVERT,
> +
> + /**
> + * Matches any protocol in place of the current layer, a single ANY
> + * may also stand for several protocol layers.
> + *
> + * See struct rte_flow_item_any.
> + */
> + RTE_FLOW_ITEM_TYPE_ANY,
> +
> + /**
> + * [META]
> + *
> + * Matches packets addressed to the physical function of the device.
> + *
> + * If the underlying device function differs from the one that would
> + * normally receive the matched traffic, specifying this item
> + * prevents it from reaching that device unless the flow rule
> + * contains a PF action. Packets are not duplicated between device
> + * instances by default.
> + *
> + * No associated specification structure.
> + */
> + RTE_FLOW_ITEM_TYPE_PF,
> +
> + /**
> + * [META]
> + *
> + * Matches packets addressed to a virtual function ID of the device.
> + *
> + * If the underlying device function differs from the one that would
> + * normally receive the matched traffic, specifying this item
> + * prevents it from reaching that device unless the flow rule
> + * contains a VF action. Packets are not duplicated between device
> + * instances by default.
> + *
> + * See struct rte_flow_item_vf.
> + */
> + RTE_FLOW_ITEM_TYPE_VF,
> +
> + /**
> + * [META]
> + *
> + * Matches packets coming from the specified physical port of the
> + * underlying device.
> + *
> + * The first PORT item overrides the physical port normally
> + * associated with the specified DPDK input port (port_id). This
> + * item can be provided several times to match additional physical
> + * ports.
> + *
> + * See struct rte_flow_item_port.
> + */
> + RTE_FLOW_ITEM_TYPE_PORT,
> +
> + /**
> + * Matches a byte string of a given length at a given offset.
> + *
> + * See struct rte_flow_item_raw.
> + */
> + RTE_FLOW_ITEM_TYPE_RAW,
> +
> + /**
> + * Matches an Ethernet header.
> + *
> + * See struct rte_flow_item_eth.
> + */
> + RTE_FLOW_ITEM_TYPE_ETH,
> +
> + /**
> + * Matches an 802.1Q/ad VLAN tag.
> + *
> + * See struct rte_flow_item_vlan.
> + */
> + RTE_FLOW_ITEM_TYPE_VLAN,
> +
> + /**
> + * Matches an IPv4 header.
> + *
> + * See struct rte_flow_item_ipv4.
> + */
> + RTE_FLOW_ITEM_TYPE_IPV4,
> +
> + /**
> + * Matches an IPv6 header.
> + *
> + * See struct rte_flow_item_ipv6.
> + */
> + RTE_FLOW_ITEM_TYPE_IPV6,
> +
> + /**
> + * Matches an ICMP header.
> + *
> + * See struct rte_flow_item_icmp.
> + */
> + RTE_FLOW_ITEM_TYPE_ICMP,
> +
> + /**
> + * Matches a UDP header.
> + *
> + * See struct rte_flow_item_udp.
> + */
> + RTE_FLOW_ITEM_TYPE_UDP,
> +
> + /**
> + * Matches a TCP header.
> + *
> + * See struct rte_flow_item_tcp.
> + */
> + RTE_FLOW_ITEM_TYPE_TCP,
> +
> + /**
> + * Matches a SCTP header.
> + *
> + * See struct rte_flow_item_sctp.
> + */
> + RTE_FLOW_ITEM_TYPE_SCTP,
> +
> + /**
> + * Matches a VXLAN header.
> + *
> + * See struct rte_flow_item_vxlan.
> + */
> + RTE_FLOW_ITEM_TYPE_VXLAN,
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_ANY
> + *
> + * Matches any protocol in place of the current layer, a single ANY may also
> + * stand for several protocol layers.
> + *
> + * This is usually specified as the first pattern item when looking for a
> + * protocol anywhere in a packet.
> + *
> + * A maximum value of 0 requests matching any number of protocol layers
> + * above or equal to the minimum value, a maximum value lower than the
> + * minimum one is otherwise invalid.
> + *
> + * This type does not work with a range (struct rte_flow_item.last).
> + */
> +struct rte_flow_item_any {
> + uint16_t min; /**< Minimum number of layers covered. */
> + uint16_t max; /**< Maximum number of layers covered, 0 for infinity. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_VF
> + *
> + * Matches packets addressed to a virtual function ID of the device.
> + *
> + * If the underlying device function differs from the one that would
> + * normally receive the matched traffic, specifying this item prevents it
> + * from reaching that device unless the flow rule contains a VF
> + * action. Packets are not duplicated between device instances by default.
> + *
> + * - Likely to return an error or never match any traffic if this causes a
> + * VF device to match traffic addressed to a different VF.
> + * - Can be specified multiple times to match traffic addressed to several
> + * specific VFs.
> + * - Can be combined with a PF item to match both PF and VF traffic.
> + *
> + * A zeroed mask can be used to match any VF.
can you refer explicitly to id
> + */
> +struct rte_flow_item_vf {
> + uint32_t id; /**< Destination VF ID. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_PORT
> + *
> + * Matches packets coming from the specified physical port of the underlying
> + * device.
> + *
> + * The first PORT item overrides the physical port normally associated with
> + * the specified DPDK input port (port_id). This item can be provided
> + * several times to match additional physical ports.
> + *
> + * Note that physical ports are not necessarily tied to DPDK input ports
> + * (port_id) when those are not under DPDK control. Possible values are
> + * specific to each device, they are not necessarily indexed from zero and
> + * may not be contiguous.
> + *
> + * As a device property, the list of allowed values as well as the value
> + * associated with a port_id should be retrieved by other means.
> + *
> + * A zeroed mask can be used to match any port index.
> + */
> +struct rte_flow_item_port {
> + uint32_t index; /**< Physical port index. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_RAW
> + *
> + * Matches a byte string of a given length at a given offset.
> + *
> + * Offset is either absolute (using the start of the packet) or relative to
> + * the end of the previous matched item in the stack, in which case negative
> + * values are allowed.
> + *
> + * If search is enabled, offset is used as the starting point. The search
> + * area can be delimited by setting limit to a nonzero value, which is the
> + * maximum number of bytes after offset where the pattern may start.
> + *
> + * Matching a zero-length pattern is allowed, doing so resets the relative
> + * offset for subsequent items.
> + *
> + * This type does not work with a range (struct rte_flow_item.last).
> + */
> +struct rte_flow_item_raw {
> + uint32_t relative:1; /**< Look for pattern after the previous item. */
> + uint32_t search:1; /**< Search pattern from offset (see also limit). */
> + uint32_t reserved:30; /**< Reserved, must be set to zero. */
> + int32_t offset; /**< Absolute or relative offset for pattern. */
> + uint16_t limit; /**< Search area limit for start of pattern. */
> + uint16_t length; /**< Pattern length. */
> + uint8_t pattern[]; /**< Byte string to look for. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_ETH
> + *
> + * Matches an Ethernet header.
> + */
> +struct rte_flow_item_eth {
> + struct ether_addr dst; /**< Destination MAC. */
> + struct ether_addr src; /**< Source MAC. */
> + unsigned int type; /**< EtherType. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_VLAN
> + *
> + * Matches an 802.1Q/ad VLAN tag.
> + *
> + * This type normally follows either RTE_FLOW_ITEM_TYPE_ETH or
> + * RTE_FLOW_ITEM_TYPE_VLAN.
> + */
> +struct rte_flow_item_vlan {
> + uint16_t tpid; /**< Tag protocol identifier. */
> + uint16_t tci; /**< Tag control information. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_IPV4
> + *
> + * Matches an IPv4 header.
> + *
> + * Note: IPv4 options are handled by dedicated pattern items.
> + */
> +struct rte_flow_item_ipv4 {
> + struct ipv4_hdr hdr; /**< IPv4 header definition. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_IPV6.
> + *
> + * Matches an IPv6 header.
> + *
> + * Note: IPv6 options are handled by dedicated pattern items.
> + */
> +struct rte_flow_item_ipv6 {
> + struct ipv6_hdr hdr; /**< IPv6 header definition. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_ICMP.
> + *
> + * Matches an ICMP header.
> + */
> +struct rte_flow_item_icmp {
> + struct icmp_hdr hdr; /**< ICMP header definition. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_UDP.
> + *
> + * Matches a UDP header.
> + */
> +struct rte_flow_item_udp {
> + struct udp_hdr hdr; /**< UDP header definition. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_TCP.
> + *
> + * Matches a TCP header.
> + */
> +struct rte_flow_item_tcp {
> + struct tcp_hdr hdr; /**< TCP header definition. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_SCTP.
> + *
> + * Matches a SCTP header.
> + */
> +struct rte_flow_item_sctp {
> + struct sctp_hdr hdr; /**< SCTP header definition. */
> +};
> +
> +/**
> + * RTE_FLOW_ITEM_TYPE_VXLAN.
> + *
> + * Matches a VXLAN header (RFC 7348).
> + */
> +struct rte_flow_item_vxlan {
> + uint8_t flags; /**< Normally 0x08 (I flag). */
> + uint8_t rsvd0[3]; /**< Reserved, normally 0x000000. */
> + uint8_t vni[3]; /**< VXLAN identifier. */
> + uint8_t rsvd1; /**< Reserved, normally 0x00. */
> +};
> +
> +/**
> + * Matching pattern item definition.
> + *
> + * A pattern is formed by stacking items starting from the lowest protocol
> + * layer to match. This stacking restriction does not apply to meta items
> + * which can be placed anywhere in the stack with no effect on the meaning
> + * of the resulting pattern.
> + *
> + * A stack is terminated by a END item.
> + *
> + * The spec field should be a valid pointer to a structure of the related
> + * item type. It may be set to NULL in many cases to use default values.
> + *
> + * Optionally, last can point to a structure of the same type to define an
> + * inclusive range. This is mostly supported by integer and address fields,
> + * may cause errors otherwise. Fields that do not support ranges must be set
> + * to the same value as their spec counterparts.
> + *
> + * By default all fields present in spec are considered relevant.* This
typo "*"
> + * behavior can be altered by providing a mask structure of the same type
> + * with applicable bits set to one. It can also be used to partially filter
> + * out specific fields (e.g. as an alternate mean to match ranges of IP
> + * addresses).
> + *
> + * Note this is a simple bit-mask applied before interpreting the contents
> + * of spec and last, which may yield unexpected results if not used
> + * carefully. For example, if for an IPv4 address field, spec provides
> + * 10.1.2.3, last provides 10.3.4.5 and mask provides 255.255.0.0, the
> + * effective range is 10.1.0.0 to 10.3.255.255.
> + *
> + * * The defaults for data-matching items such as IPv4 when mask is not
> + * specified actually depend on the underlying implementation since only
> + * recognized fields can be taken into account.
> + */
> +struct rte_flow_item {
> + enum rte_flow_item_type type; /**< Item type. */
> + const void *spec; /**< Pointer to item specification structure. */
> + const void *last; /**< Defines an inclusive range (spec to last). */
> + const void *mask; /**< Bit-mask applied to spec and last. */
> +};
> +
> +/**
> + * Action types.
> + *
> + * Each possible action is represented by a type. Some have associated
> + * configuration structures. Several actions combined in a list can be
> + * affected to a flow rule. That list is not ordered.
> + *
> + * They fall in three categories:
> + *
> + * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
> + * processing matched packets by subsequent flow rules, unless overridden
> + * with PASSTHRU.
> + *
> + * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
> + * for additional processing by subsequent flow rules.
> + *
> + * - Other non terminating meta actions that do not affect the fate of
> + * packets (END, VOID, MARK, FLAG, COUNT).
> + *
> + * When several actions are combined in a flow rule, they should all have
> + * different types (e.g. dropping a packet twice is not possible). The
> + * defined behavior is for PMDs to only take into account the last action of
> + * a given type found in the list. PMDs still perform error checking on the
> + * entire list.
why do you define that the pmd will interpret multiple same type rules
in this way...would it not make more sense for the pmd to just return
EINVAL for an invalid set of rules? It seems more transparent for the
application.
> + *
> + * Note that PASSTHRU is the only action able to override a terminating
> + * rule.
> + */
> +enum rte_flow_action_type {
> + /**
> + * [META]
> + *
> + * End marker for action lists. Prevents further processing of
> + * actions, thereby ending the list.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_END,
> +
> + /**
> + * [META]
> + *
> + * Used as a placeholder for convenience. It is ignored and simply
> + * discarded by PMDs.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_VOID,
> +
> + /**
> + * Leaves packets up for additional processing by subsequent flow
> + * rules. This is the default when a rule does not contain a
> + * terminating action, but can be specified to force a rule to
> + * become non-terminating.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_PASSTHRU,
> +
> + /**
> + * [META]
> + *
> + * Attaches a 32 bit value to packets.
> + *
> + * See struct rte_flow_action_mark.
> + */
> + RTE_FLOW_ACTION_TYPE_MARK,
> +
> + /**
> + * [META]
> + *
> + * Flag packets. Similar to MARK but only affects ol_flags.
> + *
> + * Note: a distinctive flag must be defined for it.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_FLAG,
> +
> + /**
> + * Assigns packets to a given queue index.
> + *
> + * See struct rte_flow_action_queue.
> + */
> + RTE_FLOW_ACTION_TYPE_QUEUE,
> +
> + /**
> + * Drops packets.
> + *
> + * PASSTHRU overrides this action if both are specified.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_DROP,
> +
> + /**
> + * [META]
> + *
> + * Enables counters for this rule.
> + *
> + * These counters can be retrieved and reset through rte_flow_query(),
> + * see struct rte_flow_query_count.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_COUNT,
> +
> + /**
> + * Duplicates packets to a given queue index.
> + *
> + * This is normally combined with QUEUE, however when used alone, it
> + * is actually similar to QUEUE + PASSTHRU.
> + *
> + * See struct rte_flow_action_dup.
> + */
> + RTE_FLOW_ACTION_TYPE_DUP,
> +
> + /**
> + * Similar to QUEUE, except RSS is additionally performed on packets
> + * to spread them among several queues according to the provided
> + * parameters.
> + *
> + * See struct rte_flow_action_rss.
> + */
> + RTE_FLOW_ACTION_TYPE_RSS,
> +
> + /**
> + * Redirects packets to the physical function (PF) of the current
> + * device.
> + *
> + * No associated configuration structure.
> + */
> + RTE_FLOW_ACTION_TYPE_PF,
> +
> + /**
> + * Redirects packets to the virtual function (VF) of the current
> + * device with the specified ID.
> + *
> + * See struct rte_flow_action_vf.
> + */
> + RTE_FLOW_ACTION_TYPE_VF,
> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYPE_MARK
> + *
> + * Attaches a 32 bit value to packets.
> + *
> + * This value is arbitrary and application-defined. For compatibility with
> + * FDIR it is returned in the hash.fdir.hi mbuf field. PKT_RX_FDIR_ID is
> + * also set in ol_flags.
> + */
> +struct rte_flow_action_mark {
> + uint32_t id; /**< 32 bit value to return with packets. */
> +};
One use case I thought we would be able to do for OVS is classification
in hardware and the unique flow id is sent with the packet to software.
But in OVS the ufid is 128 bits, so it means we can't and there is still
the miniflow extract overhead. I'm not sure if there is a practical way
around this.
Sugesh (cc'd) has looked at this before and may be able to comment or
correct me.
> +
> +/**
> + * RTE_FLOW_ACTION_TYPE_QUEUE
> + *
> + * Assign packets to a given queue index.
> + *
> + * Terminating by default.
> + */
> +struct rte_flow_action_queue {
> + uint16_t index; /**< Queue index to use. */
> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYPE_COUNT (query)
> + *
> + * Query structure to retrieve and reset flow rule counters.
> + */
> +struct rte_flow_query_count {
> + uint32_t reset:1; /**< Reset counters after query [in]. */
> + uint32_t hits_set:1; /**< hits field is set [out]. */
> + uint32_t bytes_set:1; /**< bytes field is set [out]. */
> + uint32_t reserved:29; /**< Reserved, must be zero [in, out]. */
> + uint64_t hits; /**< Number of hits for this rule [out]. */
> + uint64_t bytes; /**< Number of bytes through this rule [out]. */
> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYPE_DUP
> + *
> + * Duplicates packets to a given queue index.
> + *
> + * This is normally combined with QUEUE, however when used alone, it is
> + * actually similar to QUEUE + PASSTHRU.
> + *
> + * Non-terminating by default.
> + */
> +struct rte_flow_action_dup {
> + uint16_t index; /**< Queue index to duplicate packets to. */
> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYPE_RSS
> + *
> + * Similar to QUEUE, except RSS is additionally performed on packets to
> + * spread them among several queues according to the provided parameters.
> + *
> + * Note: RSS hash result is normally stored in the hash.rss mbuf field,
> + * however it conflicts with the MARK action as they share the same
> + * space. When both actions are specified, the RSS hash is discarded and
> + * PKT_RX_RSS_HASH is not set in ol_flags. MARK has priority. The mbuf
> + * structure should eventually evolve to store both.
> + *
> + * Terminating by default.
> + */
> +struct rte_flow_action_rss {
> + const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
> + uint16_t queues; /**< Number of entries in queue[]. */
> + uint16_t queue[]; /**< Queues indices to use. */
I'd try and avoid queue and queues - someone will say "huh?" when
reading code. s/queues/num ?
> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYPE_VF
> + *
> + * Redirects packets to a virtual function (VF) of the current device.
> + *
> + * Packets matched by a VF pattern item can be redirected to their original
> + * VF ID instead of the specified one. This parameter may not be available
> + * and is not guaranteed to work properly if the VF part is matched by a
> + * prior flow rule or if packets are not addressed to a VF in the first
> + * place.
Not clear what you mean by "not guaranteed to work if...". Please return
fail when this action is used if this is not going to work.
> + *
> + * Terminating by default.
> + */
> +struct rte_flow_action_vf {
> + uint32_t original:1; /**< Use original VF ID if possible. */
> + uint32_t reserved:31; /**< Reserved, must be zero. */
> + uint32_t id; /**< VF ID to redirect packets to. */
> +};
> +
> +/**
> + * Definition of a single action.
> + *
> + * A list of actions is terminated by a END action.
> + *
> + * For simple actions without a configuration structure, conf remains NULL.
> + */
> +struct rte_flow_action {
> + enum rte_flow_action_type type; /**< Action type. */
> + const void *conf; /**< Pointer to action configuration structure. */
> +};
> +
> +/**
> + * Opaque type returned after successfully creating a flow.
> + *
> + * This handle can be used to manage and query the related flow (e.g. to
> + * destroy it or retrieve counters).
> + */
> +struct rte_flow;
> +
> +/**
> + * Verbose error types.
> + *
> + * Most of them provide the type of the object referenced by struct
> + * rte_flow_error.cause.
> + */
> +enum rte_flow_error_type {
> + RTE_FLOW_ERROR_TYPE_NONE, /**< No error. */
> + RTE_FLOW_ERROR_TYPE_UNSPECIFIED, /**< Cause unspecified. */
> + RTE_FLOW_ERROR_TYPE_HANDLE, /**< Flow rule (handle). */
> + RTE_FLOW_ERROR_TYPE_ATTR_GROUP, /**< Group field. */
> + RTE_FLOW_ERROR_TYPE_ATTR_PRIORITY, /**< Priority field. */
> + RTE_FLOW_ERROR_TYPE_ATTR_INGRESS, /**< Ingress field. */
> + RTE_FLOW_ERROR_TYPE_ATTR_EGRESS, /**< Egress field. */
> + RTE_FLOW_ERROR_TYPE_ATTR, /**< Attributes structure. */
> + RTE_FLOW_ERROR_TYPE_ITEM_NUM, /**< Pattern length. */
> + RTE_FLOW_ERROR_TYPE_ITEM, /**< Specific pattern item. */
> + RTE_FLOW_ERROR_TYPE_ACTION_NUM, /**< Number of actions. */
> + RTE_FLOW_ERROR_TYPE_ACTION, /**< Specific action. */
> +};
> +
> +/**
> + * Verbose error structure definition.
> + *
> + * This object is normally allocated by applications and set by PMDs, the
> + * message points to a constant string which does not need to be freed by
> + * the application, however its pointer can be considered valid only as long
> + * as its associated DPDK port remains configured. Closing the underlying
> + * device or unloading the PMD invalidates it.
> + *
> + * Both cause and message may be NULL regardless of the error type.
> + */
> +struct rte_flow_error {
> + enum rte_flow_error_type type; /**< Cause field and error types. */
> + const void *cause; /**< Object responsible for the error. */
> + const char *message; /**< Human-readable error message. */
> +};
> +
> +/**
> + * Check whether a flow rule can be created on a given port.
> + *
> + * While this function has no effect on the target device, the flow rule is
> + * validated against its current configuration state and the returned value
> + * should be considered valid by the caller for that state only.
> + *
> + * The returned value is guaranteed to remain valid only as long as no
> + * successful calls to rte_flow_create() or rte_flow_destroy() are made in
> + * the meantime and no device parameter affecting flow rules in any way are
> + * modified, due to possible collisions or resource limitations (although in
> + * such cases EINVAL should not be returned).
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] attr
> + * Flow rule attributes.
> + * @param[in] pattern
> + * Pattern specification (list terminated by the END pattern item).
> + * @param[in] actions
> + * Associated actions (list terminated by the END action).
> + * @param[out] error
> + * Perform verbose error reporting if not NULL.
> + *
> + * @return
> + * 0 if flow rule is valid and can be created. A negative errno value
> + * otherwise (rte_errno is also set), the following errors are defined:
> + *
> + * -ENOSYS: underlying device does not support this functionality.
> + *
> + * -EINVAL: unknown or invalid rule specification.
> + *
> + * -ENOTSUP: valid but unsupported rule specification (e.g. partial
> + * bit-masks are unsupported).
> + *
> + * -EEXIST: collision with an existing rule.
> + *
> + * -ENOMEM: not enough resources.
> + *
> + * -EBUSY: action cannot be performed due to busy device resources, may
> + * succeed if the affected queues or even the entire port are in a stopped
> + * state (see rte_eth_dev_rx_queue_stop() and rte_eth_dev_stop()).
> + */
> +int
> +rte_flow_validate(uint8_t port_id,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item pattern[],
> + const struct rte_flow_action actions[],
> + struct rte_flow_error *error);
Why not just use rte_flow_create() and get an error? Is it less
disruptive to do a validate and find the rule cannot be created, than
using a create directly?
> +
> +/**
> + * Create a flow rule on a given port.
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] attr
> + * Flow rule attributes.
> + * @param[in] pattern
> + * Pattern specification (list terminated by the END pattern item).
> + * @param[in] actions
> + * Associated actions (list terminated by the END action).
> + * @param[out] error
> + * Perform verbose error reporting if not NULL.
> + *
> + * @return
> + * A valid handle in case of success, NULL otherwise and rte_errno is set
> + * to the positive version of one of the error codes defined for
> + * rte_flow_validate().
> + */
> +struct rte_flow *
> +rte_flow_create(uint8_t port_id,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item pattern[],
> + const struct rte_flow_action actions[],
> + struct rte_flow_error *error);
General question - are these functions threadsafe? In the OVS example
you could have several threads wanting to create flow rules at the same
time for same or different ports.
> +
> +/**
> + * Destroy a flow rule on a given port.
> + *
> + * Failure to destroy a flow rule handle may occur when other flow rules
> + * depend on it, and destroying it would result in an inconsistent state.
> + *
> + * This function is only guaranteed to succeed if handles are destroyed in
> + * reverse order of their creation.
How can the application find this information out on error?
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param flow
> + * Flow rule handle to destroy.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +int
> +rte_flow_destroy(uint8_t port_id,
> + struct rte_flow *flow,
> + struct rte_flow_error *error);
> +
> +/**
> + * Destroy all flow rules associated with a port.
> + *
> + * In the unlikely event of failure, handles are still considered destroyed
> + * and no longer valid but the port must be assumed to be in an inconsistent
> + * state.
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +int
> +rte_flow_flush(uint8_t port_id,
> + struct rte_flow_error *error);
rte_flow_destroy_all() would be more descriptive (but breaks your style)
> +
> +/**
> + * Query an existing flow rule.
> + *
> + * This function allows retrieving flow-specific data such as counters.
> + * Data is gathered by special actions which must be present in the flow
> + * rule definition.
re last sentence, it would be good if you can put a link to
RTE_FLOW_ACTION_TYPE_COUNT
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param flow
> + * Flow rule handle to query.
> + * @param action
> + * Action type to query.
> + * @param[in, out] data
> + * Pointer to storage for the associated query data type.
can this be anything other than rte_flow_query_count?
> + * @param[out] error
> + * Perform verbose error reporting if not NULL.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +int
> +rte_flow_query(uint8_t port_id,
> + struct rte_flow *flow,
> + enum rte_flow_action_type action,
> + void *data,
> + struct rte_flow_error *error);
> +
> +#ifdef __cplusplus
> +}
> +#endif
I don't see a way to dump all the rules for a port out. I think this is
neccessary for degbugging. You could have a look through dpif.h in OVS
and see how dpif_flow_dump_next() is used, it might be a good reference.
Also, it would be nice if there were an api that would allow a test
packet to be injected and traced for debugging - although I'm not
exactly sure how well it could be traced. For reference:
http://developers.redhat.com/blog/2016/10/12/tracing-packets-inside-open-vswitch/
thanks,
Kevin.
> +
> +#endif /* RTE_FLOW_H_ */
> diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
> new file mode 100644
> index 0000000..a88c621
> --- /dev/null
> +++ b/lib/librte_ether/rte_flow_driver.h
> @@ -0,0 +1,177 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright 2016 6WIND S.A.
> + * Copyright 2016 Mellanox.
> + *
> + * 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.
> + */
> +
> +#ifndef RTE_FLOW_DRIVER_H_
> +#define RTE_FLOW_DRIVER_H_
> +
> +/**
> + * @file
> + * RTE generic flow API (driver side)
> + *
> + * This file provides implementation helpers for internal use by PMDs, they
> + * are not intended to be exposed to applications and are not subject to ABI
> + * versioning.
> + */
> +
> +#include <stdint.h>
> +
> +#include <rte_errno.h>
> +#include "rte_flow.h"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Generic flow operations structure implemented and returned by PMDs.
> + *
> + * To implement this API, PMDs must handle the RTE_ETH_FILTER_GENERIC filter
> + * type in their .filter_ctrl callback function (struct eth_dev_ops) as well
> + * as the RTE_ETH_FILTER_GET filter operation.
> + *
> + * If successful, this operation must result in a pointer to a PMD-specific
> + * struct rte_flow_ops written to the argument address as described below:
> + *
> + * // PMD filter_ctrl callback
> + *
> + * static const struct rte_flow_ops pmd_flow_ops = { ... };
> + *
> + * switch (filter_type) {
> + * case RTE_ETH_FILTER_GENERIC:
> + * if (filter_op != RTE_ETH_FILTER_GET)
> + * return -EINVAL;
> + * *(const void **)arg = &pmd_flow_ops;
> + * return 0;
> + * }
> + *
> + * See also rte_flow_ops_get().
> + *
> + * These callback functions are not supposed to be used by applications
> + * directly, which must rely on the API defined in rte_flow.h.
> + *
> + * Public-facing wrapper functions perform a few consistency checks so that
> + * unimplemented (i.e. NULL) callbacks simply return -ENOTSUP. These
> + * callbacks otherwise only differ by their first argument (with port ID
> + * already resolved to a pointer to struct rte_eth_dev).
> + */
> +struct rte_flow_ops {
> + /** See rte_flow_validate(). */
> + int (*validate)
> + (struct rte_eth_dev *,
> + const struct rte_flow_attr *,
> + const struct rte_flow_item [],
> + const struct rte_flow_action [],
> + struct rte_flow_error *);
> + /** See rte_flow_create(). */
> + struct rte_flow *(*create)
> + (struct rte_eth_dev *,
> + const struct rte_flow_attr *,
> + const struct rte_flow_item [],
> + const struct rte_flow_action [],
> + struct rte_flow_error *);
> + /** See rte_flow_destroy(). */
> + int (*destroy)
> + (struct rte_eth_dev *,
> + struct rte_flow *,
> + struct rte_flow_error *);
> + /** See rte_flow_flush(). */
> + int (*flush)
> + (struct rte_eth_dev *,
> + struct rte_flow_error *);
> + /** See rte_flow_query(). */
> + int (*query)
> + (struct rte_eth_dev *,
> + struct rte_flow *,
> + enum rte_flow_action_type,
> + void *,
> + struct rte_flow_error *);
> +};
> +
> +/**
> + * Initialize generic flow error structure.
> + *
> + * This function also sets rte_errno to a given value.
> + *
> + * @param[out] error
> + * Pointer to flow error structure (may be NULL).
> + * @param code
> + * Related error code (rte_errno).
> + * @param type
> + * Cause field and error types.
> + * @param cause
> + * Object responsible for the error.
> + * @param message
> + * Human-readable error message.
> + *
> + * @return
> + * Pointer to flow error structure.
> + */
> +static inline struct rte_flow_error *
> +rte_flow_error_set(struct rte_flow_error *error,
> + int code,
> + enum rte_flow_error_type type,
> + void *cause,
> + const char *message)
> +{
> + if (error) {
> + *error = (struct rte_flow_error){
> + .type = type,
> + .cause = cause,
> + .message = message,
> + };
> + }
> + rte_errno = code;
> + return error;
> +}
> +
> +/**
> + * Get generic flow operations structure from a port.
> + *
> + * @param port_id
> + * Port identifier to query.
> + * @param[out] error
> + * Pointer to flow error structure.
> + *
> + * @return
> + * The flow operations structure associated with port_id, NULL in case of
> + * error, in which case rte_errno is set and the error structure contains
> + * additional details.
> + */
> +const struct rte_flow_ops *
> +rte_flow_ops_get(uint8_t port_id, struct rte_flow_error *error);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* RTE_FLOW_DRIVER_H_ */
>
^ permalink raw reply
* Re: [PATCH v2] i40e: Fix eth_i40e_dev_init sequence on ThunderX
From: Ananyev, Konstantin @ 2016-11-30 17:52 UTC (permalink / raw)
To: Jerin Jacob, Richardson, Bruce
Cc: Satha Rao, Zhang, Helin, Wu, Jingjing, jianbo.liu@linaro.org,
dev@dpdk.org
In-Reply-To: <20161122184930.GA11048@svelivela-lt.caveonetworks.com>
Hi Jerin,
>
> On Tue, Nov 22, 2016 at 01:46:54PM +0000, Bruce Richardson wrote:
> > On Tue, Nov 22, 2016 at 03:46:38AM +0530, Jerin Jacob wrote:
> > > On Sun, Nov 20, 2016 at 11:21:43PM +0000, Ananyev, Konstantin wrote:
> > > > Hi
> > > > >
> > > > > i40e_asq_send_command: rd32 & wr32 under ThunderX gives unpredictable
> > > > > results. To solve this include rte memory barriers
> > > > >
> > > > > Signed-off-by: Satha Rao <skoteshwar@caviumnetworks.com>
> > > > > ---
> > > > > drivers/net/i40e/base/i40e_osdep.h | 14 ++++++++++++++
> > > > > 1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/drivers/net/i40e/base/i40e_osdep.h b/drivers/net/i40e/base/i40e_osdep.h
> > > > > index 38e7ba5..ffa3160 100644
> > > > > --- a/drivers/net/i40e/base/i40e_osdep.h
> > > > > +++ b/drivers/net/i40e/base/i40e_osdep.h
> > > > > @@ -158,7 +158,13 @@ do { \
> > > > > ((volatile uint32_t *)((char *)(a)->hw_addr + (reg)))
> > > > > static inline uint32_t i40e_read_addr(volatile void *addr)
> > > > > {
> > > > > +#if defined(RTE_ARCH_ARM64)
> > > > > + uint32_t val = rte_le_to_cpu_32(I40E_PCI_REG(addr));
> > > > > + rte_rmb();
> > > > > + return val;
> > > >
> > > > If you really need an rmb/wmb with MMIO read/writes on ARM,
> > > > I think you can avoid #ifdefs here and use rte_smp_rmb/rte_smp_wmb.
> > > > BTW, I suppose if you need it for i40e, you would need it for other devices too.
> > >
> > > Yes. ARM would need for all devices(typically, the devices on external PCI bus).
> > > I guess rte_smp_rmb may not be the correct abstraction. So we need more of
> > > rte_rmb() as we need only non smp variant on IO side. I guess then it make sense to
> > > create new abstraction in eal with following variants so that each arch
> > > gets opportunity to make what it makes sense that specific platform
> > >
> > > rte_readb_relaxed
> > > rte_readw_relaxed
> > > rte_readl_relaxed
> > > rte_readq_relaxed
> > > rte_writeb_relaxed
> > > rte_writew_relaxed
> > > rte_writel_relaxed
> > > rte_writeq_relaxed
> > > rte_readb
> > > rte_readw
> > > rte_readl
> > > rte_readq
> > > rte_writeb
> > > rte_writew
> > > rte_writel
> > > rte_writeq
> > >
> > > Thoughts ?
> > >
> >
> > That seems like a lot of API calls!
> > Perhaps you can clarify - why would the rte_smp_rmb() not work for you?
>
> Currently arm64 mapped DMB as rte_smp_rmb() for smp case.
>
> Ideally for io barrier and non smp case, we need to map it as DSB and it is
> bit heavier than DMB
Ok, so you need some new macro, like rte_io_(r|w)mb or so, that would expand into dmb
for ARM, correct?
>
> The linux kernel arm64 mappings
> http://lxr.free-electrons.com/source/arch/arm64/include/asm/io.h#L142
>
> DMB vs DSB
> https://community.arm.com/thread/3833
>
> The relaxed one are without any barriers.(the use case like accessing on
> chip peripherals may need only relaxed versions)
>
> Thoughts on new rte EAL abstraction?
Looks like a lot of macros but if you guys think that would help - NP with that :)
Again, in that case we probably can get rid of driver specific pci reg read/write defines.
Konstantin
>
> >
> > /Bruce
^ permalink raw reply
* [PATCH v4] net/kni: add KNI PMD
From: Ferruh Yigit @ 2016-11-30 18:12 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Yong Wang
In-Reply-To: <20161010131946.13303-1-ferruh.yigit@intel.com>
Add KNI PMD which wraps librte_kni for ease of use.
KNI PMD can be used as any regular PMD to send / receive packets to the
Linux networking stack.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
v4:
* allow only single queue
* use driver.name as name
v3:
* rebase on top of latest master
v2:
* updated driver name eth_kni -> net_kni
---
config/common_base | 1 +
config/common_linuxapp | 1 +
drivers/net/Makefile | 1 +
drivers/net/kni/Makefile | 63 +++++
drivers/net/kni/rte_eth_kni.c | 462 ++++++++++++++++++++++++++++++++
drivers/net/kni/rte_pmd_kni_version.map | 4 +
mk/rte.app.mk | 10 +-
7 files changed, 537 insertions(+), 5 deletions(-)
create mode 100644 drivers/net/kni/Makefile
create mode 100644 drivers/net/kni/rte_eth_kni.c
create mode 100644 drivers/net/kni/rte_pmd_kni_version.map
diff --git a/config/common_base b/config/common_base
index 4bff83a..3385879 100644
--- a/config/common_base
+++ b/config/common_base
@@ -543,6 +543,7 @@ CONFIG_RTE_PIPELINE_STATS_COLLECT=n
# Compile librte_kni
#
CONFIG_RTE_LIBRTE_KNI=n
+CONFIG_RTE_LIBRTE_PMD_KNI=n
CONFIG_RTE_KNI_KMOD=n
CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
CONFIG_RTE_KNI_VHOST=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2483dfa..2ecd510 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -39,6 +39,7 @@ CONFIG_RTE_EAL_IGB_UIO=y
CONFIG_RTE_EAL_VFIO=y
CONFIG_RTE_KNI_KMOD=y
CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_LIBRTE_PMD_KNI=y
CONFIG_RTE_LIBRTE_VHOST=y
CONFIG_RTE_LIBRTE_PMD_VHOST=y
CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index bc93230..c4771cd 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -41,6 +41,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic
DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k
DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e
DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += kni
DIRS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4
DIRS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5
DIRS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += mpipe
diff --git a/drivers/net/kni/Makefile b/drivers/net/kni/Makefile
new file mode 100644
index 0000000..0b7cf91
--- /dev/null
+++ b/drivers/net/kni/Makefile
@@ -0,0 +1,63 @@
+# BSD LICENSE
+#
+# Copyright(c) 2016 Intel Corporation. All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_kni.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lpthread
+
+EXPORT_MAP := rte_pmd_kni_version.map
+
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += rte_eth_kni.c
+
+#
+# Export include files
+#
+SYMLINK-y-include +=
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_kni
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_mempool
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c
new file mode 100644
index 0000000..6c4df96
--- /dev/null
+++ b/drivers/net/kni/rte_eth_kni.c
@@ -0,0 +1,462 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <fcntl.h>
+#include <pthread.h>
+#include <unistd.h>
+
+#include <rte_ethdev.h>
+#include <rte_kni.h>
+#include <rte_malloc.h>
+#include <rte_vdev.h>
+
+/* Only single queue supported */
+#define KNI_MAX_QUEUE_PER_PORT 1
+
+#define MAX_PACKET_SZ 2048
+#define MAX_KNI_PORTS 8
+
+struct pmd_queue_stats {
+ uint64_t pkts;
+ uint64_t bytes;
+ uint64_t err_pkts;
+};
+
+struct pmd_queue {
+ struct pmd_internals *internals;
+ struct rte_mempool *mb_pool;
+
+ struct pmd_queue_stats rx;
+ struct pmd_queue_stats tx;
+};
+
+struct pmd_internals {
+ struct rte_kni *kni;
+ int is_kni_started;
+
+ pthread_t thread;
+ int stop_thread;
+
+ struct pmd_queue rx_queues[KNI_MAX_QUEUE_PER_PORT];
+ struct pmd_queue tx_queues[KNI_MAX_QUEUE_PER_PORT];
+};
+
+static struct ether_addr eth_addr;
+static struct rte_eth_link pmd_link = {
+ .link_speed = ETH_SPEED_NUM_10G,
+ .link_duplex = ETH_LINK_FULL_DUPLEX,
+ .link_status = 0
+};
+static int is_kni_initialized;
+
+static uint16_t
+eth_kni_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
+{
+ struct pmd_queue *kni_q = q;
+ struct rte_kni *kni = kni_q->internals->kni;
+ uint16_t nb_pkts;
+
+ nb_pkts = rte_kni_rx_burst(kni, bufs, nb_bufs);
+
+ kni_q->rx.pkts += nb_pkts;
+ kni_q->rx.err_pkts += nb_bufs - nb_pkts;
+
+ return nb_pkts;
+}
+
+static uint16_t
+eth_kni_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
+{
+ struct pmd_queue *kni_q = q;
+ struct rte_kni *kni = kni_q->internals->kni;
+ uint16_t nb_pkts;
+
+ nb_pkts = rte_kni_tx_burst(kni, bufs, nb_bufs);
+
+ kni_q->tx.pkts += nb_pkts;
+ kni_q->tx.err_pkts += nb_bufs - nb_pkts;
+
+ return nb_pkts;
+}
+
+static void *
+kni_handle_request(void *param)
+{
+ struct pmd_internals *internals = param;
+#define MS 1000
+
+ while (!internals->stop_thread) {
+ rte_kni_handle_request(internals->kni);
+ usleep(500 * MS);
+ }
+
+ return param;
+}
+
+static int
+eth_kni_start(struct rte_eth_dev *dev)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ uint16_t port_id = dev->data->port_id;
+ struct rte_mempool *mb_pool;
+ struct rte_kni_conf conf;
+ const char *name = dev->data->name + 4; /* remove net_ */
+
+ snprintf(conf.name, RTE_KNI_NAMESIZE, "%s", name);
+ conf.force_bind = 0;
+ conf.group_id = port_id;
+ conf.mbuf_size = MAX_PACKET_SZ;
+ mb_pool = internals->rx_queues[0].mb_pool;
+
+ internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
+ if (internals->kni == NULL) {
+ RTE_LOG(ERR, PMD,
+ "Fail to create kni for port: %d\n", port_id);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int
+eth_kni_dev_start(struct rte_eth_dev *dev)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ int ret;
+
+ if (internals->is_kni_started == 0) {
+ ret = eth_kni_start(dev);
+ if (ret)
+ return -1;
+ internals->is_kni_started = 1;
+ }
+
+ ret = pthread_create(&internals->thread, NULL, kni_handle_request,
+ internals);
+ if (ret) {
+ RTE_LOG(ERR, PMD, "Fail to create kni request thread\n");
+ return -1;
+ }
+
+ dev->data->dev_link.link_status = 1;
+
+ return 0;
+}
+
+static void
+eth_kni_dev_stop(struct rte_eth_dev *dev)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ int ret;
+
+ internals->stop_thread = 1;
+
+ ret = pthread_cancel(internals->thread);
+ if (ret)
+ RTE_LOG(ERR, PMD, "Can't cancel the thread\n");
+
+ ret = pthread_join(internals->thread, NULL);
+ if (ret)
+ RTE_LOG(ERR, PMD, "Can't join the thread\n");
+
+ internals->stop_thread = 0;
+
+ dev->data->dev_link.link_status = 0;
+}
+
+static int
+eth_kni_dev_configure(struct rte_eth_dev *dev __rte_unused)
+{
+ return 0;
+}
+
+static void
+eth_kni_dev_info(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
+{
+ struct rte_eth_dev_data *data = dev->data;
+
+ dev_info->driver_name = data->drv_name;
+ dev_info->max_mac_addrs = 1;
+ dev_info->max_rx_pktlen = (uint32_t)-1;
+ dev_info->max_rx_queues = KNI_MAX_QUEUE_PER_PORT;
+ dev_info->max_tx_queues = KNI_MAX_QUEUE_PER_PORT;
+ dev_info->min_rx_bufsize = 0;
+ dev_info->pci_dev = NULL;
+}
+
+static int
+eth_kni_rx_queue_setup(struct rte_eth_dev *dev,
+ uint16_t rx_queue_id,
+ uint16_t nb_rx_desc __rte_unused,
+ unsigned int socket_id __rte_unused,
+ const struct rte_eth_rxconf *rx_conf __rte_unused,
+ struct rte_mempool *mb_pool)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ struct pmd_queue *q;
+
+ q = &internals->rx_queues[rx_queue_id];
+ q->internals = internals;
+ q->mb_pool = mb_pool;
+
+ dev->data->rx_queues[rx_queue_id] = q;
+
+ return 0;
+}
+
+static int
+eth_kni_tx_queue_setup(struct rte_eth_dev *dev,
+ uint16_t tx_queue_id,
+ uint16_t nb_tx_desc __rte_unused,
+ unsigned int socket_id __rte_unused,
+ const struct rte_eth_txconf *tx_conf __rte_unused)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ struct pmd_queue *q;
+
+ q = &internals->tx_queues[tx_queue_id];
+ q->internals = internals;
+
+ dev->data->tx_queues[tx_queue_id] = q;
+
+ return 0;
+}
+
+static void
+eth_kni_queue_release(void *q __rte_unused)
+{
+}
+
+static int
+eth_kni_link_update(struct rte_eth_dev *dev __rte_unused,
+ int wait_to_complete __rte_unused)
+{
+ return 0;
+}
+
+static void
+eth_kni_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
+{
+ unsigned long rx_packets_total = 0, rx_bytes_total = 0;
+ unsigned long tx_packets_total = 0, tx_bytes_total = 0;
+ struct rte_eth_dev_data *data = dev->data;
+ unsigned long tx_packets_err_total = 0;
+ unsigned int i, num_stats;
+ struct pmd_queue *q;
+
+ num_stats = RTE_MIN((unsigned int)RTE_ETHDEV_QUEUE_STAT_CNTRS,
+ data->nb_rx_queues);
+ for (i = 0; i < num_stats; i++) {
+ q = data->rx_queues[i];
+ stats->q_ipackets[i] = q->rx.pkts;
+ stats->q_ibytes[i] = q->rx.bytes;
+ rx_packets_total += stats->q_ipackets[i];
+ rx_bytes_total += stats->q_ibytes[i];
+ }
+
+ num_stats = RTE_MIN((unsigned int)RTE_ETHDEV_QUEUE_STAT_CNTRS,
+ data->nb_tx_queues);
+ for (i = 0; i < num_stats; i++) {
+ q = data->tx_queues[i];
+ stats->q_opackets[i] = q->tx.pkts;
+ stats->q_obytes[i] = q->tx.bytes;
+ stats->q_errors[i] = q->tx.err_pkts;
+ tx_packets_total += stats->q_opackets[i];
+ tx_bytes_total += stats->q_obytes[i];
+ tx_packets_err_total += stats->q_errors[i];
+ }
+
+ stats->ipackets = rx_packets_total;
+ stats->ibytes = rx_bytes_total;
+ stats->opackets = tx_packets_total;
+ stats->obytes = tx_bytes_total;
+ stats->oerrors = tx_packets_err_total;
+}
+
+static void
+eth_kni_stats_reset(struct rte_eth_dev *dev)
+{
+ struct rte_eth_dev_data *data = dev->data;
+ struct pmd_queue *q;
+ unsigned int i;
+
+ for (i = 0; i < data->nb_rx_queues; i++) {
+ q = data->rx_queues[i];
+ q->rx.pkts = 0;
+ q->rx.bytes = 0;
+ }
+ for (i = 0; i < data->nb_tx_queues; i++) {
+ q = data->tx_queues[i];
+ q->tx.pkts = 0;
+ q->tx.bytes = 0;
+ q->tx.err_pkts = 0;
+ }
+}
+
+static const struct eth_dev_ops eth_kni_ops = {
+ .dev_start = eth_kni_dev_start,
+ .dev_stop = eth_kni_dev_stop,
+ .dev_configure = eth_kni_dev_configure,
+ .dev_infos_get = eth_kni_dev_info,
+ .rx_queue_setup = eth_kni_rx_queue_setup,
+ .tx_queue_setup = eth_kni_tx_queue_setup,
+ .rx_queue_release = eth_kni_queue_release,
+ .tx_queue_release = eth_kni_queue_release,
+ .link_update = eth_kni_link_update,
+ .stats_get = eth_kni_stats_get,
+ .stats_reset = eth_kni_stats_reset,
+};
+
+static struct rte_vdev_driver eth_kni_drv;
+
+static struct rte_eth_dev *
+eth_kni_create(const char *name, unsigned int numa_node)
+{
+ struct pmd_internals *internals = NULL;
+ struct rte_eth_dev_data *data;
+ struct rte_eth_dev *eth_dev;
+
+ RTE_LOG(INFO, PMD, "Creating kni ethdev on numa socket %u\n",
+ numa_node);
+
+ data = rte_zmalloc_socket(name, sizeof(*data), 0, numa_node);
+ if (data == NULL)
+ goto error;
+
+ internals = rte_zmalloc_socket(name, sizeof(*internals), 0, numa_node);
+ if (internals == NULL)
+ goto error;
+
+ /* reserve an ethdev entry */
+ eth_dev = rte_eth_dev_allocate(name);
+ if (eth_dev == NULL)
+ goto error;
+
+ data->dev_private = internals;
+ data->port_id = eth_dev->data->port_id;
+ memmove(data->name, eth_dev->data->name, sizeof(data->name));
+ data->nb_rx_queues = 1;
+ data->nb_tx_queues = 1;
+ data->dev_link = pmd_link;
+ data->mac_addrs = ð_addr;
+
+ eth_dev->data = data;
+ eth_dev->dev_ops = ð_kni_ops;
+ eth_dev->driver = NULL;
+
+ data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+ data->kdrv = RTE_KDRV_NONE;
+ data->drv_name = eth_kni_drv.driver.name;
+ data->numa_node = numa_node;
+
+ return eth_dev;
+
+error:
+ rte_free(data);
+ rte_free(internals);
+
+ return NULL;
+}
+
+static int
+kni_init(void)
+{
+ if (is_kni_initialized == 0)
+ rte_kni_init(MAX_KNI_PORTS);
+
+ is_kni_initialized += 1;
+
+ return 0;
+}
+
+static int
+eth_kni_probe(const char *name, const char *params __rte_unused)
+{
+ struct rte_eth_dev *eth_dev;
+ int ret;
+
+ RTE_LOG(INFO, PMD, "Initializing eth_kni for %s\n", name);
+
+ ret = kni_init();
+ if (ret < 0)
+ /* Not return error to prevent panic in rte_eal_init() */
+ return 0;
+
+ eth_dev = eth_kni_create(name, rte_socket_id());
+ if (eth_dev == NULL)
+ return -1;
+
+ eth_dev->rx_pkt_burst = eth_kni_rx;
+ eth_dev->tx_pkt_burst = eth_kni_tx;
+
+ return 0;
+}
+
+static int
+eth_kni_remove(const char *name)
+{
+ struct rte_eth_dev *eth_dev;
+ struct pmd_internals *internals;
+
+ RTE_LOG(INFO, PMD, "Un-Initializing eth_kni for %s\n", name);
+
+ /* find the ethdev entry */
+ eth_dev = rte_eth_dev_allocated(name);
+ if (eth_dev == NULL)
+ return -1;
+
+ eth_kni_dev_stop(eth_dev);
+
+ if (eth_dev->data) {
+ internals = eth_dev->data->dev_private;
+ rte_kni_release(internals->kni);
+
+ rte_free(internals);
+ }
+ rte_free(eth_dev->data);
+
+ rte_eth_dev_release_port(eth_dev);
+
+ is_kni_initialized -= 1;
+ if (is_kni_initialized == 0)
+ rte_kni_close();
+
+ return 0;
+}
+
+static struct rte_vdev_driver eth_kni_drv = {
+ .probe = eth_kni_probe,
+ .remove = eth_kni_remove,
+};
+
+RTE_PMD_REGISTER_VDEV(net_kni, eth_kni_drv);
diff --git a/drivers/net/kni/rte_pmd_kni_version.map b/drivers/net/kni/rte_pmd_kni_version.map
new file mode 100644
index 0000000..31eca32
--- /dev/null
+++ b/drivers/net/kni/rte_pmd_kni_version.map
@@ -0,0 +1,4 @@
+DPDK_17.02 {
+
+ local: *;
+};
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index f75f0e2..af02816 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -59,11 +59,6 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
#
# Order is important: from higher level to lower level
#
-
-ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
-_LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni
-endif
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE) += -lrte_pipeline
_LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table
_LDLIBS-$(CONFIG_RTE_LIBRTE_PORT) += -lrte_port
@@ -84,6 +79,10 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power
_LDLIBS-y += --whole-archive
+ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
+_LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni
+endif
+
_LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer
_LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash
_LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost
@@ -115,6 +114,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += -lrte_pmd_enic
_LDLIBS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += -lrte_pmd_fm10k
_LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e
_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += -lrte_pmd_kni
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4 -libverbs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5 -libverbs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
--
2.9.3
^ permalink raw reply related
* [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
From: Cristian Dumitrescu @ 2016-11-30 18:16 UTC (permalink / raw)
To: dev; +Cc: cristian.dumitrescu
This RFC proposes an ethdev-based abstraction layer for Quality of Service (QoS)
hierarchical scheduler. The goal of the abstraction layer is to provide a simple
generic API that is agnostic of the underlying HW, SW or mixed HW-SW complex
implementation.
Q1: What is the benefit for having an abstraction layer for QoS hierarchical
layer?
A1: There is growing interest in the industry for handling various HW-based,
SW-based or mixed hierarchical scheduler implementations using a unified DPDK
API.
Q2: Which devices are targeted by this abstraction layer?
A2: All current and future devices that expose a hierarchical scheduler feature
under DPDK, including NICs, FPGAs, ASICs, SOCs, SW libraries.
Q3: Which scheduler hierarchies are supported by the API?
A3: Hopefully any scheduler hierarchy can be described and covered by the
current API. Of course, functional correctness, accuracy and performance levels
depend on the specific implementations of this API.
Q4: Why have this abstraction layer into ethdev as opposed to a new type of
device (e.g. scheddev) similar to ethdev, cryptodev, eventdev, etc?
A4: Packets are sent to the Ethernet device using the ethdev API
rte_eth_tx_burst() function, with the hierarchical scheduling taking place
automatically (i.e. no SW intervention) in HW implementations. Basically, the
hierarchical scheduler is done as part of packet TX operation.
The hierarchical scheduler is typically the last stage before packet TX and it
is tightly integrated with the TX stage. The hierarchical scheduler is just
another offload feature of the Ethernet device, which needs to be accommodated
by the ethdev API similar to any other offload feature (such as RSS, DCB,
flow director, etc).
Once the decision to schedule a specific packet has been taken, this packet
cannot be dropped and it has to be sent over the wire as is, otherwise what
takes place on the wire is not what was planned at scheduling time, so the
scheduling is not accurate (Note: there are some devices which allow prepending
headers to the packet after the scheduling stage at the expense of sending
correction requests back to the scheduler, but this only strengthens the bond
between scheduling and TX).
Q5: Given that the packet scheduling takes place automatically for pure HW
implementations, how does packet scheduling take place for poll-mode SW
implementations?
A5: The API provided function rte_sched_run() is designed to take care of this.
For HW implementations, this function typically does nothing. For SW
implementations, this function is typically expected to perform dequeue of
packets from the hierarchical scheduler and their write to Ethernet device TX
queue, periodic flush of any buffers on enqueue-side into the hierarchical
scheduler for burst-oriented implementations, etc.
Q6: Which are the scheduling algorithms supported?
A6: The fundamental scheduling algorithms that are supported are Strict Priority
(SP) and Weighted Fair Queuing (WFQ). The SP and WFQ algorithms are supported at
the level of each node of the scheduling hierarchy, regardless of the node
level/position in the tree. The SP algorithm is used to schedule between sibling
nodes with different priority, while WFQ is used to schedule between groups of
siblings that have the same priority.
Algorithms such as Weighed Round Robin (WRR), byte-level WRR, Deficit WRR
(DWRR), etc are considered approximations of the ideal WFQ and are therefore
assimilated to WFQ, although an associated implementation-dependent accuracy,
performance and resource usage trade-off might exist.
Q7: Which are the supported congestion management algorithms?
A7: Tail drop, head drop and Weighted Random Early Detection (WRED). They are
available for every leaf node in the hierarchy, subject to the specific
implementation supporting them.
Q8: Is traffic shaping supported?
A8: Yes, there are a number of shapers (rate limiters) that can be supported for
each node in the hierarchy (built-in limit is currently set to 4 per node). Each
shaper can be private to a node (used only by that node) or shared between
multiple nodes.
Q9: What is the purpose of having shaper profiles and WRED profiles?
A9: In most implementations, many shapers typically share the same configuration
parameters, so defining shaper profiles simplifies the configuration task. Same
considerations apply to WRED contexts and profiles.
Q10: How is the scheduling hierarchy defined and created?
A10: Scheduler hierarchy tree is set up by creating new nodes and connecting
them to other existing nodes, which thus become parent nodes. The unique ID that
is assigned to each node when the node is created is further used to update the
node configuration or to connect children nodes to it. The leaf nodes of the
scheduler hierarchy are each attached to one of the Ethernet device TX queues.
Q11: Are on-the-fly changes of the scheduling hierarchy allowed by the API?
A11: Yes. The actual changes take place subject to the specific implementation
supporting them, otherwise error code is returned.
Q12: What is the typical function call sequence to set up and run the Ethernet
device scheduler?
A12: The typical simplified function call sequence is listed below:
i) Configure the Ethernet device and its TX queues: rte_eth_dev_configure(),
rte_eth_tx_queue_setup()
ii) Create WRED profiles and WRED contexts, shaper profiles and shapers:
rte_eth_sched_wred_profile_add(), rte_eth_sched_wred_context_add(),
rte_eth_sched_shaper_profile_add(), rte_eth_sched_shaper_add()
iii) Create the scheduler hierarchy nodes and tree: rte_eth_sched_node_add()
iv) Freeze the start-up hierarchy and ask the device whether it supports it:
rte_eth_sched_node_add()
v) Start the Ethernet port: rte_eth_dev_start()
vi) Run-time scheduler hierarchy updates: rte_eth_sched_node_add(),
rte_eth_sched_node_<attribute>_set()
vii) Run-time packet enqueue into the hierarchical scheduler: rte_eth_tx_burst()
viii) Run-time support for SW poll-mode implementations (see previous answer):
rte_sched_run()
Q13: Which are the possible options for the user when the Ethernet port does not
support the scheduling hierarchy required by the user?
A13: The following options are available to the user:
i) abort
ii) try out a new hierarchy (e.g. with less leaf nodes), if acceptable
iii) wrap the Ethernet device into a new type of Ethernet device that has a SW
front-end implementing the hierarchical scheduler (e.g. existing DPDK library
librte_sched); instantiate the new device type on-the-fly and check if the
hierarchy requirements can be met by the new device.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
lib/librte_ether/rte_ethdev.h | 794 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 794 insertions(+)
mode change 100644 => 100755 lib/librte_ether/rte_ethdev.h
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
old mode 100644
new mode 100755
index 9678179..d4d8604
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -182,6 +182,8 @@ extern "C" {
#include <rte_pci.h>
#include <rte_dev.h>
#include <rte_devargs.h>
+#include <rte_meter.h>
+#include <rte_red.h>
#include "rte_ether.h"
#include "rte_eth_ctrl.h"
#include "rte_dev_info.h"
@@ -1038,6 +1040,152 @@ TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback);
/**< l2 tunnel forwarding mask */
#define ETH_L2_TUNNEL_FORWARDING_MASK 0x00000008
+/**
+ * Scheduler configuration
+ */
+
+/**< Max number of shapers per node */
+#define RTE_ETH_SCHED_SHAPERS_PER_NODE 4
+/**< Invalid shaper ID */
+#define RTE_ETH_SCHED_SHAPER_ID_NONE UINT32_MAX
+/**< Max number of WRED contexts per node */
+#define RTE_ETH_SCHED_WRED_CONTEXTS_PER_NODE 4
+/**< Invalid WRED context ID */
+#define RTE_ETH_SCHED_WRED_CONTEXT_ID_NONE UINT32_MAX
+/**< Invalid node ID */
+#define RTE_ETH_SCHED_NODE_NULL UINT32_MAX
+
+/**
+ * Congestion management (CMAN) mode
+ *
+ * This is used for controlling the admission of packets into a packet queue or
+ * group of packet queues on congestion. On request of writing a new packet
+ * into the current queue while the queue is full, the *tail drop* algorithm
+ * drops the new packet while leaving the queue unmodified, as opposed to *head
+ * drop* algorithm, which drops the packet at the head of the queue (the oldest
+ * packet waiting in the queue) and admits the new packet at the tail of the
+ * queue.
+ *
+ * The *Random Early Detection (RED)* algorithm works by proactively dropping
+ * more and more input packets as the queue occupancy builds up. When the queue
+ * is full or almost full, RED effectively works as *tail drop*. The *Weighted
+ * RED* algorithm uses a separate set of RED thresholds per packet color.
+ */
+enum rte_eth_sched_cman_mode {
+ RTE_ETH_SCHED_CMAN_TAIL_DROP = 0, /**< Tail drop */
+ RTE_ETH_SCHED_CMAN_HEAD_DROP, /**< Head drop */
+ RTE_ETH_SCHED_CMAN_WRED, /**< Weighted Random Early Detection (WRED) */
+};
+
+/**
+ * WRED profile
+ */
+struct rte_eth_sched_wred_params {
+ /**< One set of RED parameters per packet color */
+ struct rte_red_params red_params[e_RTE_METER_COLORS];
+};
+
+/**
+ * Shaper (rate limiter) profile
+ *
+ * Multiple shaper instances can share the same shaper profile. Each node can
+ * have multiple shapers enabled (up to RTE_ETH_SCHED_SHAPERS_PER_NODE). Each
+ * shaper can be private to a node (only one node using it) or shared (multiple
+ * nodes use the same shaper instance).
+ */
+struct rte_eth_sched_shaper_params {
+ uint64_t rate; /**< Token bucket rate (bytes per second) */
+ uint64_t size; /**< Token bucket size (bytes) */
+};
+
+/**
+ * Node parameters
+ *
+ * Each scheduler hierarchy node has multiple inputs (children nodes of the
+ * current parent node) and a single output (which is input to its parent
+ * node). The current node arbitrates its inputs using Strict Priority (SP)
+ * and Weighted Fair Queuing (WFQ) algorithms to schedule input packets on its
+ * output while observing its shaping/rate limiting constraints. Algorithms
+ * such as Weighted Round Robin (WRR), byte-level WRR, Deficit WRR (DWRR), etc
+ * are considered approximations of the ideal WFQ and are assimilated to WFQ,
+ * although an associated implementation-dependent trade-off on accuracy,
+ * performance and resource usage might exist.
+ *
+ * Children nodes with different priorities are scheduled using the SP
+ * algorithm, based on their priority, with zero (0) as the highest priority.
+ * Children with same priority are scheduled using the WFQ algorithm, based on
+ * their weight, which is relative to the sum of the weights of all siblings
+ * with same priority, with one (1) as the lowest weight.
+ */
+struct rte_eth_sched_node_params {
+ /**< Child node priority (used by SP). The highest priority is zero. */
+ uint32_t priority;
+ /**< Child node weight (used by WFQ), relative to some of weights of all
+ siblings with same priority). The lowest weight is one. */
+ uint32_t weight;
+ /**< Set of shaper instances enabled for current node. Each node shaper
+ can be disabled by setting it to RTE_ETH_SCHED_SHAPER_ID_NONE. */
+ uint32_t shaper_id[RTE_ETH_SCHED_SHAPERS_PER_NODE];
+ /**< Set to zero if current node is not a hierarchy leaf node, set to a
+ non-zero value otherwise. A leaf node is a hierarchy node that does
+ not have any children. A leaf node has to be connected to a valid
+ packet queue. */
+ int is_leaf;
+ /**< Parameters valid for leaf nodes only */
+ struct {
+ /**< Packet queue ID */
+ uint64_t queue_id;
+ /**< Congestion management mode */
+ enum rte_eth_sched_cman_mode cman;
+ /**< Set of WRED contexts enabled for current leaf node. Each
+ leaf node WRED context can be disabled by setting it to
+ RTE_ETH_SCHED_WRED_CONTEXT_ID_NONE. Only valid when
+ congestion management for current leaf node is set to WRED. */
+ uint32_t wred_context_id[RTE_ETH_SCHED_WRED_CONTEXTS_PER_NODE];
+ } leaf;
+};
+
+/**
+ * Node statistics counter type
+ */
+enum rte_eth_sched_stats_counter {
+ /**< Number of packets scheduled from current node. */
+ RTE_ETH_SCHED_STATS_COUNTER_N_PKTS = 1<< 0,
+ /**< Number of bytes scheduled from current node. */
+ RTE_ETH_SCHED_STATS_COUNTER_N_BYTES = 1 << 1,
+ RTE_ETH_SCHED_STATS_COUNTER_N_PKTS_DROPPED = 1 << 2,
+ RTE_ETH_SCHED_STATS_COUNTER_N_BYTES_DROPPED = 1 << 3,
+ /**< Number of packets currently waiting in the packet queue of current
+ leaf node. */
+ RTE_ETH_SCHED_STATS_COUNTER_N_PKTS_QUEUED = 1 << 4,
+ /**< Number of bytes currently waiting in the packet queue of current
+ leaf node. */
+ RTE_ETH_SCHED_STATS_COUNTER_N_BYTES_QUEUED = 1 << 5,
+};
+
+/**
+ * Node statistics counters
+ */
+struct rte_eth_sched_node_stats {
+ /**< Number of packets scheduled from current node. */
+ uint64_t n_pkts;
+ /**< Number of bytes scheduled from current node. */
+ uint64_t n_bytes;
+ /**< Statistics counters for leaf nodes only */
+ struct {
+ /**< Number of packets dropped by current leaf node. */
+ uint64_t n_pkts_dropped;
+ /**< Number of bytes dropped by current leaf node. */
+ uint64_t n_bytes_dropped;
+ /**< Number of packets currently waiting in the packet queue of
+ current leaf node. */
+ uint64_t n_pkts_queued;
+ /**< Number of bytes currently waiting in the packet queue of
+ current leaf node. */
+ uint64_t n_bytes_queued;
+ } leaf;
+};
+
/*
* Definitions of all functions exported by an Ethernet driver through the
* the generic structure of type *eth_dev_ops* supplied in the *rte_eth_dev*
@@ -1421,6 +1569,120 @@ typedef int (*eth_get_dcb_info)(struct rte_eth_dev *dev,
struct rte_eth_dcb_info *dcb_info);
/**< @internal Get dcb information on an Ethernet device */
+typedef int (*eth_sched_wred_profile_add_t)(struct rte_eth_dev *dev,
+ uint32_t wred_profile_id,
+ struct rte_eth_sched_wred_params *profile);
+/**< @internal Scheduler WRED profile add */
+
+typedef int (*eth_sched_wred_profile_delete_t)(struct rte_eth_dev *dev,
+ uint32_t wred_profile_id);
+/**< @internal Scheduler WRED profile delete */
+
+typedef int (*eth_sched_wred_context_add_t)(struct rte_eth_dev *dev,
+ uint32_t wred_context_id,
+ uint32_t wred_profile_id);
+/**< @internal Scheduler WRED context add */
+
+typedef int (*eth_sched_wred_context_delete_t)(struct rte_eth_dev *dev,
+ uint32_t wred_context_id);
+/**< @internal Scheduler WRED context delete */
+
+typedef int (*eth_sched_shaper_profile_add_t)(struct rte_eth_dev *dev,
+ uint32_t shaper_profile_id,
+ struct rte_eth_sched_shaper_params *profile);
+/**< @internal Scheduler shaper profile add */
+
+typedef int (*eth_sched_shaper_profile_delete_t)(struct rte_eth_dev *dev,
+ uint32_t shaper_profile_id);
+/**< @internal Scheduler shaper profile delete */
+
+typedef int (*eth_sched_shaper_add_t)(struct rte_eth_dev *dev,
+ uint32_t shaper_id,
+ uint32_t shaper_profile_id);
+/**< @internal Scheduler shaper instance add */
+
+typedef int (*eth_sched_shaper_delete_t)(struct rte_eth_dev *dev,
+ uint32_t shaper_id);
+/**< @internal Scheduler shaper instance delete */
+
+typedef int (*eth_sched_node_add_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint32_t parent_node_id,
+ struct rte_eth_sched_node_params *params);
+/**< @internal Scheduler node add */
+
+typedef int (*eth_sched_node_delete_t)(struct rte_eth_dev *dev,
+ uint32_t node_id);
+/**< @internal Scheduler node delete */
+
+typedef int (*eth_sched_hierarchy_set_t)(struct rte_eth_dev *dev,
+ int clear_on_fail);
+/**< @internal Scheduler hierarchy set */
+
+typedef int (*eth_sched_node_priority_set_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint32_t priority);
+/**< @internal Scheduler node priority set */
+
+typedef int (*eth_sched_node_weight_set_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint32_t weight);
+/**< @internal Scheduler node weight set */
+
+typedef int (*eth_sched_node_shaper_set_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint32_t shaper_pos,
+ uint32_t shaper_id);
+/**< @internal Scheduler node shaper set */
+
+typedef int (*eth_sched_node_queue_set_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint32_t queue_id);
+/**< @internal Scheduler node queue set */
+
+typedef int (*eth_sched_node_cman_set_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ enum rte_eth_sched_cman_mode cman);
+/**< @internal Scheduler node congestion management mode set */
+
+typedef int (*eth_sched_node_wred_context_set_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint32_t wred_context_pos,
+ uint32_t wred_context_id);
+/**< @internal Scheduler node WRED context set */
+
+typedef int (*eth_sched_stats_get_enabled_t)(struct rte_eth_dev *dev,
+ uint64_t *nonleaf_node_capability_stats_mask,
+ uint64_t *nonleaf_node_enabled_stats_mask,
+ uint64_t *leaf_node_capability_stats_mask,
+ uint64_t *leaf_node_enabled_stats_mask);
+/**< @internal Scheduler get set of stats counters enabled for all nodes */
+
+typedef int (*eth_sched_stats_enable_t)(struct rte_eth_dev *dev,
+ uint64_t nonleaf_node_enabled_stats_mask,
+ uint64_t leaf_node_enabled_stats_mask);
+/**< @internal Scheduler enable selected stats counters for all nodes */
+
+typedef int (*eth_sched_node_stats_get_enabled_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint64_t *capability_stats_mask,
+ uint64_t *enabled_stats_mask);
+/**< @internal Scheduler get set of stats counters enabled for specific node */
+
+typedef int (*eth_sched_node_stats_enable_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ uint64_t enabled_stats_mask);
+/**< @internal Scheduler enable selected stats counters for specific node */
+
+typedef int (*eth_sched_node_stats_read_t)(struct rte_eth_dev *dev,
+ uint32_t node_id,
+ struct rte_eth_sched_node_stats *stats,
+ int clear);
+/**< @internal Scheduler read stats counters for specific node */
+
+typedef int (*eth_sched_run_t)(struct rte_eth_dev *dev);
+/**< @internal Scheduler run */
+
/**
* @internal A structure containing the functions exported by an Ethernet driver.
*/
@@ -1547,6 +1809,53 @@ struct eth_dev_ops {
eth_l2_tunnel_eth_type_conf_t l2_tunnel_eth_type_conf;
/** Enable/disable l2 tunnel offload functions */
eth_l2_tunnel_offload_set_t l2_tunnel_offload_set;
+
+ /** Scheduler WRED profile add */
+ eth_sched_wred_profile_add_t sched_wred_profile_add;
+ /** Scheduler WRED profile delete */
+ eth_sched_wred_profile_delete_t sched_wred_profile_delete;
+ /** Scheduler WRED context add */
+ eth_sched_wred_context_add_t sched_wred_context_add;
+ /** Scheduler WRED context delete */
+ eth_sched_wred_context_delete_t sched_wred_context_delete;
+ /** Scheduler shaper profile add */
+ eth_sched_shaper_profile_add_t sched_shaper_profile_add;
+ /** Scheduler shaper profile delete */
+ eth_sched_shaper_profile_delete_t sched_shaper_profile_delete;
+ /** Scheduler shaper instance add */
+ eth_sched_shaper_add_t sched_shaper_add;
+ /** Scheduler shaper instance delete */
+ eth_sched_shaper_delete_t sched_shaper_delete;
+ /** Scheduler node add */
+ eth_sched_node_add_t sched_node_add;
+ /** Scheduler node delete */
+ eth_sched_node_delete_t sched_node_delete;
+ /** Scheduler hierarchy set */
+ eth_sched_hierarchy_set_t sched_hierarchy_set;
+ /** Scheduler node priority set */
+ eth_sched_node_priority_set_t sched_node_priority_set;
+ /** Scheduler node weight set */
+ eth_sched_node_weight_set_t sched_node_weight_set;
+ /** Scheduler node shaper set */
+ eth_sched_node_shaper_set_t sched_node_shaper_set;
+ /** Scheduler node queue set */
+ eth_sched_node_queue_set_t sched_node_queue_set;
+ /** Scheduler node congestion management mode set */
+ eth_sched_node_cman_set_t sched_node_cman_set;
+ /** Scheduler node WRED context set */
+ eth_sched_node_wred_context_set_t sched_node_wred_context_set;
+ /** Scheduler get statistics counter type enabled for all nodes */
+ eth_sched_stats_get_enabled_t sched_stats_get_enabled;
+ /** Scheduler enable selected statistics counters for all nodes */
+ eth_sched_stats_enable_t sched_stats_enable;
+ /** Scheduler get statistics counter type enabled for current node */
+ eth_sched_node_stats_get_enabled_t sched_node_stats_get_enabled;
+ /** Scheduler enable selected statistics counters for current node */
+ eth_sched_node_stats_enable_t sched_node_stats_enable;
+ /** Scheduler read statistics counters for current node */
+ eth_sched_node_stats_read_t sched_node_stats_read;
+ /** Scheduler run */
+ eth_sched_run_t sched_run;
};
/**
@@ -4336,6 +4645,491 @@ rte_eth_dev_l2_tunnel_offload_set(uint8_t port_id,
uint8_t en);
/**
+ * Scheduler WRED profile add
+ *
+ * Create a new WRED profile with ID set to *wred_profile_id*. The new profile
+ * is used to create one or several WRED contexts.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param wred_profile_id
+ * WRED profile ID for the new profile. Needs to be unused.
+ * @param profile
+ * WRED profile parameters. Needs to be pre-allocated and valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_wred_profile_add(uint8_t port_id,
+ uint32_t wred_profile_id,
+ struct rte_eth_sched_wred_params *profile);
+
+/**
+ * Scheduler WRED profile delete
+ *
+ * Delete an existing WRED profile. This operation fails when there is currently
+ * at least one user (i.e. WRED context) of this WRED profile.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param wred_profile_id
+ * WRED profile ID. Needs to be the valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_wred_profile_delete(uint8_t port_id,
+ uint32_t wred_profile_id);
+
+/**
+ * Scheduler WRED context add or update
+ *
+ * When *wred_context_id* is invalid, a new WRED context with this ID is created
+ * by using the WRED profile identified by *wred_profile_id*.
+ *
+ * When *wred_context_id* is valid, this WRED context is no longer using the
+ * profile previously assigned to it and is updated to use the profile
+ * identified by *wred_profile_id*.
+ *
+ * A valid WRED context is assigned to one or several scheduler hierarchy leaf
+ * nodes configured to use WRED as the congestion management mode.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param wred_context_id
+ * WRED context ID
+ * @param wred_profile_id
+ * WRED profile ID. Needs to be the valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_wred_context_add(uint8_t port_id,
+ uint32_t wred_context_id,
+ uint32_t wred_profile_id);
+
+/**
+ * Scheduler WRED context delete
+ *
+ * Delete an existing WRED context. This operation fails when there is currently
+ * at least one user (i.e. scheduler hierarchy leaf node) of this WRED context.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param wred_context_id
+ * WRED context ID. Needs to be the valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_wred_context_delete(uint8_t port_id,
+ uint32_t wred_context_id);
+
+/**
+ * Scheduler shaper profile add
+ *
+ * Create a new shaper profile with ID set to *shaper_profile_id*. The new
+ * shaper profile is used to create one or several shapers.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param shaper_profile_id
+ * Shaper profile ID for the new profile. Needs to be unused.
+ * @param profile
+ * Shaper profile parameters. Needs to be pre-allocated and valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_shaper_profile_add(uint8_t port_id,
+ uint32_t shaper_profile_id,
+ struct rte_eth_sched_shaper_params *profile);
+
+/**
+ * Scheduler shaper profile delete
+ *
+ * Delete an existing shaper profile. This operation fails when there is
+ * currently at least one user (i.e. shaper) of this shaper profile.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param shaper_profile_id
+ * Shaper profile ID. Needs to be the valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+/* no users (shapers) using this profile */
+int rte_eth_sched_shaper_profile_delete(uint8_t port_id,
+ uint32_t shaper_profile_id);
+
+/**
+ * Scheduler shaper add or update
+ *
+ * When *shaper_id* is not a valid shaper ID, a new shaper with this ID is
+ * created using the shaper profile identified by *shaper_profile_id*.
+ *
+ * When *shaper_id* is a valid shaper ID, this shaper is no longer using the
+ * shaper profile previously assigned to it and is updated to use the shaper
+ * profile identified by *shaper_profile_id*.
+ *
+ * A valid shaper is assigned to one or several scheduler hierarchy nodes.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param shaper_id
+ * Shaper ID
+ * @param shaper_profile_id
+ * Shaper profile ID. Needs to be the valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_shaper_add(uint8_t port_id,
+ uint32_t shaper_id,
+ uint32_t shaper_profile_id);
+
+/**
+ * Scheduler shaper delete
+ *
+ * Delete an existing shaper. This operation fails when there is currently at
+ * least one user (i.e. scheduler hierarchy node) of this shaper.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param shaper_id
+ * Shaper ID. Needs to be the valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_shaper_delete(uint8_t port_id,
+ uint32_t shaper_id);
+
+/**
+ * Scheduler node add or remap
+ *
+ * When *node_id* is not a valid node ID, a new node with this ID is created and
+ * connected as child to the existing node identified by *parent_node_id*.
+ *
+ * When *node_id* is a valid node ID, this node is disconnected from its current
+ * parent and connected as child to another existing node identified by
+ * *parent_node_id *.
+ *
+ * This function can be called during port initialization phase (before the
+ * Ethernet port is started) for building the scheduler start-up hierarchy.
+ * Subject to the specific Ethernet port supporting on-the-fly scheduler
+ * hierarchy updates, this function can also be called during run-time (after
+ * the Ethernet port is started).
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID
+ * @param parent_node_id
+ * Parent node ID. Needs to be the valid.
+ * @param params
+ * Node parameters. Needs to be pre-allocated and valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_add(uint8_t port_id,
+ uint32_t node_id,
+ uint32_t parent_node_id,
+ struct rte_eth_sched_node_params *params);
+
+/**
+ * Scheduler node delete
+ *
+ * Delete an existing node. This operation fails when this node currently has at
+ * least one user (i.e. child node).
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_delete(uint8_t port_id,
+ uint32_t node_id);
+
+/**
+ * Scheduler hierarchy set
+ *
+ * This function is called during the port initialization phase (before the
+ * Ethernet port is started) to freeze the scheduler start-up hierarchy.
+ *
+ * This function fails when the currently configured scheduler hierarchy is not
+ * supported by the Ethernet port, in which case the user can abort or try out
+ * another hierarchy configuration (e.g. a hierarchy with less leaf nodes),
+ * which can be build from scratch (when *clear_on_fail* is enabled) or by
+ * modifying the existing hierarchy configuration (when *clear_on_fail* is
+ * disabled).
+ *
+ * Note that, even when the configured scheduler hierarchy is supported (so this
+ * function is successful), the Ethernet port start might still fail due to e.g.
+ * not enough memory being available in the system, etc.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param clear_on_fail
+ * On function call failure, hierarchy is cleared when this parameter is
+ * non-zero and preserved when this parameter is equal to zero.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_hierarchy_set(uint8_t port_id,
+ int clear_on_fail);
+
+/**
+ * Scheduler node priority set
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param priority
+ * Node priority. The highest node priority is zero. Used by the SP algorithm
+ * running on the parent of the current node for scheduling this child node.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_priority_set(uint8_t port_id,
+ uint32_t node_id,
+ uint32_t priority);
+
+/**
+ * Scheduler node weight set
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param weight
+ * Node weight. The node weight is relative to the weight sum of all siblings
+ * that have the same priority. The lowest weight is zero. Used by the WFQ
+ * algorithm running on the parent of the current node for scheduling this
+ * child node.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_weight_set(uint8_t port_id,
+ uint32_t node_id,
+ uint32_t weight);
+
+/**
+ * Scheduler node shaper set
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param shaper_pos
+ * Position in the shaper array of the current node
+ * (0 .. RTE_ETH_SCHED_SHAPERS_PER_NODE-1).
+ * @param shaper_id
+ * Shaper ID. Needs to be either valid shaper ID or set to
+ * RTE_ETH_SCHED_SHAPER_ID_NONE in order to invalidate the shaper on position
+ * *shaper_pos* within the current node.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_shaper_set(uint8_t port_id,
+ uint32_t node_id,
+ uint32_t shaper_pos,
+ uint32_t shaper_id);
+
+/**
+ * Scheduler node queue set
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param queue_id
+ * Queue ID. Needs to be valid.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_queue_set(uint8_t port_id,
+ uint32_t node_id,
+ uint32_t queue_id);
+
+/**
+ * Scheduler node congestion management mode set
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid leaf node ID.
+ * @param cman
+ * Congestion management mode.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_cman_set(uint8_t port_id,
+ uint32_t node_id,
+ enum rte_eth_sched_cman_mode cman);
+
+/**
+ * Scheduler node WRED context set
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid leaf node ID that has WRED selected as the
+ * congestion management mode.
+ * @param wred_context_pos
+ * Position in the WRED context array of the current leaf node
+ * (0 .. RTE_ETH_SCHED_WRED_CONTEXTS_PER_NODE-1)
+ * @param wred_context_id
+ * WRED context ID. Needs to be either valid WRED context ID or set to
+ * RTE_ETH_SCHED_WRED_CONTEXT_ID_NONE in order to invalidate the WRED context
+ * on position *wred_context_pos* within the current leaf node.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_wred_context_set(uint8_t port_id,
+ uint32_t node_id,
+ uint32_t wred_context_pos,
+ uint32_t wred_context_id);
+
+/**
+ * Scheduler get statistics counter types enabled for all nodes
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param nonleaf_node_capability_stats_mask
+ * Statistics counter types available per node for all non-leaf nodes. Needs
+ * to be pre-allocated.
+ * @param nonleaf_node_enabled_stats_mask
+ * Statistics counter types currently enabled per node for each non-leaf node.
+ * This is a subset of *nonleaf_node_capability_stats_mask*. Needs to be
+ * pre-allocated.
+ * @param leaf_node_capability_stats_mask
+ * Statistics counter types available per node for all leaf nodes. Needs to
+ * be pre-allocated.
+ * @param leaf_node_enabled_stats_mask
+ * Statistics counter types currently enabled for each leaf node. This is
+ * a subset of *leaf_node_capability_stats_mask*. Needs to be pre-allocated.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_stats_get_enabled(uint8_t port_id,
+ uint64_t *nonleaf_node_capability_stats_mask,
+ uint64_t *nonleaf_node_enabled_stats_mask,
+ uint64_t *leaf_node_capability_stats_mask,
+ uint64_t *leaf_node_enabled_stats_mask);
+
+/**
+ * Scheduler enable selected statistics counters for all nodes
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param nonleaf_node_enabled_stats_mask
+ * Statistics counter types to be enabled per node for each non-leaf node.
+ * This needs to be a subset of the statistics counter types available per
+ * node for all non-leaf nodes. Any statistics counter type not included in
+ * this set is to be disabled for all non-leaf nodes.
+ * @param leaf_node_enabled_stats_mask
+ * Statistics counter types to be enabled per node for each leaf node. This
+ * needs to be a subset of the statistics counter types available per node for
+ * all leaf nodes. Any statistics counter type not included in this set is to
+ * be disabled for all leaf nodes.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_stats_enable(uint8_t port_id,
+ uint64_t nonleaf_node_enabled_stats_mask,
+ uint64_t leaf_node_enabled_stats_mask);
+
+/**
+ * Scheduler get statistics counter types enabled for current node
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param capability_stats_mask
+ * Statistics counter types available for the current node. Needs to be pre-allocated.
+ * @param enabled_stats_mask
+ * Statistics counter types currently enabled for the current node. This is
+ * a subset of *capability_stats_mask*. Needs to be pre-allocated.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_stats_get_enabled(uint8_t port_id,
+ uint32_t node_id,
+ uint64_t *capability_stats_mask,
+ uint64_t *enabled_stats_mask);
+
+/**
+ * Scheduler enable selected statistics counters for current node
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param enabled_stats_mask
+ * Statistics counter types to be enabled for the current node. This needs to
+ * be a subset of the statistics counter types available for the current node.
+ * Any statistics counter type not included in this set is to be disabled for
+ * the current node.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_stats_enable(uint8_t port_id,
+ uint32_t node_id,
+ uint64_t enabled_stats_mask);
+
+/**
+ * Scheduler node statistics counters read
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param node_id
+ * Node ID. Needs to be valid.
+ * @param stats
+ * When non-NULL, it contains the current value for the statistics counters
+ * enabled for the current node.
+ * @param clear
+ * When this parameter has a non-zero value, the statistics counters are
+ * cleared (i.e. set to zero) immediately after they have been read, otherwise
+ * the statistics counters are left untouched.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+int rte_eth_sched_node_stats_read(uint8_t port_id,
+ uint32_t node_id,
+ struct rte_eth_sched_node_stats *stats,
+ int clear);
+
+/**
+ * Scheduler run
+ *
+ * The packet enqueue side of the scheduler hierarchy is typically done through
+ * the Ethernet device TX function. For HW implementations, the packet dequeue
+ * side is typically done by the Ethernet device without any SW intervention,
+ * therefore this functions should not do anything.
+ *
+ * However, for poll-mode SW or mixed HW-SW implementations, the SW intervention
+ * is likely to be required for running the packet dequeue side of the scheduler
+ * hierarchy. Other potential task performed by this function is periodic flush
+ * of any packet enqueue-side buffers used by the burst-mode implementations.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+static inline int
+rte_eth_sched_run(uint8_t port_id)
+{
+ struct rte_eth_dev *dev;
+
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
+#endif
+
+ dev = &rte_eth_devices[port_id];
+
+ return (dev->dev_ops->sched_run)? dev->dev_ops->sched_run(dev) : 0;
+}
+
+/**
* Get the port id from pci adrress or device name
* Ex: 0000:2:00.0 or vdev name net_pcap0
*
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v12 0/6] add Tx preparation
From: Thomas Monjalon @ 2016-11-30 18:26 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Harish Patil, dev, Rahul Lakkireddy, Stephen Hurd, Jan Medala,
Jakub Palider, John Daley, Adrien Mazarguil, Alejandro Lucero,
Rasesh Mody, Jacob, Jerin, Yuanhan Liu, Yong Wang,
Kulasek, TomaszX, olivier.matz
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E2444@irsmsx105.ger.corp.intel.com>
2016-11-30 17:42, Ananyev, Konstantin:
> > >Please, we need a comment for each driver saying
> > >"it is OK, we do not need any checksum preparation for TSO"
> > >or
> > >"yes we have to implement tx_prepare or TSO will not work in this mode"
> > >
> >
> > qede PMD doesn’t currently support TSO yet, it only supports Tx TCP/UDP/IP
> > csum offloads.
> > So Tx preparation isn’t applicable. So as of now -
> > "it is OK, we do not need any checksum preparation for TSO"
>
> Thanks for the answer.
> Though please note that it not only for TSO.
Oh yes, sorry, my wording was incorrect.
We need to know if any checksum preparation is needed prior
offloading its final computation to the hardware or driver.
So the question applies to TSO and simple checksum offload.
We are still waiting answers for
bnxt, cxgbe, ena, nfp, thunderx, virtio and vmxnet3.
> This is for any TX offload for which the upper layer SW would have
> to modify the contents of the packet.
> Though as I can see for qede neither PKT_TX_IP_CKSUM or PKT_TX_TCP_CKSUM
> exhibits any extra requirements for the user.
> Is that correct?
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Harish Patil @ 2016-11-30 18:39 UTC (permalink / raw)
To: Ananyev, Konstantin, Thomas Monjalon, dev@dpdk.org,
Rahul Lakkireddy, Stephen Hurd, Jan Medala, Jakub Palider,
John Daley, Adrien Mazarguil, Alejandro Lucero, Rasesh Mody,
Jacob, Jerin, Yuanhan Liu, Yong Wang
Cc: Kulasek, TomaszX, olivier.matz@6wind.com
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E2444@irsmsx105.ger.corp.intel.com>
>
>
>
>Hi Harish,
>>
>>
>> >We need attention of every PMD developers on this thread.
>> >
>> >Reminder of what Konstantin suggested:
>> >"
>> >- if the PMD supports TX offloads AND
>> >- if to be able use any of these offloads the upper layer SW would have
>> >to:
>> > * modify the contents of the packet OR
>> > * obey HW specific restrictions
>> >then it is a PMD developer responsibility to provide tx_prep() that
>>would
>> >implement
>> >expected modifications of the packet contents and restriction checks.
>> >Otherwise, tx_prep() implementation is not required and can be safely
>>set
>> >to NULL.
>> >"
>> >
>> >I copy/paste also my previous conclusion:
>> >
>> >Before txprep, there is only one API: the application must prepare the
>> >packets checksum itself (get_psd_sum in testpmd).
>> >With txprep, the application have 2 choices: keep doing the job itself
>> >or call txprep which calls a PMD-specific function.
>> >The question is: does non-Intel drivers need a checksum preparation for
>> >TSO?
>> >Will it behave well if txprep does nothing in these drivers?
>> >
>> >When looking at the code, most of drivers handle the TSO flags.
>> >But it is hard to know whether they rely on the pseudo checksum or not.
>> >
>> >git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG'
>> >drivers/net/
>> >
>> >drivers/net/bnxt/bnxt_txr.c
>> >drivers/net/cxgbe/sge.c
>> >drivers/net/e1000/em_rxtx.c
>> >drivers/net/e1000/igb_rxtx.c
>> >drivers/net/ena/ena_ethdev.c
>> >drivers/net/enic/enic_rxtx.c
>> >drivers/net/fm10k/fm10k_rxtx.c
>> >drivers/net/i40e/i40e_rxtx.c
>> >drivers/net/ixgbe/ixgbe_rxtx.c
>> >drivers/net/mlx4/mlx4.c
>> >drivers/net/mlx5/mlx5_rxtx.c
>> >drivers/net/nfp/nfp_net.c
>> >drivers/net/qede/qede_rxtx.c
>> >drivers/net/thunderx/nicvf_rxtx.c
>> >drivers/net/virtio/virtio_rxtx.c
>> >drivers/net/vmxnet3/vmxnet3_rxtx.c
>> >
>> >Please, we need a comment for each driver saying
>> >"it is OK, we do not need any checksum preparation for TSO"
>> >or
>> >"yes we have to implement tx_prepare or TSO will not work in this mode"
>> >
>>
>> qede PMD doesn’t currently support TSO yet, it only supports Tx
>>TCP/UDP/IP
>> csum offloads.
>> So Tx preparation isn’t applicable. So as of now -
>> "it is OK, we do not need any checksum preparation for TSO"
>
>Thanks for the answer.
>Though please note that it not only for TSO.
Okay. I initially thought so. But was not sure, so I explicitly indicated
that there is no TSO support.
>This is for any TX offload for which the upper layer SW would have
>to modify the contents of the packet.
>Though as I can see for qede neither PKT_TX_IP_CKSUM or PKT_TX_TCP_CKSUM
>exhibits any extra requirements for the user.
>Is that correct?
That’s right.
>
>Konstantin
>
>
>>
>>
>> Thanks,
>> Harish
>
>
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Ajit Khaparde @ 2016-11-30 19:37 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Rahul Lakkireddy, Stephen Hurd, Jan Medala, Jakub Palider,
John Daley, Adrien Mazarguil, Alejandro Lucero, Harish Patil,
Rasesh Mody, Jerin Jacob, Yuanhan Liu, Yong Wang, Tomasz Kulasek,
konstantin.ananyev, olivier.matz
In-Reply-To: <8317180.L80Qf11uiu@xps13>
On Mon,
Nov 28, 2016 at 5:03 AM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> We need attention of every PMD developers on this thread.
>
> Reminder of what Konstantin suggested:
> "
> - if the PMD supports TX offloads AND
> - if to be able use any of these offloads the upper layer SW would have to:
> * modify the contents of the packet OR
> * obey HW specific restrictions
> then it is a PMD developer responsibility to provide tx_prep() that would
> implement
> expected modifications of the packet contents and restriction checks.
> Otherwise, tx_prep() implementation is not required and can be safely set
> to NULL.
> "
>
> I copy/paste also my previous conclusion:
>
> Before txprep, there is only one API: the application must prepare the
> packets checksum itself (get_psd_sum in testpmd).
> With txprep, the application have 2 choices: keep doing the job itself
> or call txprep which calls a PMD-specific function.
> The question is: does non-Intel drivers need a checksum preparation for
> TSO?
> Will it behave well if txprep does nothing in these drivers?
>
> When looking at the code, most of drivers handle the TSO flags.
> But it is hard to know whether they rely on the pseudo checksum or not.
>
> git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG'
> drivers/net/
>
> drivers/net/bnxt/bnxt_txr.c
>
::: snip:::
>
> Please, we need a comment for each driver saying
> "it is OK, we do not need any checksum preparation for TSO"
> or
> "yes we have to implement tx_prepare or TSO will not work in this mode"
>
The bnxt devices
don't need pse
udo header checksum in the packet for TSO or TX
checksum offload.
So..
"it is OK, we do not need any checksum preparation for TSO"
^ permalink raw reply
* Re: [PATCH] cryptodev: fix crash on null dereference
From: Jerin Jacob @ 2016-11-30 20:36 UTC (permalink / raw)
To: De Lara Guarch, Pablo; +Cc: dev@dpdk.org, Doherty, Declan
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8973CA3F577@IRSMSX108.ger.corp.intel.com>
On Wed, Nov 30, 2016 at 03:10:14PM +0000, De Lara Guarch, Pablo wrote:
> Hi Jerin,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Tuesday, November 15, 2016 7:12 PM
> > To: dev@dpdk.org
> > Cc: Doherty, Declan; Jerin Jacob
> > Subject: [dpdk-dev] [PATCH] cryptodev: fix crash on null dereference
> >
> > crypodev->data->name will be null when
> > rte_cryptodev_get_dev_id() invoked without a valid
> > crypto device instance.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>
> Could you add a "Fixes" line?
Sure. I will send the v2 then
>
> Thanks,
> Pablo
^ permalink raw reply
* apply commit e30a0178d290a4e83dc01f9c2170d4859339c9cf "kni: support RHEL 7.3" to dpdk-stable?
From: Roberts, Lee A. @ 2016-11-30 20:54 UTC (permalink / raw)
To: dev@dpdk.org
Does it make sense to apply the commit for "kni: support RHEL 7.3" (http://www.dpdk.org/browse/dpdk/commit/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h?id=e30a0178d290a4e83dc01f9c2170d4859339c9cf)
to the stable tree to enable clean compilation on RHEL 7.3?
- Lee Roberts
^ permalink raw reply
* Re: [PATCH v2] i40e: Fix eth_i40e_dev_init sequence on ThunderX
From: Jerin Jacob @ 2016-11-30 20:54 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Richardson, Bruce, Satha Rao, Zhang, Helin, Wu, Jingjing,
jianbo.liu@linaro.org, dev@dpdk.org
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E2477@irsmsx105.ger.corp.intel.com>
On Wed, Nov 30, 2016 at 05:52:02PM +0000, Ananyev, Konstantin wrote:
> Hi Jerin,
Hi Konstantin,
>
> >
> > On Tue, Nov 22, 2016 at 01:46:54PM +0000, Bruce Richardson wrote:
> > > On Tue, Nov 22, 2016 at 03:46:38AM +0530, Jerin Jacob wrote:
> > > > On Sun, Nov 20, 2016 at 11:21:43PM +0000, Ananyev, Konstantin wrote:
> > > > Hi
> > > > > >
> > > > > > i40e_asq_send_command: rd32 & wr32 under ThunderX gives unpredictable
> > > > > > results. To solve this include rte memory barriers
> > > > > >
> > > > > > Signed-off-by: Satha Rao <skoteshwar@caviumnetworks.com>
> > > > > > ---
> > > > > > drivers/net/i40e/base/i40e_osdep.h | 14 ++++++++++++++
> > > > > > 1 file changed, 14 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/net/i40e/base/i40e_osdep.h b/drivers/net/i40e/base/i40e_osdep.h
> > > > > > index 38e7ba5..ffa3160 100644
> > > > > > --- a/drivers/net/i40e/base/i40e_osdep.h
> > > > > > +++ b/drivers/net/i40e/base/i40e_osdep.h
> > > > > > @@ -158,7 +158,13 @@ do { \
> > > > > > ((volatile uint32_t *)((char *)(a)->hw_addr + (reg)))
> > > > > > static inline uint32_t i40e_read_addr(volatile void *addr)
> > > > > > {
> > > > > > +#if defined(RTE_ARCH_ARM64)
> > > > > > + uint32_t val = rte_le_to_cpu_32(I40E_PCI_REG(addr));
> > > > > > + rte_rmb();
> > > > > > + return val;
> > > > >
> > > > > If you really need an rmb/wmb with MMIO read/writes on ARM,
> > > > > I think you can avoid #ifdefs here and use rte_smp_rmb/rte_smp_wmb.
> > > > > BTW, I suppose if you need it for i40e, you would need it for other devices too.
> > > >
> > > > Yes. ARM would need for all devices(typically, the devices on external PCI bus).
> > > > I guess rte_smp_rmb may not be the correct abstraction. So we need more of
> > > > rte_rmb() as we need only non smp variant on IO side. I guess then it make sense to
> > > > create new abstraction in eal with following variants so that each arch
> > > > gets opportunity to make what it makes sense that specific platform
> > > >
> > > > rte_readb_relaxed
> > > > rte_readw_relaxed
> > > > rte_readl_relaxed
> > > > rte_readq_relaxed
> > > > rte_writeb_relaxed
> > > > rte_writew_relaxed
> > > > rte_writel_relaxed
> > > > rte_writeq_relaxed
> > > > rte_readb
> > > > rte_readw
> > > > rte_readl
> > > > rte_readq
> > > > rte_writeb
> > > > rte_writew
> > > > rte_writel
> > > > rte_writeq
> > > >
> > > > Thoughts ?
> > > >
> > >
> > > That seems like a lot of API calls!
> > > Perhaps you can clarify - why would the rte_smp_rmb() not work for you?
> >
> > Currently arm64 mapped DMB as rte_smp_rmb() for smp case.
> >
> > Ideally for io barrier and non smp case, we need to map it as DSB and it is
> > bit heavier than DMB
>
> Ok, so you need some new macro, like rte_io_(r|w)mb or so, that would expand into dmb
> for ARM, correct?
The io barrier expands to dsb.
http://lxr.free-electrons.com/source/arch/arm64/include/asm/io.h#L110
>
> >
> > The linux kernel arm64 mappings
> > http://lxr.free-electrons.com/source/arch/arm64/include/asm/io.h#L142
> >
> > DMB vs DSB
> > https://community.arm.com/thread/3833
> >
> > The relaxed one are without any barriers.(the use case like accessing on
> > chip peripherals may need only relaxed versions)
> >
> > Thoughts on new rte EAL abstraction?
>
> Looks like a lot of macros but if you guys think that would help - NP with that :)
I don't have strong opinion here. If there is concern on a lot of macros
then, I can introduce only "rte_io_(r|w)mb" instead of read[b|w|l|q]/write[b|w|l|q]/relaxed.
let me know?
> Again, in that case we probably can get rid of driver specific pci reg read/write defines.
Yes. But, That's going to have a lot of change :-(
If there is no objection then I will introduce
"read[b|w|l|q]/write[b|w|l|q]/relaxed" and then change all external pcie drivers
with new macros.
>
> Konstantin
>
> >
> > >
> > > /Bruce
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Jerin Jacob @ 2016-11-30 21:01 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ananyev, Konstantin, Harish Patil, dev, Rahul Lakkireddy,
Stephen Hurd, Jan Medala, Jakub Palider, John Daley,
Adrien Mazarguil, Alejandro Lucero, Rasesh Mody, Jacob, Jerin,
Yuanhan Liu, Yong Wang, Kulasek, TomaszX, olivier.matz
In-Reply-To: <3517413.XL3bTbAyaC@xps13>
On Wed, Nov 30, 2016 at 07:26:36PM +0100, Thomas Monjalon wrote:
> 2016-11-30 17:42, Ananyev, Konstantin:
> > > >Please, we need a comment for each driver saying
> > > >"it is OK, we do not need any checksum preparation for TSO"
> > > >or
> > > >"yes we have to implement tx_prepare or TSO will not work in this mode"
> > > >
> > >
> > > qede PMD doesn’t currently support TSO yet, it only supports Tx TCP/UDP/IP
> > > csum offloads.
> > > So Tx preparation isn’t applicable. So as of now -
> > > "it is OK, we do not need any checksum preparation for TSO"
> >
> > Thanks for the answer.
> > Though please note that it not only for TSO.
>
> Oh yes, sorry, my wording was incorrect.
> We need to know if any checksum preparation is needed prior
> offloading its final computation to the hardware or driver.
> So the question applies to TSO and simple checksum offload.
>
> We are still waiting answers for
> bnxt, cxgbe, ena, nfp, thunderx, virtio and vmxnet3.
The thunderx devices don't need pseudo header checksum
in the packet for TSO or TX checksum offload. So..
"it is OK, we do not need any checksum preparation for TSO"
>
> > This is for any TX offload for which the upper layer SW would have
> > to modify the contents of the packet.
> > Though as I can see for qede neither PKT_TX_IP_CKSUM or PKT_TX_TCP_CKSUM
> > exhibits any extra requirements for the user.
> > Is that correct?
>
^ permalink raw reply
* Hyper-v support
From: Varun @ 2016-11-30 22:34 UTC (permalink / raw)
To: dev
Hi,
I would like to know if the latest DPDK (16.11) supports hyper-v?
I couldn't find any conclusive evidence online or in dpdk roadmap. Is it
likely that we see it in 17.05?
--
Regards,
Varun
^ permalink raw reply
* Re: [PATCH v2 3/7] pci: Pass rte_pci_addr to functions instead of separate args
From: Shreyansh Jain @ 2016-12-01 6:26 UTC (permalink / raw)
To: Ben Walker; +Cc: dev
In-Reply-To: <1479931644-78960-3-git-send-email-benjamin.walker@intel.com>
Hello Ben,
On Thursday 24 November 2016 01:37 AM, Ben Walker wrote:
> Instead of passing domain, bus, devid, func, just pass
> an rte_pci_addr.
>
> Signed-off-by: Ben Walker <benjamin.walker@intel.com>
> ---
> lib/librte_eal/linuxapp/eal/eal_pci.c | 32 +++++++++++++-------------------
> 1 file changed, 13 insertions(+), 19 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
> index 876ba38..073af5f 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> @@ -267,8 +267,7 @@ pci_parse_sysfs_resource(const char *filename, struct rte_pci_device *dev)
>
> /* Scan one pci sysfs entry, and fill the devices list from it. */
> static int
> -pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
> - uint8_t devid, uint8_t function)
> +pci_scan_one(const char *dirname, const struct rte_pci_addr *addr)
> {
> char filename[PATH_MAX];
> unsigned long tmp;
> @@ -281,10 +280,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
> return -1;
>
> memset(dev, 0, sizeof(*dev));
> - dev->addr.domain = domain;
> - dev->addr.bus = bus;
> - dev->addr.devid = devid;
> - dev->addr.function = function;
> + dev->addr = *addr;
>
> /* get vendor id */
> snprintf(filename, sizeof(filename), "%s/vendor", dirname);
> @@ -429,16 +425,14 @@ pci_update_device(const struct rte_pci_addr *addr)
> pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
> addr->function);
>
> - return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> - addr->function);
> + return pci_scan_one(filename, addr);
> }
>
> /*
> * split up a pci address into its constituent parts.
> */
> static int
> -parse_pci_addr_format(const char *buf, int bufsize, uint16_t *domain,
> - uint8_t *bus, uint8_t *devid, uint8_t *function)
> +parse_pci_addr_format(const char *buf, int bufsize, struct rte_pci_addr *addr)
> {
> /* first split on ':' */
> union splitaddr {
> @@ -466,10 +460,10 @@ parse_pci_addr_format(const char *buf, int bufsize, uint16_t *domain,
>
> /* now convert to int values */
> errno = 0;
> - *domain = (uint16_t)strtoul(splitaddr.domain, NULL, 16);
> - *bus = (uint8_t)strtoul(splitaddr.bus, NULL, 16);
> - *devid = (uint8_t)strtoul(splitaddr.devid, NULL, 16);
> - *function = (uint8_t)strtoul(splitaddr.function, NULL, 10);
> + addr->domain = (uint16_t)strtoul(splitaddr.domain, NULL, 16);
> + addr->bus = (uint8_t)strtoul(splitaddr.bus, NULL, 16);
> + addr->devid = (uint8_t)strtoul(splitaddr.devid, NULL, 16);
> + addr->function = (uint8_t)strtoul(splitaddr.function, NULL, 10);
> if (errno != 0)
> goto error;
>
> @@ -490,8 +484,7 @@ rte_eal_pci_scan(void)
> struct dirent *e;
> DIR *dir;
> char dirname[PATH_MAX];
> - uint16_t domain;
> - uint8_t bus, devid, function;
> + struct rte_pci_addr addr;
>
> dir = opendir(pci_get_sysfs_path());
> if (dir == NULL) {
> @@ -500,20 +493,21 @@ rte_eal_pci_scan(void)
> return -1;
> }
>
> +
> while ((e = readdir(dir)) != NULL) {
> if (e->d_name[0] == '.')
> continue;
>
> - if (parse_pci_addr_format(e->d_name, sizeof(e->d_name), &domain,
> - &bus, &devid, &function) != 0)
> + if (parse_pci_addr_format(e->d_name, sizeof(e->d_name), &addr) != 0)
> continue;
>
> snprintf(dirname, sizeof(dirname), "%s/%s",
> pci_get_sysfs_path(), e->d_name);
> - if (pci_scan_one(dirname, domain, bus, devid, function) < 0)
> + if (pci_scan_one(dirname, &addr) < 0)
> goto error;
> }
> closedir(dir);
> +
> return 0;
>
> error:
>
Do you mind if I use this patch directly as part of my patchset for bus
Model? I was doing a similar change to make the pci_scan_one simpler
(and pass along a new argument)..
-
Shreyansh
^ permalink raw reply
* [PATCH 0/3] maintainers: minor updates to virtio and stable
From: Yuanhan Liu @ 2016-12-01 7:06 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, John McNamara, Yuanhan Liu
---
Yuanhan Liu (3):
maintainers: update virtio maintainer
maintainers: update virtio section name
maintainers: add stable mailing list
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.9.0
^ permalink raw reply
* [PATCH 1/3] maintainers: update virtio maintainer
From: Yuanhan Liu @ 2016-12-01 7:06 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, John McNamara, Yuanhan Liu, Huawei Xie
In-Reply-To: <1480575999-14453-1-git-send-email-yuanhan.liu@linux.intel.com>
Huawei has left DPDK team for months, and he hasn't showed up since
then. Remove him.
Cc: Huawei Xie <huawei.xie@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 26d9590..cc1ab68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -365,7 +365,6 @@ F: drivers/net/qede/
F: doc/guides/nics/qede.rst
RedHat virtio
-M: Huawei Xie <huawei.xie@intel.com>
M: Yuanhan Liu <yuanhan.liu@linux.intel.com>
T: git://dpdk.org/next/dpdk-next-virtio
F: drivers/net/virtio/
--
1.9.0
^ permalink raw reply related
* [PATCH 2/3] maintainers: update virtio section name
From: Yuanhan Liu @ 2016-12-01 7:06 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, John McNamara, Yuanhan Liu
In-Reply-To: <1480575999-14453-1-git-send-email-yuanhan.liu@linux.intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
hmm.., maybe we could seperate lib vhost and virtio pmd, into two
different sections?
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cc1ab68..3df1754 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -364,7 +364,7 @@ M: Sony Chacko <sony.chacko@qlogic.com>
F: drivers/net/qede/
F: doc/guides/nics/qede.rst
-RedHat virtio
+Virtio PMD and vhost lib
M: Yuanhan Liu <yuanhan.liu@linux.intel.com>
T: git://dpdk.org/next/dpdk-next-virtio
F: drivers/net/virtio/
--
1.9.0
^ permalink raw reply related
* [PATCH 3/3] maintainers: add stable mailing list
From: Yuanhan Liu @ 2016-12-01 7:06 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, John McNamara, Yuanhan Liu
In-Reply-To: <1480575999-14453-1-git-send-email-yuanhan.liu@linux.intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3df1754..076e86c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -35,6 +35,7 @@ F: scripts/test-build.sh
Stable Branches
---------------
T: git://dpdk.org/dpdk-stable
+M: stable@dpdk.org
Security Issues
---------------
--
1.9.0
^ permalink raw reply related
* Re: [PATCH v12 0/6] add Tx preparation
From: Adrien Mazarguil @ 2016-12-01 7:15 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Thomas Monjalon, dev@dpdk.org, Rahul Lakkireddy, Stephen Hurd,
Jan Medala, Jakub Palider, John Daley, Alejandro Lucero,
Harish Patil, Rasesh Mody, Jerin Jacob, Yuanhan Liu, Yong Wang,
Kulasek, TomaszX, olivier.matz@6wind.com
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E20C8@irsmsx105.ger.corp.intel.com>
Hi Konstantin,
On Wed, Nov 30, 2016 at 10:54:50AM +0000, Ananyev, Konstantin wrote:
[...]
> > Something is definitely needed here, and only PMDs can provide it. I think
> > applications should not have to clear checksum fields or initialize them to
> > some magic value, same goes for any other offload or hardware limitation
> > that needs to be worked around.
> >
> > tx_prep() is one possible answer to this issue, however as mentioned in the
> > original patch it can be very expensive if exposed by the PMD.
> >
> > Another issue I'm more concerned about is the way limitations are managed
> > (struct rte_eth_desc_lim). While not officially tied to tx_prep(), this
> > structure contains new fields that are only relevant to a few devices, and I
> > fear it will keep growing with each new hardware quirk to manage, breaking
> > ABIs in the process.
>
> Well, if some new HW capability/limitation would arise and we'd like to support
> it in DPDK, then yes we probably would need to think how to incorporate it here.
> Do you have anything particular in mind here?
Nothing in particular, so for the sake of the argument, let's suppose that I
would like to add a field to expose some limitation that only applies to my
PMD during TX but looks generic enough to make sense, e.g. maximum packet
size when VLAN tagging is requested. PMDs are free to set that field to some
special value (say, 0) if they do not care.
Since that field exists however, conscious applications should check its
value for each packet that needs to be transmitted. This extra code causes a
slowdown just by sitting in the data path. Since it is not the only field in
that structure, the performance impact can be significant.
Even though this code is inside applications, it remains unfair to PMDs for
which these tests are irrelevant. This problem is identified and addressed
by tx_prepare().
Thanks to tx_prepare(), these checks are moved back into PMDs where they
belong. PMDs that do not need them do not have to provide support for
tx_prepare() and do not suffer any performance impact as result;
applications only have to make sure tx_prepare() is always called at some
point before tx_burst().
Once you reach this stage, you've effectively made tx_prepare() mandatory
before tx_burst(). If some bug occurs, then perhaps you forgot to call
tx_prepare(), you just need to add it. The total cost for doing TX is
therefore tx_prepare() + tx_burst().
I'm perhaps a bit pessimistic mind you, but I do not think tx_prepare() will
remain optional for long. Sure, PMDs that do not implement it do not care,
I'm focusing on applications, for which the performance impact of calling
tx_prepare() followed by tx_burst() is higher than a single tx_burst()
performing all the necessary preparation at once.
[...]
> > Following the same logic, why can't such a thing be made part of the TX
> > burst function as well (through a direct call to rte_phdr_cksum_fix()
> > whenever necessary). From an application standpoint, what are the advantages
> > of having to:
> >
> > if (tx_prep()) // iterate and update mbufs as needed
> > tx_burst(); // iterate and send
> >
> > Compared to:
> >
> > tx_burst(); // iterate, update as needed and send
>
> I think that was discussed extensively quite a lot previously here:
> As Thomas already replied - main motivation is to allow user
> to execute them on different stages of packet TX pipeline,
> and probably on different cores.
> I think that provides better flexibility to the user to when/where
> do these preparations and hopefully would lead to better performance.
And I agree, I think this use case is valid but does not warrant such a high
penalty when your application does not need that much flexibility. Simple
(yet conscious) applications need the highest performance. Complex ones as
you described already suffer quite a bit from IPCs and won't mind a couple
of extra CPU cycles right?
Yes they will, therefore we need a method that satisfies both cases.
As a possible solution, a special mbuf flag could be added to each mbuf
having gone through tx_prepare(). That way, tx_burst() could skip some
checks and things it would otherwise have done.
Another possibility, telling the PMD first that you always intend to use
tx_prepare() and getting a simpler/faster tx_burst() callback as a result.
> Though, if you or any other PMD developer/maintainer would prefer
> for particular PMD to combine both functionalities into tx_burst() and
> keep tx_prep() as NOP - this is still possible too.
Whether they implement it or not, this issue does not impact PMDs anyway, we
should probably ask DPDK application developers instead.
[...]
> > For both mlx4 and mlx5 then,
> > "it is OK, we do not need any checksum preparation for TSO".
> >
> > Actually I do not think we'll ever need tx_prep() unless we add our own
> > quirks to struct rte_eth_desc_lim (and friends) which are currently quietly
> > handled by TX burst functions.
>
> Ok, so MLX PMD is not affected by these changes and tx_prep for MLX can be safely
> set to NULL, correct?
Correct, actually the rest of this message should be in a separate
thread. From the MLX side, there is no issue with tx_prepare().
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Adrien Mazarguil @ 2016-12-01 7:19 UTC (permalink / raw)
To: Kulasek, TomaszX
Cc: Thomas Monjalon, dev@dpdk.org, Ananyev, Konstantin,
olivier.matz@6wind.com
In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F57A50@IRSMSX102.ger.corp.intel.com>
Hi Tomasz,
On Wed, Nov 30, 2016 at 10:30:54AM +0000, Kulasek, TomaszX wrote:
[...]
> > > In my opinion the second approach is both faster to applications and
> > > more friendly from a usability perspective, am I missing something
> > obvious?
> >
> > I think it was not clearly explained in this patchset, but this is my
> > understanding:
> > tx_prepare and tx_burst can be called at different stages of a pipeline,
> > on different cores.
>
> Yes, this API is intended to be used optionaly, not only just before tx_burst.
>
> 1. Separating both stages:
> a) We may have a control over burst (packet content, validation) when needed.
> b) For invalid packets we may restore them or do some another task if needed (even on early stage of processing).
> c) Tx burst keep as simple as it should be.
>
> 2. Joining the functionality of tx_prepare and tx_burst have some disadvantages:
> a) When packet is invalid it cannot be restored by application should be dropped.
> b) Tx burst needs to modify the content of the packet.
> c) We have no way to eliminate overhead of preparation (tx_prepare) for the application where performance is a key.
>
> 3. Using tx callbacks
> a) We still need to have different implementations for different devices.
> b) The overhead in performance (comparing to the pair tx_prepare/tx_burst) will not be better while both ways uses very similar mechanism.
>
> In addition, tx_prepare mechanism can be turned off by compilation flag (as discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory dereference and check can have significant impact on performance).
Thanks for the reminder, also I've missed v12 for some reason and still
thought rte_phdr_cksum_fix() was some generic function that applications had
to use directly regardless.
Although I agree with your description, I still think there is an issue,
please see my reply to Konstantin [1].
[1] http://dpdk.org/ml/archives/dev/2016-December/050970.html
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Rahul Lakkireddy @ 2016-12-01 8:24 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, Stephen Hurd, Jan Medala, Jakub Palider, John Daley,
Adrien Mazarguil, Alejandro Lucero, Harish Patil, Rasesh Mody,
Jerin Jacob, Yuanhan Liu, Yong Wang, Tomasz Kulasek,
konstantin.ananyev@intel.com, olivier.matz@6wind.com
In-Reply-To: <8317180.L80Qf11uiu@xps13>
Hi Thomas,
On Monday, November 11/28/16, 2016 at 16:33:06 +0530, Thomas Monjalon wrote:
> We need attention of every PMD developers on this thread.
>
> Reminder of what Konstantin suggested:
> "
> - if the PMD supports TX offloads AND
> - if to be able use any of these offloads the upper layer SW would have to:
> * modify the contents of the packet OR
> * obey HW specific restrictions
> then it is a PMD developer responsibility to provide tx_prep() that would implement
> expected modifications of the packet contents and restriction checks.
> Otherwise, tx_prep() implementation is not required and can be safely set to NULL.
> "
>
> I copy/paste also my previous conclusion:
>
> Before txprep, there is only one API: the application must prepare the
> packets checksum itself (get_psd_sum in testpmd).
> With txprep, the application have 2 choices: keep doing the job itself
> or call txprep which calls a PMD-specific function.
> The question is: does non-Intel drivers need a checksum preparation for TSO?
> Will it behave well if txprep does nothing in these drivers?
>
> When looking at the code, most of drivers handle the TSO flags.
> But it is hard to know whether they rely on the pseudo checksum or not.
>
> git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' drivers/net/
>
> drivers/net/bnxt/bnxt_txr.c
> drivers/net/cxgbe/sge.c
> drivers/net/e1000/em_rxtx.c
> drivers/net/e1000/igb_rxtx.c
> drivers/net/ena/ena_ethdev.c
> drivers/net/enic/enic_rxtx.c
> drivers/net/fm10k/fm10k_rxtx.c
> drivers/net/i40e/i40e_rxtx.c
> drivers/net/ixgbe/ixgbe_rxtx.c
> drivers/net/mlx4/mlx4.c
> drivers/net/mlx5/mlx5_rxtx.c
> drivers/net/nfp/nfp_net.c
> drivers/net/qede/qede_rxtx.c
> drivers/net/thunderx/nicvf_rxtx.c
> drivers/net/virtio/virtio_rxtx.c
> drivers/net/vmxnet3/vmxnet3_rxtx.c
>
> Please, we need a comment for each driver saying
> "it is OK, we do not need any checksum preparation for TSO"
> or
> "yes we have to implement tx_prepare or TSO will not work in this mode"
For CXGBE PMD, "it is OK, we do not need any checksum preparation for
TSO".
Thanks,
Rahul
^ permalink raw reply
* Re: [PATCH 01/22] ethdev: introduce generic flow API
From: Adrien Mazarguil @ 2016-12-01 8:36 UTC (permalink / raw)
To: Kevin Traynor
Cc: dev, Thomas Monjalon, Pablo de Lara, Olivier Matz, sugesh.chandra
In-Reply-To: <59393e58-6c85-d2e5-1aab-a721fe9c933e@redhat.com>
Hi Kevin,
On Wed, Nov 30, 2016 at 05:47:17PM +0000, Kevin Traynor wrote:
> Hi Adrien,
>
> On 11/16/2016 04:23 PM, Adrien Mazarguil wrote:
> > This new API supersedes all the legacy filter types described in
> > rte_eth_ctrl.h. It is slightly higher level and as a result relies more on
> > PMDs to process and validate flow rules.
> >
> > Benefits:
> >
> > - A unified API is easier to program for, applications do not have to be
> > written for a specific filter type which may or may not be supported by
> > the underlying device.
> >
> > - The behavior of a flow rule is the same regardless of the underlying
> > device, applications do not need to be aware of hardware quirks.
> >
> > - Extensible by design, API/ABI breakage should rarely occur if at all.
> >
> > - Documentation is self-standing, no need to look up elsewhere.
> >
> > Existing filter types will be deprecated and removed in the near future.
>
> I'd suggest to add a deprecation notice to deprecation.rst, ideally with
> a target release.
Will do, not a sure about the target release though. It seems a bit early
since no PMD really supports this API yet.
[...]
> > diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
> > new file mode 100644
> > index 0000000..064963d
> > --- /dev/null
> > +++ b/lib/librte_ether/rte_flow.c
> > @@ -0,0 +1,159 @@
> > +/*-
> > + * BSD LICENSE
> > + *
> > + * Copyright 2016 6WIND S.A.
> > + * Copyright 2016 Mellanox.
>
> There's Mellanox copyright but you are the only signed-off-by - is that
> right?
Yes, I'm the primary maintainer for Mellanox PMDs and this API was designed
on their behalf to expose several features from mlx4/mlx5 as the existing
filter types had too many limitations.
[...]
> > +/* Get generic flow operations structure from a port. */
> > +const struct rte_flow_ops *
> > +rte_flow_ops_get(uint8_t port_id, struct rte_flow_error *error)
> > +{
> > + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > + const struct rte_flow_ops *ops;
> > + int code;
> > +
> > + if (unlikely(!rte_eth_dev_is_valid_port(port_id)))
> > + code = ENODEV;
> > + else if (unlikely(!dev->dev_ops->filter_ctrl ||
> > + dev->dev_ops->filter_ctrl(dev,
> > + RTE_ETH_FILTER_GENERIC,
> > + RTE_ETH_FILTER_GET,
> > + &ops) ||
> > + !ops))
> > + code = ENOTSUP;
> > + else
> > + return ops;
> > + rte_flow_error_set(error, code, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> > + NULL, rte_strerror(code));
> > + return NULL;
> > +}
> > +
>
> Is it expected that the application or pmd will provide locking between
> these functions if required? I think it's going to have to be the app.
Locking is indeed expected to be performed by applications. This API only
documents places where locking would make sense if necessary and expected
behavior.
Like all control path APIs, this one assumes a single control thread.
Applications must take the necessary precautions.
[...]
> > +/**
> > + * Flow rule attributes.
> > + *
> > + * Priorities are set on two levels: per group and per rule within groups.
> > + *
> > + * Lower values denote higher priority, the highest priority for both levels
> > + * is 0, so that a rule with priority 0 in group 8 is always matched after a
> > + * rule with priority 8 in group 0.
> > + *
> > + * Although optional, applications are encouraged to group similar rules as
> > + * much as possible to fully take advantage of hardware capabilities
> > + * (e.g. optimized matching) and work around limitations (e.g. a single
> > + * pattern type possibly allowed in a given group).
> > + *
> > + * Group and priority levels are arbitrary and up to the application, they
> > + * do not need to be contiguous nor start from 0, however the maximum number
> > + * varies between devices and may be affected by existing flow rules.
> > + *
> > + * If a packet is matched by several rules of a given group for a given
> > + * priority level, the outcome is undefined. It can take any path, may be
> > + * duplicated or even cause unrecoverable errors.
>
> I get what you are trying to do here wrt supporting multiple
> pmds/hardware implementations and it's a good idea to keep it flexible.
>
> Given that the outcome is undefined, it would be nice that the
> application has a way of finding the specific effects for verification
> and debugging.
Right, however it was deemed a bit difficult to manage in many cases hence
the vagueness.
For example, suppose two rules with the same group and priority, one
matching any IPv4 header, the other one any UDP header:
- TCPv4 packets => rule #1.
- UDPv6 packets => rule #2.
- UDPv4 packets => both?
That last one is perhaps invalid, checking that some unspecified protocol
combination does not overlap is expensive and may miss corner cases, even
assuming this is not an issue, what if the application guarantees that no
UDPv4 packets can ever hit that rule?
Suggestions are welcome though, perhaps we can refine the description.
> > + *
> > + * Note that support for more than a single group and priority level is not
> > + * guaranteed.
> > + *
> > + * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).
> > + *
> > + * Several pattern items and actions are valid and can be used in both
> > + * directions. Those valid for only one direction are described as such.
> > + *
> > + * Specifying both directions at once is not recommended but may be valid in
> > + * some cases, such as incrementing the same counter twice.
> > + *
> > + * Not specifying any direction is currently an error.
> > + */
> > +struct rte_flow_attr {
> > + uint32_t group; /**< Priority group. */
> > + uint32_t priority; /**< Priority level within group. */
> > + uint32_t ingress:1; /**< Rule applies to ingress traffic. */
> > + uint32_t egress:1; /**< Rule applies to egress traffic. */
> > + uint32_t reserved:30; /**< Reserved, must be zero. */
> > +};
[...]
> > +/**
> > + * RTE_FLOW_ITEM_TYPE_VF
> > + *
> > + * Matches packets addressed to a virtual function ID of the device.
> > + *
> > + * If the underlying device function differs from the one that would
> > + * normally receive the matched traffic, specifying this item prevents it
> > + * from reaching that device unless the flow rule contains a VF
> > + * action. Packets are not duplicated between device instances by default.
> > + *
> > + * - Likely to return an error or never match any traffic if this causes a
> > + * VF device to match traffic addressed to a different VF.
> > + * - Can be specified multiple times to match traffic addressed to several
> > + * specific VFs.
> > + * - Can be combined with a PF item to match both PF and VF traffic.
> > + *
> > + * A zeroed mask can be used to match any VF.
>
> can you refer explicitly to id
If you mean "VF" to "VF ID" then yes, will do it for v2.
> > + */
> > +struct rte_flow_item_vf {
> > + uint32_t id; /**< Destination VF ID. */
> > +};
[...]
> > +/**
> > + * Matching pattern item definition.
> > + *
> > + * A pattern is formed by stacking items starting from the lowest protocol
> > + * layer to match. This stacking restriction does not apply to meta items
> > + * which can be placed anywhere in the stack with no effect on the meaning
> > + * of the resulting pattern.
> > + *
> > + * A stack is terminated by a END item.
> > + *
> > + * The spec field should be a valid pointer to a structure of the related
> > + * item type. It may be set to NULL in many cases to use default values.
> > + *
> > + * Optionally, last can point to a structure of the same type to define an
> > + * inclusive range. This is mostly supported by integer and address fields,
> > + * may cause errors otherwise. Fields that do not support ranges must be set
> > + * to the same value as their spec counterparts.
> > + *
> > + * By default all fields present in spec are considered relevant.* This
>
> typo "*"
No, that's an asterisk for a footnote below. Perhaps it is a bit unusual,
would something like "[1]" look better?
> > + * behavior can be altered by providing a mask structure of the same type
> > + * with applicable bits set to one. It can also be used to partially filter
> > + * out specific fields (e.g. as an alternate mean to match ranges of IP
> > + * addresses).
> > + *
> > + * Note this is a simple bit-mask applied before interpreting the contents
> > + * of spec and last, which may yield unexpected results if not used
> > + * carefully. For example, if for an IPv4 address field, spec provides
> > + * 10.1.2.3, last provides 10.3.4.5 and mask provides 255.255.0.0, the
> > + * effective range is 10.1.0.0 to 10.3.255.255.
> > + *
See footnote below:
> > + * * The defaults for data-matching items such as IPv4 when mask is not
> > + * specified actually depend on the underlying implementation since only
> > + * recognized fields can be taken into account.
> > + */
> > +struct rte_flow_item {
> > + enum rte_flow_item_type type; /**< Item type. */
> > + const void *spec; /**< Pointer to item specification structure. */
> > + const void *last; /**< Defines an inclusive range (spec to last). */
> > + const void *mask; /**< Bit-mask applied to spec and last. */
> > +};
> > +
> > +/**
> > + * Action types.
> > + *
> > + * Each possible action is represented by a type. Some have associated
> > + * configuration structures. Several actions combined in a list can be
> > + * affected to a flow rule. That list is not ordered.
> > + *
> > + * They fall in three categories:
> > + *
> > + * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
> > + * processing matched packets by subsequent flow rules, unless overridden
> > + * with PASSTHRU.
> > + *
> > + * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
> > + * for additional processing by subsequent flow rules.
> > + *
> > + * - Other non terminating meta actions that do not affect the fate of
> > + * packets (END, VOID, MARK, FLAG, COUNT).
> > + *
> > + * When several actions are combined in a flow rule, they should all have
> > + * different types (e.g. dropping a packet twice is not possible). The
> > + * defined behavior is for PMDs to only take into account the last action of
> > + * a given type found in the list. PMDs still perform error checking on the
> > + * entire list.
>
> why do you define that the pmd will interpret multiple same type rules
> in this way...would it not make more sense for the pmd to just return
> EINVAL for an invalid set of rules? It seems more transparent for the
> application.
Well, I had to define something as a default. The reason is that any number
of VOID actions may specified and did not want that to be a special case in
order to keep PMD parsers as simple as possible. I'll settle for EINVAL (or
some other error) if at least one PMD maintainer other than Nelio who
intends to implement this API is not convinced by this explanation, all
right?
[...]
> > +/**
> > + * RTE_FLOW_ACTION_TYPE_MARK
> > + *
> > + * Attaches a 32 bit value to packets.
> > + *
> > + * This value is arbitrary and application-defined. For compatibility with
> > + * FDIR it is returned in the hash.fdir.hi mbuf field. PKT_RX_FDIR_ID is
> > + * also set in ol_flags.
> > + */
> > +struct rte_flow_action_mark {
> > + uint32_t id; /**< 32 bit value to return with packets. */
> > +};
>
> One use case I thought we would be able to do for OVS is classification
> in hardware and the unique flow id is sent with the packet to software.
> But in OVS the ufid is 128 bits, so it means we can't and there is still
> the miniflow extract overhead. I'm not sure if there is a practical way
> around this.
>
> Sugesh (cc'd) has looked at this before and may be able to comment or
> correct me.
Yes, we settled on 32 bit because currently no known hardware implementation
supports more than this. If that changes, another action with a larger type
shall be provided (no ABI breakage).
Also since even 64 bit would not be enough for the use case you mention,
there is no choice but use this as an indirect value (such as an array or
hash table index/value).
[...]
> > +/**
> > + * RTE_FLOW_ACTION_TYPE_RSS
> > + *
> > + * Similar to QUEUE, except RSS is additionally performed on packets to
> > + * spread them among several queues according to the provided parameters.
> > + *
> > + * Note: RSS hash result is normally stored in the hash.rss mbuf field,
> > + * however it conflicts with the MARK action as they share the same
> > + * space. When both actions are specified, the RSS hash is discarded and
> > + * PKT_RX_RSS_HASH is not set in ol_flags. MARK has priority. The mbuf
> > + * structure should eventually evolve to store both.
> > + *
> > + * Terminating by default.
> > + */
> > +struct rte_flow_action_rss {
> > + const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
> > + uint16_t queues; /**< Number of entries in queue[]. */
> > + uint16_t queue[]; /**< Queues indices to use. */
>
> I'd try and avoid queue and queues - someone will say "huh?" when
> reading code. s/queues/num ?
Agreed, will update for v2.
> > +};
> > +
> > +/**
> > + * RTE_FLOW_ACTION_TYPE_VF
> > + *
> > + * Redirects packets to a virtual function (VF) of the current device.
> > + *
> > + * Packets matched by a VF pattern item can be redirected to their original
> > + * VF ID instead of the specified one. This parameter may not be available
> > + * and is not guaranteed to work properly if the VF part is matched by a
> > + * prior flow rule or if packets are not addressed to a VF in the first
> > + * place.
>
> Not clear what you mean by "not guaranteed to work if...". Please return
> fail when this action is used if this is not going to work.
Again, this is a case where it is difficult for a PMD to determine if the
entire list of flow rules makes sense. Perhaps it does, perhaps whatever
goes through has already been filtered out of possible issues.
Here the documentation states the precautions an application should take to
guarantee it will work as intended. Perhaps it can be reworded (any
suggestion?), but a PMD can certainly not provide any strong guarantee.
> > + *
> > + * Terminating by default.
> > + */
> > +struct rte_flow_action_vf {
> > + uint32_t original:1; /**< Use original VF ID if possible. */
> > + uint32_t reserved:31; /**< Reserved, must be zero. */
> > + uint32_t id; /**< VF ID to redirect packets to. */
> > +};
[...]
> > +/**
> > + * Check whether a flow rule can be created on a given port.
> > + *
> > + * While this function has no effect on the target device, the flow rule is
> > + * validated against its current configuration state and the returned value
> > + * should be considered valid by the caller for that state only.
> > + *
> > + * The returned value is guaranteed to remain valid only as long as no
> > + * successful calls to rte_flow_create() or rte_flow_destroy() are made in
> > + * the meantime and no device parameter affecting flow rules in any way are
> > + * modified, due to possible collisions or resource limitations (although in
> > + * such cases EINVAL should not be returned).
> > + *
> > + * @param port_id
> > + * Port identifier of Ethernet device.
> > + * @param[in] attr
> > + * Flow rule attributes.
> > + * @param[in] pattern
> > + * Pattern specification (list terminated by the END pattern item).
> > + * @param[in] actions
> > + * Associated actions (list terminated by the END action).
> > + * @param[out] error
> > + * Perform verbose error reporting if not NULL.
> > + *
> > + * @return
> > + * 0 if flow rule is valid and can be created. A negative errno value
> > + * otherwise (rte_errno is also set), the following errors are defined:
> > + *
> > + * -ENOSYS: underlying device does not support this functionality.
> > + *
> > + * -EINVAL: unknown or invalid rule specification.
> > + *
> > + * -ENOTSUP: valid but unsupported rule specification (e.g. partial
> > + * bit-masks are unsupported).
> > + *
> > + * -EEXIST: collision with an existing rule.
> > + *
> > + * -ENOMEM: not enough resources.
> > + *
> > + * -EBUSY: action cannot be performed due to busy device resources, may
> > + * succeed if the affected queues or even the entire port are in a stopped
> > + * state (see rte_eth_dev_rx_queue_stop() and rte_eth_dev_stop()).
> > + */
> > +int
> > +rte_flow_validate(uint8_t port_id,
> > + const struct rte_flow_attr *attr,
> > + const struct rte_flow_item pattern[],
> > + const struct rte_flow_action actions[],
> > + struct rte_flow_error *error);
>
> Why not just use rte_flow_create() and get an error? Is it less
> disruptive to do a validate and find the rule cannot be created, than
> using a create directly?
The rationale can be found in the original RFC, which I'll convert to actual
documentation in v2. In short:
- Calling rte_flow_validate() before rte_flow_create() is useless since
rte_flow_create() also performs validation.
- We cannot possibly express a full static set of allowed flow rules, even
if we could, it usually depends on the current hardware configuration
therefore would not be static.
- rte_flow_validate() is thus provided as a replacement for capability
flags. It can be used to determine during initialization if the underlying
device can support the typical flow rules an application might want to
provide later and do something useful with that information (e.g. always
use software fallback due to HW limitations).
- rte_flow_validate() being a subset of rte_flow_create(), it is essentially
free to expose.
> > +
> > +/**
> > + * Create a flow rule on a given port.
> > + *
> > + * @param port_id
> > + * Port identifier of Ethernet device.
> > + * @param[in] attr
> > + * Flow rule attributes.
> > + * @param[in] pattern
> > + * Pattern specification (list terminated by the END pattern item).
> > + * @param[in] actions
> > + * Associated actions (list terminated by the END action).
> > + * @param[out] error
> > + * Perform verbose error reporting if not NULL.
> > + *
> > + * @return
> > + * A valid handle in case of success, NULL otherwise and rte_errno is set
> > + * to the positive version of one of the error codes defined for
> > + * rte_flow_validate().
> > + */
> > +struct rte_flow *
> > +rte_flow_create(uint8_t port_id,
> > + const struct rte_flow_attr *attr,
> > + const struct rte_flow_item pattern[],
> > + const struct rte_flow_action actions[],
> > + struct rte_flow_error *error);
>
> General question - are these functions threadsafe? In the OVS example
> you could have several threads wanting to create flow rules at the same
> time for same or different ports.
No they aren't, applications have to perform their own locking. The RFC (to
be converted to actual documentation in v2) says that:
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
- There is no provision for reentrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
> > +
> > +/**
> > + * Destroy a flow rule on a given port.
> > + *
> > + * Failure to destroy a flow rule handle may occur when other flow rules
> > + * depend on it, and destroying it would result in an inconsistent state.
> > + *
> > + * This function is only guaranteed to succeed if handles are destroyed in
> > + * reverse order of their creation.
>
> How can the application find this information out on error?
Without maintaining a list, they cannot. The specified case is the only
possible guarantee. That does not mean PMDs should not do their best to
destroy flow rules, only that ordering must remain consistent in case of
inability to destroy one.
What do you suggest?
> > + *
> > + * @param port_id
> > + * Port identifier of Ethernet device.
> > + * @param flow
> > + * Flow rule handle to destroy.
> > + * @param[out] error
> > + * Perform verbose error reporting if not NULL.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +int
> > +rte_flow_destroy(uint8_t port_id,
> > + struct rte_flow *flow,
> > + struct rte_flow_error *error);
> > +
> > +/**
> > + * Destroy all flow rules associated with a port.
> > + *
> > + * In the unlikely event of failure, handles are still considered destroyed
> > + * and no longer valid but the port must be assumed to be in an inconsistent
> > + * state.
> > + *
> > + * @param port_id
> > + * Port identifier of Ethernet device.
> > + * @param[out] error
> > + * Perform verbose error reporting if not NULL.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +int
> > +rte_flow_flush(uint8_t port_id,
> > + struct rte_flow_error *error);
>
> rte_flow_destroy_all() would be more descriptive (but breaks your style)
There are enough underscores as it is. I like flush, if enough people
complain we'll change it but it has to occur before the first public
release.
> > +
> > +/**
> > + * Query an existing flow rule.
> > + *
> > + * This function allows retrieving flow-specific data such as counters.
> > + * Data is gathered by special actions which must be present in the flow
> > + * rule definition.
>
> re last sentence, it would be good if you can put a link to
> RTE_FLOW_ACTION_TYPE_COUNT
Will do, I did not know how until very recently.
> > + *
> > + * @param port_id
> > + * Port identifier of Ethernet device.
> > + * @param flow
> > + * Flow rule handle to query.
> > + * @param action
> > + * Action type to query.
> > + * @param[in, out] data
> > + * Pointer to storage for the associated query data type.
>
> can this be anything other than rte_flow_query_count?
Likely in the future. I've only defined this one as a counterpart for
existing API functionality and because we wanted to expose it in mlx5.
> > + * @param[out] error
> > + * Perform verbose error reporting if not NULL.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +int
> > +rte_flow_query(uint8_t port_id,
> > + struct rte_flow *flow,
> > + enum rte_flow_action_type action,
> > + void *data,
> > + struct rte_flow_error *error);
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
>
> I don't see a way to dump all the rules for a port out. I think this is
> neccessary for degbugging. You could have a look through dpif.h in OVS
> and see how dpif_flow_dump_next() is used, it might be a good reference.
DPDK does not maintain flow rules and, depending on hardware capabilities
and level of compliance, PMDs do not necessarily do it either, particularly
since it requires space and application probably have a better method to
store these pointers for their own needs.
What you see here is only a PMD interface. Depending on applications needs,
generic helper functions built on top of these may be added to manage flow
rules in the future.
> Also, it would be nice if there were an api that would allow a test
> packet to be injected and traced for debugging - although I'm not
> exactly sure how well it could be traced. For reference:
> http://developers.redhat.com/blog/2016/10/12/tracing-packets-inside-open-vswitch/
Thanks for the link, I'm not sure how you'd do this either. Remember, as
generic as it looks, this interface is only meant to configure the
underlying device. You need to see it as one big offload, everything else
is left to applications.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH 00/22] Generic flow API (rte_flow)
From: Adrien Mazarguil @ 2016-12-01 8:39 UTC (permalink / raw)
To: Pei, Yulong
Cc: dev@dpdk.org, Thomas Monjalon, De Lara Guarch, Pablo,
Olivier Matz, Xing, Beilei
In-Reply-To: <188971FCDA171749BED5DA74ABF3E6F03946BD34@shsmsx102.ccr.corp.intel.com>
Hi Yulong,
On Mon, Nov 28, 2016 at 10:03:53AM +0000, Pei, Yulong wrote:
> Hi Adrien,
>
> I think that you already did test for your patchset, do you have any automated test scripts can be shared for validation since there did not have testpmd flow command documentation yet?
No automated script, at least not yet. I intend to submit v2 with extra
API documentation, testpmd commands with examples of expected behavior and
output, as well as fixes for the issues pointed out by Nelio.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH v12 0/6] add Tx preparation
From: Thomas Monjalon @ 2016-12-01 8:58 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: Ananyev, Konstantin, dev, Rahul Lakkireddy, Stephen Hurd,
Jan Medala, Jakub Palider, John Daley, Alejandro Lucero,
Harish Patil, Rasesh Mody, Jerin Jacob, Yuanhan Liu, Yong Wang,
Kulasek, TomaszX, olivier.matz
In-Reply-To: <20161201071518.GG10340@6wind.com>
2016-12-01 08:15, Adrien Mazarguil:
> I'm perhaps a bit pessimistic mind you, but I do not think tx_prepare() will
> remain optional for long. Sure, PMDs that do not implement it do not care,
> I'm focusing on applications, for which the performance impact of calling
> tx_prepare() followed by tx_burst() is higher than a single tx_burst()
> performing all the necessary preparation at once.
I agree that tx_prepare() should become mandatory shortly.
> [...]
> > > Following the same logic, why can't such a thing be made part of the TX
> > > burst function as well (through a direct call to rte_phdr_cksum_fix()
> > > whenever necessary). From an application standpoint, what are the advantages
> > > of having to:
> > >
> > > if (tx_prep()) // iterate and update mbufs as needed
> > > tx_burst(); // iterate and send
> > >
> > > Compared to:
> > >
> > > tx_burst(); // iterate, update as needed and send
> >
> > I think that was discussed extensively quite a lot previously here:
> > As Thomas already replied - main motivation is to allow user
> > to execute them on different stages of packet TX pipeline,
> > and probably on different cores.
> > I think that provides better flexibility to the user to when/where
> > do these preparations and hopefully would lead to better performance.
>
> And I agree, I think this use case is valid but does not warrant such a high
> penalty when your application does not need that much flexibility. Simple
> (yet conscious) applications need the highest performance. Complex ones as
> you described already suffer quite a bit from IPCs and won't mind a couple
> of extra CPU cycles right?
>
> Yes they will, therefore we need a method that satisfies both cases.
>
> As a possible solution, a special mbuf flag could be added to each mbuf
> having gone through tx_prepare(). That way, tx_burst() could skip some
> checks and things it would otherwise have done.
I like this idea!
^ permalink raw reply
* [PATCH 0/3] AESNI MB PMD updates
From: Pablo de Lara @ 2016-12-01 9:36 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara
The library used in AESNI MB PMD, Intel Multi Buffer Crypto for IPsec,
has been migrated to a new location, in github (see documentation patch
for the link).
The library has also been updated, so single crypto operations
are supported (cipher and authentication only). Therefore, the PMD
has been updated to support these operations.
This patchset depends on patchset "Add scatter-gather list capability to
Intel QuickAssist Technology driver" (http://dpdk.org/ml/archives/dev/2016-November/050947.html)
Pablo de Lara (3):
doc: update AESNI MB PMD guide
crypto/aesni_mb: add single operation functionality
doc: add missing supported algos for AESNI MB PMD
app/test/test_cryptodev.c | 34 ++++++++++++++++++++
app/test/test_cryptodev_aes_test_vectors.h | 36 ++++++++++++++-------
app/test/test_cryptodev_hash_test_vectors.h | 36 ++++++++++++++-------
doc/guides/cryptodevs/aesni_mb.rst | 14 +++------
doc/guides/rel_notes/release_17_02.rst | 8 +++++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 49 +++++++++++++++++++----------
6 files changed, 128 insertions(+), 49 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] doc: update AESNI MB PMD guide
From: Pablo de Lara @ 2016-12-01 9:36 UTC (permalink / raw)
To: declan.doherty; +Cc: dev, Pablo de Lara
In-Reply-To: <1480585017-63239-1-git-send-email-pablo.de.lara.guarch@intel.com>
The Intel(R) Multi Buffer Crypto library used in the AESNI MB PMD
has been moved to a new repository, in github.
This patch updates the link where it can be downloaded.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
doc/guides/cryptodevs/aesni_mb.rst | 10 +++-------
doc/guides/rel_notes/release_17_02.rst | 7 +++++++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index e812e95..b47cb6a 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -66,21 +66,17 @@ Limitations
* Cipher only is not supported.
* Only in-place is currently supported (destination address is the same as source address).
* Only supports session-oriented API implementation (session-less APIs are not supported).
-* Not performance tuned.
Installation
------------
To build DPDK with the AESNI_MB_PMD the user is required to download the mult-
-buffer library from `here <https://downloadcenter.intel.com/download/22972>`_
-and compile it on their user system before building DPDK. When building the
-multi-buffer library it is necessary to have YASM package installed and also
-requires the overriding of YASM path when building, as a path is hard coded in
-the Makefile of the release package.
+buffer library from `here <https://github.com/01org/intel-ipsec-mb>`_
+and compile it on their user system before building DPDK.
.. code-block:: console
- make YASM=/usr/bin/yasm
+ make
Initialization
--------------
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 873333b..4f666df 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -44,6 +44,13 @@ New Features
* Scatter-gather list (SGL) support.
+
+* **Updated the AESNI MB PMD.**
+
+ * The Intel(R) Multi Buffer Crypto for IPsec library used in
+ AESNI MB PMD has been moved to a new repository, in github.
+
+
Resolved Issues
---------------
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox