From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether Date: Wed, 22 Oct 2014 15:25:18 +0200 Message-ID: <1498449.2AChC3Xc4h@xps13> References: <1413881168-20239-1-git-send-email-jijiang.liu@intel.com> <6121673.LPIm1x7VbG@xps13> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82A66@SHSMSX101.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: dev-VfR2kkLFssw@public.gmane.org To: "Liu, Jijiang" Return-path: In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82A66-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 2014-10-22 12:47, Liu, Jijiang: > > > Currently, A PF associated to a port, right? What tunnel type sh= ould > > > be supported in a PF, which is required we configure it. > > > Tunneling packet is encapsulation packet, in terms of VxLAN, pack= et > > > format is outer L2 header+ outer L3 header +outer L4 header + > > > tunneling header+ inner L2 header + inner L3 header + inner L4 he= ader +PAY4. > > > For a VM/VF, the real useful packet data is "inner L2 header + i= nner > > > 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=E3=80=82 > > > > > > DPDK just provide API/mechanism to guarantee a PF/port to receive= the > > > tunneling packet data, the encapsulation/ decapsulation work shou= ld be > > > done by user application. > >=20 > > You mean that all packets received on the PF which doesn't match th= e > > configured tunnel type, won't be received by the software? >=20 > 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.=20= > Even if the incoming packet format is VXLAN packet format, hardware a= nd > software don't think it is VXLAN packet because we didn't configure U= DP > Destination port.=20 >=20 > Now I want to remove this limitation, even if the tunnel type is no= t > configured at PF initialization phase, user also can configure the Vx= LAN > UDP destination number. > It is more flexible and reasonable. >=20 > > Other question, why a port is associated with only one tunnel type?= >=20 > Good question. Now I think we had better remove this limitation becau= se it is NIC related. >=20 > Two points are summarized here. > 1. The tunnel types is for a whole port/PF, I have explained it a lot= s. > 2. I will remove tunnel type configuration from rte_eth_conf structur= e. >=20 > 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 --=20 Thomas