2014-10-22 12:47, Liu, Jijiang: > > > 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? > > No, it will be received by the software. > In terms of VxLAN packet, if tunnel type is not configured VXLAN type, > and software can't use API to configure the UDP destination number. > Even if the incoming packet format is VXLAN packet format, hardware and > software don't think it is VXLAN packet because we didn't configure UDP > Destination port. > > Now I want to remove this limitation, even if the tunnel type is not > configured at PF initialization phase, user also can configure the VxLAN > UDP destination number. > It is more flexible and reasonable. > > > Other question, why a port is associated with only one tunnel type? > > Good question. Now I think we had better remove this limitation because it is > NIC related. > > Two points are summarized here. > 1. The tunnel types is for a whole port/PF, I have explained it a lots. > 2. I will remove tunnel type configuration from rte_eth_conf structure. > > Any comments?
Honestly, I haven't understood your explanation :) I just understood that you want to remove tunnel type from rte_eth_conf and I think it's a really good thing. Thanks -- Thomas
