From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id A547A7E7B for ; Wed, 22 Oct 2014 11:44:14 +0200 (CEST) Received: by mail-wg0-f52.google.com with SMTP id a1so3227524wgh.23 for ; Wed, 22 Oct 2014 02:52:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=ZQwuyINkjlLmmYvOoUw26K1BZ0zMLJDHQzQzATJ8HJk=; b=Z7XsGXffN6aQKXji4e8GcC3fG2opShQEo/YYnR4qtmddK9szcG2vrplM2azxazxA3/ LhgRYj2S0c2v4K5VXM9ZKtcjIJmZADAEuHKJmakagHYPrpAXn0SkMGxevrSx6wTZ7if4 G2oBmlwLMuWojOFn3hJSTIdJE2mVS5cHIPBMBl1MJXlnka2GlmC4hmbXS6IL6Jvt9eH1 A73GLvH/GOLCN0aurffED1GYMNgO4tzfLsUqm44M9ah2a7MfHLBATjj3jCVKiJvxIgxe RLa2dNKgrmLQVy1ng8igs/UigNUSiP2B/WbCugn0DG6N5Gi2wjtDeFfZ2md6v65dRsZd 4/MA== X-Gm-Message-State: ALoCoQmJHC0A3/y6ZvT0P4pyqEIgbtUvkiRWDOowwXuQ0cF2aDG0rsKk4rjkOMkDpqAwx79zDBem X-Received: by 10.180.107.69 with SMTP id ha5mr4146387wib.69.1413971554384; Wed, 22 Oct 2014 02:52:34 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id gt7sm1307109wib.18.2014.10.22.02.52.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 02:52:33 -0700 (PDT) From: Thomas Monjalon To: "Liu, Jijiang" Date: Wed, 22 Oct 2014 11:52:12 +0200 Message-ID: <6121673.LPIm1x7VbG@xps13> Organization: 6WIND User-Agent: KMail/4.14.1 (Linux/3.16.4-1-ARCH; KDE/4.14.1; x86_64; ; ) In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D827A2@SHSMSX101.ccr.corp.intel.com> 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 09:44:14 -0000 2014-10-22 01:46, Liu, Jijiang: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2014-10-21 13:48, Liu, Jijiang: > > > From: Thomas Monjalon [mailto:thomas.monjalon@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, 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