From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by dpdk.org (Postfix) with ESMTP id 6AC6A5B1E for ; Mon, 30 Jul 2018 19:28:40 +0200 (CEST) Received: by mail-pg1-f176.google.com with SMTP id p23-v6so7603753pgv.13 for ; Mon, 30 Jul 2018 10:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HflBrXW2YBsqNhwO2Hfg3NHIIqpyRQljE1w8uiegglg=; b=RnxLIWd+RAuBEGVbBuCnh3MUGEDIVs/YcYlqjFlpDI9HuJZFBa8GZe3TUuBLhxecZp slizpiJgWj5c89hEPBfhqOQjQXa8Z7hjW6PukJiw1E4aQVY+uX5pX2l0iDDt930q+egY vaJvPz2THRT69V0haik1aqeKkaQcs0iofLw5qJbCcHnm5bACKu7BMAW+hV8YYKPxJc3/ s0EM1p088NnkBqXeU4SYufv++sqzb+E3FxZAO9vTNmsnvihrM/VJLeUjoXOXO9ohntgp /T11TvS6ZvvGkUxQssx/R9WHJSPZbXpUa0fnbKIQjVpfiB5cvxJxwjFmAduaMj5wWDrK FzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HflBrXW2YBsqNhwO2Hfg3NHIIqpyRQljE1w8uiegglg=; b=uh/cQjlINBhbehaX3yXl0HDDE4Z0FsKr/T/mOlBKoGbfJpr8Dj79VAxybfgRs6ekB4 TlEsRQXpNNX0ipauJaWL/6H4fya/bTRxGy3+KMEfKCP9pUBe08cJTro2C3n1VQiP8Za2 RjlgvRlIk640/QMXZHSthoKg3Oygrcym2jFz1w7FQjjs9ft+0X3cdlZcX2FD7aS0mUyS M1vjfnCcR461caASZwQ9Pa3ihsGs/Xjyu3F8fCU34w3x1r/A52f7X2xF//N8LmVdShu4 yI54rBYxwDqae6kJF9ktUWRLpPb7OGWZRSLL/hYpdYd2gHd7CtJKZArZIDgzte0oo19U QKqQ== X-Gm-Message-State: AOUpUlErgRy9MtfzstUxpydntEoPuTMBNSdAtB1jEWGCLcKTLwdCL9Wl CBDEcsci+tDT+1n4uKYk40wFlg== X-Google-Smtp-Source: AAOMgpdJqYKtnnhoKE7HjkUiF44MSPHOhWL/UJ232ridOK0FiOjTVSpHMKP8oxTet/rzPO0CuikWeg== X-Received: by 2002:a62:df4e:: with SMTP id u75-v6mr18819814pfg.195.1532971719478; Mon, 30 Jul 2018 10:28:39 -0700 (PDT) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id o72-v6sm17469842pfk.76.2018.07.30.10.28.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Jul 2018 10:28:39 -0700 (PDT) Date: Mon, 30 Jul 2018 10:28:36 -0700 From: Stephen Hemminger To: Ori Kam Cc: xuemingl@mellanox.com, dekelp@mellanox.com, shahafs@mellanox.com, adrien.mazarguil@6wind.com, thomas@monjalon.net, yskoh@mellanox.com, ferruh.yigit@intel.com, arybchenko@solarflare.com, dev@dpdk.org Message-ID: <20180730102836.00605a3e@xeon-e3> In-Reply-To: <1532967565-13962-1-git-send-email-orika@mellanox.com> References: <1532967565-13962-1-git-send-email-orika@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] ethdev: add generic L2/L3 tunnel encapsulation actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 17:28:40 -0000 On Mon, 30 Jul 2018 19:19:25 +0300 Ori Kam wrote: > Currenlty the encap/decap actions only support encapsulation > of VXLAN and NVGRE L2 packets. > There is a need to add more L2 tunnels and also L3 tunnels. > > One issue with the current approch is the duplication of code. > For example the code for handling NVGRE and VXLAN are exactly the same, > and each new tunnel will have the same exact structure. > > Last issue with the current approach is the use of rte_items. > The most significant issue with that is that the PMD needs to convert > the items and this hurts the insertion rate. Other issue is that > the rte_item has 3 members while we only need the spec (last and mask > are useless). I know that the extra member have only small memory > impact but considering that we can have millions of rules, this became > more important consideration, and it is bad practice to add a variable > that is never used. > > My suggestion is to create 2 commands, one for encapsulation of L2 > packets and one for encapsulation of L3 tunnels. > The parameters for those functions will be a uint8_t buffer with > a length parameter. > > The current approach is not implemented yet in drivers yet, and > is marked as experimental, so it should be removed. > > Any comments will be hugely appreciated. > > Signed-off-by: Ori Kam What about binary and source compatibilities with older release?