2014-10-22 01:46, Liu, Jijiang: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-10-21 13:48, Liu, Jijiang: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > 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.
You mean that all packets received on the PF which doesn't match the configured tunnel type, won't be received by the software? Other question, why a port is associated with only one tunnel type? > Normally, the tunneling packet processing like below: > Tunneling packet ------>PF processing/receive ---------> application SW do > decapsulation -------> VF/VM processing I really try to understand what you have in mind. Thanks for explaining -- Thomas
