Message ID | cover.1529420040.git.nelio.laranjeiro@6wind.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C84461BB0B; Thu, 21 Jun 2018 09:13:37 +0200 (CEST) Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id 5783E1BACD for <dev@dpdk.org>; Thu, 21 Jun 2018 09:13:36 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id x6-v6so3292019wmc.3 for <dev@dpdk.org>; Thu, 21 Jun 2018 00:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references; bh=NmYXzbBAruUa02scjkkXTrKmn++oeyD8oIIugzoM2Ts=; b=YtQqvmMVFnDppcp/VpW8EK89Lj7dxWkPYb2/tmqFtG0lDQ9eYZ60JQ0u5LSj18OHgl nTQMNaVeRoNMGcngTcbXZygPm2xMOppw0MMZp0WkMM4UL8QUt7vjq8F8aJf02IcTibAP Mt/FSaILb+P14XjbP8y4VYwfzB89SLcqI3UZFhavlBFTV4tzy4qXBCHSWczmBuwT7UQs uIpELCtpXvFXeFndr3X+LSE/V1IgRpZXqboKFZQcwnNhVJn8Ry5ELtyaRWvMpuMkh8x3 sahC6fggira/TEWvjEc9qx5yF8hWZ6OFRWq/CP8DCCmZRtWTZRS+/GmrW4+NutuuzkCy ho7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=NmYXzbBAruUa02scjkkXTrKmn++oeyD8oIIugzoM2Ts=; b=pSYz57brPnlewgzh89AEOTJxSQCgr0z6jfdtTxuK4moXgRfp2FDy7jRTaFYs3+Ekf3 n8ORC6qayNlyplJWMuFFFKOGeEWfdaMyWKHzxAPR7AfOksZRfYdRhaBc6ESSrOM8I0oP q9i9gWa6jZalmU1othlbjdaCCl9Apgecg8P2wQtvXTgiUX3JgJfjIM3Ra/ppOk/jSJsL AwLyT3Kiidhw11WLKDyUqAHFN9yf59llrOC/ODlU3hrhazS0QDtnR0mh+IC/SeAp4kM3 c3F+oZokMueg/o6kW+20zrGdVOz+4+ENI2Jjj4U8YkGLHvsau/4wWwQbznsTOwHhHLzD P4Pw== X-Gm-Message-State: APt69E134kce6dGl3uH2adi+EEHxDBLnGgybSjV1mmJvLE9HLM7hjkex XdCpctvpqfJXv7WWB+ToTo74600i3A== X-Google-Smtp-Source: ADUXVKKimj78CF8UYJSkBSmAtIYUrW1DmIy68jVxLskVa16mqZ1gzPFXygU2/vGQf4rHRxx9ItiKxg== X-Received: by 2002:a1c:d9cb:: with SMTP id q194-v6mr3930477wmg.91.1529565215839; Thu, 21 Jun 2018 00:13:35 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id n7-v6sm5187998wrr.39.2018.06.21.00.13.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 00:13:35 -0700 (PDT) From: Nelio Laranjeiro <nelio.laranjeiro@6wind.com> To: dev@dpdk.org, Adrien Mazarguil <adrien.mazarguil@6wind.com>, Wenzhuo Lu <wenzhuo.lu@intel.com>, Jingjing Wu <jingjing.wu@intel.com>, Bernard Iremonger <bernard.iremonger@intel.com>, Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>, Ori Kam <orika@mellanox.com>, Stephen Hemminger <stephen@networkplumber.org> Date: Thu, 21 Jun 2018 09:13:38 +0200 Message-Id: <cover.1529420040.git.nelio.laranjeiro@6wind.com> X-Mailer: git-send-email 2.18.0.rc2 In-Reply-To: <cover.1529332365.git.nelio.laranjeiro@6wind.com> References: <cover.1529332365.git.nelio.laranjeiro@6wind.com> Subject: [dpdk-dev] [PATCH v4 0/2] app/testpmd implement VXLAN/NVGRE Encap/Decap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
app/testpmd implement VXLAN/NVGRE Encap/Decap
|
|
Message
Nélio Laranjeiro
June 21, 2018, 7:13 a.m. UTC
This series adds an easy and maintainable configuration version support for those two actions for 18.08 by using global variables in testpmd to store the necessary information for the tunnel encapsulation. Those variables are used in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily the action for flows. A common way to use it: set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end set vxlan ipv6 4 4 4 ::1 ::2222 11:11:11:11:11:11 22:22:22:22:22:22 flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end set nvgre ipv4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 flow create 0 ingress pattern end actions nvgre_encap / queue index 0 / end set nvgre ipv6 4 ::1 ::2222 11:11:11:11:11:11 22:22:22:22:22:22 flow create 0 ingress pattern end actions nvgre_encap / queue index 0 / end This also replace the proposal done by Mohammad Abdul Awal [1] which handles in a more complex way for the same work. Note this API has already a modification planned for 18.11 [2] thus those series should have a limited life for a single release. [1] https://dpdk.org/ml/archives/dev/2018-May/101403.html [2] https://dpdk.org/ml/archives/dev/2018-June/103485.html Changes in v4: - fix big endian issue on vni and tni. - add samples to the documentation. - set the VXLAN UDP source port to 0 by default to let the driver generate it from the inner hash as described in the RFC 7348. - use default rte flow mask for each item. Changes in v3: - support VLAN in the outer encapsulation. - fix the documentation with missing arguments. Changes in v2: - add default IPv6 values for NVGRE encapsulation. - replace VXLAN to NVGRE in comments concerning NVGRE layer. Nelio Laranjeiro (2): app/testpmd: add VXLAN encap/decap support app/testpmd: add NVGRE encap/decap support app/test-pmd/cmdline.c | 252 ++++++++++++++++++ app/test-pmd/cmdline_flow.c | 268 ++++++++++++++++++++ app/test-pmd/testpmd.c | 32 +++ app/test-pmd/testpmd.h | 32 +++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 72 ++++++ 5 files changed, 656 insertions(+)
Comments
Hi Nelio, On 21/06/2018 08:13, Nelio Laranjeiro wrote: > This series adds an easy and maintainable configuration version support for > those two actions for 18.08 by using global variables in testpmd to store the > necessary information for the tunnel encapsulation. Those variables are used > in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily > the action for flows. > > A common way to use it: > > set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end This way we can define only one tunnel for all the flows. This is not a convenient for testing a scenario (e.g. mutiport or switch) with multiple tunnels. Isn't it? Regards, Awal.
On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote: > Hi Nelio, > > > On 21/06/2018 08:13, Nelio Laranjeiro wrote: > > This series adds an easy and maintainable configuration version support for > > those two actions for 18.08 by using global variables in testpmd to store the > > necessary information for the tunnel encapsulation. Those variables are used > > in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily > > the action for flows. > > > > A common way to use it: > > > > set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > This way we can define only one tunnel for all the flows. This is not a > convenient for testing a scenario (e.g. mutiport or switch) with multiple > tunnels. Isn't it? Hi Awal. The "set vxlan" command will just configure the outer VXLAN tunnel to be used, when the "flow" command is invoked, it will use the VXLAN tunnel information and create a valid VXLAN_ENCAP action. For instance: testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end testpmd> set vxlan ipv6 4 34 42 ::1 ::2222 80:12:13:14:15:16 22:22:22:22:22:22 testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one with an IPv6. Whereas: testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end actions vxlan_encap / queue index 0 / end testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end actions vxlan_encap / queue index 0 / end will encapsulate the packets having as IPv4 source IP 10.2.3.4 and 20.2.3.4 with the same VXLAN tunnel headers. Regards,
On 22/06/2018 09:31, Nélio Laranjeiro wrote: > On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote: >> Hi Nelio, >> >> >> On 21/06/2018 08:13, Nelio Laranjeiro wrote: >>> This series adds an easy and maintainable configuration version support for >>> those two actions for 18.08 by using global variables in testpmd to store the >>> necessary information for the tunnel encapsulation. Those variables are used >>> in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily >>> the action for flows. >>> >>> A common way to use it: >>> >>> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 >>> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end >> This way we can define only one tunnel for all the flows. This is not a >> convenient for testing a scenario (e.g. mutiport or switch) with multiple >> tunnels. Isn't it? > Hi Awal. > > The "set vxlan" command will just configure the outer VXLAN tunnel to be > used, when the "flow" command is invoked, it will use the VXLAN tunnel > information and create a valid VXLAN_ENCAP action. For instance: > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > testpmd> set vxlan ipv6 4 34 42 ::1 ::2222 80:12:13:14:15:16 22:22:22:22:22:22 > testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one > with an IPv6. Whereas: > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end > actions vxlan_encap / queue index 0 / end > testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end > actions vxlan_encap / queue index 0 / end > > will encapsulate the packets having as IPv4 source IP 10.2.3.4 and > 20.2.3.4 with the same VXLAN tunnel headers. I understand that the same IPv4 tunnel will be used for both flows in your example above. I have the following questions. 1) How can we create two or more IPv4 (or IPv6) tunnel? 1) How can we make the flows to use different IPv4 tunnels? As an example, testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end Is it possible? Regards, Awal. > > Regards, >
On Fri, Jun 22, 2018 at 09:51:15AM +0100, Mohammad Abdul Awal wrote: > > > On 22/06/2018 09:31, Nélio Laranjeiro wrote: > > On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote: > > > Hi Nelio, > > > > > > > > > On 21/06/2018 08:13, Nelio Laranjeiro wrote: > > > > This series adds an easy and maintainable configuration version support for > > > > those two actions for 18.08 by using global variables in testpmd to store the > > > > necessary information for the tunnel encapsulation. Those variables are used > > > > in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily > > > > the action for flows. > > > > > > > > A common way to use it: > > > > > > > > set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > > > flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > > This way we can define only one tunnel for all the flows. This is not a > > > convenient for testing a scenario (e.g. mutiport or switch) with multiple > > > tunnels. Isn't it? > > Hi Awal. > > > > The "set vxlan" command will just configure the outer VXLAN tunnel to be > > used, when the "flow" command is invoked, it will use the VXLAN tunnel > > information and create a valid VXLAN_ENCAP action. For instance: > > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > testpmd> set vxlan ipv6 4 34 42 ::1 ::2222 80:12:13:14:15:16 22:22:22:22:22:22 > > testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > > > will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one > > with an IPv6. Whereas: > > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end > > actions vxlan_encap / queue index 0 / end > > testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end > > actions vxlan_encap / queue index 0 / end > > > > will encapsulate the packets having as IPv4 source IP 10.2.3.4 and > > 20.2.3.4 with the same VXLAN tunnel headers. > > I understand that the same IPv4 tunnel will be used for both flows in your > example above. I have the following questions. > > 1) How can we create two or more IPv4 (or IPv6) tunnel? > 1) How can we make the flows to use different IPv4 tunnels? > As an example, > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 > testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end > testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end > Doing this, the flows will use the same tunnel, you must do: testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end to have what you want. > Is it possible? Regards,
On 22/06/2018 10:08, Nélio Laranjeiro wrote: > On Fri, Jun 22, 2018 at 09:51:15AM +0100, Mohammad Abdul Awal wrote: >> >> On 22/06/2018 09:31, Nélio Laranjeiro wrote: >>> On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote: >>>> Hi Nelio, >>>> >>>> >>>> On 21/06/2018 08:13, Nelio Laranjeiro wrote: >>>>> This series adds an easy and maintainable configuration version support for >>>>> those two actions for 18.08 by using global variables in testpmd to store the >>>>> necessary information for the tunnel encapsulation. Those variables are used >>>>> in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily >>>>> the action for flows. >>>>> >>>>> A common way to use it: >>>>> >>>>> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 >>>>> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end >>>> This way we can define only one tunnel for all the flows. This is not a >>>> convenient for testing a scenario (e.g. mutiport or switch) with multiple >>>> tunnels. Isn't it? >>> Hi Awal. >>> >>> The "set vxlan" command will just configure the outer VXLAN tunnel to be >>> used, when the "flow" command is invoked, it will use the VXLAN tunnel >>> information and create a valid VXLAN_ENCAP action. For instance: >>> >>> testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 >>> testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end >>> testpmd> set vxlan ipv6 4 34 42 ::1 ::2222 80:12:13:14:15:16 22:22:22:22:22:22 >>> testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end >>> >>> will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one >>> with an IPv6. Whereas: >>> >>> testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 >>> testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end >>> actions vxlan_encap / queue index 0 / end >>> testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end >>> actions vxlan_encap / queue index 0 / end >>> >>> will encapsulate the packets having as IPv4 source IP 10.2.3.4 and >>> 20.2.3.4 with the same VXLAN tunnel headers. >> I understand that the same IPv4 tunnel will be used for both flows in your >> example above. I have the following questions. >> >> 1) How can we create two or more IPv4 (or IPv6) tunnel? >> 1) How can we make the flows to use different IPv4 tunnels? >> As an example, >> >> testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 >> testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 >> testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end >> testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end >> > Doing this, the flows will use the same tunnel, you must do: > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 > testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end > > to have what you want. OK, thanks for the clarification. So, since there will be only one global instance of the tunnel, for any subsequent "set vxlan" operations, the tunnel created from the last last operation will be used. May be it should be cleared in the description/documentation? >> Is it possible? > Regards, >
On Fri, Jun 22, 2018 at 11:19:14AM +0100, Mohammad Abdul Awal wrote: > On 22/06/2018 10:08, Nélio Laranjeiro wrote: > > On Fri, Jun 22, 2018 at 09:51:15AM +0100, Mohammad Abdul Awal wrote: > > > > > > On 22/06/2018 09:31, Nélio Laranjeiro wrote: > > > > On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote: > > > > > Hi Nelio, > > > > > > > > > > > > > > > On 21/06/2018 08:13, Nelio Laranjeiro wrote: > > > > > > This series adds an easy and maintainable configuration version support for > > > > > > those two actions for 18.08 by using global variables in testpmd to store the > > > > > > necessary information for the tunnel encapsulation. Those variables are used > > > > > > in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily > > > > > > the action for flows. > > > > > > > > > > > > A common way to use it: > > > > > > > > > > > > set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > > > > > flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > > > > This way we can define only one tunnel for all the flows. This is not a > > > > > convenient for testing a scenario (e.g. mutiport or switch) with multiple > > > > > tunnels. Isn't it? > > > > Hi Awal. > > > > > > > > The "set vxlan" command will just configure the outer VXLAN tunnel to be > > > > used, when the "flow" command is invoked, it will use the VXLAN tunnel > > > > information and create a valid VXLAN_ENCAP action. For instance: > > > > > > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > > > testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > > > testpmd> set vxlan ipv6 4 34 42 ::1 ::2222 80:12:13:14:15:16 22:22:22:22:22:22 > > > > testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end > > > > > > > > will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one > > > > with an IPv6. Whereas: > > > > > > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > > > testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end > > > > actions vxlan_encap / queue index 0 / end > > > > testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end > > > > actions vxlan_encap / queue index 0 / end > > > > > > > > will encapsulate the packets having as IPv4 source IP 10.2.3.4 and > > > > 20.2.3.4 with the same VXLAN tunnel headers. > > > I understand that the same IPv4 tunnel will be used for both flows in your > > > example above. I have the following questions. > > > > > > 1) How can we create two or more IPv4 (or IPv6) tunnel? > > > 1) How can we make the flows to use different IPv4 tunnels? > > > As an example, > > > > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 > > > testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end > > > testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end > > > > > Doing this, the flows will use the same tunnel, you must do: > > > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22 > > testpmd> flow create 0 ingress pattern end actions vxlan_encap <first tunnel?> / queue index 0 / end > > testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33 44:44:44:44:44:44 > > testpmd> flow create 0 ingress pattern end actions vxlan_encap <second tunnel?> / queue index 0 / end > > > > to have what you want. > OK, thanks for the clarification. So, since there will be only one global > instance of the tunnel, for any subsequent "set vxlan" operations, the > tunnel created from the last last operation will be used. May be it should > be cleared in the description/documentation? Will add it in the v5. > > > Is it possible? > > Regards, > > > Thanks,