2015-12-14 15:48, Jijiang Liu:
> 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.
Sorry, I don't understand what you mean.
Maybe others have a clue?
> 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. */
> };
More generally, is it possible/reasonnable to try saving the whole device
configuration in this struct? What is the limit?
This rte_eth_conf struct is an input for rte_eth_dev_configure().
Should we add some fields which are not used by rte_eth_dev_configure()
but configured through rte_eth_dev_filter_ctrl() instead?
