[dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether

[Liu, Jijiang]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, October 22, 2014 5:19 AM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet
> identification API in librte_ether
> 
> 2014-10-21 13:48, Liu, Jijiang:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2014-10-21 16:46, Jijiang Liu:
> > > >  int
> > > > +rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> > > > +			   struct rte_eth_udp_tunnel *udp_tunnel,
> > > > +			   uint8_t count)
> > > > +{
> > > > +	uint8_t i;
> > > > +	struct rte_eth_dev *dev;
> > > > +	struct rte_eth_udp_tunnel *tunnel;
> > > > +
> > > > +	if (port_id >= nb_ports) {
> > > > +		PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > > +	if (udp_tunnel == NULL) {
> > > > +		PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > > +	tunnel = udp_tunnel;
> > > > +
> > > > +	for (i = 0; i < count; i++, tunnel++) {
> > > > +		if (tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
> > > > +			PMD_DEBUG_TRACE("Invalid tunnel type\n");
> > > > +			return -EINVAL;
> > > > +		}
> > > > +	}
> > >
> > > I'm not sure it's a good idea to provide a count parameter to
> > > iterate in a loop.
> > > It's probably something that the application should do by itself.
> >
> > It is necessary to check if this prot_type(tunnel type) is valid here
> > in case applications don't do that.
> 
> Yes, you have to check prot_type but looping for several tunnels is not
> needed at this level.
> 
> > > But I doubt we should configure a tunnel type for a whole port.
> >
> > Yes, your understanding is correct. It is for a whole port/PF, that's
> > why we should add tunnel_type in rte_eth_conf structure.
> 
> Please explain me why a tunnel type should be associated to a port.
> This design looks really broken.

I don't think this design looks really broken.

Currently, A PF  associated to a port, right? What tunnel type should be supported in a PF, which is required we configure it.
Tunneling packet is encapsulation packet, in terms of VxLAN, packet format is outer L2 header+ outer L3 header +outer L4 header + tunneling header+ inner L2 header + inner L3 header + inner L4 header +PAY4.
For a VM/VF, the  real useful packet data is "inner L2 header + inner L3 header + inner L4 header +PAY4".  

In NIC, A port/PF receive this kind of tunneling packet(outer L2+...PAY4),  software should be responsible for decapsulating the packet and deliver real data(innerL2 + PAY4) to VM/VF。

DPDK just provide API/mechanism to guarantee a PF/port to receive the tunneling packet data, the encapsulation/ decapsulation work should be done by user application.

Normally, the tunneling packet processing like below:
Tunneling packet ------>PF processing/receive ---------> application SW do decapsulation -------> VF/VM processing

> Thanks
> --
> Thomas