[dpdk-dev] [PATCH v6 2/5] lib/librte_ether: support l2 tunnel operations
Thomas Monjalon
thomas.monjalon at 6wind.com
Wed Mar 9 01:14:38 CET 2016
2016-03-08 14:53, Wenzhuo Lu:
> +/**
> + * l2 tunnel type.
> + */
> +enum rte_eth_l2_tunnel_type {
> + RTE_L2_TUNNEL_TYPE_NONE = 0,
> + RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_L2_TUNNEL_TYPE_MAX,
> +};
We already have rte_eth_tunnel_type.
Why this struct is in rte_eth_ctrl.h and not used with rte_eth_dev_filter_ctrl?
> + /**
> + * Config l2 tunnel ether type of an Ethernet device for filtering specific
> + * tunnel packets by ether type.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param l2_tunnel
> + * l2 tunnel configuration.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if port identifier is invalid.
> + * - (-ENOTSUP) if hardware doesn't support tunnel type.
> + */
> +int
> +rte_eth_dev_l2_tunnel_eth_type_conf(uint8_t port_id,
> + struct rte_eth_l2_tunnel *l2_tunnel);
> +
> + /**
> + * Enable/disable l2 tunnel offload functions. Include,
> + * 1, The ability of parsing a type of l2 tunnel of an Ethernet device.
> + * Filtering, forwarding and offloading this type of tunnel packets depend on
> + * this ability.
> + * 2, Stripping the l2 tunnel tag.
> + * 3, Insertion of the l2 tunnel tag.
> + * 4, Forwarding the packets based on the l2 tunnel tag.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param l2_tunnel
> + * l2 tunnel parameters.
> + * @param mask
> + * Indicate the offload function.
> + * @param en
> + * Enable or disable this function.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if port identifier is invalid.
> + * - (-ENOTSUP) if hardware doesn't support tunnel type.
> + */
> +int
> +rte_eth_dev_l2_tunnel_offload_set(uint8_t port_id,
> + struct rte_eth_l2_tunnel *l2_tunnel,
> + uint32_t mask,
> + uint8_t en);
> +
> + /**
> + * Add a filter for packet forwarding based on l2 tunnel tag of an Ethernet
> + * device for specific tunnel packets.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param l2_tunnel
> + * l2 tunnel configuration.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if port identifier is invalid.
> + * - (-ENOTSUP) if hardware doesn't support tunnel type.
> + */
> +int
> +rte_eth_dev_l2_tunnel_filter_add(uint8_t port_id,
> + struct rte_eth_l2_tunnel *l2_tunnel);
> +
> + /**
> + * Delete a filter for packet forwarding based on l2 tunnel tag of an Ethernet
> + * device for specific tunnel packets.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param l2_tunnel
> + * l2 tunnel configuration.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if port identifier is invalid.
> + * - (-ENOTSUP) if hardware doesn't support tunnel type.
> + */
> +int
> +rte_eth_dev_l2_tunnel_filter_del(uint8_t port_id,
> + struct rte_eth_l2_tunnel *l2_tunnel);
> +
Why are we still adding some filtering functions after having the assertion that
the new filtering API in lib/librte_ether/rte_eth_ctrl.h was generic enough?
The filtering API v2 was a total failure.
Are we going to add new functions each time a new bit of a header must be parsed
by an offloaded filtering?
Are we going to add new functions for each new filter of a NIC?
> --- a/lib/librte_ether/rte_ether_version.map
> +++ b/lib/librte_ether/rte_ether_version.map
> @@ -114,6 +114,10 @@ DPDK_2.2 {
> rte_eth_tx_queue_setup;
> rte_eth_xstats_get;
> rte_eth_xstats_reset;
> + rte_eth_dev_l2_tunnel_eth_type_conf;
> + rte_eth_dev_l2_tunnel_offload_set;
> + rte_eth_dev_l2_tunnel_filter_add;
> + rte_eth_dev_l2_tunnel_filter_del;
It is not the right section but it doesn't really matter.
More information about the dev
mailing list