From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 851787E7B for ; Wed, 22 Oct 2014 15:17:21 +0200 (CEST) Received: by mail-wg0-f49.google.com with SMTP id x12so3693659wgg.8 for ; Wed, 22 Oct 2014 06:25:42 -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=LcRpCCxlqTmrY9K/Bff6zrTLLCrUyKup8bGizoT319o=; b=MYv6pVWwrVYzCPAQT04MRofgTLLfUuNWng1K7KXDu3jpQpOQE2X0kuoPYrGxbPOcUi RhuaR/iHeX4qPYDDkBzTMJ/9gDvREWXeyY7JF1AFKA2y3mucKp5TPUGIBOayG7nMAARP CLnaGVThVuoz/9x3zF86M5DdhEtnp2O09qteZfoPf0N1mIaZNquIGT5F/d3CCAGfuHJ5 4/pGkoLvPSOexZcUtP3AOKjswbNU4syhf3wAxhSk3ECTkT2Cr8Uvo25jEAqB0D+5QugN 9O9GLzq+Vy8mNyetbWR3hJej+aX/t4gu2J/ddZ71iR4L6TEgcB7n+WRtq2OgJGyy0okk kRLA== X-Gm-Message-State: ALoCoQkPt1aGGA6zPWNzEIW2TAZAI/r+5Ym8ktQiwTlr4qIKNCpg4Z5vQCxgoqUMlpbXQAK1aOSg X-Received: by 10.180.107.69 with SMTP id ha5mr5426852wib.69.1413984341986; Wed, 22 Oct 2014 06:25:41 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id cu9sm18914636wjc.3.2014.10.22.06.25.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 06:25:41 -0700 (PDT) From: Thomas Monjalon To: "Liu, Jijiang" Date: Wed, 22 Oct 2014 15:25:18 +0200 Message-ID: <1498449.2AChC3Xc4h@xps13> Organization: 6WIND User-Agent: KMail/4.14.1 (Linux/3.16.4-1-ARCH; KDE/4.14.1; x86_64; ; ) In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82A66@SHSMSX101.ccr.corp.intel.com> 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-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 13:17:21 -0000 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