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