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 11:52:12 +0200 Message-ID: <6121673.LPIm1x7VbG@xps13> References: <1413881168-20239-1-git-send-email-jijiang.liu@intel.com> <282785858.Uoneh1Nj8l@xps13> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D827A2@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: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D827A2-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 01:46, Liu, Jijiang: > From: Thomas Monjalon [mailto:thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org] > > 2014-10-21 13:48, Liu, Jijiang: > > > From: Thomas Monjalon [mailto:thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org] > > > > 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, th= at's > > > why we should add tunnel_type in rte_eth_conf structure. > >=20 > > Please explain me why a tunnel type should be associated to a port.= > > This design looks really broken. >=20 > I don't think this design looks really broken. >=20 > 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 f= ormat > is outer L2 header+ outer L3 header +outer L4 header + tunneling head= er+ > 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". =20 >=20 > In NIC, A port/PF receive this kind of tunneling packet(outer L2+...P= AY4), > software should be responsible for decapsulating the packet and deliv= er > real data(innerL2 + PAY4) to VM/VF=E3=80=82 >=20 > DPDK just provide API/mechanism to guarantee a PF/port to receive the= > tunneling packet data, the encapsulation/ decapsulation work should b= e > done by user application. You mean that all packets received on the PF which doesn't match the co= nfigured 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= --=20 Thomas