From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 006B8A0C52 for ; Mon, 16 Aug 2021 10:55:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CA54A4003C; Mon, 16 Aug 2021 10:55:58 +0200 (CEST) Received: from smtp-relay-canonical-1.canonical.com (smtp-relay-canonical-1.canonical.com [185.125.188.121]) by mails.dpdk.org (Postfix) with ESMTP id 4C1094003C for ; Mon, 16 Aug 2021 10:55:57 +0200 (CEST) Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPS id 1375E412B1 for ; Mon, 16 Aug 2021 08:55:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1629104157; bh=IQnR/VVk9TdA0RSZPi61qxVzv1I1zQDIiJrWY9w+NOs=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GECYkIo0PvdVrfrOv+ouQiB7sV1F8wZyxptGNRD2vdB6oGNBn1gJMtcepFnS5g8Zo ImNTtGQEq1iiXJOgZ3XUc2JoHmE1Jjfkj7jk+Ye1MjogTOFtC16Ml+aFxkBXb2WjMr WZ1vORvaBwJa3idHdk4GvicoB8HRcGnYVNTaxgeHtzMa61daI1pcfRBBgetzNiaGQb i6eO7E9fuv2Omm8yDfoYnn+NSDccK9sjMQnA2zoJNa6Y22NGEkXmOZ8WLy1I8Sw/xS A1Hf9QoaHtQQy6Ai7sncmG+CF+JsTeoqRwKyJqqXxaED8RJlJGFOA9W3Oucq4qDnTR eLthepAex8alg== Received: by mail-qt1-f198.google.com with SMTP id t35-20020a05622a1823b02902647b518455so8988896qtc.3 for ; Mon, 16 Aug 2021 01:55:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IQnR/VVk9TdA0RSZPi61qxVzv1I1zQDIiJrWY9w+NOs=; b=cVCQd1WNAa7AantHUBr50AYnHiLh36qaktPTVvH3HbP0aT0V04dLrNI0FFJf5HACzR vAuDOQY8M4Od9vr6UOdFkmwk9r3M2CbvDBKzyb1lUAG9Wye2vsZwR9Ri9t32Uvm4DPhD KiBC92Uk80e9Lz/ZE3fwRBtdgwGJYGpqgT/hrRq4ujmgNL9qKbwTRhK3HZkaSujW3PMh e0XDF5hdtG8cJR11FToSD1AV9l4IsL2xtBBpOxx4vt/Y6ABx10fSrtTrJSxDEZDmwuDt tH6U0ijTeKw2nPhRaCfgcmGRgFXOybHSNR5wAwz3KmvFF5ss0UGJen1dsIervclMOq1u q1lw== X-Gm-Message-State: AOAM531EYA6iniLKQr72/bz7S8Q0ZyM/FF77Hc4YeYdb8RTopVCmDg6A 6WczffV8ymV1rc3Bxa7x+wKbDOoRHX2CPpAfvgL9eXmQ9f0HIM6ZP/7Ufwnx5MscudJAY/+wU91 0+9dz0vmajkYEaBjG2VszMGJ2NvnvLwSAUpBHST8p X-Received: by 2002:a0c:aac2:: with SMTP id g2mr14895353qvb.44.1629104155730; Mon, 16 Aug 2021 01:55:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzncIB/HCdng2wNxWf2fH7lfR8tBiYxB0TiNXADp9k7flU15jQuXU9qmk7tRXJF5//XAi/7pJHbY62K2fGCkF8= X-Received: by 2002:a0c:aac2:: with SMTP id g2mr14895339qvb.44.1629104155364; Mon, 16 Aug 2021 01:55:55 -0700 (PDT) MIME-Version: 1.0 References: <20210812160015.35642-1-hnadeau@iol.unh.edu> In-Reply-To: <20210812160015.35642-1-hnadeau@iol.unh.edu> From: Christian Ehrhardt Date: Mon, 16 Aug 2021 10:55:29 +0200 Message-ID: To: Henry Nadeau Cc: dpdk stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [PATCH 19.11] doc: spell check Backporting spell check patch to previous version of DPDK. All changes should be correct, but if not please reach out so I can submit a new version. X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, Aug 12, 2021 at 6:00 PM Henry Nadeau wrote: > > [ upstream commit <9c30a6f3c9> ] Thanks, applied with an update to the commit message to match the correct f= orm > Signed-off-by: Henry Nadeau > --- > doc/guides/bbdevs/fpga_lte_fec.rst | 2 +- > doc/guides/contributing/stable.rst | 2 +- > doc/guides/cryptodevs/scheduler.rst | 2 +- > doc/guides/howto/pvp_reference_benchmark.rst | 2 +- > doc/guides/nics/bnxt.rst | 6 +++--- > doc/guides/nics/mlx5.rst | 2 +- > doc/guides/nics/octeontx2.rst | 2 +- > doc/guides/nics/virtio.rst | 2 +- > doc/guides/prog_guide/bbdev.rst | 2 +- > doc/guides/prog_guide/dev_kit_build_system.rst | 2 +- > doc/guides/prog_guide/env_abstraction_layer.rst | 2 +- > doc/guides/prog_guide/eventdev.rst | 2 +- > doc/guides/prog_guide/multi_proc_support.rst | 2 +- > doc/guides/prog_guide/qos_framework.rst | 2 +- > doc/guides/rawdevs/ntb.rst | 2 +- > doc/guides/rel_notes/release_16_11.rst | 2 +- > doc/guides/rel_notes/release_19_08.rst | 2 +- > doc/guides/rel_notes/release_2_2.rst | 2 +- > doc/guides/sample_app_ug/l2_forward_cat.rst | 2 +- > doc/guides/sample_app_ug/performance_thread.rst | 2 +- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- > 21 files changed, 23 insertions(+), 23 deletions(-) > > diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst b/doc/guides/bbdevs/fpga_= lte_fec.rst > index 206b6f4f9b..8509de934f 100644 > --- a/doc/guides/bbdevs/fpga_lte_fec.rst > +++ b/doc/guides/bbdevs/fpga_lte_fec.rst > @@ -50,7 +50,7 @@ FPGA LTE FEC does not support the following: > Installation > -------------- > > -Section 3 of the DPDK manual provides instuctions on installing and comp= iling DPDK. The > +Section 3 of the DPDK manual provides instructions on installing and com= piling DPDK. The > default set of bbdev compile flags may be found in config/common_base, w= here for example > the flag to build the FPGA LTE FEC device, ``CONFIG_RTE_LIBRTE_PMD_BBDEV= _FPGA_LTE_FEC``, is already > set. It is assumed DPDK has been compiled using for instance: > diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing= /stable.rst > index 4d38bb8606..0a76a9173f 100644 > --- a/doc/guides/contributing/stable.rst > +++ b/doc/guides/contributing/stable.rst > @@ -95,7 +95,7 @@ Features should not be backported to stable releases. I= t may be acceptable, in > limited cases, to back port features for the LTS release where: > > * There is a justifiable use case (for example a new PMD). > -* The change is non-invasive. > +* The change is noninvasive. > * The work of preparing the backport is done by the proposer. > * There is support within the community. > > diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/= scheduler.rst > index 7004ca431a..dd3de7f4d7 100644 > --- a/doc/guides/cryptodevs/scheduler.rst > +++ b/doc/guides/cryptodevs/scheduler.rst > @@ -126,7 +126,7 @@ operation: > than the designated threshold, otherwise it will be handled by the se= condary > slave. > > - A typical usecase in this mode is with the QAT cryptodev as the prima= ry and > + A typical use case in this mode is with the QAT cryptodev as the prim= ary and > a software cryptodev as the secondary slave. This may help applicatio= ns to > process additional crypto workload than what the QAT cryptodev can ha= ndle on > its own, by making use of the available CPU cycles to deal with small= er > diff --git a/doc/guides/howto/pvp_reference_benchmark.rst b/doc/guides/ho= wto/pvp_reference_benchmark.rst > index 64b1f4d8ec..971cb25d03 100644 > --- a/doc/guides/howto/pvp_reference_benchmark.rst > +++ b/doc/guides/howto/pvp_reference_benchmark.rst > @@ -26,7 +26,7 @@ Setup overview > > PVP setup using 2 NICs > > -In this diagram, each red arrow represents one logical core. This use-ca= se > +In this diagram, each red arrow represents one logical core. This use ca= se > requires 6 dedicated logical cores. A forwarding configuration with a si= ngle > NIC is also possible, requiring 3 logical cores. > > diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst > index 434ba9d6cc..60ad3127e8 100644 > --- a/doc/guides/nics/bnxt.rst > +++ b/doc/guides/nics/bnxt.rst > @@ -54,14 +54,14 @@ automatically when the port is started if allowed by = the current configuration. > RX Requirements for Vector Mode > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -Vector mode receive will be enabled if the following constrainsts are me= t: > +Vector mode receive will be enabled if the following constraints are met= : > * Packets must fit within a single mbuf (no scatter RX). > * LRO offload must be disabled. > > TX Requirements for Vector Mode > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -Vector mode transmit will be enabled if the following constrainsts are m= et: > +Vector mode transmit will be enabled if the following constraints are me= t: > * Packets must be contained within a single mbuf (no gather TX). > * All transmit offloads other than VLAN insertion must be disabled. > > @@ -123,7 +123,7 @@ Chipsets and adapters supported by the bnxt PMD inclu= de: > `= _ > of the `Broadcom website `_. > > - * **Broadcom StrataGX=C2=AE BCM5871X Series of Communucations Processo= rs** > + * **Broadcom StrataGX=C2=AE BCM5871X Series of Communications Processo= rs** > > These ARM based processors target a broad range of networking applic= ations > including virtual CPE (vCPE) and NFV appliances, 10G service routers= and > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst > index 18573cf6a0..c542cc974b 100644 > --- a/doc/guides/nics/mlx5.rst > +++ b/doc/guides/nics/mlx5.rst > @@ -1027,7 +1027,7 @@ the DPDK application. > > echo -n " /sys/bus/pci/drivers/mlx5_core/u= nbind > > -5. Enbale switchdev mode:: > +5. Enable switchdev mode:: > > echo switchdev > /sys/class/net//compat/devlink/mode > > diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rs= t > index db62a4523f..cad4a7592a 100644 > --- a/doc/guides/nics/octeontx2.rst > +++ b/doc/guides/nics/octeontx2.rst > @@ -162,7 +162,7 @@ Runtime Config Options > > -w 0002:02:00.0,max_sqb_count=3D64 > > - With the above configuration, each send queue's decscriptor buffer co= unt is > + With the above configuration, each send queue's descriptor buffer cou= nt is > limited to a maximum of 64 buffers. > > - ``switch header enable`` (default ``none``) > diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst > index d1f5fb8986..7301a8fed1 100644 > --- a/doc/guides/nics/virtio.rst > +++ b/doc/guides/nics/virtio.rst > @@ -473,7 +473,7 @@ are shown in below table: > Split virtqueue in-order non-mergeable path virtio_recv_pkts_inorder= virtio_xmit_pkts_inorder > Split virtqueue vectorized Rx path virtio_recv_pkts_vec = virtio_xmit_pkts > Packed virtqueue mergeable path virtio_recv_mergeable_pk= ts_packed virtio_xmit_pkts_packed > - Packed virtqueue non-meregable path virtio_recv_pkts_packed = virtio_xmit_pkts_packed > + Packed virtqueue non-mergeable path virtio_recv_pkts_packed = virtio_xmit_pkts_packed > Packed virtqueue in-order mergeable path virtio_recv_mergeable_pk= ts_packed virtio_xmit_pkts_packed > Packed virtqueue in-order non-mergeable path virtio_recv_pkts_packed = virtio_xmit_pkts_packed > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbde= v.rst > index d39167af1f..27e6848b94 100644 > --- a/doc/guides/prog_guide/bbdev.rst > +++ b/doc/guides/prog_guide/bbdev.rst > @@ -639,7 +639,7 @@ optionally the ``soft_output`` mbuf data pointers. > "soft output","soft LLR output buffer (optional)" > "op_flags","bitmask of all active operation capabilities" > "rv_index","redundancy version index [0..3]" > - "iter_max","maximum number of iterations to perofrm in decode all CBs= " > + "iter_max","maximum number of iterations to perform in decode all CBs= " > "iter_min","minimum number of iterations to perform in decoding all C= Bs" > "iter_count","number of iterations to performed in decoding all CBs" > "ext_scale","scale factor on extrinsic info (5 bits)" > diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/= prog_guide/dev_kit_build_system.rst > index 74dba4dd16..5e36e382ba 100644 > --- a/doc/guides/prog_guide/dev_kit_build_system.rst > +++ b/doc/guides/prog_guide/dev_kit_build_system.rst > @@ -9,7 +9,7 @@ Development Kit Build System > The DPDK requires a build system for compilation activities and so on. > This section describes the constraints and the mechanisms used in the DP= DK framework. > > -There are two use-cases for the framework: > +There are two use cases for the framework: > > * Compilation of the DPDK libraries and sample applications; > the framework generates specific binary libraries, > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides= /prog_guide/env_abstraction_layer.rst > index 48a2fec066..6c84566596 100644 > --- a/doc/guides/prog_guide/env_abstraction_layer.rst > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst > @@ -465,7 +465,7 @@ devices would fail anyway. > - By default, the mempool, first asks for IOVA-contiguous memory usi= ng > ``RTE_MEMZONE_IOVA_CONTIG``. This is slow in RTE_IOVA_PA mode and = it may > affect the application boot time. > - - It is easy to enable large amount of IOVA-contiguous memory use-ca= ses > + - It is easy to enable large amount of IOVA-contiguous memory use ca= ses > with IOVA in VA mode. > > It is expected that all PCI drivers work in both RTE_IOVA_PA and > diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/e= ventdev.rst > index 7bcd7603b1..b415d6355f 100644 > --- a/doc/guides/prog_guide/eventdev.rst > +++ b/doc/guides/prog_guide/eventdev.rst > @@ -120,7 +120,7 @@ Ports > ~~~~~ > > Ports are the points of contact between worker cores and the eventdev. T= he > -general use-case will see one CPU core using one port to enqueue and deq= ueue > +general use case will see one CPU core using one port to enqueue and deq= ueue > events from an eventdev. Ports are linked to queues in order to retrieve= events > from those queues (more details in `Linking Queues and Ports`_ below). > > diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/pr= og_guide/multi_proc_support.rst > index a84083b96c..8cfa4e9a45 100644 > --- a/doc/guides/prog_guide/multi_proc_support.rst > +++ b/doc/guides/prog_guide/multi_proc_support.rst > @@ -325,7 +325,7 @@ supported. However, since sending messages (not reque= sts) does not involve an > IPC thread, sending messages while processing another message or request= is > supported. > > -Since the memory sybsystem uses IPC internally, memory allocations and I= PC must > +Since the memory subsystem uses IPC internally, memory allocations and I= PC must > not be mixed: it is not safe to use IPC inside a memory-related callback= , nor is > it safe to allocate/free memory inside IPC callbacks. Attempting to do s= o may > lead to a deadlock. > diff --git a/doc/guides/prog_guide/qos_framework.rst b/doc/guides/prog_gu= ide/qos_framework.rst > index a159709450..f39b099f03 100644 > --- a/doc/guides/prog_guide/qos_framework.rst > +++ b/doc/guides/prog_guide/qos_framework.rst > @@ -737,7 +737,7 @@ Strict priority scheduling of traffic classes within = the same pipe is implemente > which selects the queues in ascending order. > Therefore, queue 0 (associated with TC 0, highest priority TC) is handle= d before > queue 1 (TC 1, lower priority than TC 0), > -which is handled before queue 2 (TC 2, lower priority than TC 1) and it = conitnues until queues of all TCs except the > +which is handled before queue 2 (TC 2, lower priority than TC 1) and it = continues until queues of all TCs except the > lowest priority TC are handled. At last, queues 12..15 (best effort TC, = lowest priority TC) are handled. > > Upper Limit Enforcement > diff --git a/doc/guides/rawdevs/ntb.rst b/doc/guides/rawdevs/ntb.rst > index 58472135f5..e86cdc33f9 100644 > --- a/doc/guides/rawdevs/ntb.rst > +++ b/doc/guides/rawdevs/ntb.rst > @@ -18,7 +18,7 @@ BIOS setting on Intel Skylake > ----------------------------- > > Intel Non-transparent Bridge needs special BIOS setting. Since the PMD o= nly > -supports Intel Skylake platform, introduce BIOS setting here. The refere= ncce > +supports Intel Skylake platform, introduce BIOS setting here. The refere= nce > is https://www.intel.com/content/dam/support/us/en/documents/server-prod= ucts/Intel_Xeon_Processor_Scalable_Family_BIOS_User_Guide.pdf > > - Set the needed PCIe port as NTB to NTB mode on both hosts. > diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_note= s/release_16_11.rst > index 92e0ec694e..3cec9143cf 100644 > --- a/doc/guides/rel_notes/release_16_11.rst > +++ b/doc/guides/rel_notes/release_16_11.rst > @@ -77,7 +77,7 @@ New Features > the current version, even 64 bytes packets take two slots with Virtio = PMD on guest > side. > > - The main impact is better performance for 0% packet loss use-cases, as= it > + The main impact is better performance for 0% packet loss use cases, as= it > behaves as if the virtqueue size was enlarged, so more packets can be = buffered > in the case of system perturbations. On the downside, small performanc= e degradations > were measured when running micro-benchmarks. > diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_note= s/release_19_08.rst > index cbb27e8dc3..d2baa828b1 100644 > --- a/doc/guides/rel_notes/release_19_08.rst > +++ b/doc/guides/rel_notes/release_19_08.rst > @@ -151,7 +151,7 @@ New Features > * Added multi-queue support to allow one af_xdp vdev with multiple net= dev > queues. > * Enabled "need_wakeup" feature which can provide efficient support fo= r the > - usecase where the application and driver executing on the same core. > + use case where the application and driver executing on the same core= . > > * **Enabled infinite Rx in the PCAP PMD.** > > diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/= release_2_2.rst > index cea5c8746d..8273473ff4 100644 > --- a/doc/guides/rel_notes/release_2_2.rst > +++ b/doc/guides/rel_notes/release_2_2.rst > @@ -322,7 +322,7 @@ Drivers > > Several customers have reported a link flap issue on 82579. The sympto= ms > are random and intermittent link losses when 82579 is connected to spe= cific > - switches. the Issue was root caused as an inter-operability problem be= tween > + switches. the Issue was root caused as an interoperability problem bet= ween > the NIC and at least some Broadcom PHYs in the Energy Efficient Ethern= et > wake mechanism. > > diff --git a/doc/guides/sample_app_ug/l2_forward_cat.rst b/doc/guides/sam= ple_app_ug/l2_forward_cat.rst > index 0a813200ba..2b4651e0fe 100644 > --- a/doc/guides/sample_app_ug/l2_forward_cat.rst > +++ b/doc/guides/sample_app_ug/l2_forward_cat.rst > @@ -198,7 +198,7 @@ queried for system CPU information and L3CA capabilit= ies via > ``pqos_cap_get(...)`` and ``pqos_cap_get_type(..., PQOS_CAP_TYPE_L3CA, .= ..)`` > calls. When all capability and topology information is collected, the re= quested > CAT configuration is validated. A check is then performed (on per socket= basis) > -for a sufficient number of un-associated COS. COS are selected and > +for a sufficient number of unassociated COS. COS are selected and > configured via the ``pqos_l3ca_set(...)`` call. Finally, COS are associa= ted to > relevant CPUs via ``pqos_l3ca_assoc_set(...)`` calls. > > diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides= /sample_app_ug/performance_thread.rst > index 5fed46465f..a2db452c01 100644 > --- a/doc/guides/sample_app_ug/performance_thread.rst > +++ b/doc/guides/sample_app_ug/performance_thread.rst > @@ -1194,7 +1194,7 @@ Tracing of events can be individually masked, and t= he mask may be programmed > at run time. An unmasked event results in a callback that provides infor= mation > about the event. The default callback simply prints trace information. T= he > default mask is 0 (all events off) the mask can be modified by calling t= he > -function ``lthread_diagniostic_set_mask()``. > +function ``lthread_diagnostic_set_mask()``. > > It is possible register a user callback function to implement more > sophisticated diagnostic functions. > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/tes= tpmd_app_ug/testpmd_funcs.rst > index 73ef0b41d3..a28f2ede9d 100644 > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > @@ -4732,7 +4732,7 @@ Sample Raw encapsulation rule > > Raw encapsulation configuration can be set by the following commands > > -Eecapsulating VxLAN:: > +Encapsulating VxLAN:: > > testpmd> set raw_encap 4 eth src is 10:11:22:33:44:55 / vlan tci is 1 > inner_type is 0x0800 / ipv4 / udp dst is 4789 / vxlan vni > -- > 2.25.1 > --=20 Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd