Re: [dpdk-dev] [PATCH v6 2/5] lib/librte_ether: support l2 tunnel operations

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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.