Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf

[Ivan Boule <ivan.boule@6wind.com>]

On 12/14/2015 08:48 AM, Jijiang Liu wrote:
> In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration.
>
> And tunneling packet encapsulation operation will benifit from the change.
>
> There are more descriptions for the ABI changes below,
>
> The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
> struct rte_eth_tunnel_conf {
>         uint16_t tx_queue;
>         uint16_t filter_type;
>         struct rte_eth_tunnel_flow flow_tnl;
> };
>
> The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent out, refer to [1].
>
> [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
>
> The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> struct rte_eth_conf {
> 	...
> 	uint32_t dcb_capability_en;
> 	struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
> 	struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> 	struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> 	/**< Tunnel configuration. */
> };
>
> v2 change:
>    Add more description for the change.
>
> v3 change:
>    Change ABI announcement description.
>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> ---cmdline.c
>   doc/guides/rel_notes/deprecation.rst |    6 ++++++
>   1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 5c458f2..9dbe89e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -23,3 +23,9 @@ Deprecation Notices
>   * ABI changes are planned for struct rte_eth_tunnel_flow in order to extend new fileds to support
>     tunneling packet configuration in unified tunneling APIs. The release 2.2 does not contain these ABI
>     changes, but release 2.3 will, and no backwards compatibility is planned.
> +
> +* ABI changes are planned for the struct rte_eth_conf in order to add 'tunnel_conf' variable
> +  in the struct to store tunnel configuration when using new API rte_eth_dev_tunnel_configure
> +  (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf * tunnel_conf) to configure
> +  tunnel flow and classification information. The release 2.2 does not contain these ABI change,
> +  but release 2.3 will, and no backward compatibility is planned.
>
Hi Jijiang,

Can you provide a real use case - I mean an example of a real network 
application - that really needs to save tunnel configurations in a data 
structure associated with a NIC port?

Firstly, if the only usage is to enable applications to retrieve tunnel
configurations, then you are simply growing the size of the per-port
structure with tunnel configurations, and imposing it to every DPDK 
application.
You impose it to those applications that don't care about tunneling, but 
also to those applications which do care, but which prefer to have their 
own representation of ports where they store everything they need to.

If the tunnel configuration is also used for other purposes, then it
must be precisely described what happens with the saved tunnel 
configuration when the application changes the state of a port.
This is the case for instance when the application reconfigures the 
number of RX queues of a port.
Who is responsible for checking that some tunnels won't be matched anymore?
Who is responsible for dropping/invalidating the saved tunnel 
configuration, if such operations must be performed?
This list is likely to be not exhaustive, of course.

More globally, all side-effects of saving the tunnel configuration must 
be considered and addressed in a coherent way and in an easy-to-use 
approach.

By the way, as far as I know, the Linux kernel does not [need to] save 
tunnel data or ARP entries behind "netdevice" structures.

PS : in the "rte_eth_tunnel_conf" data structure, I think that the first 
field should be named "rx_queue" instead of "tx_queue".

Regards,
Ivan

-- 
Ivan Boule
6WIND Development Engineer