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

Liu, Jijiang jijiang.liu at intel.com
Tue Dec 15 04:00:19 CET 2015



> -----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. 



More information about the dev mailing list