> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, December 14, 2015 11:10 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
> rte_eth_conf
>
> > And tunneling packet encapsulation operation will benefit from the change.
>
> Sorry, I don't understand what you mean.
> Maybe others have a clue?
We want to add functions of tunneling packet decapsulation/encapsulation as
APIs into DPDK, and it had better store tunnel configuration in a device's
configuration, as a result, outer src/dst MAC address, outer src/dst IP address
and others can be stored for a pair of queues.
The stored configuration can be used when encapsulating a tunneling packet for
sending out via a specific queue.
And for RX side, we can use flow director or tunnel filter mechanism to
guarantee a specific flow enter the a specific.
For example,
We do the following configuration,
rx_queue: 1
tx_queue: 1
Tunnel id: 1000
Outer Src MAC:
Outer dst MAC: 66.55.44.33.22.11
Outer Src IP:
Outer dst IP: 192.168.10.2
inner dst MAC: 22.33.44.55.66.77
And set RX classification condition for RX queue 1: Outer dst MAC +
Tunnel id + inner dst MAC ( or 5 tuples), and decapsulate the tunneling packet
and save some fields in the 'tunnel_conf' in the ' rte_eth_conf ',
then these stored configuration can be used when encapsulating a
tunneling packet for sending out via TX queue 1.
> > The change of struct 'rte_eth_conf' like below, but it have not finalized
> > yet.
> > struct rte_eth_conf {
> > ...
> >
> > struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
> > /**< Tunnel configuration. */
> > };
> 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?
The tunnel configuration is not just for classification, we also need them to
do encapsulation operation.
