[dpdk-dev] [PATCH v6] eal: add manual probing option
From: Gaetan Rivet
Add a new EAL option enabling manual probing in the EAL.
This command line option will configure the EAL so that buses
will not trigger their probe step on their own.
Applications are then expected to hotplug devices as they see fit.
Devices declared on the command line by the user (using -w and --vdev),
will be probed using the hotplug API, in the order they are declared.
This has the effect of offering a way for users to control probe order
of their devices, for drivers requiring it.
Signed-off-by: Gaetan Rivet
Acked-by : Vamsi Attunuru
Tested-by: Vamsi Attunuru
Reviewed-by: Jerin Jacob
---
haven't heard many opinions on the matter, please shout if you see an issue
with this approach.
@Slava: I have tested rather quickly that it does not break anything,
and that it works as intended for basic cases.
Can you test it further for your use-case and tell me if it works fine?
Beyond the obvious difference between both probe mode, something to keep in
mind:
while using -w on invalid devices would not block (PCI) bus probing, it will
stop manual
probing in its track. All devices need to exist and be valid device IDs.
v2: fixed a few typos, map file (and used Travis to validate).
Slava, are you able to test this patch?
v3: properly fixed the map file (inherited 19.08 instead of 19.05).
Added a function to set the probe manual from the application,
without having the user do it from the command line.
Stopped spamming Slava about it, Vamsi was actually the one interested in
it!
Standing issue worth chiming in:
Currently manual-probe will cut off probing from all buses.
It could be interesting to be able to only cut buses supporting hotplug,
given that they are the one able to probe devices afterward.
No real use-case for this right now, so leaving as-is. Might be worth
considering in the future.
v4: Rebased on master,
Moved implementation in common EAL,
Used public API within the EAL to set the option,
Made the API experimental
v5: added note in the Getting Started Guide.
v6: Rebased on master
doc/guides/linux_gsg/eal_args.include.rst | 13 ++
doc/guides/rel_notes/release_20_02.rst | 9
lib/librte_eal/common/eal_common_bus.c | 6 +++
lib/librte_eal/common/eal_common_dev.c | 54 ++
lib/librte_eal/common/eal_common_options.c | 8
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 +
lib/librte_eal/common/eal_private.h| 9
lib/librte_eal/common/include/rte_eal.h| 36 +++
lib/librte_eal/rte_eal_version.map | 4 ++
10 files changed, 142 insertions(+)
diff --git a/doc/guides/linux_gsg/eal_args.include.rst
b/doc/guides/linux_gsg/eal_args.include.rst
index ed8b0e35b..d0717d4a0 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -69,6 +69,19 @@ Device-related options
--vdev 'net_pcap0,rx_pcap=input.pcap,tx_pcap=output.pcap'
+* ``--manual-probe``
+
+Switch the ``EAL`` probe mode to manual. The main bus probe step
+is disabled and applications are expected to manually probe
+devices using ``rte_dev_probe()``.
+
+Devices declared on the command-line using ``-w`` and ``-vdev``
+are interpreted as hotplug commands. They are thus probed in the
+order they are declared.
+
+This makes this option useful to enforce a specific device probe
+order, instead of relying on each bus scan implementation details.
+
* ``-d ``
Load external drivers. An argument can be a single shared object file, or a
diff --git a/doc/guides/rel_notes/release_20_02.rst
b/doc/guides/rel_notes/release_20_02.rst
index 0eaa45a76..624158486 100644
--- a/doc/guides/rel_notes/release_20_02.rst
+++ b/doc/guides/rel_notes/release_20_02.rst
@@ -56,6 +56,15 @@ New Features
Also, make sure to start the actual text at the margin.
=
+* **EAL will now allow probing devices manually.**
+
+ Previously, a user could not force an order when probing declared devices.
+ This could cause issues for drivers depending on another device being
present.
+ A new option ``--manual-probe`` is now available to do just that.
+ This new option relies on the device bus supporting hotplug. It can
+ also be used to disable automatic probing from the ``PCI`` bus without
+ having to disable the whole bus.
+
Removed Items
-
diff --git a/lib/librte_eal/common/eal_common_bus.c
b/lib/librte_eal/common/eal_common_bus.c
index baa5b532a..145a96812 100644
--- a/lib/librte_eal/common/eal_common_bus.c
+++ b/lib/librte_eal/common/eal_common_bus.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -63,6 +64,11 @@ rte_bus_probe(void)
int ret;
struct rte_bus *bus, *vbus = NULL;
+ if (rte_eal_manual_probe()) {
+
[dpdk-dev] [PATCH] mbuf: fix to update documentation of QinQ stripped bit interpretation
Certain hardware may be able to strip and/or save only the outermost VLAN instead of both the VLANs in the mbuf in a QinQ scenario. To handle such cases, we could re-interpret setting of just PKT_RX_QINQ_STRIPPED to indicate that only the outermost VLAN has been stripped and saved in mbuf->vlan_tci_outer. Only When both PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, the 2 VLANs have been stripped by the hardware and their TCI are saved in mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). Signed-off-by: Somnath Kotur --- lib/librte_mbuf/rte_mbuf_core.h | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h index 9a8557d..db1070b 100644 --- a/lib/librte_mbuf/rte_mbuf_core.h +++ b/lib/librte_mbuf/rte_mbuf_core.h @@ -124,12 +124,19 @@ #define PKT_RX_FDIR_FLX (1ULL << 14) /** - * The 2 vlans have been stripped by the hardware and their tci are - * saved in mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). + * The outer vlan has been stripped by the hardware and their tci are + * saved in mbuf->vlan_tci_outer (outer). * This can only happen if vlan stripping is enabled in the RX * configuration of the PMD. - * When PKT_RX_QINQ_STRIPPED is set, the flags (PKT_RX_VLAN | - * PKT_RX_VLAN_STRIPPED | PKT_RX_QINQ) must also be set. + * When PKT_RX_QINQ_STRIPPED is set, the flags (PKT_RX_VLAN | PKT_RX_QINQ) + * must also be set. + * When both PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, the 2 vlans + * have been stripped by the hardware and their tci are saved in + * mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). + * This can only happen if vlan stripping is enabled in the RX configuration + * of the PMD. + * When PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, + * (PKT_RX_VLAN | PKT_RX_QINQ) must also be set. */ #define PKT_RX_QINQ_STRIPPED (1ULL << 15) -- 1.8.3.1
Re: [dpdk-dev] [RFC PATCH] mbuf: fix to update documentation of PKT_RX_QINQ_STRIPPED
On Thu, Jan 2, 2020 at 6:35 PM Andrew Rybchenko wrote: > > Somnath, > > On 12/31/19 5:15 AM, Somnath Kotur wrote: > > Andrew, > > > > On Tue, Dec 24, 2019 at 3:23 PM Andrew Rybchenko > > wrote: > >> On 12/24/19 6:16 AM, Somnath Kotur wrote: > >>> Given that we haven't heard any objection from anyone in a while on > >>> this ...can we get this in please? > >> I'm sorry, but have you seen below? > >> It means that PKT_RX_QINQ_STRIPPED, PKT_RX_QINQ, PKT_RX_VLAN > >> and PKT_RX_VLAN_STRIPPED must be clarified. > >> > > OK, not sure I understood what is the next action here? Will you or someone > > from the main tree maintainers be sending out a patch with this > > clarification? > > Please, send non-RCF version of the patch which fixes > PKT_RX_QINQ_STRIPPED and PKT_RX_QINQ description. > PKT_RX_QINQ must not claim that both VLAN headers > have been stripped in the case of PKT_RX_QINQ_STRIPPED. > OK, think i've done the non-RFC patch based on my understanding here > I think that VLAN should be used instead of "vlan" in description > as well as TCI instead of "tci". Also vlans -> VLANs. > Done > >> It sounds like change of semantics in order to resolve the > >> problem, but anyway it is still a small change of semantics. > > May be dropped. > > >> BTW, it is better to make summary human readable and avoid > >> PKT_RX_QINQ_STRIPPED (I guess check-git-log.sh yells on it). > > Please, don't forget about it as well. Done > >> Also RFC patch cannot be applied, non-RFC version is required. > >> > >> CC main tree maintainers. > >> > >>> Thanks > >>> > >>> On Mon, Dec 16, 2019 at 2:43 PM Andrew Rybchenko > >>> wrote: > On 12/16/19 11:47 AM, Somnath Kotur wrote: > > On Mon, Dec 16, 2019 at 12:01 PM Andrew Rybchenko > > wrote: > >> On 12/16/19 6:16 AM, Somnath Kotur wrote: > >>> Certain hardware may be able to strip and/or save only the outermost > >>> VLAN instead of both the VLANs in the mbuf in a QinQ scenario. > >>> To handle such cases, we could re-interpret setting of just > >>> PKT_RX_QINQ_STRIPPED > >>> to indicate that only the outermost VLAN has been stripped by the > >>> hardware and > >>> saved in mbuf->vlan_tci_outer. > >>> Only When both PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, > >>> the 2 vlans > >>> have been stripped by the hardware and their tci are saved in > >>> mbuf->vlan_tci (inner) > >>> and mbuf->vlan_tci_outer (outer). > >>> > >>> Signed-off-by: Somnath Kotur > >>> Signed-off-by: JP Lee > >>> --- > >>> lib/librte_mbuf/rte_mbuf_core.h | 15 +++ > >>> 1 file changed, 11 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/lib/librte_mbuf/rte_mbuf_core.h > >>> b/lib/librte_mbuf/rte_mbuf_core.h > >>> index 9a8557d..db1070b 100644 > >>> --- a/lib/librte_mbuf/rte_mbuf_core.h > >>> +++ b/lib/librte_mbuf/rte_mbuf_core.h > >>> @@ -124,12 +124,19 @@ > >>> #define PKT_RX_FDIR_FLX (1ULL << 14) > >>> > >>> /** > >>> - * The 2 vlans have been stripped by the hardware and their tci are > >>> - * saved in mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). > >>> + * The outer vlan has been stripped by the hardware and their tci are > >>> + * saved in mbuf->vlan_tci_outer (outer). > >>> * This can only happen if vlan stripping is enabled in the RX > >>> * configuration of the PMD. > >>> - * When PKT_RX_QINQ_STRIPPED is set, the flags (PKT_RX_VLAN | > >>> - * PKT_RX_VLAN_STRIPPED | PKT_RX_QINQ) must also be set. > >>> + * When PKT_RX_QINQ_STRIPPED is set, the flags (PKT_RX_VLAN | > >>> PKT_RX_QINQ) > >>> + * must also be set. > >>> + * When both PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, > >>> the 2 vlans > >>> + * have been stripped by the hardware and their tci are saved in > >>> + * mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). > >>> + * This can only happen if vlan stripping is enabled in the RX > >>> configuration > >>> + * of the PMD. > >>> + * When PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, > >>> + * (PKT_RX_VLAN | PKT_RX_QINQ) must also be set. > >>> */ > >>> #define PKT_RX_QINQ_STRIPPED (1ULL << 15) > >>> > >> I always thought that PKT_RX_VLAN_STRIPPED means *one* VLAN > >> stripped regardless if it is outer (if the packet is double > >> tagged) or inner (if only one VLAN tag was present). > >> > >> That's why PKT_RX_QINQ_STRIPPED description says that *two* > >> VLANs have been stripped. > >> > >> What is the problem with such approach? > > The problem is that RX_VLAN_STRIPPED implies that the stripped VLAN > > (outer or inner) is saved in mbuf->vlan_tci, correct? > Yes. > > > There is no way to convey that it is in QinQ mode and yet only outer > > VLAN has been stripped and saved in mbuf->vlan_tci_outer ? > Ah, it looks like
Re: [dpdk-dev] [PATCH v6 3/4] net/ixgbe: cleanup Tx buffers
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Monday, January 6, 2020 7:36 AM
> To: Di, ChenxuX ; dev@dpdk.org
> Cc: Yang, Qiming
> Subject: RE: [dpdk-dev] [PATCH v6 3/4] net/ixgbe: cleanup Tx buffers
>
>
> > > > Add support to the ixgbe driver for the API
> > > > rte_eth_tx_done_cleanup to force free consumed buffers on Tx ring.
[snip]
> > > > + * tx_tail is the last sent packet on the sw_ring. Goto the end
> > > > + * of that packet (the last segment in the packet chain) and
> > > > + * then the next segment will be the start of the oldest segment
> > > > + * in the sw_ring.
> > >
> > > Not sure I understand the sentence above.
> > > tx_tail is the value of TDT HW register (most recently armed by SW TD).
> > > last_id is the index of last descriptor for multi-seg packet.
> > > next_id is just the index of next descriptor in HW TD ring.
> > > How do you conclude that it will be the ' oldest segment in the sw_ring'?
> > >
> >
> > The tx_tail is the last sent packet on the sw_ring. While the
> > xmit_cleanup or Tx_free_bufs will be call when the nb_tx_free <
> tx_free_thresh .
> > So the sw_ring[tx_tail].next_id must be the begin of mbufs which are
> > not used or Already freed . then begin the loop until the mbuf is used and
> begin to free them.
> >
> >
> >
> > > Another question why do you need to write your own functions?
> > > Why can't you reuse existing ixgbe_xmit_cleanup() for full(offload)
> > > path and
> > > ixgbe_tx_free_bufs() for simple path?
> > > Yes, ixgbe_xmit_cleanup() doesn't free mbufs, but at least it could
> > > be used to determine finished TX descriptors.
> > > Based on that you can you can free appropriate sw_ring[] entries.
> > >
> >
> > The reason why I don't reuse existing function is that they all free
> > several mbufs While the free_cnt of the API rte_eth_tx_done_cleanup() is the
> number of packets.
> > It also need to be done that check which mbuffs are from the same packet.
>
> At first, I don't see anything bad if tx_done_cleanup() will free only some
> segments from the packet. As long as it is safe - there is no problem with
> that.
> I think rte_eth_tx_done_cleanup() operates on mbuf, not packet quantities.
> But in our case I think it doesn't matter, as ixgbe_xmit_cleanup() mark TXDs
> as
> free only when HW is done with all TXDs for that packet.
> As long as there is a way to reuse existing code and avoid duplication
> (without
> introducing any degradation) - we should use it.
> And I think there is a very good opportunity here to reuse existing
> ixgbe_xmit_cleanup() for tx_done_cleanup() implementation.
> Moreover because your code doesn't follow
> ixgbe_xmit_pkts()/ixgbe_xmit_cleanup()
> logic and infrastructure, it introduces unnecessary scans over TXD ring, and
> in
> some cases doesn't work as expected:
>
> +while (1) {
> +tx_last = sw_ring[tx_id].last_id;
> +
> +if (sw_ring[tx_last].mbuf) {
> +if (txr[tx_last].wb.status &
> +IXGBE_TXD_STAT_DD) {
> ...
> +} else {
> +/*
> + * mbuf still in use, nothing left to
> + * free.
> + */
> +break;
>
> It is not correct to expect that IXGBE_TXD_STAT_DD will be set on last TXD for
> *every* packet.
> We set IXGBE_TXD_CMD_RS bit only on threshold packet last descriptor.
> Plus ixgbe_xmit_cleanup() can cleanup TXD wb.status.
>
> So I strongly recommend to reuse ixgbe_xmit_cleanup() here.
> It would be much less error prone and will help to avoid code duplication.
>
> Konstantin
>
At first.
The function ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq) will cleanup TXD
wb.status.
the number of status cleanuped is always txq->tx_rs_thresh.
The API rte_eth_tx_done_cleanup() in rte_eth_dev.h show that
@param free_cnt
* Maximum number of packets to free. Use 0 to indicate all possible
packets
* should be freed. Note that a packet may be using multiple mbufs.
a number must be set while ixgbe_xmit_cleanup and ixgbe_tx_free_bufs only have
one parameter txq.
And what should do is not only free buffers and status but also check which
bufs are from
One packet and count the packet freed.
So I think it can't be implemented that reuse function xmit_cleanup without
change it.
And create a new function with the code of xmit_cleanup will cause many
duplication.
Above all , it seem not a perfect idea to reuse ixgbe_xmit_cleanup().
Second.
The function in patch is copy from code in igb_rxtx.c. it already updated in
2017,
The commit id is 8d907d2b79f7a54c809f1c44970ff455fa2865e1.
I trust the logic of code is right.
Actually it don't complete for ixgbe, i40e and ice, while it don't change the
value of
last_desc_cleaned and tx_next_dd. And it's beginning prefer last_desc_cleaned or
tx_next_dd(for offload or simple) to tx_tail.
So, I suggest to use the old function and fix the issue.
> >
> >
> > > >This is the first packet that will be
> > > > + * attempted to be freed.
> > > > + */
> > > > +
> > > > +/* Get last segment in most recently added packet. */ tx_l
Re: [dpdk-dev] [PATCH] examples/fips_validation: fix parsing of cipher length for AES-GCM
> From: Sucharitha Sarananaga
>
> Cipher length need to be updated in case of AES-GCM decryption.
>
> Fixes: 4aaad2995e13 ("examples/fips_validation: support GCM parsing")
>
> Signed-off-by: Archana Muniganti
> Signed-off-by: Sucharitha Sarananaga
> ---
> examples/fips_validation/fips_validation_gcm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/examples/fips_validation/fips_validation_gcm.c
> b/examples/fips_validation/fips_validation_gcm.c
> index ea48ddf..f295025 100644
> --- a/examples/fips_validation/fips_validation_gcm.c
> +++ b/examples/fips_validation/fips_validation_gcm.c
> @@ -19,6 +19,7 @@
> #define PTLEN_STR"PTlen = "
> #define AADLEN_STR "AADlen = "
> #define TAGLEN_STR "Taglen = "
> +#define CTLEN_STR"PTlen = "
Typo. Should be CTlen
[dpdk-dev] Fwd: How to check the packets dropped by RED in DPDK?
Hi All, I am running the qos_sched sample application to see the RED packet drop. I am generating the traffic and sending the traffic via qos_sched application. As a result, 1. The application is showing the packet drop which is so high as shown in the below figure. 2. How to determine that the packets are dropped by the RED or TAIL drop method? Following is the output I am getting from an application on every second. *___* *RX port 1: rx: 22954 err: 0 no_mbuf: 0TX port 0: tx: 1088err: 0-+++| received | dropped |-+++ RX | 20476 | 0 |QOS+TX | 20476| 0 | pps:1093--+---+-+* ___ I have enabled RED from the configuration file by enabling following flags. *CONFIG_RTE_SCHED_RED=yCONFIG_RTE_SCHED_COLLECT_STATS=y* Please do help if you can. Thank you, Gokul
[dpdk-dev] Fwd: How to check the packets dropped by RED in DPDK?
Correcting the 'packet drop' mentioned in the previous mail. Hi All, I am running the qos_sched sample application to see the RED packet drop. I am generating the traffic and sending the traffic via qos_sched application. As a result, 1. The application is showing the packet drop which is so high as shown in the below figure. 2. How to determine that the packets are dropped by the RED or TAIL drop method? Following is the output I am getting from an application on every second. *___* *RX port 1: rx: 22954 err: 0 no_mbuf: 0TX port 0: tx: 1088err: 0-+++| received| dropped |-+++ RX | 20476 | 0 | QOS+TX | 20476| 19383 | pps:1093--+---+-+* ___ I have enabled RED from the configuration file by enabling following flags. *CONFIG_RTE_SCHED_RED=y* *CONFIG_RTE_SCHED_COLLECT_STATS=y* Please do help if you can. Thank you, Gokul
Re: [dpdk-dev] [PATCH] maintainers: add co-maintainer for flow API
On Sun, Dec 29, 2019 at 08:56:58AM +, Ori Kam wrote: > I volunteer to be co maintainer for the rte_flow lib. > > Signed-off-by: Ori Kam Welcome :) Acked-by: Adrien Mazarguil -- Adrien Mazarguil 6WIND
[dpdk-dev] [PATCH v3 1/6] raw/octeontx2_ep: add build infra and device probe
Add the OCTEON TX2 SDP EP device probe along with the build infrastructure for Make and meson builds. Signed-off-by: Mahipal Challa --- MAINTAINERS| 5 + config/common_base | 5 + doc/guides/rawdevs/index.rst | 1 + doc/guides/rawdevs/octeontx2_ep.rst| 41 +++ drivers/raw/Makefile | 1 + drivers/raw/meson.build| 1 + drivers/raw/octeontx2_ep/Makefile | 40 +++ drivers/raw/octeontx2_ep/meson.build | 6 + drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 132 + drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 21 .../rte_rawdev_octeontx2_ep_version.map| 4 + mk/rte.app.mk | 2 + 12 files changed, 259 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4395d8d..24f1240 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1173,6 +1173,11 @@ M: Vamsi Attunuru F: drivers/raw/octeontx2_dma/ F: doc/guides/rawdevs/octeontx2_dma.rst +Marvell OCTEON TX2 EP +M: Mahipal Challa +F: drivers/raw/octeontx2_ep/ +F: doc/guides/rawdevs/octeontx2_ep.rst + NTB M: Xiaoyun Li M: Jingjing Wu diff --git a/config/common_base b/config/common_base index 7dec7ed..8e7dad2 100644 --- a/config/common_base +++ b/config/common_base @@ -796,6 +796,11 @@ CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV=y CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV=y # +# Compile PMD for octeontx2 EP raw device +# +CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y + +# # Compile PMD for NTB raw device # CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y diff --git a/doc/guides/rawdevs/index.rst b/doc/guides/rawdevs/index.rst index 22bc013..f64ec44 100644 --- a/doc/guides/rawdevs/index.rst +++ b/doc/guides/rawdevs/index.rst @@ -17,3 +17,4 @@ application through rawdev API. ioat ntb octeontx2_dma +octeontx2_ep diff --git a/doc/guides/rawdevs/octeontx2_ep.rst b/doc/guides/rawdevs/octeontx2_ep.rst new file mode 100644 index 000..5f5ed01 --- /dev/null +++ b/doc/guides/rawdevs/octeontx2_ep.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2019 Marvell International Ltd. + +Marvell OCTEON TX2 End Point Rawdev Driver +== + +OCTEON TX2 has an internal SDP unit which provides End Point mode of operation +by exposing its IOQs to Host, IOQs are used for packet I/O between Host and +OCTEON TX2. Each OCTEON TX2 SDP PF supports a max of 128 VFs and Each VF is +associated with a set of IOQ pairs. + +Features + + +This OCTEON TX2 End Point mode PMD supports + +#. Packet Input - Host to OCTEON TX2 with direct data instruction mode. + +#. Packet Output - OCTEON TX2 to Host with info pointer mode. + +Config File Options +~~~ + +The following options can be modified in the ``config`` file. + +- ``CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV`` (default ``y``) + + Toggle compilation of the ``lrte_pmd_octeontx2_ep`` driver. + +Initialization +-- + +The number of SDP VFs enabled, can be controlled by setting sysfs +entry `sriov_numvfs` for the corresponding PF driver. + +.. code-block:: console + + echo > /sys/bus/pci/drivers/octeontx2-ep/\:04\:00.0/sriov_numvfs + +Once the required VFs are enabled, to be accessible from DPDK, VFs need to be +bound to vfio-pci driver. diff --git a/drivers/raw/Makefile b/drivers/raw/Makefile index 0b6d13d..80b043e 100644 --- a/drivers/raw/Makefile +++ b/drivers/raw/Makefile @@ -13,5 +13,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV) += ifpga DIRS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += ioat DIRS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += ntb DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV) += octeontx2_dma +DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) += octeontx2_ep include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/drivers/raw/meson.build b/drivers/raw/meson.build index d7037cd..bb57977 100644 --- a/drivers/raw/meson.build +++ b/drivers/raw/meson.build @@ -4,6 +4,7 @@ drivers = ['dpaa2_cmdif', 'dpaa2_qdma', 'ifpga', 'ioat', 'ntb', 'octeontx2_dma', + 'octeontx2_ep', 'skeleton'] std_deps = ['rawdev'] config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV' diff --git a/drivers/raw/octeontx2_ep/Makefile b/drivers/raw/octeontx2_ep/Makefile new file mode 100644 index 000..8cec6bd --- /dev/null +++ b/drivers/raw/octeontx2_ep/Makefile @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(C) 2019 Marvell International Ltd. +# + +include $(RTE_SDK)/mk/rte.vars.mk + +# Library name +LIB = librte_rawdev_octeontx2_ep.a + +# Build flags +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +CFLAGS += -I$(RTE_SDK)/drivers/common/octeontx2/ +CFLAGS += -I$(RTE_SDK)/drivers/raw/octeontx2_ep/ + +LDLIBS += -lrte_eal +LDLIBS += -lrte_rawdev +LDLIBS += -lrte_bus_pci +LDLIBS += -lrte_mempool +LDLIBS += -lrte_com
[dpdk-dev] [PATCH v3 0/6] OCTEON TX2 End Point Driver
This patchset adds support for OCTEON TX2 end point mode of operation. The driver implementation uses DPDK rawdevice sub-system. v2: * Updated memory barrior API's as per Gavin Hu suggestion. v3: * Fixed memory leak possibility issues. Mahipal Challa (6): raw/octeontx2_ep: add build infra and device probe raw/octeontx2_ep: add device configuration raw/octeontx2_ep: add device uninitialization raw/octeontx2_ep: add enqueue operation raw/octeontx2_ep: add dequeue operation raw/octeontx2_ep: add driver self test MAINTAINERS| 5 + config/common_base | 5 + doc/guides/rawdevs/index.rst | 1 + doc/guides/rawdevs/octeontx2_ep.rst| 89 +++ drivers/common/octeontx2/hw/otx2_sdp.h | 184 + drivers/common/octeontx2/otx2_common.c | 9 + drivers/common/octeontx2/otx2_common.h | 4 + .../octeontx2/rte_common_octeontx2_version.map | 6 + drivers/raw/Makefile | 1 + drivers/raw/meson.build| 1 + drivers/raw/octeontx2_ep/Makefile | 44 ++ drivers/raw/octeontx2_ep/meson.build | 9 + drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 844 + drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 52 ++ drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 361 + drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 499 drivers/raw/octeontx2_ep/otx2_ep_test.c| 166 drivers/raw/octeontx2_ep/otx2_ep_vf.c | 476 drivers/raw/octeontx2_ep/otx2_ep_vf.h | 10 + .../rte_rawdev_octeontx2_ep_version.map| 4 + mk/rte.app.mk | 2 + 21 files changed, 2772 insertions(+) create mode 100644 doc/guides/rawdevs/octeontx2_ep.rst create mode 100644 drivers/common/octeontx2/hw/otx2_sdp.h create mode 100644 drivers/raw/octeontx2_ep/Makefile create mode 100644 drivers/raw/octeontx2_ep/meson.build create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_rawdev.c create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_rawdev.h create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_test.c create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_vf.c create mode 100644 drivers/raw/octeontx2_ep/otx2_ep_vf.h create mode 100644 drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map -- 1.8.3.1
[dpdk-dev] [PATCH v3 3/6] raw/octeontx2_ep: add device uninitialization
Add rawdev close/uninitialize operation for SDP
VF devices.
Signed-off-by: Mahipal Challa
---
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 111 ++
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 78 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 8 +++
drivers/raw/octeontx2_ep/otx2_ep_vf.c | 44
4 files changed, 241 insertions(+)
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
index 8857004..584b818 100644
--- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
+++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
@@ -21,6 +21,59 @@
#include "otx2_common.h"
#include "otx2_ep_enqdeq.h"
+static void
+sdp_dmazone_free(const struct rte_memzone *mz)
+{
+ const struct rte_memzone *mz_tmp;
+ int ret = 0;
+
+ if (mz == NULL) {
+ otx2_err("Memzone %s : NULL", mz->name);
+ return;
+ }
+
+ mz_tmp = rte_memzone_lookup(mz->name);
+ if (mz_tmp == NULL) {
+ otx2_err("Memzone %s Not Found", mz->name);
+ return;
+ }
+
+ ret = rte_memzone_free(mz);
+ if (ret)
+ otx2_err("Memzone free failed : ret = %d", ret);
+
+}
+
+/* Free IQ resources */
+int
+sdp_delete_iqs(struct sdp_device *sdpvf, uint32_t iq_no)
+{
+ struct sdp_instr_queue *iq;
+
+ iq = sdpvf->instr_queue[iq_no];
+ if (iq == NULL) {
+ otx2_err("Invalid IQ[%d]\n", iq_no);
+ return -ENOMEM;
+ }
+
+ rte_free(iq->req_list);
+ iq->req_list = NULL;
+
+ if (iq->iq_mz) {
+ sdp_dmazone_free(iq->iq_mz);
+ iq->iq_mz = NULL;
+ }
+
+ rte_free(sdpvf->instr_queue[iq_no]);
+ sdpvf->instr_queue[iq_no] = NULL;
+
+ sdpvf->num_iqs--;
+
+ otx2_info("IQ[%d] is deleted", iq_no);
+
+ return 0;
+}
+
/* IQ initialization */
static int
sdp_init_instr_queue(struct sdp_device *sdpvf, int iq_no)
@@ -126,6 +179,7 @@
return 0;
delete_IQ:
+ sdp_delete_iqs(sdpvf, iq_no);
return -ENOMEM;
}
@@ -139,6 +193,61 @@
rte_atomic64_set(&droq->pkts_pending, 0);
}
+static void
+sdp_droq_destroy_ring_buffers(struct sdp_device *sdpvf,
+ struct sdp_droq *droq)
+{
+ uint32_t idx;
+
+ for (idx = 0; idx < droq->nb_desc; idx++) {
+ if (droq->recv_buf_list[idx].buffer) {
+ rte_mempool_put(sdpvf->enqdeq_mpool,
+ droq->recv_buf_list[idx].buffer);
+
+ droq->recv_buf_list[idx].buffer = NULL;
+ }
+ }
+
+ sdp_droq_reset_indices(droq);
+}
+
+/* Free OQs resources */
+int
+sdp_delete_oqs(struct sdp_device *sdpvf, uint32_t oq_no)
+{
+ struct sdp_droq *droq;
+
+ droq = sdpvf->droq[oq_no];
+ if (droq == NULL) {
+ otx2_err("Invalid droq[%d]", oq_no);
+ return -ENOMEM;
+ }
+
+ sdp_droq_destroy_ring_buffers(sdpvf, droq);
+ rte_free(droq->recv_buf_list);
+ droq->recv_buf_list = NULL;
+
+ if (droq->info_mz) {
+ sdp_dmazone_free(droq->info_mz);
+ droq->info_mz = NULL;
+ }
+
+ if (droq->desc_ring_mz) {
+ sdp_dmazone_free(droq->desc_ring_mz);
+ droq->desc_ring_mz = NULL;
+ }
+
+ memset(droq, 0, SDP_DROQ_SIZE);
+
+ rte_free(sdpvf->droq[oq_no]);
+ sdpvf->droq[oq_no] = NULL;
+
+ sdpvf->num_oqs--;
+
+ otx2_info("OQ[%d] is deleted", oq_no);
+ return 0;
+}
+
static int
sdp_droq_setup_ring_buffers(struct sdp_device *sdpvf,
struct sdp_droq *droq)
@@ -290,5 +399,7 @@
return 0;
delete_OQ:
+ sdp_delete_oqs(sdpvf, oq_no);
return -ENOMEM;
}
+
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
index 0c56609..3db5a74 100644
--- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
+++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
@@ -63,6 +63,45 @@
}
static int
+sdp_vfdev_exit(struct rte_rawdev *rawdev)
+{
+ struct sdp_device *sdpvf;
+ uint32_t rawdev_queues, q;
+
+ otx2_info("%s:", __func__);
+
+ sdpvf = (struct sdp_device *)rawdev->dev_private;
+
+ sdpvf->fn_list.disable_io_queues(sdpvf);
+
+ rawdev_queues = sdpvf->num_oqs;
+ for (q = 0; q < rawdev_queues; q++) {
+ if (sdp_delete_oqs(sdpvf, q)) {
+ otx2_err("Failed to delete OQ:%d", q);
+ return -ENOMEM;
+ }
+ }
+ otx2_info("Num OQs:%d freed", sdpvf->num_oqs);
+
+ /* Free the oqbuf_pool */
+ rte_mempool_free(sdpvf->enqdeq_mpool);
+ sdpvf->enqdeq_mpool = NULL;
+
+ otx2_info("Enqdeq_mpool free done");
+
+ rawdev_queues = sdpvf->num_iqs;
+ for (q = 0; q < rawdev_queues; q++) {
+ if (sdp_delete_iqs(sdpvf, q)) {
+
[dpdk-dev] [PATCH v3 2/6] raw/octeontx2_ep: add device configuration
Register "dev_configure" API to configure/initialize the SDP
VF PCIe devices.
Signed-off-by: Mahipal Challa
---
doc/guides/rawdevs/octeontx2_ep.rst| 29 ++
drivers/common/octeontx2/hw/otx2_sdp.h | 184 +
drivers/common/octeontx2/otx2_common.c | 9 +
drivers/common/octeontx2/otx2_common.h | 4 +
.../octeontx2/rte_common_octeontx2_version.map | 6 +
drivers/raw/octeontx2_ep/Makefile | 3 +
drivers/raw/octeontx2_ep/meson.build | 4 +-
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 294 ++
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 11 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 148 +++
drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 434 -
drivers/raw/octeontx2_ep/otx2_ep_vf.c | 408 +++
drivers/raw/octeontx2_ep/otx2_ep_vf.h | 10 +
13 files changed, 1542 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
b/doc/guides/rawdevs/octeontx2_ep.rst
index 5f5ed01..2507fcf 100644
--- a/doc/guides/rawdevs/octeontx2_ep.rst
+++ b/doc/guides/rawdevs/octeontx2_ep.rst
@@ -39,3 +39,32 @@ entry `sriov_numvfs` for the corresponding PF driver.
Once the required VFs are enabled, to be accessible from DPDK, VFs need to be
bound to vfio-pci driver.
+
+Device Setup
+
+
+The OCTEON TX2 SDP End Point VF devices will need to be bound to a
+user-space IO driver for use. The script ``dpdk-devbind.py`` script
+included with DPDK can be used to view the state of the devices and to bind
+them to a suitable DPDK-supported kernel driver. When querying the status
+of the devices, they will appear under the category of "Misc (rawdev)
+devices", i.e. the command ``dpdk-devbind.py --status-dev misc`` can be
+used to see the state of those devices alone.
+
+Device Configuration
+
+
+Configuring SDP EP rawdev device is done using the ``rte_rawdev_configure()``
+API, which takes the mempool as parameter. PMD uses this pool to send/receive
+packets to/from the HW.
+
+The following code shows how the device is configured
+
+.. code-block:: c
+
+ struct sdp_rawdev_info config = {0};
+ struct rte_rawdev_info rdev_info = {.dev_private = &config};
+ config.enqdeq_mpool = (void *)rte_mempool_create(...);
+
+ rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
+
diff --git a/drivers/common/octeontx2/hw/otx2_sdp.h
b/drivers/common/octeontx2/hw/otx2_sdp.h
new file mode 100644
index 000..1e690f8
--- /dev/null
+++ b/drivers/common/octeontx2/hw/otx2_sdp.h
@@ -0,0 +1,184 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#ifndef __OTX2_SDP_HW_H_
+#define __OTX2_SDP_HW_H_
+
+/* SDP VF IOQs */
+#define SDP_MIN_RINGS_PER_VF(1)
+#define SDP_MAX_RINGS_PER_VF(8)
+
+/* SDP VF IQ configuration */
+#define SDP_VF_MAX_IQ_DESCRIPTORS (512)
+#define SDP_VF_MIN_IQ_DESCRIPTORS (128)
+
+#define SDP_VF_DB_MIN (1)
+#define SDP_VF_DB_TIMEOUT (1)
+#define SDP_VF_INTR_THRESHOLD (0x)
+
+#define SDP_VF_64BYTE_INSTR (64)
+#define SDP_VF_32BYTE_INSTR (32)
+
+/* SDP VF OQ configuration */
+#define SDP_VF_MAX_OQ_DESCRIPTORS (512)
+#define SDP_VF_MIN_OQ_DESCRIPTORS (128)
+#define SDP_VF_OQ_BUF_SIZE (2048)
+#define SDP_VF_OQ_REFIL_THRESHOLD (16)
+
+#define SDP_VF_OQ_INFOPTR_MODE (1)
+#define SDP_VF_OQ_BUFPTR_MODE (0)
+
+#define SDP_VF_OQ_INTR_PKT (1)
+#define SDP_VF_OQ_INTR_TIME (10)
+#define SDP_VF_CFG_IO_QUEUESSDP_MAX_RINGS_PER_VF
+
+/* Wait time in milliseconds for FLR */
+#define SDP_VF_PCI_FLR_WAIT (100)
+#define SDP_VF_BUSY_LOOP_COUNT (1)
+
+#define SDP_VF_MAX_IO_QUEUESSDP_MAX_RINGS_PER_VF
+#define SDP_VF_MIN_IO_QUEUESSDP_MIN_RINGS_PER_VF
+
+/* SDP VF IOQs per rawdev */
+#define SDP_VF_MAX_IOQS_PER_RAWDEV SDP_VF_MAX_IO_QUEUES
+#define SDP_VF_DEFAULT_IOQS_PER_RAWDEV SDP_VF_MIN_IO_QUEUES
+
+/* SDP VF Register definitions */
+#define SDP_VF_RING_OFFSET(0x1ull << 17)
+
+/* SDP VF IQ Registers */
+#define SDP_VF_R_IN_CONTROL_START (0x1)
+#define SDP_VF_R_IN_ENABLE_START (0x10010)
+#define SDP_VF_R_IN_INSTR_BADDR_START (0x10020)
+#define SDP_VF_R_IN_INSTR_RSIZE_START (0x10030)
+#define SDP_VF_R_IN_INSTR_DBELL_START (0x10040)
+#define SDP_VF_R_IN_CNTS_START(0x10050)
+#define SDP_VF_R_IN_INT_LEVELS_START (0x10060)
+#define SDP_VF_R_IN_PKT_CNT_START (0x10080)
+#define SDP_VF_R_IN_BYTE_CNT_START(0x10090)
+
+#define SDP_VF_R_IN_CONTROL(ring) \
+ (SDP_VF_R_IN_CONTROL_START + ((ring) * SDP_VF_RING_OFFSET))
+
+#define SDP_VF_R_IN_ENABLE(ring) \
+ (SDP_VF_R_IN_ENABLE_START + ((ring) * SDP_VF_RING_OFFSET))
+
+#define SDP_VF_R_IN_INSTR_BADDR(ring) \
+ (SDP_VF_R_IN_INSTR_BADDR_START
[dpdk-dev] [PATCH v3 4/6] raw/octeontx2_ep: add enqueue operation
Add rawdev enqueue operation for SDP VF devices.
Signed-off-by: Mahipal Challa
---
doc/guides/rawdevs/octeontx2_ep.rst | 6 +
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 242 ++
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 39 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 20 +++
drivers/raw/octeontx2_ep/otx2_ep_vf.c | 24 +++
6 files changed, 332 insertions(+)
diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
b/doc/guides/rawdevs/octeontx2_ep.rst
index 2507fcf..39a7c29 100644
--- a/doc/guides/rawdevs/octeontx2_ep.rst
+++ b/doc/guides/rawdevs/octeontx2_ep.rst
@@ -68,3 +68,9 @@ The following code shows how the device is configured
rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
+Performing Data Transfer
+
+
+To perform data transfer using SDP VF EP rawdev devices use standard
+``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()`` APIs.
+
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
index 584b818..6910f08 100644
--- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
+++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
@@ -403,3 +403,245 @@
return -ENOMEM;
}
+static inline void
+sdp_iqreq_delete(struct sdp_device *sdpvf,
+ struct sdp_instr_queue *iq, uint32_t idx)
+{
+ uint32_t reqtype;
+ void *buf;
+
+ buf = iq->req_list[idx].buf;
+ reqtype = iq->req_list[idx].reqtype;
+
+ switch (reqtype) {
+ case SDP_REQTYPE_NORESP:
+ rte_mempool_put(sdpvf->enqdeq_mpool, buf);
+ otx2_sdp_dbg("IQ buffer freed at idx[%d]", idx);
+ break;
+
+ case SDP_REQTYPE_NORESP_GATHER:
+ case SDP_REQTYPE_NONE:
+ default:
+ otx2_info("This iqreq mode is not supported:%d", reqtype);
+
+ }
+
+ /* Reset the request list at this index */
+ iq->req_list[idx].buf = NULL;
+ iq->req_list[idx].reqtype = 0;
+}
+
+static inline void
+sdp_iqreq_add(struct sdp_instr_queue *iq, void *buf,
+ uint32_t reqtype)
+{
+ iq->req_list[iq->host_write_index].buf = buf;
+ iq->req_list[iq->host_write_index].reqtype = reqtype;
+
+ otx2_sdp_dbg("IQ buffer added at idx[%d]", iq->host_write_index);
+
+}
+
+static void
+sdp_flush_iq(struct sdp_device *sdpvf,
+ struct sdp_instr_queue *iq,
+ uint32_t pending_thresh __rte_unused)
+{
+ uint32_t instr_processed = 0;
+
+ rte_spinlock_lock(&iq->lock);
+
+ iq->otx_read_index = sdpvf->fn_list.update_iq_read_idx(iq);
+ while (iq->flush_index != iq->otx_read_index) {
+ /* Free the IQ data buffer to the pool */
+ sdp_iqreq_delete(sdpvf, iq, iq->flush_index);
+ iq->flush_index =
+ sdp_incr_index(iq->flush_index, 1, iq->nb_desc);
+
+ instr_processed++;
+ }
+
+ iq->stats.instr_processed = instr_processed;
+ rte_atomic64_sub(&iq->instr_pending, instr_processed);
+
+ rte_spinlock_unlock(&iq->lock);
+}
+
+static inline void
+sdp_ring_doorbell(struct sdp_device *sdpvf __rte_unused,
+ struct sdp_instr_queue *iq)
+{
+ otx2_write64(iq->fill_cnt, iq->doorbell_reg);
+
+ /* Make sure doorbell write goes through */
+ rte_cio_wmb();
+ iq->fill_cnt = 0;
+
+}
+
+static inline int
+post_iqcmd(struct sdp_instr_queue *iq, uint8_t *iqcmd)
+{
+ uint8_t *iqptr, cmdsize;
+
+ /* This ensures that the read index does not wrap around to
+* the same position if queue gets full before OCTEON TX2 could
+* fetch any instr.
+*/
+ if (rte_atomic64_read(&iq->instr_pending) >=
+ (int32_t)(iq->nb_desc - 1)) {
+ otx2_err("IQ is full, pending:%ld",
+(long)rte_atomic64_read(&iq->instr_pending));
+
+ return SDP_IQ_SEND_FAILED;
+ }
+
+ /* Copy cmd into iq */
+ cmdsize = ((iq->iqcmd_64B) ? 64 : 32);
+ iqptr = iq->base_addr + (cmdsize * iq->host_write_index);
+
+ rte_memcpy(iqptr, iqcmd, cmdsize);
+
+ otx2_sdp_dbg("IQ cmd posted @ index:%d", iq->host_write_index);
+
+ /* Increment the host write index */
+ iq->host_write_index =
+ sdp_incr_index(iq->host_write_index, 1, iq->nb_desc);
+
+ iq->fill_cnt++;
+
+ /* Flush the command into memory. We need to be sure the data
+* is in memory before indicating that the instruction is
+* pending.
+*/
+ rte_io_wmb();
+ rte_atomic64_inc(&iq->instr_pending);
+
+ /* SDP_IQ_SEND_SUCCESS */
+ return 0;
+}
+
+
+static int
+sdp_send_data(struct sdp_device *sdpvf,
+ struct sdp_instr_queue *iq, void *cmd)
+{
+ uint32_t ret;
+
+ /* Lock this IQ command queue before posting instruction */
+ rte_
[dpdk-dev] [PATCH v3 6/6] raw/octeontx2_ep: add driver self test
Add rawdev's selftest feature in SDP VF driver, which
verifies the EP mode functionality test.
Signed-off-by: Mahipal Challa
---
doc/guides/rawdevs/octeontx2_ep.rst | 13 +++
drivers/raw/octeontx2_ep/Makefile | 1 +
drivers/raw/octeontx2_ep/meson.build | 1 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 2 +
drivers/raw/octeontx2_ep/otx2_ep_test.c | 166 ++
6 files changed, 184 insertions(+)
diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
b/doc/guides/rawdevs/octeontx2_ep.rst
index 39a7c29..bbcf530 100644
--- a/doc/guides/rawdevs/octeontx2_ep.rst
+++ b/doc/guides/rawdevs/octeontx2_ep.rst
@@ -74,3 +74,16 @@ Performing Data Transfer
To perform data transfer using SDP VF EP rawdev devices use standard
``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()`` APIs.
+Self test
+-
+
+On EAL initialization, SDP VF devices will be probed and populated into the
+raw devices. The rawdev ID of the device can be obtained using
+
+* Invoke ``rte_rawdev_get_dev_id("SDPEP:x")`` from the test application
+ where x is the VF device's bus id specified in "bus:device.func"(BDF)
+ format. Use this index for further rawdev function calls.
+
+* The driver's selftest rawdev API can be used to verify the SDP EP mode
+ functional tests which can send/receive the raw data packets to/from the
+ EP device.
diff --git a/drivers/raw/octeontx2_ep/Makefile
b/drivers/raw/octeontx2_ep/Makefile
index 02853fb..44fdf89 100644
--- a/drivers/raw/octeontx2_ep/Makefile
+++ b/drivers/raw/octeontx2_ep/Makefile
@@ -37,6 +37,7 @@ LIBABIVER := 1
#
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) += otx2_ep_rawdev.c
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) += otx2_ep_enqdeq.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) += otx2_ep_test.c
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) += otx2_ep_vf.c
diff --git a/drivers/raw/octeontx2_ep/meson.build
b/drivers/raw/octeontx2_ep/meson.build
index 99e6c6d..0e6338f 100644
--- a/drivers/raw/octeontx2_ep/meson.build
+++ b/drivers/raw/octeontx2_ep/meson.build
@@ -5,4 +5,5 @@
deps += ['bus_pci', 'common_octeontx2', 'rawdev']
sources = files('otx2_ep_rawdev.c',
'otx2_ep_enqdeq.c',
+ 'otx2_ep_test.c',
'otx2_ep_vf.c')
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
index 7158b97..0778603 100644
--- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
+++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
@@ -253,6 +253,7 @@
.dev_close = sdp_rawdev_close,
.enqueue_bufs = sdp_rawdev_enqueue,
.dequeue_bufs = sdp_rawdev_dequeue,
+ .dev_selftest = sdp_rawdev_selftest,
};
static int
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
index a77cbab..dab2fb7 100644
--- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
+++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
@@ -494,4 +494,6 @@ int sdp_rawdev_enqueue(struct rte_rawdev *dev, struct
rte_rawdev_buf **buffers,
int sdp_rawdev_dequeue(struct rte_rawdev *dev, struct rte_rawdev_buf **buffers,
unsigned int count, rte_rawdev_obj_t context);
+int sdp_rawdev_selftest(uint16_t dev_id);
+
#endif /* _OTX2_EP_RAWDEV_H_ */
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_test.c
b/drivers/raw/octeontx2_ep/otx2_ep_test.c
new file mode 100644
index 000..fc913a6
--- /dev/null
+++ b/drivers/raw/octeontx2_ep/otx2_ep_test.c
@@ -0,0 +1,166 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "otx2_common.h"
+#include "otx2_ep_rawdev.h"
+
+#define SDP_IOQ_NUM_BUFS (4 * 1024)
+#define SDP_IOQ_BUF_SIZE (2 * 1024)
+
+#define SDP_TEST_PKT_FSZ (0)
+#define SDP_TEST_PKT_SIZE (1024)
+
+static int
+sdp_validate_data(struct sdp_droq_pkt *oq_pkt, uint8_t *iq_pkt,
+ uint32_t pkt_len)
+{
+ if (!oq_pkt)
+ return -EINVAL;
+
+ if (pkt_len != oq_pkt->len) {
+ otx2_err("Invalid packet length");
+ return -EINVAL;
+ }
+
+ if (memcmp(oq_pkt->data, iq_pkt, pkt_len) != 0) {
+ otx2_err("Data validation failed");
+ return -EINVAL;
+ }
+ otx2_sdp_dbg("Data validation successful");
+
+ return 0;
+}
+
+static void
+sdp_ioq_buffer_fill(uint8_t *addr, uint32_t len)
+{
+ uint32_t idx;
+
+ memset(addr, 0, len);
+
+ for (idx = 0; idx < len; idx++)
+ addr[idx] = idx;
+}
+
+static struct rte_mempool*
+sdp_ioq_mempool_create(void)
+{
+ struct rte_mempool *mpool;
+
+ mpool = rte_mempool_create("ioqbuf_pool",
+ SDP_IOQ_NUM_BUFS /*num elt*/,
+ SDP_IOQ_BUF
[dpdk-dev] [PATCH v3 5/6] raw/octeontx2_ep: add dequeue operation
Add rawdev dequeue operation for SDP VF devices.
Signed-off-by: Mahipal Challa
---
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 197 ++
drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 2 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 18 ++-
4 files changed, 217 insertions(+), 1 deletion(-)
diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
index 6910f08..dd270b5 100644
--- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
+++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
@@ -260,6 +260,7 @@
rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
if (buf == NULL) {
otx2_err("OQ buffer alloc failed");
+ droq->stats.rx_alloc_failure++;
/* sdp_droq_destroy_ring_buffers(droq);*/
return -ENOMEM;
}
@@ -645,3 +646,199 @@
return SDP_IQ_SEND_FAILED;
}
+static uint32_t
+sdp_droq_refill(struct sdp_device *sdpvf, struct sdp_droq *droq)
+{
+ struct sdp_droq_desc *desc_ring;
+ uint32_t desc_refilled = 0;
+ void *buf = NULL;
+
+ desc_ring = droq->desc_ring;
+
+ while (droq->refill_count && (desc_refilled < droq->nb_desc)) {
+ /* If a valid buffer exists (happens if there is no dispatch),
+* reuse the buffer, else allocate.
+*/
+ if (droq->recv_buf_list[droq->refill_idx].buffer != NULL)
+ break;
+
+ rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
+ /* If a buffer could not be allocated, no point in
+* continuing
+*/
+ if (buf == NULL) {
+ droq->stats.rx_alloc_failure++;
+ break;
+ }
+
+ droq->recv_buf_list[droq->refill_idx].buffer = buf;
+ desc_ring[droq->refill_idx].buffer_ptr = rte_mem_virt2iova(buf);
+
+ /* Reset any previous values in the length field. */
+ droq->info_list[droq->refill_idx].length = 0;
+
+ droq->refill_idx = sdp_incr_index(droq->refill_idx, 1,
+ droq->nb_desc);
+
+ desc_refilled++;
+ droq->refill_count--;
+
+ }
+
+ return desc_refilled;
+}
+
+static int
+sdp_droq_read_packet(struct sdp_device *sdpvf __rte_unused,
+struct sdp_droq *droq,
+struct sdp_droq_pkt *droq_pkt)
+{
+ struct sdp_droq_info *info;
+ uint32_t total_len = 0;
+ uint32_t pkt_len = 0;
+
+ info = &droq->info_list[droq->read_idx];
+ sdp_swap_8B_data((uint64_t *)&info->length, 1);
+ if (!info->length) {
+ otx2_err("OQ info_list->length[%ld]", (long)info->length);
+ goto oq_read_fail;
+ }
+
+ /* Deduce the actual data size */
+ info->length -= SDP_RH_SIZE;
+ total_len += (uint32_t)info->length;
+
+ otx2_sdp_dbg("OQ: pkt_len[%ld], buffer_size %d",
+ (long)info->length, droq->buffer_size);
+ if (info->length > droq->buffer_size) {
+ otx2_err("This mode is not supported: pkt_len > buffer_size");
+ goto oq_read_fail;
+ }
+
+ if (info->length <= droq->buffer_size) {
+ pkt_len = (uint32_t)info->length;
+ droq_pkt->data = droq->recv_buf_list[droq->read_idx].buffer;
+ droq_pkt->len = pkt_len;
+
+ droq->recv_buf_list[droq->read_idx].buffer = NULL;
+ droq->read_idx = sdp_incr_index(droq->read_idx, 1,/* count */
+ droq->nb_desc /* max rd idx */);
+ droq->refill_count++;
+
+ }
+
+ info->length = 0;
+
+ return SDP_OQ_RECV_SUCCESS;
+
+oq_read_fail:
+ return SDP_OQ_RECV_FAILED;
+}
+
+static inline uint32_t
+sdp_check_droq_pkts(struct sdp_droq *droq, uint32_t burst_size)
+{
+ uint32_t min_pkts = 0;
+ uint32_t new_pkts;
+ uint32_t pkt_count;
+
+ /* Latest available OQ packets */
+ pkt_count = rte_read32(droq->pkts_sent_reg);
+
+ /* Newly arrived packets */
+ new_pkts = pkt_count - droq->last_pkt_count;
+ otx2_sdp_dbg("Recvd [%d] new OQ pkts", new_pkts);
+
+ min_pkts = (new_pkts > burst_size) ? burst_size : new_pkts;
+ if (min_pkts) {
+ rte_atomic64_add(&droq->pkts_pending, min_pkts);
+ /* Back up the aggregated packet count so far */
+ droq->last_pkt_count += min_pkts;
+ }
+
+ return min_pkts;
+}
+
+/* Check for response arrival from OCTEON TX2
+ * returns number of requests completed
+ */
+int
+sdp_rawdev_dequeue(struct rte_rawdev *rawdev,
+ struct rte_rawdev_buf **buffers, unsigned int count,
+ rte_rawdev_obj_t context __rte_unuse
Re: [dpdk-dev] [PATCH v2 10/11] examples/l3fwd: add graceful teardown for eventdevice
> >> Add graceful teardown that addresses both event mode and poll
> >mode.
> >>
> >> Signed-off-by: Pavan Nikhilesh
> >> ---
> >> examples/l3fwd/main.c | 49 ++-
> >
> >> 1 file changed, 34 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> >> index 0ae64dd41..68998f42c 100644
> >> --- a/examples/l3fwd/main.c
> >> +++ b/examples/l3fwd/main.c
> >> @@ -920,7 +920,7 @@ main(int argc, char **argv)
> >>struct lcore_conf *qconf;
> >>struct rte_eth_dev_info dev_info;
> >>struct rte_eth_txconf *txconf;
> >> - int ret;
> >> + int i, ret;
> >>unsigned nb_ports;
> >>uint16_t queueid, portid;
> >>unsigned lcore_id;
> >> @@ -1195,27 +1195,46 @@ main(int argc, char **argv)
> >>}
> >>}
> >>
> >> -
> >>check_all_ports_link_status(enabled_port_mask);
> >>
> >>ret = 0;
> >>/* launch per-lcore init on every lcore */
> >>rte_eal_mp_remote_launch(l3fwd_lkp.main_loop, NULL,
> >CALL_MASTER);
> >> - RTE_LCORE_FOREACH_SLAVE(lcore_id) {
> >> - if (rte_eal_wait_lcore(lcore_id) < 0) {
> >> - ret = -1;
> >> - break;
> >> + if (evt_rsrc->enabled) {
> >> + for (i = 0; i < evt_rsrc->rx_adptr.nb_rx_adptr; i++)
> >> + rte_event_eth_rx_adapter_stop(
> >> + evt_rsrc->rx_adptr.rx_adptr[i]);
> >> + for (i = 0; i < evt_rsrc->tx_adptr.nb_tx_adptr; i++)
> >> + rte_event_eth_tx_adapter_stop(
> >> + evt_rsrc->tx_adptr.tx_adptr[i]);
> >> +
> >> + RTE_ETH_FOREACH_DEV(portid) {
> >> + if ((enabled_port_mask & (1 << portid)) == 0)
> >> + continue;
> >> + rte_eth_dev_stop(portid);
> >>}
> >> - }
> >>
> >> - /* stop ports */
> >> - RTE_ETH_FOREACH_DEV(portid) {
> >> - if ((enabled_port_mask & (1 << portid)) == 0)
> >> - continue;
> >> - printf("Closing port %d...", portid);
> >> - rte_eth_dev_stop(portid);
> >> - rte_eth_dev_close(portid);
> >> - printf(" Done\n");
> >
> >Why to stop ports *before* making sure all lcores are stopped?
> >Shouldn't that peace of code be identical for both poll and event mode?
> >Something like:
> >rte_eal_mp_wait_lcore();
> >
> >RTE_ETH_FOREACH_DEV(portid) {
> >if ((enabled_port_mask & (1 << portid)) == 0)
> >continue;
> >rte_eth_dev_stop(portid);
> >rte_eth_dev_close(portid);
> >}
> >?
> >
>
> Event dev spec requires stopping producers before consumers else we might run
> into
> deadlock in some cases.
Ok... but for TX path wouldn't core be a producer?
Also for that wouldn't rte_event_eth_(rx|tx)_adapter_stop(0 be enough?
I am not familiar with event-dev spec at all, so forgive for possibly dumb
questions 😉
>
> >> + rte_eal_mp_wait_lcore();
> >> + RTE_ETH_FOREACH_DEV(portid) {
> >> + if ((enabled_port_mask & (1 << portid)) == 0)
> >> + continue;
> >> + rte_eth_dev_close(portid);
> >> + }
> >> +
> >> + rte_event_dev_stop(evt_rsrc->event_d_id);
> >> + rte_event_dev_close(evt_rsrc->event_d_id);
> >> +
> >> + } else {
> >> + rte_eal_mp_wait_lcore();
> >> +
> >> + RTE_ETH_FOREACH_DEV(portid) {
> >> + if ((enabled_port_mask & (1 << portid)) == 0)
> >> + continue;
> >> + printf("Closing port %d...", portid);
> >> + rte_eth_dev_stop(portid);
> >> + rte_eth_dev_close(portid);
> >> + printf(" Done\n");
> >> + }
> >>}
> >>printf("Bye...\n");
> >>
> >> --
> >> 2.17.1
Re: [dpdk-dev] [PATCH v2 09/11] examples/l3fwd: add event em main loop
> > >> Add em main loop for handling events based on capabilities of the > >> event device. > >> > >> Signed-off-by: Pavan Nikhilesh > >> --- > >> examples/l3fwd/l3fwd.h | 10 ++ > >> examples/l3fwd/l3fwd_em.c| 177 > >+++ > >> examples/l3fwd/l3fwd_em.h| 159 +--- > >> examples/l3fwd/l3fwd_em_hlm.h| 131 > > > >> examples/l3fwd/l3fwd_em_sequential.h | 26 > >> examples/l3fwd/l3fwd_event.c | 9 ++ > >> examples/l3fwd/main.c| 5 +- > >> 7 files changed, 470 insertions(+), 47 deletions(-) > >> > >> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h > >> index 8f2e4be23..2d02fa731 100644 > >> --- a/examples/l3fwd/l3fwd.h > >> +++ b/examples/l3fwd/l3fwd.h > >> @@ -221,6 +221,16 @@ > >lpm_event_main_loop_tx_q(__attribute__((unused)) void *dummy); > >> int > >> lpm_event_main_loop_tx_q_burst(__attribute__((unused)) void > >*dummy); > >> > >> +int > >> +em_event_main_loop_tx_d(__attribute__((unused)) void > >*dummy); > >> +int > >> +em_event_main_loop_tx_d_burst(__attribute__((unused)) void > >*dummy); > >> +int > >> +em_event_main_loop_tx_q(__attribute__((unused)) void > >*dummy); > >> +int > >> +em_event_main_loop_tx_q_burst(__attribute__((unused)) void > >*dummy); > > > >Same question as for lpm: if your functions don't need params, > >why not to define them as ones without params? > > Need to satisfy the prototype requirements for > rte_eal_mp_remote_launch(l3fwd_lkp.main_loop, NULL, CALL_MASTER); Ok. > > > > >> + > >> + > >> /* Return ipv4/ipv6 fwd lookup struct for LPM or EM. */ > >> void * > >> em_get_ipv4_l3fwd_lookup_struct(const int socketid);
Re: [dpdk-dev] [PATCH v2 01/11] examples/l3fwd: add framework for event device
> >> +struct l3fwd_event_resources {
> >> + uint8_t sched_type;
> >> + uint8_t enabled;
> >> + uint8_t nb_args;
> >> + char **args;
> >> +};
> >> +
> >> +static inline struct l3fwd_event_resources *
> >> +l3fwd_get_eventdev_rsrc(void)
> >> +{
> >> + static const char name[RTE_MEMZONE_NAMESIZE] =
> >"l3fwd_event_rsrc";
> >> + const struct rte_memzone *mz;
> >> +
> >> + mz = rte_memzone_lookup(name);
> >> +
> >> + if (mz != NULL)
> >> + return mz->addr;
> >> +
> >> + mz = rte_memzone_reserve(name, sizeof(struct
> >l3fwd_event_resources),
> >> + 0, 0);
> >> + if (mz != NULL) {
> >> + memset(mz->addr, 0, sizeof(struct
> >l3fwd_event_resources));
> >> + return mz->addr;
> >> + }
> >> +
> >> + rte_exit(EXIT_FAILURE, "Unable to allocate memory for
> >eventdev cfg\n");
> >> +
> >> + return NULL;
> >> +}
> >
> >Does this function really need to be inline?
> >It wouldn't be fast anyway.
> >Another question - do you really need memzone here?
> >Wouldn't just rte_malloc() be enough?
>
> Will remove inline in next version.
> rte_malloc would call for a global variable which I'm
> trying to avoid.
If you plan to move that function into .c file,
you don't need a global var. it could be static local one.
> I don't think there is any harm in using
> named memzone.
I don't see any harm, though malloc+var will be faster I think.
Though up to you - no strong opinion here.
Re: [dpdk-dev] [PATCH] add ABI checks
Thomas Monjalon writes:
> 20/12/2019 17:20, Kinsella, Ray:
>> > -Original Message-
>> > From: Richardson, Bruce
>> > Sent: Friday 20 December 2019 15:32
>> > To: David Marchand ; dev@dpdk.org
>> > Cc: tho...@monjalon.net; Laatz, Kevin ;
>> > acon...@redhat.com; nhor...@tuxdriver.com; Michael Santana
>> > ; Mcnamara, John ;
>> > Kovacevic, Marko ; Kinsella, Ray
>> >
>> > Subject: RE: [PATCH] add ABI checks
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: David Marchand
>> > > Sent: Friday, December 20, 2019 3:21 PM
>> > > To: dev@dpdk.org
>> > > Cc: tho...@monjalon.net; Richardson, Bruce
>> > > ; Laatz, Kevin ;
>> > > acon...@redhat.com; nhor...@tuxdriver.com; Michael Santana
>> > > ; Mcnamara, John
>> > ;
>> > > Kovacevic, Marko
>> > > Subject: [PATCH] add ABI checks
>> > >
>> > > Starting from Kevin and Bruce idea of using libabigail, here is an
>> > > alternate approach to implement ABI checks.
>> > >
>> > > By default, those checks are disabled and enabling them requires a
>> > > manual step that generates the ABI dumps on a reference version for a
>> > > set of configurations.
>> > >
>> > > Those checks are enabled in the CI by default for the default meson
>> > > options on x86 and aarch64 so that proposed patches are validated.
>> > > A cache of the ABI is stored in travis jobs.
>> > > Checks can be only informational by setting ABI_CHECKS_WARN_ONLY when
>> > > breaking the ABI in a future release.
>> > >
>> > > For advanced developers and maintainers, the contributing guide
>> > > details the higher level scripts that are quite close to the existing
>> > > devtools scripts.
>> > >
>> > > Signed-off-by: David Marchand
>> > > ---
>> > > .ci/linux-build.sh | 43 +++
>> > > .travis.yml | 20 +++--
>> > > devtools/check-abi-dump.sh | 46
>> > +
>> > > devtools/check-abi-reference.sh | 27 +
>> > > devtools/dpdk.abignore | 2 ++
>> > > devtools/gen-abi-dump.sh| 29 ++
>> > > devtools/gen-abi-reference.sh | 24 +++
>> > > devtools/test-build.sh | 13 ++--
>> > > devtools/test-meson-builds.sh | 6
>> > > doc/guides/contributing/patches.rst | 25
>> > > 10 files changed, 230 insertions(+), 5 deletions(-) create mode
>> > > 100755 devtools/check-abi-dump.sh create mode 100755
>> > > devtools/check-abi- reference.sh create mode 100644
>> > > devtools/dpdk.abignore create mode
>> > > 100755 devtools/gen-abi-dump.sh create mode 100755 devtools/gen-abi-
>> > > reference.sh
>> > >
>> > > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh index
>> > > ccc3a7ccd..345dba264 100755
>> > > --- a/.ci/linux-build.sh
>> > > +++ b/.ci/linux-build.sh
>> > > @@ -30,8 +30,51 @@ fi
>> > >
>> > > OPTS="$OPTS --default-library=$DEF_LIB"
>> > > meson build --werror -Dexamples=all $OPTS
>> > > +
>> > > +if [ "$ABI_CHECKS" = "1" ]; then
>> > > +git remote add ref ${REF_GIT_REPO:-https://dpdk.org/git/dpdk}
>> > > +git fetch --tags ref ${REF_GIT_BRANCH:-master}
>> > > +
>> > > +head=$(git describe --all)
>> > > +tag=$(git describe --abbrev=0)
>> > > +
>> > > +if [ "$(cat reference/VERSION 2>/dev/null)" != "$tag" ]; then
>> > > +rm -rf reference
>> > > +fi
>> > > +
>> > > +if [ ! -d reference ]; then
>> > > +gen_abi_dump=$(mktemp -t gen-abi-dump-XXX.sh)
>> > > +cp -a devtools/gen-abi-dump.sh $gen_abi_dump
>> > > +
>> > > +git checkout -qf $tag
>> > > +ninja -C build
>> > > +$gen_abi_dump build reference
>> > > +
>> > > +if [ "$AARCH64" != "1" ]; then
>> > > +mkdir -p reference/app
>> > > +cp -a build/app/dpdk-testpmd reference/app/
>> > > +
>> > > +export
>> > LD_LIBRARY_PATH=$(pwd)/build/lib:$(pwd)/build/drivers
>> > > +devtools/test-null.sh reference/app/dpdk-testpmd
>> > > +unset LD_LIBRARY_PATH
>> > > +fi
>> > > +echo $tag > reference/VERSION
>> > > +
>> > > +git checkout -qf $head
>> > > +fi
>> > > +fi
>> > > +
>> > > ninja -C build
>> > >
>> > > +if [ "$ABI_CHECKS" = "1" ]; then
>> > > +devtools/check-abi-dump.sh build reference
>> > ${ABI_CHECKS_WARN_ONLY:-}
>> > > +if [ "$AARCH64" != "1" ]; then
>> > > +export LD_LIBRARY_PATH=$(pwd)/build/lib:$(pwd)/build/drivers
>> > > +devtools/test-null.sh reference/app/dpdk-testpmd
>> > > +unset LD_LIBRARY_PATH
>> > > +fi
>> > > +fi
>> > > +
>> > > if [ "$AARCH64" != "1" ]; then
>> > > devtools/test-null.sh
>> > > fi
>> > > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..bbb060fa2
>> > > 100644
>> > > --- a/.travis.yml
>> > > +++ b/.travis.yml
>> > > @@ -1,5 +1,8 @@
>> > > language: c
>> > > -cache: ccache
>> > > +cache:
>> > > + ccache: true
>> > > + directories:
>> > > +- reference
>> > >
Re: [dpdk-dev] [PATCH v6 00/11] Add ABI compatibility checks to the meson build
Bruce Richardson writes: > On Fri, Dec 20, 2019 at 02:19:13PM +0100, David Marchand wrote: >> On Fri, Dec 20, 2019 at 12:04 PM Bruce Richardson >> wrote: >> > > For maintainers that integrate patches or developers that get a CI >> > > failure and want to fix it, we would need to help them to: >> > > * generate dumps on a reference version, so I would tend to write some >> > > documentation since playing with the current sources would be too >> > > dangerous from my pov, >> > >> > This should be a one-off reference dump archived somewhere. Each maintainer >> > should not have his own copy, I think. >> >> This is not a one-off thing. >> We maintain ABI for some time (1/2 year(s)), and we expect to bump ABI. >> When doing this, in size, the diff will be at least the same than what >> we have here. >> > > I don't think it will be quite that big, but ok, it may be significant, so > I will concede that these are too big to store in the main git repo. > >> >> If you disable libraries, features etc... you get a new ABI. >> What would be the reference*s* then? >> Builds with default options from meson for each architecture? >> > > On the project level API, yes, removing libraries/drivers does affect > things. However, the specific checks are done on the individual .so level, > so having some drivers off in the build should not be a problem. Even with > features - all public functions need to correspond with map file entries, > so we can't conditionally remove them without providing a stub AFAIK. > Therefore, having one master reference of the DPDK_20 ABI is perfectly > feasible. But when is it cut? What happens during an interrim, where users have an outdated reference but don't remember what they downloaded? What about when we have multiple LTS' that have different ABI versions and need to ensure that we don't break ABIs for backports? >> >> > > * run the checks, like adding the check in the >> > > devtools/test-*-build.sh scripts that already exist, with a new >> > > configuration item to point at the dumps per target, >> > > >> > >> > Where do we store the dumps then? Do they get stored in a separate git >> > repo? >> >> Creating a separate git repo is just adding more pain to submitters >> (/maintainers): they would have to submit (/apply) patches against two >> trees. >> > > Well, the official ABI dumps need to be stored somewhere, because if it's > an official ABI, then it is exactly that. There cannot be different people > with different versions of the ABI to check against. Everyone should check > against the one common, official reference. Isn't the reference stored in the git repo anyway? It should always be possible to generate it. And I trust the version I generate from the source of truth anyway, over something I download. > Regards, > /Bruce
Re: [dpdk-dev] [PATCH v6 3/4] net/ixgbe: cleanup Tx buffers
> > > > > + * tx_tail is the last sent packet on the sw_ring. Goto the end
> > > > > + * of that packet (the last segment in the packet chain) and
> > > > > + * then the next segment will be the start of the oldest segment
> > > > > + * in the sw_ring.
> > > >
> > > > Not sure I understand the sentence above.
> > > > tx_tail is the value of TDT HW register (most recently armed by SW TD).
> > > > last_id is the index of last descriptor for multi-seg packet.
> > > > next_id is just the index of next descriptor in HW TD ring.
> > > > How do you conclude that it will be the ' oldest segment in the
> > > > sw_ring'?
> > > >
> > >
> > > The tx_tail is the last sent packet on the sw_ring. While the
> > > xmit_cleanup or Tx_free_bufs will be call when the nb_tx_free <
> > tx_free_thresh .
> > > So the sw_ring[tx_tail].next_id must be the begin of mbufs which are
> > > not used or Already freed . then begin the loop until the mbuf is used
> > > and
> > begin to free them.
> > >
> > >
> > >
> > > > Another question why do you need to write your own functions?
> > > > Why can't you reuse existing ixgbe_xmit_cleanup() for full(offload)
> > > > path and
> > > > ixgbe_tx_free_bufs() for simple path?
> > > > Yes, ixgbe_xmit_cleanup() doesn't free mbufs, but at least it could
> > > > be used to determine finished TX descriptors.
> > > > Based on that you can you can free appropriate sw_ring[] entries.
> > > >
> > >
> > > The reason why I don't reuse existing function is that they all free
> > > several mbufs While the free_cnt of the API rte_eth_tx_done_cleanup() is
> > > the
> > number of packets.
> > > It also need to be done that check which mbuffs are from the same packet.
> >
> > At first, I don't see anything bad if tx_done_cleanup() will free only some
> > segments from the packet. As long as it is safe - there is no problem with
> > that.
> > I think rte_eth_tx_done_cleanup() operates on mbuf, not packet quantities.
> > But in our case I think it doesn't matter, as ixgbe_xmit_cleanup() mark
> > TXDs as
> > free only when HW is done with all TXDs for that packet.
> > As long as there is a way to reuse existing code and avoid duplication
> > (without
> > introducing any degradation) - we should use it.
> > And I think there is a very good opportunity here to reuse existing
> > ixgbe_xmit_cleanup() for tx_done_cleanup() implementation.
> > Moreover because your code doesn’t follow
> > ixgbe_xmit_pkts()/ixgbe_xmit_cleanup()
> > logic and infrastructure, it introduces unnecessary scans over TXD ring,
> > and in
> > some cases doesn't work as expected:
> >
> > +while (1) {
> > +tx_last = sw_ring[tx_id].last_id;
> > +
> > +if (sw_ring[tx_last].mbuf) {
> > +if (txr[tx_last].wb.status &
> > +IXGBE_TXD_STAT_DD) {
> > ...
> > +} else {
> > +/*
> > + * mbuf still in use, nothing left to
> > + * free.
> > + */
> > +break;
> >
> > It is not correct to expect that IXGBE_TXD_STAT_DD will be set on last TXD
> > for
> > *every* packet.
> > We set IXGBE_TXD_CMD_RS bit only on threshold packet last descriptor.
> > Plus ixgbe_xmit_cleanup() can cleanup TXD wb.status.
> >
> > So I strongly recommend to reuse ixgbe_xmit_cleanup() here.
> > It would be much less error prone and will help to avoid code duplication.
> >
> > Konstantin
> >
>
> At first.
> The function ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq) will cleanup TXD
> wb.status.
> the number of status cleanuped is always txq->tx_rs_thresh.
Yes, and what's wrong with it?
>
> The API rte_eth_tx_done_cleanup() in rte_eth_dev.h show that
> @param free_cnt
> * Maximum number of packets to free. Use 0 to indicate all possible
> packets
> * should be freed. Note that a packet may be using multiple mbufs.
I don't think it is a good approach, better would be to report number of freed
mbufs,
but ok, as it is a public API, we probably need to keep it as it is.
> a number must be set while ixgbe_xmit_cleanup and ixgbe_tx_free_bufs only
> have one parameter txq.
Yes, ixgbe_xmit_cleanup() cleans up at least txq->tx_rs_thresh TXDs.
So if user requested more packets to be freed we can call ixgbe_xmit_cleanup()
in a loop.
> And what should do is not only free buffers and status but also check which
> bufs are from
> One packet and count the packet freed.
ixgbe_xmit_cleanup() itself doesn't free mbufs itself.
It only cleans up TXDs.
So in tx_done_cleanup() after calling ixgbe_xmit_cleanup()
you'll still need to go through sw_ring[]
entries that correspond to free TXDs and call mbuf_seg_free().
You can count number of full packets here.
> So I think it can't be implemented that reuse function xmit_cleanup without
> change it.
> And create a new function with the code of xmit_cleanup will cause many
> duplication.
I don't think it would.
I think all we need here is something like that
(note it is schematic one, doesn't take into accounf that TXD ring is circular):
tx_done_cleanup(..., uint32_t cnt)
{
/* we have txq->nb_tx_free TXD
Re: [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64
Ruifeng Wang writes:
> Add Travis compilation jobs for aarch64. gcc/clang compilations for
> static/shared libraries are added.
>
> Some limitations for current aarch64 Travis support:
> 1. Container is used. Huge page is not available due to security reason.
> 2. Missing kernel header package in Xenial distribution.
>
> Solutions to address the limitations:
> 1. Not to add unit test for now. And run tests with no-huge in future.
> 2. Use Bionic distribution for all aarch64 jobs.
>
> Signed-off-by: Ruifeng Wang
> Reviewed-by: Gavin Hu
> ---
Can't we achieve the same thing by setting
arch:
- amd64
- arm64
in the build matrix? Or will that also force the intel builds to use
the container infrastructure (in which case the no-huge support needs to
be fixed)?
One thing I wonder, isn't is possible to use qemu-user to do the amd64
unit tests? Then do we really need some changes to do the native build?
Does it buy us anything *today* given the cost of the hugepage
restriction? Will that ever be resolved (I didn't see so from the
docs on travis)?
> .ci/linux-setup.sh | 11 +++
> .travis.yml| 42 +-
> 2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
> index dfb9d4a20..a92978037 100755
> --- a/.ci/linux-setup.sh
> +++ b/.ci/linux-setup.sh
> @@ -3,7 +3,10 @@
> # need to install as 'root' since some of the unit tests won't run without it
> sudo python3 -m pip install --upgrade meson
>
> -# setup hugepages
> -cat /proc/meminfo
> -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> -cat /proc/meminfo
> +# hugepage settings are skipped on aarch64 due to environment limitation
> +if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> +# setup hugepages
> +cat /proc/meminfo
> +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> +cat /proc/meminfo
> +fi
> diff --git a/.travis.yml b/.travis.yml
> index 8f90d06f2..980c7605d 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -115,6 +115,46 @@ matrix:
>apt:
> packages:
>- *extra_packages
> -
> + - env: DEF_LIB="static"
> +arch: arm64
> +compiler: gcc
> +dist: bionic
> +addons:
> + apt:
> +packages:
> + - *required_packages
> + - env: DEF_LIB="shared"
> +arch: arm64
> +compiler: gcc
> +dist: bionic
> +addons:
> + apt:
> +packages:
> + - *required_packages
> + - env: DEF_LIB="static"
> +arch: arm64
> +dist: bionic
> +compiler: clang
> +addons:
> + apt:
> +packages:
> + - *required_packages
> + - env: DEF_LIB="shared"
> +arch: arm64
> +dist: bionic
> +compiler: clang
> +addons:
> + apt:
> +packages:
> + - *required_packages
> + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
> +arch: arm64
> +compiler: gcc
> +dist: bionic
> +addons:
> + apt:
> +packages:
> + - *required_packages
> + - *doc_packages
>
> script: ./.ci/${TRAVIS_OS_NAME}-build.sh
Re: [dpdk-dev] [PATCH 2/2] net/mlx5: add IPv4/IPv6 DSCP rewrite action
Hi
From: Suanming Mou
> This commit add the IPv4/IPv6 DSCP rewrite actions to the PMD code.
>
> Supported actions:
> RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP
> RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP
>
> Signed-off-by: Suanming Mou
> ---
> drivers/net/mlx5/mlx5_flow.h| 6 +-
> drivers/net/mlx5/mlx5_flow_dv.c | 184
>
> 2 files changed, 189 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 27d82ac..e42c98a 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -196,6 +196,8 @@ enum mlx5_feature_name { #define
> MLX5_FLOW_ACTION_MARK_EXT (1ull << 33) #define
> MLX5_FLOW_ACTION_SET_META (1ull << 34) #define
> MLX5_FLOW_ACTION_METER (1ull << 35)
> +#define MLX5_FLOW_ACTION_SET_IPV4_DSCP (1ull << 36) #define
> +MLX5_FLOW_ACTION_SET_IPV6_DSCP (1ull << 37)
>
> #define MLX5_FLOW_FATE_ACTIONS \
> (MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_QUEUE | \
> @@ -232,7 +234,9 @@ enum mlx5_feature_name {
> MLX5_FLOW_ACTION_OF_SET_VLAN_VID
> | \
> MLX5_FLOW_ACTION_SET_TAG | \
> MLX5_FLOW_ACTION_MARK_EXT | \
> - MLX5_FLOW_ACTION_SET_META)
> + MLX5_FLOW_ACTION_SET_META | \
> + MLX5_FLOW_ACTION_SET_IPV4_DSCP | \
> + MLX5_FLOW_ACTION_SET_IPV6_DSCP)
I don't think DSCP set is a reg feature... please check...
> #define MLX5_FLOW_VLAN_ACTIONS
> (MLX5_FLOW_ACTION_OF_POP_VLAN | \
> MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 4c16281..15fe726 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -157,6 +157,7 @@ struct field_modify_info modify_vlan_out_first_vid[]
> = { };
>
> struct field_modify_info modify_ipv4[] = {
> + {1, 1, MLX5_MODI_OUT_IP_DSCP},
> {1, 8, MLX5_MODI_OUT_IPV4_TTL},
> {4, 12, MLX5_MODI_OUT_SIPV4},
> {4, 16, MLX5_MODI_OUT_DIPV4},
> @@ -164,6 +165,7 @@ struct field_modify_info modify_ipv4[] = { };
>
> struct field_modify_info modify_ipv6[] = {
> + {1, 0, MLX5_MODI_OUT_IP_DSCP},
> {1, 7, MLX5_MODI_OUT_IPV6_HOPLIMIT},
> {4, 8, MLX5_MODI_OUT_SIPV6_127_96},
> {4, 12, MLX5_MODI_OUT_SIPV6_95_64},
> @@ -1191,6 +1193,82 @@ struct field_modify_info modify_tcp[] = { }
>
> /**
> + * Convert modify-header set IPv4 DSCP action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ipv4_dscp
> + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_dscp *conf =
> + (const struct rte_flow_action_set_dscp *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV4 };
> + struct rte_flow_item_ipv4 ipv4;
> + struct rte_flow_item_ipv4 ipv4_mask;
> +
> + memset(&ipv4, 0, sizeof(ipv4));
> + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> + ipv4.hdr.type_of_service = conf->dscp;
> + ipv4_mask.hdr.type_of_service = 0x3f;
Please use RTE_IPV4_HDR_DSCP_MASK.
> + item.spec = &ipv4;
> + item.mask = &ipv4_mask;
> + return flow_dv_convert_modify_action(&item, modify_ipv4, NULL,
> resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header set IPv6 DSCP action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ipv6_dscp
> + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_dscp *conf =
> + (const struct rte_flow_action_set_dscp *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV6 };
> + struct rte_flow_item_ipv6 ipv6;
> + struct rte_flow_item_ipv6 ipv6_mask;
> +
> + memset(&ipv6, 0, sizeof(ipv6));
> + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
Re: [dpdk-dev] [PATCH] net/mlx5: fix metadata item endianness conversion
From: Viacheslav Ovsiienko
> The metadata register c0 field in the matcher might be split into two
> independent fields - the source vport index and META item value. These
> fields have no permanent assigned bits, the configuration is queried from the
> kernel drivers.
>
> It means the metadata item field might be less than 32 bits.
> Also, the metadata are engaged in datapath and there are no any metadata
> endianness conversions in datapath to provide the better performance, all
> conversions are implemented in rte_flow engine. If there are less than 32
> bits of metadata the extra right shift is needed after endianness conversion
> for little- endian hosts.
>
> Fixes: acfcd5c52f94 ("net/mlx5: update meta register matcher set")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] net/mlx5: fix register c0 usage for metadata entities
From: Viacheslav Ovsiienko
> The register c0 might be engaged to support META and MARK related items
> and actions. Also, this register might be used by kernel to specify the source
> vport index. The register c0 is split into two 16-bit fields. Depending on the
> mask returned by kernel the PMD can use upper or lower half of register c0.
> This patch adds the missing support for upper half.
>
> Fixes: e554b672aa05 ("net/mlx5: support flow tag")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] net/mlx5: fix matcher metadata register c0 field setup
From: Viacheslav Ovsiienko
> The metadata register c0 field in the matcher might be split into two
> independent fields - the source vport index and META item value. These
> fields have no permanent assigned bits, the configuration is queried from the
> kernel drivers.
>
> MLX5_SET configures the specified 32-bit field as whole entity.
> For metadata register c0 we should take into account the provided mask in
> order to configure the specified subfield bits only.
>
> Fixes: acfcd5c52f94 ("net/mlx5: update meta register matcher set")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_flow_dv.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 4c16281..893db3e 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -5742,6 +5742,7 @@ struct field_modify_info modify_tcp[] = {
> MLX5_ADDR_OF(fte_match_param, matcher,
> misc_parameters_2);
> void *misc2_v =
> MLX5_ADDR_OF(fte_match_param, key,
> misc_parameters_2);
> + uint32_t temp;
>
> data &= mask;
> switch (reg_type) {
> @@ -5754,8 +5755,18 @@ struct field_modify_info modify_tcp[] = {
> MLX5_SET(fte_match_set_misc2, misc2_v, metadata_reg_b,
> data);
> break;
> case REG_C_0:
> - MLX5_SET(fte_match_set_misc2, misc2_m,
> metadata_reg_c_0, mask);
> - MLX5_SET(fte_match_set_misc2, misc2_v,
> metadata_reg_c_0, data);
> + /*
> + * The metadata register C0 field might be divided into
> + * source vport index and META item value, we should set
> + * this field accorfing to specified mask, not as whole one.
> + */
Typo - accorfing => according.
> + temp = MLX5_GET(fte_match_set_misc2, misc2_m,
> metadata_reg_c_0);
> + temp |= mask;
> + MLX5_SET(fte_match_set_misc2, misc2_m,
> metadata_reg_c_0, temp);
> + temp = MLX5_GET(fte_match_set_misc2, misc2_v,
> metadata_reg_c_0);
> + temp &= ~mask;
> + temp |= data;
> + MLX5_SET(fte_match_set_misc2, misc2_v,
> metadata_reg_c_0, temp);
> break;
> case REG_C_1:
> MLX5_SET(fte_match_set_misc2, misc2_m,
> metadata_reg_c_1, mask);
Raslan, please fix the typo in integration.
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst routines set
From: Viacheslav Ovsiienko
> The tx_burst routine supporting multi-segment packets with legacy MPW
> and without inline was missed, and there was no valid selection for these
> options, patch adds the missing routine.
>
> Fixes: 82e75f8323bf ("net/mlx5: fix legacy multi-packet Tx descriptors")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] net/mlx5: fix legacy inline multi-packet performance
From: Viacheslav Ovsiienko
> The legacy multi-packet write is the feature allowing to put multiple packets
> into one transmitting descriptor, this feature is supported by only NIC
> ConnectX-4LX.
> The number of packets should be limited to provide optimal size descriptor
> and better performance.
>
> Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] net/mlx5: fix default mark copy flow
From: Viacheslav Ovsiienko
> In extensive metadata mode the MARK copy table is engaged, if the
> application creates the flow with zero MARK ID action:
>
> flow create 1 ingress pattern eth / ... / end actions mark id 0 / .. end
>
> And then destroys that, the traffic to the port stops. This happens due to
> default flow for the copy table has the zero ID and is removed with the
> application rule. The patch extends internal ID variable to 64 bits and
> provide
> the UINT64_MAX ID for the copy table default rule.
>
> Fixes: dd3c774f6ffb ("net/mlx5: add metadata register copy table")
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH v2 09/12] net/ice/base: change fdir desc preparation
ACK
-Original Message-
From: Zhang, Qi Z
Sent: Sunday, January 5, 2020 7:39 PM
To: Yang, Qiming
Cc: dev@dpdk.org; Ye, Xiaolong ; Zhang, Qi Z
; Patil, Kiran ; Stillwell Jr,
Paul M
Subject: [PATCH v2 09/12] net/ice/base: change fdir desc preparation
Change internal implemenatation of how FD filter programming desc is prepared.
This is to minimize the amount of code needed to prep the FD filter programming
desc (avoid memcpy, etc...) and just use predefined shifts and mask. This type
of change are needed to expedite FD setup during data path (ADQ uses this
codepath during initial flow setup) and it will also be useful when adding
side-band flow-director filter.
Signed-off-by: Kiran Patil
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
Acked-by: Qiming Yang
---
drivers/net/ice/base/ice_fdir.c | 92 -
1 file changed, 55 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
index 37b388169..87fa0afba 100644
--- a/drivers/net/ice/base/ice_fdir.c
+++ b/drivers/net/ice/base/ice_fdir.c
@@ -352,35 +352,6 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
#define ICE_FDIR_NUM_PKT ARRAY_SIZE(ice_fdir_pkt)
-/* Flow Direcotr (FD) filter program descriptor Context */ -static const
struct ice_ctx_ele ice_fd_fltr_desc_ctx_info[] = {
- /* Field Width LSB */
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, qindex, 11, 0),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, comp_q, 1, 11),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, comp_report,2, 12),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fd_space, 2, 14),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, cnt_index, 13, 16),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, cnt_ena,2, 29),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, evict_ena, 1, 31),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, toq,3, 32),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, toq_prio, 3, 35),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, dpu_recipe, 2, 38),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, drop, 1, 40),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, flex_prio, 3, 41),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, flex_mdid, 4, 44),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, flex_val, 16, 48),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, dtype, 4, 64),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, pcmd, 1, 68),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, desc_prof_prio, 3, 69),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, desc_prof, 6, 72),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fd_vsi, 10, 78),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, swap, 1, 88),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fdid_prio, 3, 89),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fdid_mdid, 4, 92),
- ICE_CTX_STORE(ice_fd_fltr_desc_ctx, fdid, 32, 96),
- { 0 }
-};
-
/**
* ice_set_dflt_val_fd_desc
* @fd_fltr_ctx: pointer to fd filter descriptor @@ -455,19 +426,66 @@
ice_fdir_get_prgm_desc(struct ice_hw *hw, struct ice_fdir_fltr *input,
/**
* ice_set_fd_desc_val
- * @fd_fltr_ctx: pointer to fd filter descriptor context
+ * @ctx: pointer to fd filter descriptor context
* @fdir_desc: populated with fd filter descriptor values
*/
void
-ice_set_fd_desc_val(struct ice_fd_fltr_desc_ctx *fd_fltr_ctx,
+ice_set_fd_desc_val(struct ice_fd_fltr_desc_ctx *ctx,
struct ice_fltr_desc *fdir_desc)
{
- u64 ctx_buf[2] = { 0 };
-
- ice_set_ctx((u8 *)fd_fltr_ctx, (u8 *)ctx_buf,
- ice_fd_fltr_desc_ctx_info);
- fdir_desc->qidx_compq_space_stat = CPU_TO_LE64(ctx_buf[0]);
- fdir_desc->dtype_cmd_vsi_fdid = CPU_TO_LE64(ctx_buf[1]);
+ u64 qword;
+
+ /* prep QW0 of FD filter programming desc */
+ qword = ((u64)ctx->qindex << ICE_FXD_FLTR_QW0_QINDEX_S) &
+ ICE_FXD_FLTR_QW0_QINDEX_M;
+ qword |= ((u64)ctx->comp_q << ICE_FXD_FLTR_QW0_COMP_Q_S) &
+ICE_FXD_FLTR_QW0_COMP_Q_M;
+ qword |= ((u64)ctx->comp_report << ICE_FXD_FLTR_QW0_COMP_REPORT_S) &
+ICE_FXD_FLTR_QW0_COMP_REPORT_M;
+ qword |= ((u64)ctx->fd_space << ICE_FXD_FLTR_QW0_FD_SPACE_S) &
+ICE_FXD_FLTR_QW0_FD_SPACE_M;
+ qword |= ((u64)ctx->cnt_index << ICE_FXD_FLTR_QW0_STAT_CNT_S) &
+ICE_FXD_FLTR_QW0_STAT_CNT_M;
+ qword |= ((u64)ctx->cnt_ena << ICE_FXD_FLTR_QW0_STAT_ENA_S) &
+ICE_FXD_FLTR_QW0_STAT_ENA_M;
+ qword |= ((u64)ctx->evict_ena << ICE_FXD_FLTR_QW0_EVICT_ENA_S) &
+ICE_FXD_FLTR_QW0_EVICT_ENA_M;
+ qword |= ((u64)
Re: [dpdk-dev] [PATCH v2 02/12] net/ice/base: support MAC/VLAN with TCP/UDP in switch
ACK
-Original Message-
From: Zhang, Qi Z
Sent: Sunday, January 5, 2020 7:39 PM
To: Yang, Qiming
Cc: dev@dpdk.org; Ye, Xiaolong ; Zhang, Qi Z
; Patil, Kiran ; Stillwell Jr,
Paul M
Subject: [PATCH v2 02/12] net/ice/base: support MAC/VLAN with TCP/UDP in switch
Add a feature to allow user to add switch filter using input like MAC + VLAN
(C-tag only) + L4 (TCP/UDP) port. API "ice_add_adv_rule"
is extended to handle this filter type.
Signed-off-by: Kiran Patil
Signed-off-by: Paul M Stillwell Jr
Signed-off-by: Qi Zhang
Acked-by: Qiming Yang
---
drivers/net/ice/base/ice_switch.c | 206 ++
1 file changed, 188 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index afa4fe30d..f8f5fde3c 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -251,8 +251,8 @@ u8 dummy_udp_tun_udp_packet[] = {
0x00, 0x08, 0x00, 0x00,
};
-static const
-struct ice_dummy_pkt_offsets dummy_udp_packet_offsets[] = {
+/* offset info for MAC + IPv4 + UDP dummy packet */ static const struct
+ice_dummy_pkt_offsets dummy_udp_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -260,8 +260,8 @@ struct ice_dummy_pkt_offsets dummy_udp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_udp_packet[] = {
+/* Dummy packet for MAC + IPv4 + UDP */ static const u8
+dummy_udp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -280,8 +280,40 @@ dummy_udp_packet[] = {
0x00, 0x00, /* 2 bytes for 4 byte alignment */
};
-static const
-struct ice_dummy_pkt_offsets dummy_tcp_packet_offsets[] = {
+/* offset info for MAC + VLAN + IPv4 + UDP dummy packet */ static const
+struct ice_dummy_pkt_offsets dummy_vlan_udp_packet_offsets[] = {
+ { ICE_MAC_OFOS, 0 },
+ { ICE_ETYPE_OL, 12 },
+ { ICE_VLAN_OFOS,14 },
+ { ICE_IPV4_OFOS,18 },
+ { ICE_UDP_ILOS, 38 },
+ { ICE_PROTOCOL_LAST,0 },
+};
+
+/* C-tag (801.1Q), IPv4:UDP dummy packet */ static const u8
+dummy_vlan_udp_packet[] = {
+ 0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x81, 0x00, /* ICE_ETYPE_OL 12 */
+
+ 0x00, 0x00, 0x08, 0x00, /* ICE_VLAN_OFOS 14 */
+
+ 0x45, 0x00, 0x00, 0x1c, /* ICE_IPV4_OFOS 18 */
+ 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x11, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x00, 0x00, 0x00, 0x00, /* ICE_UDP_ILOS 38 */
+ 0x00, 0x08, 0x00, 0x00,
+
+ 0x00, 0x00, /* 2 bytes for 4 byte alignment */
+};
+
+/* offset info for MAC + IPv4 + TCP dummy packet */ static const struct
+ice_dummy_pkt_offsets dummy_tcp_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV4_OFOS,14 },
@@ -289,8 +321,8 @@ struct ice_dummy_pkt_offsets dummy_tcp_packet_offsets[] = {
{ ICE_PROTOCOL_LAST,0 },
};
-static const u8
-dummy_tcp_packet[] = {
+/* Dummy packet for MAC + IPv4 + TCP */ static const u8
+dummy_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
@@ -312,8 +344,42 @@ dummy_tcp_packet[] = {
0x00, 0x00, /* 2 bytes for 4 byte alignment */
};
-static const
-struct ice_dummy_pkt_offsets dummy_tcp_ipv6_packet_offsets[] = {
+/* offset info for MAC + VLAN (C-tag, 802.1Q) + IPv4 + TCP dummy packet
+*/ static const struct ice_dummy_pkt_offsets dummy_vlan_tcp_packet_offsets[] =
{
+ { ICE_MAC_OFOS, 0 },
+ { ICE_ETYPE_OL, 12 },
+ { ICE_VLAN_OFOS,14 },
+ { ICE_IPV4_OFOS,18 },
+ { ICE_TCP_IL, 38 },
+ { ICE_PROTOCOL_LAST,0 },
+};
+
+/* C-tag (801.1Q), IPv4:TCP dummy packet */ static const u8
+dummy_vlan_tcp_packet[] = {
+ 0x00, 0x00, 0x00, 0x00, /* ICE_MAC_OFOS 0 */
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x81, 0x00, /* ICE_ETYPE_OL 12 */
+
+ 0x00, 0x00, 0x08, 0x00, /* ICE_VLAN_OFOS 14 */
+
+ 0x45, 0x00, 0x00, 0x28, /* ICE_IPV4_OFOS 18 */
+ 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x06, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x00, 0x00, 0x00, 0x00, /* ICE_TCP_IL 38 */
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x50, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00,
+
+ 0x00, 0x00, /* 2 bytes for 4 byte alignment */
+};
+
+static const struct ice_dummy_pkt_offsets
+dummy_tcp_ipv6_packet_offsets[] = {
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
{ ICE_IPV6_O
[dpdk-dev] [PATCH] examples/fips_validation: fix parsing of cipher length for AES-GCM
From: Sucharitha Sarananaga
Cipher length need to be updated in case of AES-GCM decryption.
Fixes: 4aaad2995e13 ("examples/fips_validation: support GCM parsing")
Signed-off-by: Archana Muniganti
Signed-off-by: Sucharitha Sarananaga
---
examples/fips_validation/fips_validation_gcm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/examples/fips_validation/fips_validation_gcm.c
b/examples/fips_validation/fips_validation_gcm.c
index ea48ddf..f295025 100644
--- a/examples/fips_validation/fips_validation_gcm.c
+++ b/examples/fips_validation/fips_validation_gcm.c
@@ -19,6 +19,7 @@
#define PTLEN_STR "PTlen = "
#define AADLEN_STR "AADlen = "
#define TAGLEN_STR "Taglen = "
+#define CTLEN_STR "PTlen = "
#define COUNT_STR "Count = "
#define KEY_STR"Key = "
@@ -46,6 +47,7 @@ struct fips_test_callback gcm_interim_vectors[] = {
{KEYLEN_STR, parser_read_uint32_bit_val, &vec.aead.key},
{IVLEN_STR, parser_read_uint32_bit_val, &vec.iv},
{PTLEN_STR, parser_read_uint32_bit_val, &vec.pt},
+ {CTLEN_STR, parser_read_uint32_bit_val, &vec.ct},
{AADLEN_STR, parser_read_uint32_bit_val, &vec.aead.aad},
{TAGLEN_STR, parser_read_uint32_bit_val,
&vec.aead.digest},
--
1.8.3.1
Re: [dpdk-dev] [PATCH] examples/fips_validation: fix parsing of cipher length for AES-GCM
Hi Akhil,
Please see inline.
Thanks,
Archana
> -Original Message-
> From: Akhil Goyal
> Sent: Monday, January 6, 2020 3:09 PM
> To: Archana Muniganti ;
> marko.kovace...@intel.com; roy.fan.zh...@intel.com
> Cc: Sucharitha Sarananaga ; Anoob Joseph
> ; Abed Mohammad Kamaluddin
> ; Jerin Jacob Kollanukkaran
> ; dev@dpdk.org; sta...@dpdk.org
> Subject: [EXT] RE: [PATCH] examples/fips_validation: fix parsing of cipher
> length for AES-GCM
>
> External Email
>
> --
> > From: Sucharitha Sarananaga
> >
> > Cipher length need to be updated in case of AES-GCM decryption.
> >
> > Fixes: 4aaad2995e13 ("examples/fips_validation: support GCM parsing")
> >
> > Signed-off-by: Archana Muniganti
> > Signed-off-by: Sucharitha Sarananaga
> > ---
> > examples/fips_validation/fips_validation_gcm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/examples/fips_validation/fips_validation_gcm.c
> > b/examples/fips_validation/fips_validation_gcm.c
> > index ea48ddf..f295025 100644
> > --- a/examples/fips_validation/fips_validation_gcm.c
> > +++ b/examples/fips_validation/fips_validation_gcm.c
> > @@ -19,6 +19,7 @@
> > #define PTLEN_STR "PTlen = "
> > #define AADLEN_STR "AADlen = "
> > #define TAGLEN_STR "Taglen = "
> > +#define CTLEN_STR "PTlen = "
> Typo. Should be CTlen
[Archana] NIST request file for AES-GCM test vectors contains 'PTlen =' field.
This field holds plain text length when encrypt test vectors are used. And same
field holds cipher text length when decrypt test vectors are used.
Hence added a new macro that will be used in AES-GCM 'decryption'
[dpdk-dev] [PATCH v1 1/1] config: add Broadcom Stingray for meson cross-compilation
Broadcom Stingray is armv8 CPU having cortex-a72. The implementor ID is 0x41 (arm) and the primary part number is 0xd08 (cortex-a72). Signed-off-by: Qingmin Liu --- config/arm/arm64_stingray_linux_gcc | 17 + 1 file changed, 17 insertions(+) create mode 100644 config/arm/arm64_stingray_linux_gcc diff --git a/config/arm/arm64_stingray_linux_gcc b/config/arm/arm64_stingray_linux_gcc new file mode 100644 index 0..86797d23c --- /dev/null +++ b/config/arm/arm64_stingray_linux_gcc @@ -0,0 +1,17 @@ +[binaries] +c = 'aarch64-linux-gnu-gcc' +cpp = 'aarch64-linux-gnu-cpp' +ar = 'aarch64-linux-gnu-gcc-ar' +strip = 'aarch64-linux-gnu-strip' +pkgconfig = 'aarch64-linux-gnu-pkg-config' +pcap-config = '' + +[host_machine] +system = 'linux' +cpu_family = 'aarch64' +cpu = 'armv8-a' +endian = 'little' + +[properties] +implementor_id = '0x41' +implementor_pn = '0xd08' -- 2.21.0
[dpdk-dev] [PATCH v1 0/1] Add Broadcom Stingray for meson cross-compilation
Add Broadcom Stingray meson config support. Qingmin Liu (1): config: add Broadcom Stingray for meson cross-compilation config/arm/arm64_stingray_linux_gcc | 17 + 1 file changed, 17 insertions(+) create mode 100644 config/arm/arm64_stingray_linux_gcc -- 2.21.0
Re: [dpdk-dev] [PATCH 14/14] examples/ipsec-secgw: add cmd line option for bufs
> > > > Add command line option -s which can be used to configure number of
> > > > buffers in a pool. Default number of buffers is 8192.
> > > >
> > > > Signed-off-by: Anoob Joseph
> > > > Signed-off-by: Lukasz Bartosik
> > > > ---
> > > > examples/ipsec-secgw/ipsec-secgw.c | 23 +++
> > > > 1 file changed, 19 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > > > b/examples/ipsec-secgw/ipsec-secgw.c
> > > > index 76719f2..f8e28d6 100644
> > > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > > @@ -59,8 +59,6 @@ volatile bool force_quit;
> > > >
> > > > #define MEMPOOL_CACHE_SIZE 256
> > > >
> > > > -#define NB_MBUF(32000)
> > > > -
> > > > #define CDEV_QUEUE_DESC 2048
> > > > #define CDEV_MAP_ENTRIES 16384
> > > > #define CDEV_MP_NB_OBJS 1024
> > > > @@ -167,6 +165,7 @@ static int32_t numa_on = 1; /**< NUMA is
> > enabled
> > > > by default. */ static uint32_t nb_lcores; static uint32_t
> > > > single_sa; static uint32_t single_sa_idx;
> > > > +static uint32_t nb_bufs_in_pool = 8192;
> > >
> > > Why to change the default number (behavior) here?
> > > Why not to keep existing one as default?
> >
> > Or, at least try to guess required number of mbufs (like l3fwd, etc., do)?
>
> [Anoob] Existing code sets the default number of mbufs to 32k, which is
> leading to higher cache misses on our platform. Also, other
> example applications have 8192 as the minimum. Hence the change.
>
> Do you see any perf issues with lowering the default value?
8K is not much at all.
Ipsec-secgw uses 1K as RXD/TXD num per queue.
So just 4RX+4TX queues will already bring it to the edge.
With 8+ RX queues app simply wouldn't be able to start.
Looks like a change in behavior.
> Also, I'm fine with making the default one same as the ones in l2fwd & l3fwd.
Ok.
>
> From l3fwd:
>
> /*
> * This expression is used to calculate the number of mbufs needed
> * depending on user input, taking into account memory for rx and
> * tx hardware rings, cache per lcore and mtable per port per lcore.
> * RTE_MAX is used to ensure that NB_MBUF never goes below a minimum
> * value of 8192
> */
> #define NB_MBUF(nports) RTE_MAX( \
> (nports*nb_rx_queue*nb_rxd +\
> nports*nb_lcores*MAX_PKT_BURST +\
> nports*n_tx_queue*nb_txd + \
> nb_lcores*MEMPOOL_CACHE_SIZE), \
> (unsigned)8192)
>
> I do understand that we will have to rework the above logic a bit more to
> handle the in-flight packets in cryptodev.
Yes, plus also will need to take into account size of fragmentation table.
> What's your suggestion?
I think the best way is to calculate mumber of required mbufs as discussed
above,
plus add ability to the user to overwrite this value (cmd-line option).
> > > >
> > > > /*
> > > > * RX/TX HW offload capabilities to enable/use on ethernet ports.
> > > > @@ -1261,6 +1260,7 @@ print_usage(const char *prgname)
> > > > " [-w REPLAY_WINDOW_SIZE]"
> > > > " [-e]"
> > > > " [-a]"
> > > > + " [-s NUMBER_OF_MBUFS_IN_PKT_POOL]"
> > > > " -f CONFIG_FILE"
> > > > " --config (port,queue,lcore)[,(port,queue,lcore)]"
> > > > " [--single-sa SAIDX]"
> > > > @@ -1284,6 +1284,7 @@ print_usage(const char *prgname)
> > > > " size for each SA\n"
> > > > " -e enables ESN\n"
> > > > " -a enables SA SQN atomic behaviour\n"
> > > > + " -s number of mbufs in packet pool (default 8192)\n"
> > > > " -f CONFIG_FILE: Configuration file\n"
> > > > " --config (port,queue,lcore): Rx queue
> > > > configuration\n"
> > > > " --single-sa SAIDX: Use single SA index for outbound
> > traffic,\n"
> > > > @@ -1534,7 +1535,7 @@ parse_args(int32_t argc, char **argv, struct
> > > > eh_conf *eh_conf)
> > > >
> > > > argvopt = argv;
> > > >
> > > > - while ((opt = getopt_long(argc, argvopt, "aelp:Pu:f:j:w:",
> > > > + while ((opt = getopt_long(argc, argvopt, "aelp:Pu:f:j:w:s:",
> > > > lgopts, &option_index)) != EOF) {
> > > >
> > > > switch (opt) {
> > > > @@ -1568,6 +1569,19 @@ parse_args(int32_t argc, char **argv, struct
> > eh_conf *eh_conf)
> > > > cfgfile = optarg;
> > > > f_present = 1;
> > > > break;
> > > > +
> > > > + case 's':
> > > > + ret = parse_decimal(optarg);
> > > > + if (ret < 0) {
> > > > + printf("Invalid number of buffers in a
> > > > pool: "
> > > > + "%s\n", optarg);
> > > > + print_usage(prgname);
> > > > +
Re: [dpdk-dev] [PATCH] maintainers: add co-maintainer for flow API
On 1/6/2020 10:37 AM, Adrien Mazarguil wrote: > On Sun, Dec 29, 2019 at 08:56:58AM +, Ori Kam wrote: >> I volunteer to be co maintainer for the rte_flow lib. >> >> Signed-off-by: Ori Kam > > Welcome :) > > Acked-by: Adrien Mazarguil > We need help on rte_flow, thank for volunteering Ori! Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add eventmode to ipsec-secgw
> > > Add eventmode support to ipsec-secgw. This uses event helper to setup
> > > and use the eventmode capabilities. Add driver inbound worker.
> > >
> > > Example command:
> > > ./ipsec-secgw -c 0x1 -w 0002:02:00.0,ipsec_in_max_spi=100 -w
> > > 0002:07:00.0 -w 0002:0e:00.0 -w 0002:10:00.1 -- -P -p 0x3 -u 0x1
> > > --config "(0,0,0),(1,0,0)" -f a-aes-gcm-msa.cfg --transfer-mode 1
> > > --schedule-type 2 --process-mode drv --process-dir in
> > >
> > > Signed-off-by: Anoob Joseph
> > > Signed-off-by: Lukasz Bartosik
> > > ---
> > > examples/ipsec-secgw/Makefile | 1 +
> > > examples/ipsec-secgw/event_helper.c | 3 +
> > > examples/ipsec-secgw/event_helper.h | 26 +++
> > > examples/ipsec-secgw/ipsec-secgw.c | 344
> > +++-
> > > examples/ipsec-secgw/ipsec.h| 7 +
> > > examples/ipsec-secgw/ipsec_worker.c | 180 +++
> > > examples/ipsec-secgw/meson.build| 2 +-
> > > 7 files changed, 555 insertions(+), 8 deletions(-) create mode
> > > 100644 examples/ipsec-secgw/ipsec_worker.c
> > >
> > > diff --git a/examples/ipsec-secgw/Makefile
> > > b/examples/ipsec-secgw/Makefile index 09e3c5a..f6fd94c 100644
> > > --- a/examples/ipsec-secgw/Makefile
> > > +++ b/examples/ipsec-secgw/Makefile
> > > @@ -15,6 +15,7 @@ SRCS-y += sa.c
> > > SRCS-y += rt.c
> > > SRCS-y += ipsec_process.c
> > > SRCS-y += ipsec-secgw.c
> > > +SRCS-y += ipsec_worker.c
> > > SRCS-y += event_helper.c
> > >
> > > CFLAGS += -gdwarf-2
> > > diff --git a/examples/ipsec-secgw/event_helper.c
> > > b/examples/ipsec-secgw/event_helper.c
> > > index 6549875..44f997d 100644
> > > --- a/examples/ipsec-secgw/event_helper.c
> > > +++ b/examples/ipsec-secgw/event_helper.c
> > > @@ -984,6 +984,9 @@ eh_find_worker(uint32_t lcore_id, struct eh_conf
> > *conf,
> > > else
> > > curr_conf.cap.burst = EH_RX_TYPE_NON_BURST;
> > >
> > > + curr_conf.cap.ipsec_mode = conf->ipsec_mode;
> > > + curr_conf.cap.ipsec_dir = conf->ipsec_dir;
> > > +
> > > /* Parse the passed list and see if we have matching capabilities */
> > >
> > > /* Initialize the pointer used to traverse the list */ diff --git
> > > a/examples/ipsec-secgw/event_helper.h
> > > b/examples/ipsec-secgw/event_helper.h
> > > index 2895dfa..07849b0 100644
> > > --- a/examples/ipsec-secgw/event_helper.h
> > > +++ b/examples/ipsec-secgw/event_helper.h
> > > @@ -74,6 +74,22 @@ enum eh_tx_types {
> > > EH_TX_TYPE_NO_INTERNAL_PORT
> > > };
> > >
> > > +/**
> > > + * Event mode ipsec mode types
> > > + */
> > > +enum eh_ipsec_mode_types {
> > > + EH_IPSEC_MODE_TYPE_APP = 0,
> > > + EH_IPSEC_MODE_TYPE_DRIVER
> > > +};
> > > +
> > > +/**
> > > + * Event mode ipsec direction types
> > > + */
> > > +enum eh_ipsec_dir_types {
> > > + EH_IPSEC_DIR_TYPE_OUTBOUND = 0,
> > > + EH_IPSEC_DIR_TYPE_INBOUND,
> > > +};
> > > +
> > > /* Event dev params */
> > > struct eventdev_params {
> > > uint8_t eventdev_id;
> > > @@ -183,6 +199,12 @@ struct eh_conf {
> > >*/
> > > void *mode_params;
> > > /**< Mode specific parameters */
> > > +
> > > + /** Application specific params */
> > > + enum eh_ipsec_mode_types ipsec_mode;
> > > + /**< Mode of ipsec run */
> > > + enum eh_ipsec_dir_types ipsec_dir;
> > > + /**< Direction of ipsec processing */
> > > };
> > >
> > > /* Workers registered by the application */ @@ -194,6 +216,10 @@
> > > struct eh_app_worker_params {
> > > /**< Specify status of rx type burst */
> > > uint64_t tx_internal_port : 1;
> > > /**< Specify whether tx internal port is available */
> > > + uint64_t ipsec_mode : 1;
> > > + /**< Specify ipsec processing level */
> > > + uint64_t ipsec_dir : 1;
> > > + /**< Specify direction of ipsec */
> > > };
> > > uint64_t u64;
> > > } cap;
> > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > > b/examples/ipsec-secgw/ipsec-secgw.c
> > > index 7506922..c5d95b9 100644
> > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > @@ -2,6 +2,7 @@
> > > * Copyright(c) 2016 Intel Corporation
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -14,6 +15,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #include
> > > @@ -41,12 +43,17 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > #include
> > > #include
> > >
> > > +#include "event_helper.h"
> > > #include "ipsec.h"
> > > #include "parser.h"
> > >
> > > +volatile bool force_quit;
> > > +
> > > #define RTE_LOGTYPE_IPSEC RTE_LOGTYPE_USER1
> > >
> > > #define MAX_JUMBO_PKT_LEN 9600
> > > @@ -133,12 +140,21 @@ struct flow_info
> > flow_info_tbl[RTE_MAX_ETHPORTS];
> > > #define CMD_LINE_OPT_CONFIG "config"
> > > #define CMD_LINE_OPT_SINGLE_S
Re: [dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add eventmode to ipsec-secgw
> > > Add eventmode support to ipsec-secgw. This uses event helper to setup > > > and use the eventmode capabilities. Add driver inbound worker. > > > > > > Example command: > > > ./ipsec-secgw -c 0x1 -w 0002:02:00.0,ipsec_in_max_spi=100 -w > > > 0002:07:00.0 -w 0002:0e:00.0 -w 0002:10:00.1 -- -P -p 0x3 -u 0x1 > > > --config "(0,0,0),(1,0,0)" -f a-aes-gcm-msa.cfg --transfer-mode 1 > > > --schedule-type 2 --process-mode drv --process-dir in > > > > As I can see new event mode is totally orthogonal to the existing poll > > mode. > > Event mode has it is own data-path, and it doesn't reuse any part of poll- > > mode data-path code. > > Plus in event mode many poll-mode options: > > libirary/legacy mode, fragment/reassemble, replay-window, ESN, fall-back > > session, etc. > > are simply ignored. > > [Anoob] The features are not supported with the initial version. But the > features are equally applicable to eventmode and is planned for the > future. Also, fragment/reassemble, replay-window, ESN, fall-back session etc > are not applicable for non-library mode. True, but in poll-mode library-mode support all functionality that legacy-mode does, plus some extra. Also I still hope that after perf-problems evaluation with NXP we will be able to safely remove legacy poll-mode. >We can follow the > same logic and allow for an extra arg (which is --transfer-mode). > > > Also as I can read the current code - > > right now these modes can't be mixed and used together. > > User has to use either only event based or poll mode API/devices. > > [Anoob] Same like how we cannot mix library and non-library modes. > > > > > If so, then at least we need a check (and report with error exit) for these > > mutually exclusive option variants. > > [Anoob] Will do that. Ok. > > Probably even better would be to generate two separate binaries Let say: > > ipsec-secgw-event and ipsec-secgw-poll. > > We can still keep the same parent directory, makefile, common src files etc. > > for both. > > [Anoob] I would be inclined to not fork the current application. Do you see > any issues if the same binary could run in both modes. The > default behavior would be poll mode (with existing behavior). My main concern here that there will be over-helming number of options (some of which are mutually exclusive) in the same app. So it will be really hard to maintain and use such app. My thought was that it might be cleaner to have two different apps each with its own set of options.
Re: [dpdk-dev] [PATCH 12/14] examples/ipsec-secgw: add driver outbound worker
> > > This patch adds the driver outbound worker thread for ipsec-secgw.
> > > In this mode the security session is a fixed one and sa update is not
> > > done.
> > >
> > > Signed-off-by: Ankur Dwivedi
> > > Signed-off-by: Anoob Joseph
> > > Signed-off-by: Lukasz Bartosik
> > > ---
> > > examples/ipsec-secgw/ipsec-secgw.c | 12 +
> > > examples/ipsec-secgw/ipsec.c| 9
> > > examples/ipsec-secgw/ipsec_worker.c | 90
> > > -
> > > 3 files changed, 110 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > > b/examples/ipsec-secgw/ipsec-secgw.c
> > > index 2e7d4d8..76719f2 100644
> > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > @@ -2011,6 +2011,18 @@ cryptodevs_init(void)
> > > i++;
> > > }
> > >
> > > + /*
> > > + * Set the queue pair to at least the number of ethernet
> > > + * devices for inline outbound.
> > > + */
> > > + qp = RTE_MAX(rte_eth_dev_count_avail(), qp);
> >
> >
> > Not sure, what for?
> > Why we can't process packets from several eth devs on the same crypto-dev
> > queue?
>
> [Anoob] This is because of a limitation in our hardware. In our hardware,
> it's the crypto queue pair which would be submitting to the
> ethernet queue for Tx. But in DPDK spec, the security processing is done by
> the ethernet PMD Tx routine alone. We manage to do this by
> sharing the crypto queue internally. The crypto queues initialized during
> crypto_configure() gets mapped to various ethernet ports. Because
> of this, we need to have atleast as many crypto queues as the number of eth
> ports.
Ok, but that breaks current behavior.
Right now in poll-mode it is possible to map traffic from N eth-devs to M
crypto-devs (N>= M, by using M lcores).
Would prefer to keep this functionality in place.
>
> The above change is required because here we limit the number of crypto qps
> based on the number of cores etc. So when tried on single
> core, the qps get limited to 1, which causes session_create() to fail for all
> ports other than the first one.
>
> >
> > > +
> > > + /*
> > > + * The requested number of queues should never exceed
> > > + * the max available
> > > + */
> > > + qp = RTE_MIN(qp, max_nb_qps);
> > > +
> > > if (qp == 0)
> > > continue;
> > >
> > > diff --git a/examples/ipsec-secgw/ipsec.c
> > > b/examples/ipsec-secgw/ipsec.c index e529f68..9ff8a63 100644
> > > --- a/examples/ipsec-secgw/ipsec.c
> > > +++ b/examples/ipsec-secgw/ipsec.c
> > > @@ -141,6 +141,10 @@ create_lookaside_session(struct ipsec_ctx
> > *ipsec_ctx, struct ipsec_sa *sa,
> > > return 0;
> > > }
> > >
> > > +uint16_t sa_no;
> > > +#define MAX_FIXED_SESSIONS 10
> > > +struct rte_security_session *sec_session_fixed[MAX_FIXED_SESSIONS];
> > > +
> > > int
> > > create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> > > struct rte_ipsec_session *ips)
> > > @@ -401,6 +405,11 @@ create_inline_session(struct socket_ctx *skt_ctx,
> > > struct ipsec_sa *sa,
> > >
> > > ips->security.ol_flags = sec_cap->ol_flags;
> > > ips->security.ctx = sec_ctx;
> > > + if (sa_no < MAX_FIXED_SESSIONS) {
> > > + sec_session_fixed[sa_no] =
> > > + ipsec_get_primary_session(sa)-
> > >security.ses;
> > > + sa_no++;
> > > + }
> > > }
> >
> > Totally lost what is the purpose of these changes...
> > Why first 10 inline-proto are special and need to be saved inside global
> > array
> > (sec_session_fixed)?
> > Why later, in ipsec_worker.c this array is referenced by eth port_id?
> > What would happen if number of inline-proto sessions is less than number of
> > eth ports?
>
> [Anoob] This is required for the outbound driver mode. The 'driver mode' is
> more like 'single_sa' mode of the existing application. The idea
> is to skip all the lookups etc done in the s/w and perform ipsec processing
> fully in h/w. In outbound, following is roughly what we should do
> for driver mode,
>
> pkt = rx_burst();
>
> /* set_pkt_metadata() */
> pkt-> udata64 = session;
>
> tx_burst(pkt);
>
> The session is created on eth ports. And so, if we have single SA, then the
> entire traffic will have to be forwarded on the same port. The
> above change is to make sure we could send traffic on all ports.
>
> Currently we just use the first 10 SAs and save it in the array. So the user
> has to set the conf properly and make sure the SAs are distributed
> such. Will update this to save the first parsed outbound SA for a port in the
> array. That way the size of the array will be
> RTE_MAX_ETHPORTS.
Ok, then if it is for specific case (event-mode + sing-sa mode) then in
create_inline_session
we probably shouldn't do it always, but only when this mode is sele
Re: [dpdk-dev] [EXT] [PATCH 2/2] examples/l3fwd: support multiple queues in event mode
> -Original Message- > From: Sunil Kumar Kori > Sent: Monday, January 6, 2020 11:39 AM > To: Nipun Gupta ; dev@dpdk.org > Cc: Pavan Nikhilesh Bhagavatula ; Jerin Jacob > Kollanukkaran ; Hemant Agrawal > ; Akhil Goyal ; > marko.kovace...@intel.com; or...@mellanox.com; > bruce.richard...@intel.com; radu.nico...@intel.com; > tomasz.kante...@intel.com > Subject: RE: [EXT] [PATCH 2/2] examples/l3fwd: support multiple queues in > event mode > > > > Regards > Sunil Kumar Kori > > >-Original Message- > >From: Nipun Gupta > >Sent: Monday, January 6, 2020 10:05 AM > >To: dev@dpdk.org > >Cc: Pavan Nikhilesh Bhagavatula ; Jerin Jacob > >Kollanukkaran ; hemant.agra...@nxp.com; > >akhil.go...@nxp.com; marko.kovace...@intel.com; or...@mellanox.com; > >bruce.richard...@intel.com; radu.nico...@intel.com; > >tomasz.kante...@intel.com; Sunil Kumar Kori ; Nipun > >Gupta > >Subject: [EXT] [PATCH 2/2] examples/l3fwd: support multiple queues in event > >mode > > > >External Email > > > >-- > >Signed-off-by: Nipun Gupta > >--- > > examples/l3fwd/l3fwd_event.c | 55 > > examples/l3fwd/l3fwd_event.h | 4 +++ > > examples/l3fwd/main.c| 8 -- > > 3 files changed, 53 insertions(+), 14 deletions(-) > > > >diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index > >68998f42c..ecfaca435 100644 > >--- a/examples/l3fwd/main.c > >+++ b/examples/l3fwd/main.c > >@@ -285,7 +285,8 @@ print_usage(const char *prgname) > > " [--parse-ptype]" > > " [--per-port-pool]" > > " [--mode]" > >-" [--eventq-sched]\n\n" > >+" [--eventq-sched]" > >+" [--event-eth-queues]\n\n" > > > > " -p PORTMASK: Hexadecimal bitmask of ports to > >configure\n" > > " -P : Enable promiscuous mode\n" > >@@ -306,7 +307,10 @@ print_usage(const char *prgname) > > " --eventq-sched: Event queue synchronization method " > > " ordered, atomic or parallel.\n\t\t" > > " Default: atomic\n\t\t" > >-" Valid only if --mode=eventdev\n\n", > >+" Valid only if --mode=eventdev\n" > >+" --event-eth-queues: Number of ethernet queues per > >device.\n\t\t" > Will it be better to make it like "eth-rx-queues" simply ? So that It will > clearly > reflect that which queues it is referring to, Rx or Tx. Also Comment should > be > updated accordingly. Agree we should add rx also in the name to make it more clear, but I do not want to remove event from the name. How about ' --event-eth-rxqs'? Regards, Nipun > >+" Default: 1\n\t\t" > >+" Valid only if --mode=eventdev\n\n", > > prgname); > > } > > > >-- > >2.17.1
[dpdk-dev] [PATCH] net/virtio_user: do not close invalid file descriptor
Valgrind complains that virtio_user is calling close(-1).
Fix this by adding check in virtio that is similar to existing code.
Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger
---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index ea016e85d8af..ffbaa75b7e83 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -537,7 +537,8 @@ virtio_user_dev_uninit(struct virtio_user_dev *dev)
close(dev->kickfds[i]);
}
- close(dev->vhostfd);
+ if (dev->vhostfd >= 0)
+ close(dev->vhostfd);
if (dev->is_server && dev->listenfd >= 0) {
close(dev->listenfd);
--
2.20.1
Re: [dpdk-dev] [PATCH v2 1/2] ci: add travis ci support for aarch64
On 2019-12-20 01:37, Ruifeng Wang wrote:
Add Travis compilation jobs for aarch64. gcc/clang compilations for
static/shared libraries are added.
Some limitations for current aarch64 Travis support:
1. Container is used. Huge page is not available due to security
reason.
2. Missing kernel header package in Xenial distribution.
Solutions to address the limitations:
1. Not to add unit test for now. And run tests with no-huge in future.
2. Use Bionic distribution for all aarch64 jobs.
Signed-off-by: Ruifeng Wang
Reviewed-by: Gavin Hu
---
.ci/linux-setup.sh | 11 +++
.travis.yml| 37 -
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
index dfb9d4a20..a92978037 100755
--- a/.ci/linux-setup.sh
+++ b/.ci/linux-setup.sh
@@ -3,7 +3,10 @@
# need to install as 'root' since some of the unit tests won't run
without it
sudo python3 -m pip install --upgrade meson
-# setup hugepages
-cat /proc/meminfo
-sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
-cat /proc/meminfo
dont test for TRAVIS_ARCH here as multiple archs may need to avoid the
hugepage setup as well.
How about:
if [ "$RUN_TESTS" = "1" ]; then
# setup hugepages
If your planning to add a tests using --no-huge option could we add a
NOHUGEPAGES option to the matrix?
+# hugepage settings are skipped on aarch64 due to environment
limitation
+if [ "$TRAVIS_ARCH" != "aarch64" ]; then
+# setup hugepages
+cat /proc/meminfo
+sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
+cat /proc/meminfo
+fi
diff --git a/.travis.yml b/.travis.yml
index 8f90d06f2..048cb6ba5 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -115,6 +115,41 @@ matrix:
apt:
packages:
- *extra_packages
-
+ - env: DEF_LIB="static"
+arch: arm64
+compiler: gcc
+addons:
+ apt:
+packages:
+ - *required_packages
+ - env: DEF_LIB="shared"
+arch: arm64
+compiler: gcc
+addons:
+ apt:
+packages:
+ - *required_packages
+ - env: DEF_LIB="static"
+arch: arm64
+compiler: clang
+addons:
+ apt:
+packages:
+ - *required_packages
+ - env: DEF_LIB="shared"
+arch: arm64
+compiler: clang
+addons:
+ apt:
+packages:
+ - *required_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
+arch: arm64
+compiler: gcc
+addons:
+ apt:
+packages:
+ - *required_packages
+ - *doc_packages
script: ./.ci/${TRAVIS_OS_NAME}-build.sh
[dpdk-dev] [PATCH] mem: fix incorrect munmap in error unwind
The loop to unwind existing mmaps was only unmapping the
first segment.
Also, remove obvious redundant assignment.
Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")
Cc: anatoly.bura...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linux/eal/eal_memory.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal_memory.c
b/lib/librte_eal/linux/eal/eal_memory.c
index 43e4ffc757bd..cf5b2433614b 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -1967,9 +1967,8 @@ eal_legacy_hugepage_attach(void)
close(fd);
error:
/* map all segments into memory to make sure we get the addrs */
- cur_seg = 0;
for (cur_seg = 0; cur_seg < i; cur_seg++) {
- struct hugepage_file *hf = &hp[i];
+ struct hugepage_file *hf = &hp[cur_seg];
size_t map_sz = hf->size;
void *map_addr = hf->final_va;
--
2.20.1
[dpdk-dev] [Bug 380] memory subsystem leaks file descriptors
https://bugs.dpdk.org/show_bug.cgi?id=380 Bug ID: 380 Summary: memory subsystem leaks file descriptors Product: DPDK Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: step...@networkplumber.org Target Milestone: --- The DPDK EAL memory segment code opens a file descriptor for each memory segment, and these are never closed even after rte_eal_cleanup is called. Either the file should be closed after mmap (kernel will still have reference) or more cleanup logic needs to be added -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 381] hugepages not detached on cleanup
https://bugs.dpdk.org/show_bug.cgi?id=381 Bug ID: 381 Summary: hugepages not detached on cleanup Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: step...@networkplumber.org Target Milestone: --- When application calls rte_eal_cleanup all resources in use by DPDK should be closed and freed. The bug is that the hugepage memory associated with a process is not munmapped in either primary or secondary process. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] C++ app does not execute DPDK constructors.
Hi *What am I trying to do?* I am trying to write Gtests for my application based on DPDK. *Details about the app:* The application compiles dpdk as static library. Its a pretty simple. For now it just runs a dummy Gtest and create a memory pool. The key is, its a C++ file. I see no issue if it were a C app. *Issue I am facing:* The call to rte_mempool_create fails() with "Err: No such file or directory". *More debugging:* The reason for the above failure is, the constructor for the ring driver is not getting called. Specifically below code in ~/driver/mempool/ring/rte_mempool_ring.c. MEMPOOL_REGISTER_OPS(ops_mp_mc); MEMPOOL_REGISTER_OPS(ops_sp_sc); MEMPOOL_REGISTER_OPS(ops_mp_sc); MEMPOOL_REGISTER_OPS(ops_sp_mc); So when I look at the C app which has these constructors called, I see the init_array size to be much larger than the the C++ app. Considering the two code are almost identical, I don't know what am I missing to have these constructors run. They are definitely getting compiled but are not called. *What have I tried:* 1. I tried the --whole-archive LD option but I dont think that should play a part here since the constructors does get called with C app. Any suggestions? Regards Sachin.
[dpdk-dev] [PATCH v3 0/7] bnxt patchset
v2->v3: - Rebased patches against latest dpdk-next-net - sync commit logs Ajit Khaparde (2): net/bnxt: add support for flow mark action net/bnxt: fix to not overwrite error message Santoshkumar Karanappa Rastapur (2): net/bnxt: fix link failure during port toggle net/bnxt: fix non matching flow hitting filter rule Somnath Kotur (3): net/bnxt: fix to use first valid profile net/bnxt: fix flow flush to sync with flow destroy net/bnxt: fix to reuse an L2 filter drivers/net/bnxt/bnxt.h| 15 ++- drivers/net/bnxt/bnxt_cpr.c| 2 +- drivers/net/bnxt/bnxt_ethdev.c | 34 - drivers/net/bnxt/bnxt_filter.h | 7 + drivers/net/bnxt/bnxt_flow.c | 233 + drivers/net/bnxt/bnxt_hwrm.c | 66 -- drivers/net/bnxt/bnxt_hwrm.h | 3 + drivers/net/bnxt/bnxt_rxr.c| 41 +- drivers/net/bnxt/bnxt_rxr.h| 11 ++ 9 files changed, 277 insertions(+), 135 deletions(-) -- 2.21.0 (Apple Git-122.2)
[dpdk-dev] [PATCH v3 3/7] net/bnxt: fix flow flush to sync with flow destroy
From: Somnath Kotur
Sync flow flush routine with flow destroy so that the operations
performed per flow during a flush are the same as that are done for an
individual flow destroy by having a common function to call for both.
One of the things that was missed in the flow flush routine was the
deletion of the L2 filter that would have been created as part of an
n-tuple filter.
Also, decrement the l2_ref_cnt for a filter in the case of a filter
update as it would've bumped up previously in validate_and_parse_flow()
Fixes: 89278c59d97c58 ("net/bnxt: fix flow flush handling")
Cc: sta...@dpdk.org
Signed-off-by: Somnath Kotur
Reviewed-by: Santoshkumar Karanappa Rastapur
---
drivers/net/bnxt/bnxt_flow.c | 132 ---
1 file changed, 46 insertions(+), 86 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 7bd6811f1..7343b7e7b 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -1536,10 +1536,13 @@ bnxt_update_filter(struct bnxt *bp, struct
bnxt_filter_info *old_filter,
* filter which points to the new destination queue and so we clear
* the previous L2 filter. For ntuple filters, we are going to reuse
* the old L2 filter and create new NTUPLE filter with this new
-* destination queue subsequently during bnxt_flow_create.
+* destination queue subsequently during bnxt_flow_create. So we
+* decrement the ref cnt of the L2 filter that would've been bumped
+* up previously in bnxt_validate_and_parse_flow as the old n-tuple
+* filter that was referencing it will be deleted now.
*/
+ bnxt_hwrm_clear_l2_filter(bp, old_filter);
if (new_filter->filter_type == HWRM_CFA_L2_FILTER) {
- bnxt_hwrm_clear_l2_filter(bp, old_filter);
bnxt_hwrm_set_l2_filter(bp, new_filter->dst_id, new_filter);
} else {
if (new_filter->filter_type == HWRM_CFA_EM_FILTER)
@@ -1816,46 +1819,24 @@ static int bnxt_handle_tunnel_redirect_destroy(struct
bnxt *bp,
}
static int
-bnxt_flow_destroy(struct rte_eth_dev *dev,
- struct rte_flow *flow,
- struct rte_flow_error *error)
+_bnxt_flow_destroy(struct bnxt *bp,
+ struct rte_flow *flow,
+ struct rte_flow_error *error)
{
- struct bnxt *bp = dev->data->dev_private;
struct bnxt_filter_info *filter;
struct bnxt_vnic_info *vnic;
int ret = 0;
- bnxt_acquire_flow_lock(bp);
- if (!flow) {
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Invalid flow: failed to destroy flow.");
- bnxt_release_flow_lock(bp);
- return -EINVAL;
- }
-
filter = flow->filter;
vnic = flow->vnic;
- if (!filter) {
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Invalid flow: failed to destroy flow.");
- bnxt_release_flow_lock(bp);
- return -EINVAL;
- }
-
if (filter->filter_type == HWRM_CFA_TUNNEL_REDIRECT_FILTER &&
filter->enables == filter->tunnel_type) {
- ret = bnxt_handle_tunnel_redirect_destroy(bp,
- filter,
- error);
- if (!ret) {
+ ret = bnxt_handle_tunnel_redirect_destroy(bp, filter, error);
+ if (!ret)
goto done;
- } else {
- bnxt_release_flow_lock(bp);
+ else
return ret;
- }
}
ret = bnxt_match_filter(bp, filter);
@@ -1902,7 +1883,36 @@ bnxt_flow_destroy(struct rte_eth_dev *dev,
"Failed to destroy flow.");
}
+ return ret;
+}
+
+static int
+bnxt_flow_destroy(struct rte_eth_dev *dev,
+ struct rte_flow *flow,
+ struct rte_flow_error *error)
+{
+ struct bnxt *bp = dev->data->dev_private;
+ int ret = 0;
+
+ bnxt_acquire_flow_lock(bp);
+ if (!flow) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
+ "Invalid flow: failed to destroy flow.");
+ bnxt_release_flow_lock(bp);
+ return -EINVAL;
+ }
+
+ if (!flow->filter) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
+ "Invalid flow: failed to destroy flow.");
+ bnxt_release_flow_lock(bp);
+ return -EINVAL;
+ }
+ ret = _bnxt_flow_destr
[dpdk-dev] [PATCH v3 4/7] net/bnxt: fix non matching flow hitting filter rule
From: Santoshkumar Karanappa Rastapur
As part of ntuple filter, we were creating L2 filter with the ntuple
redirect queue resulting in any L2 matching flow getting steered to
this queue. For ntuple filters, we need to create the L2 filter with
default queue. The user specified redirect queue will be set while
creating the ntuple filter in hardware.
Fixes: 5c1171c97216 ("net/bnxt: refactor filter/flow")
Cc: sta...@dpdk.org
Signed-off-by: Santoshkumar Karanappa Rastapur
Signed-off-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_flow.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 7343b7e7b..855994a6b 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -1126,7 +1126,16 @@ bnxt_validate_and_parse_flow(struct rte_eth_dev *dev,
PMD_DRV_LOG(DEBUG,
"Setting vnic ff_idx %d\n", vnic->ff_pool_idx);
filter->dst_id = vnic->fw_vnic_id;
- filter1 = bnxt_get_l2_filter(bp, filter, vnic);
+
+ /* For ntuple filter, create the L2 filter with default VNIC.
+* The user specified redirect queue will be set while creating
+* the ntuple filter in hardware.
+*/
+ vnic0 = BNXT_GET_DEFAULT_VNIC(bp);
+ if (use_ntuple)
+ filter1 = bnxt_get_l2_filter(bp, filter, vnic0);
+ else
+ filter1 = bnxt_get_l2_filter(bp, filter, vnic);
if (filter1 == NULL) {
rte_flow_error_set(error,
ENOSPC,
--
2.21.0 (Apple Git-122.2)
[dpdk-dev] [PATCH v3 7/7] net/bnxt: fix to not overwrite error message
In some cases when flow creation fails, we overwrite the specific
error message with a generic error message. This patch fixes it.
Fixes: d24610f7bfda ("net/bnxt: allow flow creation when RSS is enabled")
Cc: sta...@dpdk.org
Signed-off-by: Ajit Khaparde
Reviewed-by: Lance Richardson
---
drivers/net/bnxt/bnxt_flow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 707aedcec..cde1fa41c 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -1485,7 +1485,7 @@ bnxt_validate_and_parse_flow(struct rte_eth_dev *dev,
if (rxq && !vnic->rx_queue_cnt)
rxq->vnic = &bp->vnic_info[0];
}
- return rc;
+ return -rte_errno;
}
static
@@ -1815,7 +1815,7 @@ bnxt_flow_create(struct rte_eth_dev *dev,
rte_flow_error_set(error, 0,
RTE_FLOW_ERROR_TYPE_NONE, NULL,
"Flow with pattern exists, updating
destination queue");
- else
+ else if (!rte_errno)
rte_flow_error_set(error, -ret,
RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
"Failed to create flow.");
--
2.21.0 (Apple Git-122.2)
[dpdk-dev] [PATCH v3 5/7] net/bnxt: fix to reuse an L2 filter
From: Somnath Kotur
The software L2 filter was being released back to the free pool,
though it was created in HW and the filter corresponding to an actual
'flow' would have reference to the HW L2 filter.
But if this 'flow were to be deleted, then this HW L2 filter also
would be gone.
Fix this by storing the L2 filter created originally either for an
n-tuple flow or otherwise as part of the vnic's filter list.
This would require the filter_info struct to have a backptr to the
vnic which it came from.
Now that L2 filters can be re-used for an n-tuple filter(s), delete
L2 filter as well so the reference count of an L2 filter (if reused)
can be decremented appropriately.
Fixes: 5c1171c97216 ("net/bnxt: refactor filter/flow")
Cc: sta...@dpdk.org
Signed-off-by: Somnath Kotur
Reviewed-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt_filter.h | 4
drivers/net/bnxt/bnxt_flow.c | 20 +---
drivers/net/bnxt/bnxt_hwrm.c | 20 +++-
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_filter.h b/drivers/net/bnxt/bnxt_filter.h
index 9db3e7487..fc40f112b 100644
--- a/drivers/net/bnxt/bnxt_filter.h
+++ b/drivers/net/bnxt/bnxt_filter.h
@@ -77,6 +77,10 @@ struct bnxt_filter_info {
uint16_tip_addr_type;
uint16_tethertype;
uint32_tpriority;
+ /* Backptr to vnic. As of now, used only by an L2 filter
+* to remember which vnic it was created on
+*/
+ struct bnxt_vnic_info *vnic;
};
struct bnxt_filter_info *bnxt_alloc_filter(struct bnxt *bp);
diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 855994a6b..2bd492ea3 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -746,10 +746,9 @@ bnxt_find_matching_l2_filter(struct bnxt *bp, struct
bnxt_filter_info *nf)
{
struct bnxt_filter_info *mf, *f0;
struct bnxt_vnic_info *vnic0;
- struct rte_flow *flow;
int i;
- vnic0 = &bp->vnic_info[0];
+ vnic0 = BNXT_GET_DEFAULT_VNIC(bp);
f0 = STAILQ_FIRST(&vnic0->filter);
/* This flow has same DST MAC as the port/l2 filter. */
@@ -762,8 +761,7 @@ bnxt_find_matching_l2_filter(struct bnxt *bp, struct
bnxt_filter_info *nf)
if (vnic->fw_vnic_id == INVALID_VNIC_ID)
continue;
- STAILQ_FOREACH(flow, &vnic->flow_list, next) {
- mf = flow->filter;
+ STAILQ_FOREACH(mf, &vnic->filter, next) {
if (mf->matching_l2_fltr_ptr)
continue;
@@ -798,6 +796,8 @@ bnxt_create_l2_filter(struct bnxt *bp, struct
bnxt_filter_info *nf,
if (filter1 == NULL)
return NULL;
+ memcpy(filter1, nf, sizeof(*filter1));
+
filter1->flags = HWRM_CFA_L2_FILTER_ALLOC_INPUT_FLAGS_XDP_DISABLE;
filter1->flags |= HWRM_CFA_L2_FILTER_ALLOC_INPUT_FLAGS_PATH_RX;
if (nf->valid_flags & BNXT_FLOW_L2_SRC_VALID_FLAG ||
@@ -880,11 +880,14 @@ bnxt_get_l2_filter(struct bnxt *bp, struct
bnxt_filter_info *nf,
l2_filter = bnxt_find_matching_l2_filter(bp, nf);
if (l2_filter) {
l2_filter->l2_ref_cnt++;
- nf->matching_l2_fltr_ptr = l2_filter;
} else {
l2_filter = bnxt_create_l2_filter(bp, nf, vnic);
- nf->matching_l2_fltr_ptr = NULL;
+ if (l2_filter) {
+ STAILQ_INSERT_TAIL(&vnic->filter, l2_filter, next);
+ l2_filter->vnic = vnic;
+ }
}
+ nf->matching_l2_fltr_ptr = l2_filter;
return l2_filter;
}
@@ -1429,11 +1432,6 @@ bnxt_validate_and_parse_flow(struct rte_eth_dev *dev,
goto ret;
}
- if (filter1 && !filter->matching_l2_fltr_ptr) {
- bnxt_free_filter(bp, filter1);
- filter1->fw_l2_filter_id = -1;
- }
-
done:
act = bnxt_flow_non_void_action(++act);
if (act->type != RTE_FLOW_ACTION_TYPE_END) {
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index bee4c154f..8178213e5 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -363,10 +363,11 @@ int bnxt_hwrm_cfa_vlan_antispoof_cfg(struct bnxt *bp,
uint16_t fid,
}
int bnxt_hwrm_clear_l2_filter(struct bnxt *bp,
- struct bnxt_filter_info *filter)
+struct bnxt_filter_info *filter)
{
int rc = 0;
struct bnxt_filter_info *l2_filter = filter;
+ struct bnxt_vnic_info *vnic = NULL;
struct hwrm_cfa_l2_filter_free_input req = {.req_type = 0 };
struct hwrm_cfa_l2_filter_free_output *resp = bp->hwrm_cmd_resp_addr;
@@ -379,6 +380,9 @@ int bnxt_hwrm_clear_l2_filter(struct bnxt *bp,
PMD_DRV_LOG(DEBUG, "filter: %p l2_filter: %p ref_cnt: %d\n",
[dpdk-dev] [PATCH v3 2/7] net/bnxt: fix to use first valid profile
From: Somnath Kotur
In the case when CoS classification is disabled, driver was iterating
looking for only lossy profiles as that is what is expected to be used
for regular NIC operations. But in certain custom profiles, there were
no lossy profiles configured, only lossless profiles instead.
To handle such cases, it is better to fallback to using the first valid
profile.
Fixes: 698aa7e95325 ("net/bnxt: add code to determine the Tx COS queue")
Cc: sta...@dpdk.org
Signed-off-by: Somnath Kotur
Reviewed-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt_hwrm.c | 44 +---
drivers/net/bnxt/bnxt_hwrm.h | 3 +++
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index d0dcd561c..bee4c154f 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -1210,6 +1210,35 @@ static int bnxt_hwrm_port_phy_qcfg(struct bnxt *bp,
return rc;
}
+static bool bnxt_find_lossy_profile(struct bnxt *bp)
+{
+ int i = 0;
+
+ for (i = BNXT_COS_QUEUE_COUNT - 1; i >= 0; i--) {
+ if (bp->tx_cos_queue[i].profile ==
+ HWRM_QUEUE_SERVICE_PROFILE_LOSSY) {
+ bp->tx_cosq_id[0] = bp->tx_cos_queue[i].id;
+ return true;
+ }
+ }
+ return false;
+}
+
+static void bnxt_find_first_valid_profile(struct bnxt *bp)
+{
+ int i = 0;
+
+ for (i = BNXT_COS_QUEUE_COUNT - 1; i >= 0; i--) {
+ if (bp->tx_cos_queue[i].profile !=
+ HWRM_QUEUE_SERVICE_PROFILE_UNKNOWN &&
+ bp->tx_cos_queue[i].id !=
+ HWRM_QUEUE_SERVICE_PROFILE_UNKNOWN) {
+ bp->tx_cosq_id[0] = bp->tx_cos_queue[i].id;
+ break;
+ }
+ }
+}
+
int bnxt_hwrm_queue_qportcfg(struct bnxt *bp)
{
int rc = 0;
@@ -1269,14 +1298,13 @@ int bnxt_hwrm_queue_qportcfg(struct bnxt *bp)
bp->tx_cos_queue[i].id;
}
} else {
- for (i = BNXT_COS_QUEUE_COUNT - 1; i >= 0; i--) {
- if (bp->tx_cos_queue[i].profile ==
- HWRM_QUEUE_SERVICE_PROFILE_LOSSY) {
- bp->tx_cosq_id[0] =
- bp->tx_cos_queue[i].id;
- break;
- }
- }
+ /* When CoS classification is disabled, for normal NIC
+* operations, ideally we should look to use LOSSY.
+* If not found, fallback to the first valid profile
+*/
+ if (!bnxt_find_lossy_profile(bp))
+ bnxt_find_first_valid_profile(bp);
+
}
}
diff --git a/drivers/net/bnxt/bnxt_hwrm.h b/drivers/net/bnxt/bnxt_hwrm.h
index abe5de9db..d8d1360f9 100644
--- a/drivers/net/bnxt/bnxt_hwrm.h
+++ b/drivers/net/bnxt/bnxt_hwrm.h
@@ -35,6 +35,9 @@ struct bnxt_cp_ring_info;
#define HWRM_QUEUE_SERVICE_PROFILE_LOSSY \
HWRM_QUEUE_QPORTCFG_OUTPUT_QUEUE_ID0_SERVICE_PROFILE_LOSSY
+#define HWRM_QUEUE_SERVICE_PROFILE_UNKNOWN \
+ HWRM_QUEUE_QPORTCFG_OUTPUT_QUEUE_ID0_SERVICE_PROFILE_UNKNOWN
+
#define HWRM_FUNC_RESOURCE_QCAPS_OUTPUT_VF_RESV_STRATEGY_MINIMAL_STATIC \
HWRM_FUNC_RESOURCE_QCAPS_OUTPUT_VF_RESERVATION_STRATEGY_MINIMAL_STATIC
#define HWRM_FUNC_RESOURCE_QCAPS_OUTPUT_VF_RESV_STRATEGY_MAXIMAL \
--
2.21.0 (Apple Git-122.2)
[dpdk-dev] [PATCH v3 6/7] net/bnxt: add support for flow mark action
Add support for RTE_FLOW_ACTION_TYPE_MARK.
Use the flow_id provided by FW during flow creation to lookup the
mark id provided by the application.
Signed-off-by: Ajit Khaparde
Reviewed-by: Lance Richardson
---
drivers/net/bnxt/bnxt.h| 5 +++
drivers/net/bnxt/bnxt_ethdev.c | 16 -
drivers/net/bnxt/bnxt_filter.h | 3 ++
drivers/net/bnxt/bnxt_flow.c | 66 --
drivers/net/bnxt/bnxt_hwrm.c | 2 ++
drivers/net/bnxt/bnxt_rxr.c| 41 -
drivers/net/bnxt/bnxt_rxr.h| 11 ++
7 files changed, 132 insertions(+), 12 deletions(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index ab0b8dde1..21ca059b8 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -515,6 +515,7 @@ struct bnxt {
#define BNXT_FLAG_INIT_DONEBIT(21)
#define BNXT_FLAG_FW_CAP_ONE_STEP_TX_TSBIT(22)
#define BNXT_FLAG_ADV_FLOW_MGMTBIT(23)
+#define BNXT_FLAG_RX_VECTOR_PKT_MODE BIT(24)
#define BNXT_PF(bp)(!((bp)->flags & BNXT_FLAG_VF))
#define BNXT_VF(bp)((bp)->flags & BNXT_FLAG_VF)
#define BNXT_NPAR(bp) ((bp)->port_partition_type)
@@ -654,6 +655,10 @@ struct bnxt {
/* Struct to hold adapter error recovery related info */
struct bnxt_error_recovery_info *recovery_info;
+#define BNXT_MARK_TABLE_SZ (sizeof(uint32_t) * 64 * 1024)
+/* TCAM and EM should be 16-bit only. Other modes not supported. */
+#define BNXT_FLOW_ID_MASK 0x
+ uint32_t*mark_table;
};
int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu);
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 88df82b86..7b5df9ac1 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -458,6 +458,10 @@ static int bnxt_init_chip(struct bnxt *bp)
}
bnxt_print_link_info(bp->eth_dev);
+ bp->mark_table = rte_zmalloc("bnxt_mark_table", BNXT_MARK_TABLE_SZ, 0);
+ if (!bp->mark_table)
+ PMD_DRV_LOG(ERR, "Allocation of mark table failed\n");
+
return 0;
err_free:
@@ -740,8 +744,10 @@ static int bnxt_scattered_rx(struct rte_eth_dev *eth_dev)
}
static eth_rx_burst_t
-bnxt_receive_function(__rte_unused struct rte_eth_dev *eth_dev)
+bnxt_receive_function(struct rte_eth_dev *eth_dev)
{
+ struct bnxt *bp = eth_dev->data->dev_private;
+
#ifdef RTE_ARCH_X86
#ifndef RTE_LIBRTE_IEEE1588
/*
@@ -762,6 +768,7 @@ bnxt_receive_function(__rte_unused struct rte_eth_dev
*eth_dev)
DEV_RX_OFFLOAD_VLAN_FILTER))) {
PMD_DRV_LOG(INFO, "Using vector mode receive for port %d\n",
eth_dev->data->port_id);
+ bp->flags |= BNXT_FLAG_RX_VECTOR_PKT_MODE;
return bnxt_recv_pkts_vec;
}
PMD_DRV_LOG(INFO, "Vector mode receive disabled for port %d\n",
@@ -773,6 +780,7 @@ bnxt_receive_function(__rte_unused struct rte_eth_dev
*eth_dev)
eth_dev->data->dev_conf.rxmode.offloads);
#endif
#endif
+ bp->flags &= ~BNXT_FLAG_RX_VECTOR_PKT_MODE;
return bnxt_recv_pkts;
}
@@ -956,6 +964,8 @@ static void bnxt_dev_stop_op(struct rte_eth_dev *eth_dev)
bnxt_int_handler(eth_dev);
bnxt_shutdown_nic(bp);
bnxt_hwrm_if_change(bp, 0);
+ memset(bp->mark_table, 0, BNXT_MARK_TABLE_SZ);
+ bp->flags &= ~BNXT_FLAG_RX_VECTOR_PKT_MODE;
bp->dev_stopped = 1;
bp->rx_cosq_cnt = 0;
}
@@ -976,6 +986,9 @@ static void bnxt_dev_close_op(struct rte_eth_dev *eth_dev)
bp->grp_info = NULL;
}
+ rte_free(bp->mark_table);
+ bp->mark_table = NULL;
+
bnxt_dev_uninit(eth_dev);
}
@@ -4775,6 +4788,7 @@ bnxt_dev_init(struct rte_eth_dev *eth_dev)
bp = eth_dev->data->dev_private;
bp->dev_stopped = 1;
+ bp->flags &= ~BNXT_FLAG_RX_VECTOR_PKT_MODE;
if (bnxt_vf_pciid(pci_dev->id.device_id))
bp->flags |= BNXT_FLAG_VF;
diff --git a/drivers/net/bnxt/bnxt_filter.h b/drivers/net/bnxt/bnxt_filter.h
index fc40f112b..8f8a4c13b 100644
--- a/drivers/net/bnxt/bnxt_filter.h
+++ b/drivers/net/bnxt/bnxt_filter.h
@@ -23,9 +23,11 @@ struct bnxt;
#define BNXT_FLOW_L2_INNER_DST_VALID_FLAG BIT(4)
#define BNXT_FLOW_L2_DROP_FLAG BIT(5)
#define BNXT_FLOW_PARSE_INNER_FLAG BIT(6)
+#define BNXT_FLOW_MARK_FLAGBIT(7)
struct bnxt_filter_info {
STAILQ_ENTRY(bnxt_filter_info) next;
+ uint32_tflow_id;
uint64_tfw_l2_filter_id;
struct bnxt_filter_info *matching_l2_fltr_ptr;
uint64_tfw_em_filter_id;
@@ -81,6 +83,7 @@ struct bnxt_filter_info {
* to remember which vnic it was created on
*/
struct bnxt_vnic_info *vnic;
+ uint32_t
[dpdk-dev] [PATCH v3 1/7] net/bnxt: fix link failure during port toggle
From: Santoshkumar Karanappa Rastapur
We need to wait for up to 500ms to receive async event notification after
forcing link down. Similarly we need to wait for up to 10s for link to
come up after configuring the hardware for link up.
Fixes: c09f57b49c13 ("net/bnxt: add start/stop/link update operations")
Cc: sta...@dpdk.org
Signed-off-by: Santoshkumar Karanappa Rastapur
Signed-off-by: Somnath Kotur
---
drivers/net/bnxt/bnxt.h| 10 ++
drivers/net/bnxt/bnxt_cpr.c| 2 +-
drivers/net/bnxt/bnxt_ethdev.c | 18 +-
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index ab18e8acd..ab0b8dde1 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -231,9 +231,10 @@ struct bnxt_pf_info {
uint8_t evb_mode;
};
-/* Max wait time is 10 * 100ms = 1s */
-#define BNXT_LINK_WAIT_CNT 10
-#define BNXT_LINK_WAIT_INTERVAL100
+/* Max wait time for link up is 10s and link down is 500ms */
+#define BNXT_LINK_UP_WAIT_CNT 200
+#define BNXT_LINK_DOWN_WAIT_CNT10
+#define BNXT_LINK_WAIT_INTERVAL50
struct bnxt_link_info {
uint32_tphy_flags;
uint8_t mac_type;
@@ -656,7 +657,8 @@ struct bnxt {
};
int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu);
-int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int wait_to_complete);
+int bnxt_link_update(struct rte_eth_dev *eth_dev, int wait_to_complete,
+bool exp_link_status);
int bnxt_rcv_msg_from_vf(struct bnxt *bp, uint16_t vf_id, void *msg);
int is_bnxt_in_error(struct bnxt *bp);
uint16_t bnxt_rss_ctxts(const struct bnxt *bp);
diff --git a/drivers/net/bnxt/bnxt_cpr.c b/drivers/net/bnxt/bnxt_cpr.c
index 2c3129fe2..bb316b9e0 100644
--- a/drivers/net/bnxt/bnxt_cpr.c
+++ b/drivers/net/bnxt/bnxt_cpr.c
@@ -63,7 +63,7 @@ void bnxt_handle_async_event(struct bnxt *bp,
case HWRM_ASYNC_EVENT_CMPL_EVENT_ID_LINK_SPEED_CHANGE:
case HWRM_ASYNC_EVENT_CMPL_EVENT_ID_LINK_SPEED_CFG_CHANGE:
/* FALLTHROUGH */
- bnxt_link_update_op(bp->eth_dev, 0);
+ bnxt_link_update(bp->eth_dev, 0, ETH_LINK_UP);
break;
case HWRM_ASYNC_EVENT_CMPL_EVENT_ID_PF_DRVR_UNLOAD:
PMD_DRV_LOG(INFO, "Async event: PF driver unloaded\n");
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 1b4ed293d..88df82b86 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -856,7 +856,7 @@ static int bnxt_dev_start_op(struct rte_eth_dev *eth_dev)
eth_dev->data->scattered_rx = bnxt_scattered_rx(eth_dev);
- bnxt_link_update_op(eth_dev, 1);
+ bnxt_link_update(eth_dev, 1, ETH_LINK_UP);
if (rx_offloads & DEV_RX_OFFLOAD_VLAN_FILTER)
vlan_mask |= ETH_VLAN_FILTER_MASK;
@@ -940,7 +940,7 @@ static void bnxt_dev_stop_op(struct rte_eth_dev *eth_dev)
* During reset recovery, there is no need to wait
*/
if (!is_bnxt_in_error(bp))
- rte_delay_ms(BNXT_LINK_WAIT_INTERVAL * 2);
+ bnxt_link_update(eth_dev, 1, ETH_LINK_DOWN);
/* Clean queue intr-vector mapping */
rte_intr_efd_disable(intr_handle);
@@ -1086,12 +1086,14 @@ static int bnxt_mac_addr_add_op(struct rte_eth_dev
*eth_dev,
return rc;
}
-int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int wait_to_complete)
+int bnxt_link_update(struct rte_eth_dev *eth_dev, int wait_to_complete,
+bool exp_link_status)
{
int rc = 0;
struct bnxt *bp = eth_dev->data->dev_private;
struct rte_eth_link new;
- unsigned int cnt = BNXT_LINK_WAIT_CNT;
+ int cnt = exp_link_status ? BNXT_LINK_UP_WAIT_CNT :
+ BNXT_LINK_DOWN_WAIT_CNT;
rc = is_bnxt_in_error(bp);
if (rc)
@@ -1109,7 +,7 @@ int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int
wait_to_complete)
goto out;
}
- if (!wait_to_complete || new.link_status)
+ if (!wait_to_complete || new.link_status == exp_link_status)
break;
rte_delay_ms(BNXT_LINK_WAIT_INTERVAL);
@@ -1131,6 +1133,12 @@ int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int
wait_to_complete)
return rc;
}
+static int bnxt_link_update_op(struct rte_eth_dev *eth_dev,
+ int wait_to_complete)
+{
+ return bnxt_link_update(eth_dev, wait_to_complete, ETH_LINK_UP);
+}
+
static int bnxt_promiscuous_enable_op(struct rte_eth_dev *eth_dev)
{
struct bnxt *bp = eth_dev->data->dev_private;
--
2.21.0 (Apple Git-122.2)
Re: [dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs
> >
> > >
> > > On Sat, 21 Dec 2019 16:07:23 +
> > > Honnappa Nagarahalli wrote:
> > >
> > > > Converting these into macros will help remove the size based
> duplication of
> > > APIs. I came up with the following macro:
> > > >
> > > > #define RTE_GET_BIT(nr, var, ret, memorder) \ ({ \
> > > > if (sizeof(var) == sizeof(uint32_t)) { \
> > > > uint32_t mask1 = 1U << (nr)%32; \
> > > > ret = __atomic_load_n(&var, (memorder)) & mask1;\
> > > > } \
> > > > else {\
> > > > uint64_t mask2 = 1UL << (nr)%64;\
> > > > ret = __atomic_load_n(&var, (memorder)) & mask2;\
> > > > } \
> > > > })
> > >
> > > Macros are more error prone. Especially because this is in exposed header
> file
> > That's another question I have. Why do we need to have these APIs in a
> public header file? These will add to the ABI burden as well. These APIs
> should be in a common-but-not-public header file. I am also not sure how
> helpful these APIs are for applications as these APIs seem to have considered
> requirements only from the PMDs.
>
> Why do we have to wrap every C atomic builtin? What value is there in that?
As long as we stick to requirements from PMD we do not need to worry about
every atomic builtin. We seem to be making these APIs public, which requires us
to keep these APIs generic considering possible future requirements.
Re: [dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs
> > >
> > > >
> > > > On Sat, 21 Dec 2019 16:07:23 + Honnappa Nagarahalli
> > > > wrote:
> > > >
> > > > > Converting these into macros will help remove the size based
> > > > > duplication
> > of
> > > > APIs. I came up with the following macro:
> > > > >
> > > > > #define RTE_GET_BIT(nr, var, ret, memorder) \ ({ \
> > > > > if (sizeof(var) == sizeof(uint32_t)) { \
> > > > > uint32_t mask1 = 1U << (nr)%32; \
> > > > > ret = __atomic_load_n(&var, (memorder)) & mask1;\
> > > > > } \
> > > > > else {\
> > > > > uint64_t mask2 = 1UL << (nr)%64;\
> > > > > ret = __atomic_load_n(&var, (memorder)) & mask2;\
> > > > > } \
> > > > > })
> > > >
> > > > Macros are more error prone. Especially because this is in exposed
> > > > header
> > file
> > > That's another question I have. Why do we need to have these APIs in
> > > a
> > public header file? These will add to the ABI burden as well. These
> > APIs should be in a common-but-not-public header file. I am also not
> > sure how helpful these APIs are for applications as these APIs seem to
> > have considered requirements only from the PMDs.
> >
> > Why do we have to wrap every C atomic builtin? What value is there in that?
>
> The wrapping is aimed to reduce code duplication, on average 3 lines cut
> down to 1 line for a single core.
> Overall I am thinking this bitops APIs are targeted for use by PMDs only,
> applications can use C11 freely.
> The initial thought for the new APIs came from the idea of consolidating the
> scattered bit operations all over the PMDs. It is unwise to expanding to
> applications or libraries, as different memory orderings are required and
> complexity generate.
>
> If the use cases are limited to PMDs, a 'volatile' or a compiler barrier is
> sufficient therefore the number of APIs can be saved by half.
> http://inbox.dpdk.org/dev/VI1PR08MB53766C30B5CDA00FB9FCE9678F2E0
> @VI1PR08MB5376.eurprd08.prod.outlook.com/
>
> Any thoughts and comments are welcome!
I would prefer that the APIs/Macros just address PMD's requirements. These also
should be kept private (through naming conventions?). Given that the current
PMDs are not using C11, we can skip using C11 atomics in these APIs.
>
Re: [dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs
On Tue, 7 Jan 2020 00:44:51 +
Honnappa Nagarahalli wrote:
>
>
> > > >
> > > > >
> > > > > On Sat, 21 Dec 2019 16:07:23 + Honnappa Nagarahalli
> > > > > wrote:
> > > > >
> > > > > > Converting these into macros will help remove the size based
> > > > > > duplication
> > > of
> > > > > APIs. I came up with the following macro:
> > > > > >
> > > > > > #define RTE_GET_BIT(nr, var, ret, memorder) \ ({ \
> > > > > > if (sizeof(var) == sizeof(uint32_t)) { \
> > > > > > uint32_t mask1 = 1U << (nr)%32; \
> > > > > > ret = __atomic_load_n(&var, (memorder)) & mask1;\
> > > > > > } \
> > > > > > else {\
> > > > > > uint64_t mask2 = 1UL << (nr)%64;\
> > > > > > ret = __atomic_load_n(&var, (memorder)) & mask2;\
> > > > > > } \
> > > > > > })
> > > > >
> > > > > Macros are more error prone. Especially because this is in exposed
> > > > > header
> > > file
> > > > That's another question I have. Why do we need to have these APIs in
> > > > a
> > > public header file? These will add to the ABI burden as well. These
> > > APIs should be in a common-but-not-public header file. I am also not
> > > sure how helpful these APIs are for applications as these APIs seem to
> > > have considered requirements only from the PMDs.
> > >
> > > Why do we have to wrap every C atomic builtin? What value is there in
> > > that?
> >
> > The wrapping is aimed to reduce code duplication, on average 3 lines cut
> > down to 1 line for a single core.
> > Overall I am thinking this bitops APIs are targeted for use by PMDs only,
> > applications can use C11 freely.
> > The initial thought for the new APIs came from the idea of consolidating the
> > scattered bit operations all over the PMDs. It is unwise to expanding to
> > applications or libraries, as different memory orderings are required and
> > complexity generate.
> >
> > If the use cases are limited to PMDs, a 'volatile' or a compiler barrier is
> > sufficient therefore the number of APIs can be saved by half.
> > http://inbox.dpdk.org/dev/VI1PR08MB53766C30B5CDA00FB9FCE9678F2E0
> > @VI1PR08MB5376.eurprd08.prod.outlook.com/
> >
> > Any thoughts and comments are welcome!
> I would prefer that the APIs/Macros just address PMD's requirements. These
> also should be kept private (through naming conventions?). Given that the
> current PMDs are not using C11, we can skip using C11 atomics in these APIs.
Not in favor, just use existing Gcc/clang/icc atomics instead of creating
unnecessary bloat wrappers.
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/virtio_user: do not close invalid file descriptor
On Mon, Jan 06, 2020 at 11:18:37AM -0800, Stephen Hemminger wrote:
> Valgrind complains that virtio_user is calling close(-1).
> Fix this by adding check in virtio that is similar to existing code.
>
> Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")
> Cc: jianfeng@intel.com
> Cc: sta...@dpdk.org
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/virtio/virtio_user/virtio_user_dev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Tiwei Bie
Re: [dpdk-dev] [PATCH] vhost: fix socket initial value
On Fri, Jan 03, 2020 at 01:36:21PM -0500, Xiao Wang wrote:
> By default, a vhost socket is created without attaching VDPA device,
> this patch fixes the initial value of vdpa_dev_id.
>
> Fixes: b4953225cea4 ("vhost: add APIs for datapath configuration")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Wang
> ---
> lib/librte_vhost/socket.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Tiwei Bie
Re: [dpdk-dev] [PATCH v3] net/i40e: fix TSO pkt exceeds allowed buf size issue
On 12/26, Xiaoyun Li wrote:
>Hardware limits that max buffer size per tx descriptor should be
>(16K-1)B. So when TSO enabled, the mbuf data size may exceed the
>limit and cause malicious behavior to the NIC. This patch fixes
>this issue by using more tx descs for this kind of large buffer.
>
>Fixes: 4861cde46116 ("i40e: new poll mode driver")
>Cc: sta...@dpdk.org
>
>Signed-off-by: Xiaoyun Li
>---
>v3:
> * Reused the existing macros to define I40E_MAX_DATA_PER_TXD
>v2:
> * Each pkt can have several segments so the needed tx descs should sum
> * all segments up.
>---
> drivers/net/i40e/i40e_rxtx.c | 45 +++-
> 1 file changed, 44 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
>index 17dc8c78f..bbdba39b3 100644
>--- a/drivers/net/i40e/i40e_rxtx.c
>+++ b/drivers/net/i40e/i40e_rxtx.c
>@@ -989,6 +989,24 @@ i40e_set_tso_ctx(struct rte_mbuf *mbuf, union
>i40e_tx_offload tx_offload)
> return ctx_desc;
> }
>
>+/* HW requires that Tx buffer size ranges from 1B up to (16K-1)B. */
>+#define I40E_MAX_DATA_PER_TXD \
>+ (I40E_TXD_QW1_TX_BUF_SZ_MASK >> I40E_TXD_QW1_TX_BUF_SZ_SHIFT)
>+/* Calculate the number of TX descriptors needed for each pkt */
>+static inline uint16_t
>+i40e_calc_pkt_desc(struct rte_mbuf *tx_pkt)
>+{
>+ struct rte_mbuf *txd = tx_pkt;
>+ uint16_t count = 0;
>+
>+ while (txd != NULL) {
>+ count += DIV_ROUND_UP(txd->data_len, I40E_MAX_DATA_PER_TXD);
>+ txd = txd->next;
>+ }
>+
>+ return count;
>+}
>+
> uint16_t
> i40e_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> {
>@@ -1046,8 +1064,15 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf
>**tx_pkts, uint16_t nb_pkts)
>* The number of descriptors that must be allocated for
>* a packet equals to the number of the segments of that
>* packet plus 1 context descriptor if needed.
>+ * Recalculate the needed tx descs when TSO enabled in case
>+ * the mbuf data size exceeds max data size that hw allows
>+ * per tx desc.
>*/
>- nb_used = (uint16_t)(tx_pkt->nb_segs + nb_ctx);
>+ if (ol_flags & PKT_TX_TCP_SEG)
>+ nb_used = (uint16_t)(i40e_calc_pkt_desc(tx_pkt) +
>+ nb_ctx);
>+ else
>+ nb_used = (uint16_t)(tx_pkt->nb_segs + nb_ctx);
> tx_last = (uint16_t)(tx_id + nb_used - 1);
>
> /* Circular ring */
>@@ -1160,6 +1185,24 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf
>**tx_pkts, uint16_t nb_pkts)
> slen = m_seg->data_len;
> buf_dma_addr = rte_mbuf_data_iova(m_seg);
>
>+ while ((ol_flags & PKT_TX_TCP_SEG) &&
>+ unlikely(slen > I40E_MAX_DATA_PER_TXD)) {
>+ txd->buffer_addr =
>+ rte_cpu_to_le_64(buf_dma_addr);
>+ txd->cmd_type_offset_bsz =
>+ i40e_build_ctob(td_cmd,
>+ td_offset, I40E_MAX_DATA_PER_TXD,
>+ td_tag);
>+
>+ buf_dma_addr += I40E_MAX_DATA_PER_TXD;
>+ slen -= I40E_MAX_DATA_PER_TXD;
>+
>+ txe->last_id = tx_last;
>+ tx_id = txe->next_id;
>+ txe = txn;
>+ txd = &txr[tx_id];
>+ txn = &sw_ring[txe->next_id];
>+ }
> PMD_TX_LOG(DEBUG, "mbuf: %p, TDD[%u]:\n"
> "buf_dma_addr: %#"PRIx64";\n"
> "td_cmd: %#x;\n"
>--
>2.17.1
>
Applied to dpdk-next-net-intel, Thanks.
Re: [dpdk-dev] [PATCH v2] net/vhost: fix return value of vhost creates not checked
On Tue, Dec 17, 2019 at 09:36:17AM +0800, Yunjian Wang wrote: > > - eth_dev_vhost_create(dev, iface_name, queues, dev->device.numa_node, > - flags, disable_flags); > + ret = eth_dev_vhost_create(dev, iface_name, queues, > +dev->device.numa_node, flags, disable_flags); > + if (ret == -1) > + VHOST_LOG(ERR, "Failed to create %s", name); A newline is needed at the end of the error message. Other than that, Reviewed-by: Tiwei Bie
Re: [dpdk-dev] [PATCH v3 6/6] raw/octeontx2_ep: add driver self test
Hi Mahipal,
> -Original Message-
> From: Mahipal Challa
> Sent: Monday, January 6, 2020 8:07 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com; Gavin Hu
> Subject: [dpdk-dev] [PATCH v3 6/6] raw/octeontx2_ep: add driver self test
>
> Add rawdev's selftest feature in SDP VF driver, which
> verifies the EP mode functionality test.
>
> Signed-off-by: Mahipal Challa
> ---
> doc/guides/rawdevs/octeontx2_ep.rst | 13 +++
> drivers/raw/octeontx2_ep/Makefile | 1 +
> drivers/raw/octeontx2_ep/meson.build | 1 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 2 +
> drivers/raw/octeontx2_ep/otx2_ep_test.c | 166
> ++
> 6 files changed, 184 insertions(+)
>
> diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> b/doc/guides/rawdevs/octeontx2_ep.rst
> index 39a7c29..bbcf530 100644
> --- a/doc/guides/rawdevs/octeontx2_ep.rst
> +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> @@ -74,3 +74,16 @@ Performing Data Transfer
> To perform data transfer using SDP VF EP rawdev devices use standard
> ``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()``
> APIs.
>
> +Self test
> +-
> +
> +On EAL initialization, SDP VF devices will be probed and populated into the
> +raw devices. The rawdev ID of the device can be obtained using
> +
> +* Invoke ``rte_rawdev_get_dev_id("SDPEP:x")`` from the test application
> + where x is the VF device's bus id specified in "bus:device.func"(BDF)
> + format. Use this index for further rawdev function calls.
> +
> +* The driver's selftest rawdev API can be used to verify the SDP EP mode
> + functional tests which can send/receive the raw data packets to/from the
> + EP device.
> diff --git a/drivers/raw/octeontx2_ep/Makefile
> b/drivers/raw/octeontx2_ep/Makefile
> index 02853fb..44fdf89 100644
> --- a/drivers/raw/octeontx2_ep/Makefile
> +++ b/drivers/raw/octeontx2_ep/Makefile
> @@ -37,6 +37,7 @@ LIBABIVER := 1
> #
> SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_rawdev.c
> SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_enqdeq.c
> +SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_test.c
> SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_vf.c
>
>
> diff --git a/drivers/raw/octeontx2_ep/meson.build
> b/drivers/raw/octeontx2_ep/meson.build
> index 99e6c6d..0e6338f 100644
> --- a/drivers/raw/octeontx2_ep/meson.build
> +++ b/drivers/raw/octeontx2_ep/meson.build
> @@ -5,4 +5,5 @@
> deps += ['bus_pci', 'common_octeontx2', 'rawdev']
> sources = files('otx2_ep_rawdev.c',
> 'otx2_ep_enqdeq.c',
> + 'otx2_ep_test.c',
> 'otx2_ep_vf.c')
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> index 7158b97..0778603 100644
> --- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> @@ -253,6 +253,7 @@
> .dev_close = sdp_rawdev_close,
> .enqueue_bufs = sdp_rawdev_enqueue,
> .dequeue_bufs = sdp_rawdev_dequeue,
> + .dev_selftest = sdp_rawdev_selftest,
> };
>
> static int
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> index a77cbab..dab2fb7 100644
> --- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> @@ -494,4 +494,6 @@ int sdp_rawdev_enqueue(struct rte_rawdev *dev,
> struct rte_rawdev_buf **buffers,
> int sdp_rawdev_dequeue(struct rte_rawdev *dev, struct rte_rawdev_buf
> **buffers,
> unsigned int count, rte_rawdev_obj_t context);
>
> +int sdp_rawdev_selftest(uint16_t dev_id);
> +
> #endif /* _OTX2_EP_RAWDEV_H_ */
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_test.c
> b/drivers/raw/octeontx2_ep/otx2_ep_test.c
> new file mode 100644
> index 000..fc913a6
> --- /dev/null
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_test.c
> @@ -0,0 +1,166 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "otx2_common.h"
> +#include "otx2_ep_rawdev.h"
> +
> +#define SDP_IOQ_NUM_BUFS (4 * 1024)
> +#define SDP_IOQ_BUF_SIZE (2 * 1024)
> +
> +#define SDP_TEST_PKT_FSZ (0)
> +#define SDP_TEST_PKT_SIZE (1024)
> +
> +static int
> +sdp_validate_data(struct sdp_droq_pkt *oq_pkt, uint8_t *iq_pkt,
> + uint32_t pkt_len)
> +{
> + if (!oq_pkt)
> + return -EINVAL;
> +
> + if (pkt_len != oq_pkt->len) {
> + otx2_err("Invalid packet length");
> + return -EINVAL;
> + }
> +
> + if (memcmp(oq_pkt->data, iq_pkt, pkt_len) != 0) {
> + otx2_err("Data validation failed");
> + return -EINVAL;
> + }
Re: [dpdk-dev] [PATCH v2] net/vhost: fix return value of vhost creates not checked
Thanks, I will fix it in v3. Yunjian > -Original Message- > From: Tiwei Bie [mailto:tiwei@intel.com] > Sent: Tuesday, January 7, 2020 10:32 AM > To: wangyunjian > Cc: dev@dpdk.org; maxime.coque...@redhat.com; zhihong.w...@intel.com; > xudingke ; sta...@dpdk.org > Subject: Re: [PATCH v2] net/vhost: fix return value of vhost creates not > checked > > On Tue, Dec 17, 2019 at 09:36:17AM +0800, Yunjian Wang wrote: > > > > - eth_dev_vhost_create(dev, iface_name, queues, dev->device.numa_node, > > - flags, disable_flags); > > + ret = eth_dev_vhost_create(dev, iface_name, queues, > > + dev->device.numa_node, flags, disable_flags); > > + if (ret == -1) > > + VHOST_LOG(ERR, "Failed to create %s", name); > > A newline is needed at the end of the error message. > Other than that, > > Reviewed-by: Tiwei Bie
[dpdk-dev] [PATCH v3] net/vhost: fix return value of vhost creates not checked
The function eth_dev_vhost_create() could return errors,
the return value need to be checked.
Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
v3:
* Add newline at the end of the error message
v2:
* Change function eth_dev_vhost_create return 0 on success
---
drivers/net/vhost/rte_eth_vhost.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index 46f01a7..a635889 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1302,7 +1302,7 @@ struct vhost_xstats_name_off {
}
rte_eth_dev_probing_finish(eth_dev);
- return data->port_id;
+ return 0;
error:
if (internal) {
@@ -1455,8 +1455,10 @@ struct vhost_xstats_name_off {
if (dev->device.numa_node == SOCKET_ID_ANY)
dev->device.numa_node = rte_socket_id();
- eth_dev_vhost_create(dev, iface_name, queues, dev->device.numa_node,
- flags, disable_flags);
+ ret = eth_dev_vhost_create(dev, iface_name, queues,
+ dev->device.numa_node, flags, disable_flags);
+ if (ret == -1)
+ VHOST_LOG(ERR, "Failed to create %s\n", name);
out_free:
rte_kvargs_free(kvlist);
--
1.8.3.1
Re: [dpdk-dev] [PATCH v3 6/6] raw/octeontx2_ep: add driver self test
Hi Gavin,
Please see response inline
> -Original Message-
> From: Gavin Hu
> Sent: Tuesday, January 7, 2020 8:13 AM
> To: Mahipal Challa ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Subrahmanyam Nilla
> ; Venkateshwarlu Nalla ; nd
>
> Subject: [EXT] RE: [dpdk-dev] [PATCH v3 6/6] raw/octeontx2_ep: add driver
> self test
>
> External Email
>
> --
> Hi Mahipal,
>
> > -Original Message-
> > From: Mahipal Challa
> > Sent: Monday, January 6, 2020 8:07 PM
> > To: dev@dpdk.org
> > Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> > venk...@marvell.com; Gavin Hu
> > Subject: [dpdk-dev] [PATCH v3 6/6] raw/octeontx2_ep: add driver self
> > test
> >
> > Add rawdev's selftest feature in SDP VF driver, which verifies the EP
> > mode functionality test.
> >
> > Signed-off-by: Mahipal Challa
> > ---
> > doc/guides/rawdevs/octeontx2_ep.rst | 13 +++
> > drivers/raw/octeontx2_ep/Makefile | 1 +
> > drivers/raw/octeontx2_ep/meson.build | 1 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 2 +
> > drivers/raw/octeontx2_ep/otx2_ep_test.c | 166
> > ++
> > 6 files changed, 184 insertions(+)
> >
> > diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> > b/doc/guides/rawdevs/octeontx2_ep.rst
> > index 39a7c29..bbcf530 100644
> > --- a/doc/guides/rawdevs/octeontx2_ep.rst
> > +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> > @@ -74,3 +74,16 @@ Performing Data Transfer To perform data transfer
> > using SDP VF EP rawdev devices use standard
> > ``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()``
> > APIs.
> >
> > +Self test
> > +-
> > +
> > +On EAL initialization, SDP VF devices will be probed and populated
> > +into the raw devices. The rawdev ID of the device can be obtained
> > +using
> > +
> > +* Invoke ``rte_rawdev_get_dev_id("SDPEP:x")`` from the test
> > +application
> > + where x is the VF device's bus id specified in
> > +"bus:device.func"(BDF)
> > + format. Use this index for further rawdev function calls.
> > +
> > +* The driver's selftest rawdev API can be used to verify the SDP EP
> > +mode
> > + functional tests which can send/receive the raw data packets
> > +to/from the
> > + EP device.
> > diff --git a/drivers/raw/octeontx2_ep/Makefile
> > b/drivers/raw/octeontx2_ep/Makefile
> > index 02853fb..44fdf89 100644
> > --- a/drivers/raw/octeontx2_ep/Makefile
> > +++ b/drivers/raw/octeontx2_ep/Makefile
> > @@ -37,6 +37,7 @@ LIBABIVER := 1
> > #
> > SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_rawdev.c
> > SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_enqdeq.c
> > +SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> > otx2_ep_test.c
> > SRCS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV) +=
> otx2_ep_vf.c
> >
> >
> > diff --git a/drivers/raw/octeontx2_ep/meson.build
> > b/drivers/raw/octeontx2_ep/meson.build
> > index 99e6c6d..0e6338f 100644
> > --- a/drivers/raw/octeontx2_ep/meson.build
> > +++ b/drivers/raw/octeontx2_ep/meson.build
> > @@ -5,4 +5,5 @@
> > deps += ['bus_pci', 'common_octeontx2', 'rawdev'] sources =
> > files('otx2_ep_rawdev.c',
> > 'otx2_ep_enqdeq.c',
> > + 'otx2_ep_test.c',
> > 'otx2_ep_vf.c')
> > diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> > b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> > index 7158b97..0778603 100644
> > --- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> > +++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.c
> > @@ -253,6 +253,7 @@
> > .dev_close = sdp_rawdev_close,
> > .enqueue_bufs = sdp_rawdev_enqueue,
> > .dequeue_bufs = sdp_rawdev_dequeue,
> > + .dev_selftest = sdp_rawdev_selftest,
> > };
> >
> > static int
> > diff --git a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> > b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> > index a77cbab..dab2fb7 100644
> > --- a/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> > +++ b/drivers/raw/octeontx2_ep/otx2_ep_rawdev.h
> > @@ -494,4 +494,6 @@ int sdp_rawdev_enqueue(struct rte_rawdev *dev,
> > struct rte_rawdev_buf **buffers, int sdp_rawdev_dequeue(struct
> > rte_rawdev *dev, struct rte_rawdev_buf **buffers,
> >unsigned int count, rte_rawdev_obj_t context);
> >
> > +int sdp_rawdev_selftest(uint16_t dev_id);
> > +
> > #endif /* _OTX2_EP_RAWDEV_H_ */
> > diff --git a/drivers/raw/octeontx2_ep/otx2_ep_test.c
> > b/drivers/raw/octeontx2_ep/otx2_ep_test.c
> > new file mode 100644
> > index 000..fc913a6
> > --- /dev/null
> > +++ b/drivers/raw/octeontx2_ep/otx2_ep_test.c
> > @@ -0,0 +1,166 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2019 Marvell International Ltd.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
Re: [dpdk-dev] [PATCH 12/14] examples/ipsec-secgw: add driver outbound worker
Hi Konstantin,
Please see inline.
Thanks,
Anoob
> -Original Message-
> From: dev On Behalf Of Ananyev, Konstantin
> Sent: Monday, January 6, 2020 11:16 PM
> To: Anoob Joseph ; Akhil Goyal ;
> Nicolau, Radu ; Thomas Monjalon
>
> Cc: Ankur Dwivedi ; Jerin Jacob Kollanukkaran
> ; Narayana Prasad Raju Athreya
> ; Archana Muniganti ;
> Tejasree Kondoj ; Vamsi Krishna Attunuru
> ; Lukas Bartosik ;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 12/14] examples/ipsec-secgw: add driver
> outbound worker
>
> > > > This patch adds the driver outbound worker thread for ipsec-secgw.
> > > > In this mode the security session is a fixed one and sa update is
> > > > not done.
> > > >
> > > > Signed-off-by: Ankur Dwivedi
> > > > Signed-off-by: Anoob Joseph
> > > > Signed-off-by: Lukasz Bartosik
> > > > ---
> > > > examples/ipsec-secgw/ipsec-secgw.c | 12 +
> > > > examples/ipsec-secgw/ipsec.c| 9
> > > > examples/ipsec-secgw/ipsec_worker.c | 90
> > > > -
> > > > 3 files changed, 110 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > > > b/examples/ipsec-secgw/ipsec-secgw.c
> > > > index 2e7d4d8..76719f2 100644
> > > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > > @@ -2011,6 +2011,18 @@ cryptodevs_init(void)
> > > > i++;
> > > > }
> > > >
> > > > + /*
> > > > +* Set the queue pair to at least the number of ethernet
> > > > +* devices for inline outbound.
> > > > +*/
> > > > + qp = RTE_MAX(rte_eth_dev_count_avail(), qp);
> > >
> > >
> > > Not sure, what for?
> > > Why we can't process packets from several eth devs on the same
> > > crypto-dev queue?
> >
> > [Anoob] This is because of a limitation in our hardware. In our
> > hardware, it's the crypto queue pair which would be submitting to the
> > ethernet queue for Tx. But in DPDK spec, the security processing is
> > done by the ethernet PMD Tx routine alone. We manage to do this by sharing
> the crypto queue internally. The crypto queues initialized during
> crypto_configure() gets mapped to various ethernet ports. Because of this, we
> need to have atleast as many crypto queues as the number of eth ports.
>
> Ok, but that breaks current behavior.
> Right now in poll-mode it is possible to map traffic from N eth-devs to M
> crypto-
> devs (N>= M, by using M lcores).
> Would prefer to keep this functionality in place.
[Anoob] Understood. I don't think that functionality is broken. If the number
of qps available is lower than the number of eth devs, then only the ones
available would be enabled. Inline protocol session for the other eth devs
would fail for us.
Currently, the app assumes that for one core, it needs only one qp (and for M
core, M qp). Is there any harm in enabling all qps available? If such a change
can be done, that would also work for us.
>
> >
> > The above change is required because here we limit the number of
> > crypto qps based on the number of cores etc. So when tried on single core,
> > the
> qps get limited to 1, which causes session_create() to fail for all ports
> other than
> the first one.
> >
> > >
> > > > +
> > > > + /*
> > > > +* The requested number of queues should never exceed
> > > > +* the max available
> > > > +*/
> > > > + qp = RTE_MIN(qp, max_nb_qps);
> > > > +
> > > > if (qp == 0)
> > > > continue;
> > > >
> > > > diff --git a/examples/ipsec-secgw/ipsec.c
> > > > b/examples/ipsec-secgw/ipsec.c index e529f68..9ff8a63 100644
> > > > --- a/examples/ipsec-secgw/ipsec.c
> > > > +++ b/examples/ipsec-secgw/ipsec.c
> > > > @@ -141,6 +141,10 @@ create_lookaside_session(struct ipsec_ctx
> > > *ipsec_ctx, struct ipsec_sa *sa,
> > > > return 0;
> > > > }
> > > >
> > > > +uint16_t sa_no;
> > > > +#define MAX_FIXED_SESSIONS 10
> > > > +struct rte_security_session
> > > > +*sec_session_fixed[MAX_FIXED_SESSIONS];
> > > > +
> > > > int
> > > > create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> > > > struct rte_ipsec_session *ips)
> > > > @@ -401,6 +405,11 @@ create_inline_session(struct socket_ctx
> > > > *skt_ctx, struct ipsec_sa *sa,
> > > >
> > > > ips->security.ol_flags = sec_cap->ol_flags;
> > > > ips->security.ctx = sec_ctx;
> > > > + if (sa_no < MAX_FIXED_SESSIONS) {
> > > > + sec_session_fixed[sa_no] =
> > > > + ipsec_get_primary_session(sa)-
> > > >security.ses;
> > > > + sa_no++;
> > > > + }
> > > > }
> > >
> > > Totally lost what is the purpose of these changes...
> > > Why first 10 inline-proto are special and need to be saved inside
> >
Re: [dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs
> >
> > > > >
> > > > > >
> > > > > > On Sat, 21 Dec 2019 16:07:23 + Honnappa Nagarahalli
> > > > > > wrote:
> > > > > >
> > > > > > > Converting these into macros will help remove the size based
> > > > > > > duplication
> > > > of
> > > > > > APIs. I came up with the following macro:
> > > > > > >
> > > > > > > #define RTE_GET_BIT(nr, var, ret, memorder) \ ({ \
> > > > > > > if (sizeof(var) == sizeof(uint32_t)) { \
> > > > > > > uint32_t mask1 = 1U << (nr)%32; \
> > > > > > > ret = __atomic_load_n(&var, (memorder)) & mask1;\
> > > > > > > } \
> > > > > > > else {\
> > > > > > > uint64_t mask2 = 1UL << (nr)%64;\
> > > > > > > ret = __atomic_load_n(&var, (memorder)) & mask2;\
> > > > > > > } \
> > > > > > > })
> > > > > >
> > > > > > Macros are more error prone. Especially because this is in
> > > > > > exposed header
> > > > file
> > > > > That's another question I have. Why do we need to have these
> > > > > APIs in a
> > > > public header file? These will add to the ABI burden as well.
> > > > These APIs should be in a common-but-not-public header file. I am
> > > > also not sure how helpful these APIs are for applications as these
> > > > APIs seem to have considered requirements only from the PMDs.
> > > >
> > > > Why do we have to wrap every C atomic builtin? What value is there in
> that?
> > >
> > > The wrapping is aimed to reduce code duplication, on average 3 lines
> > > cut down to 1 line for a single core.
> > > Overall I am thinking this bitops APIs are targeted for use by PMDs
> > > only, applications can use C11 freely.
> > > The initial thought for the new APIs came from the idea of
> > > consolidating the scattered bit operations all over the PMDs. It is
> > > unwise to expanding to applications or libraries, as different
> > > memory orderings are required and complexity generate.
> > >
> > > If the use cases are limited to PMDs, a 'volatile' or a compiler
> > > barrier is sufficient therefore the number of APIs can be saved by half.
> > >
> http://inbox.dpdk.org/dev/VI1PR08MB53766C30B5CDA00FB9FCE9678F2E0
> > > @VI1PR08MB5376.eurprd08.prod.outlook.com/
> > >
> > > Any thoughts and comments are welcome!
> > I would prefer that the APIs/Macros just address PMD's requirements.
> These also should be kept private (through naming conventions?). Given that
> the current PMDs are not using C11, we can skip using C11 atomics in these
> APIs.
>
> Not in favor, just use existing Gcc/clang/icc atomics instead of creating
> unnecessary bloat wrappers.
I thought, you blessed this patch [1].
[1] http://mails.dpdk.org/archives/dev/2019-October/147297.html
Re: [dpdk-dev] [PATCH v3] net/vhost: fix return value of vhost creates not checked
On Tue, Jan 07, 2020 at 11:25:48AM +0800, Yunjian Wang wrote:
> The function eth_dev_vhost_create() could return errors,
> the return value need to be checked.
>
> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yunjian Wang
> ---
> v3:
> * Add newline at the end of the error message
> v2:
> * Change function eth_dev_vhost_create return 0 on success
> ---
> drivers/net/vhost/rte_eth_vhost.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Reviewed-by: Tiwei Bie
Re: [dpdk-dev] [PATCH v7 03/17] test/ring: add functional tests for rte_ring_xxx_elem APIs
> Hi Honnappa,
Thanks Konstantin for your feedback.
>
> > Add basic infrastructure to test rte_ring_xxx_elem APIs. Add test
> > cases for testing burst and bulk tests.
> >
> > Signed-off-by: Honnappa Nagarahalli
> > Reviewed-by: Gavin Hu
> > ---
> > app/test/test_ring.c | 466
> > ---
> > app/test/test_ring.h | 203 +++
> > 2 files changed, 419 insertions(+), 250 deletions(-) create mode
> > 100644 app/test/test_ring.h
> >
> > diff --git a/app/test/test_ring.c b/app/test/test_ring.c index
> > aaf1e70ad..e7a8b468b 100644
> > --- a/app/test/test_ring.c
> > +++ b/app/test/test_ring.c
> > @@ -23,11 +23,13 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> >
> > #include "test.h"
> > +#include "test_ring.h"
> >
> > /*
> > * Ring
> > @@ -67,6 +69,50 @@ static rte_atomic32_t synchro;
> >
> > #defineTEST_RING_FULL_EMTPY_ITER 8
> >
> > +static int esize[] = {-1, 4, 8, 16};
> > +
> > +static void
> > +test_ring_mem_init(void *obj, unsigned int count, int esize) {
> > + unsigned int i;
> > +
> > + /* Legacy queue APIs? */
> > + if (esize == -1)
> > + for (i = 0; i < count; i++)
> > + ((void **)obj)[i] = (void *)(unsigned long)i;
> > + else
> > + for (i = 0; i < (count * esize / sizeof(uint32_t)); i++)
> > + ((uint32_t *)obj)[i] = i;
> > +}
> > +
> > +static void
> > +test_ring_print_test_string(const char *istr, unsigned int api_type,
> > +int esize) {
> > + printf("\n%s: ", istr);
> > +
> > + if (esize == -1)
> > + printf("legacy APIs: ");
> > + else
> > + printf("elem APIs: element size %dB ", esize);
> > +
> > + if (api_type == TEST_RING_IGNORE_API_TYPE)
> > + return;
> > +
> > + if ((api_type & TEST_RING_N) == TEST_RING_N)
> > + printf(": default enqueue/dequeue: ");
> > + else if ((api_type & TEST_RING_S) == TEST_RING_S)
> > + printf(": SP/SC: ");
> > + else if ((api_type & TEST_RING_M) == TEST_RING_M)
> > + printf(": MP/MC: ");
> > +
> > + if ((api_type & TEST_RING_SL) == TEST_RING_SL)
> > + printf("single\n");
> > + else if ((api_type & TEST_RING_BL) == TEST_RING_BL)
> > + printf("bulk\n");
> > + else if ((api_type & TEST_RING_BR) == TEST_RING_BR)
> > + printf("burst\n");
> > +}
> > +
> > /*
> > * helper routine for test_ring_basic
> > */
> > @@ -314,286 +360,203 @@ test_ring_basic(struct rte_ring *r)
> > return -1;
> > }
> >
> > +/*
> > + * Burst and bulk operations with sp/sc, mp/mc and default (during
> > +creation) */
> > static int
> > -test_ring_burst_basic(struct rte_ring *r)
> > +test_ring_burst_bulk_tests(unsigned int api_type)
> > {
> > + struct rte_ring *r;
> > void **src = NULL, **cur_src = NULL, **dst = NULL, **cur_dst = NULL;
> > int ret;
> > - unsigned i;
> > + unsigned int i, j;
> > + unsigned int num_elems;
> >
> > - /* alloc dummy object pointers */
> > - src = malloc(RING_SIZE*2*sizeof(void *));
> > - if (src == NULL)
> > - goto fail;
> > -
> > - for (i = 0; i < RING_SIZE*2 ; i++) {
> > - src[i] = (void *)(unsigned long)i;
> > - }
> > - cur_src = src;
> > + for (i = 0; i < RTE_DIM(esize); i++) {
> > + test_ring_print_test_string("Test standard ring", api_type,
> > + esize[i]);
> >
> > - /* alloc some room for copied objects */
> > - dst = malloc(RING_SIZE*2*sizeof(void *));
> > - if (dst == NULL)
> > - goto fail;
> > + /* Create the ring */
> > + TEST_RING_CREATE("test_ring_burst_bulk_tests", esize[i],
> > + RING_SIZE, SOCKET_ID_ANY, 0, r);
> >
> > - memset(dst, 0, RING_SIZE*2*sizeof(void *));
> > - cur_dst = dst;
> > -
> > - printf("Test SP & SC basic functions \n");
> > - printf("enqueue 1 obj\n");
> > - ret = rte_ring_sp_enqueue_burst(r, cur_src, 1, NULL);
> > - cur_src += 1;
> > - if (ret != 1)
> > - goto fail;
> > -
> > - printf("enqueue 2 objs\n");
> > - ret = rte_ring_sp_enqueue_burst(r, cur_src, 2, NULL);
> > - cur_src += 2;
> > - if (ret != 2)
> > - goto fail;
> > -
> > - printf("enqueue MAX_BULK objs\n");
> > - ret = rte_ring_sp_enqueue_burst(r, cur_src, MAX_BULK, NULL);
> > - cur_src += MAX_BULK;
> > - if (ret != MAX_BULK)
> > - goto fail;
> > -
> > - printf("dequeue 1 obj\n");
> > - ret = rte_ring_sc_dequeue_burst(r, cur_dst, 1, NULL);
> > - cur_dst += 1;
> > - if (ret != 1)
> > - goto fail;
> > -
> > - printf("dequeue 2 objs\n");
> > - ret = rte_ring_sc_dequeue_burst(r, cur_dst, 2, NULL);
> > - cur_dst += 2;
> > - if (ret != 2)
> > - goto fail;
> > + /* alloc dummy object pointers */
> > + src = test_ring_calloc(RING_SIZE * 2, esize[i]);
> > + if (src == NULL)
> > +
Re: [dpdk-dev] [PATCH v7 02/17] lib/ring: apis to support configurable element size
> > diff --git a/lib/librte_ring/rte_ring_elem.h
> > b/lib/librte_ring/rte_ring_elem.h new file mode 100644 index
> > 0..fc7fe127c
> > --- /dev/null
> > +++ b/lib/librte_ring/rte_ring_elem.h
> > @@ -0,0 +1,1002 @@
> > +
> > +static __rte_always_inline void
> > +enqueue_elems_128(struct rte_ring *r, uint32_t prod_head,
> > + const void *obj_table, uint32_t n)
> > +{
> > + unsigned int i;
> > + const uint32_t size = r->size;
> > + uint32_t idx = prod_head & r->mask;
> > + __uint128_t *ring = (__uint128_t *)&r[1];
> > + const __uint128_t *obj = (const __uint128_t *)obj_table;
> > + if (likely(idx + n < size)) {
> > + for (i = 0; i < (n & ~0x1); i += 2, idx += 2) {
> > + ring[idx] = obj[i];
> > + ring[idx + 1] = obj[i + 1];
>
>
> AFAIK, that implies 16B aligned obj_table...
> Would it always be the case?
I am not sure from the compiler perspective.
At least on Arm architecture, unaligned access (address that is accessed is not
aligned to the size of the data element being accessed) will result in faults
or require additional cycles. So, aligning on 16B should be fine.
>
> > + }
> > + switch (n & 0x1) {
> > + case 1:
> > + ring[idx++] = obj[i++];
> > + }
> > + } else {
> > + for (i = 0; idx < size; i++, idx++)
> > + ring[idx] = obj[i];
> > + /* Start at the beginning */
> > + for (idx = 0; i < n; i++, idx++)
> > + ring[idx] = obj[i];
> > + }
> > +}
> > +
> > +/* the actual enqueue of elements on the ring.
> > + * Placed here since identical code needed in both
> > + * single and multi producer enqueue functions.
> > + */
> > +static __rte_always_inline void
> > +enqueue_elems(struct rte_ring *r, uint32_t prod_head, const void
> *obj_table,
> > + uint32_t esize, uint32_t num)
> > +{
> > + uint32_t idx, nr_idx, nr_num;
> > +
> > + /* 8B and 16B copies implemented individually to retain
> > +* the current performance.
> > +*/
> > + if (esize == 8)
> > + enqueue_elems_64(r, prod_head, obj_table, num);
> > + else if (esize == 16)
> > + enqueue_elems_128(r, prod_head, obj_table, num);
> > + else {
> > + /* Normalize to uint32_t */
> > + uint32_t scale = esize / sizeof(uint32_t);
> > + nr_num = num * scale;
> > + idx = prod_head & r->mask;
> > + nr_idx = idx * scale;
> > + enqueue_elems_32(r, nr_idx, obj_table, nr_num);
> > + }
> > +}
> > +
Re: [dpdk-dev] [PATCH v7 11/17] test/ring: modify burst enq/deq perf test cases
> >
> > Add test cases to test legacy and rte_ring_xxx_elem APIs for burst
> > enqueue/dequeue test cases.
> >
> > Signed-off-by: Honnappa Nagarahalli
> > Reviewed-by: Gavin Hu
> > ---
> > app/test/test_ring_perf.c | 78
> > ---
> > 1 file changed, 40 insertions(+), 38 deletions(-)
> >
> > diff --git a/app/test/test_ring_perf.c b/app/test/test_ring_perf.c
> > index 5829718c1..508c688dc 100644
> > --- a/app/test/test_ring_perf.c
> > +++ b/app/test/test_ring_perf.c
> > @@ -397,47 +397,40 @@ test_single_enqueue_dequeue(struct rte_ring *r,
> > const int esize, }
> >
> > /*
> > - * Test that does both enqueue and dequeue on a core using the
> > burst() API calls
> > - * instead of the bulk() calls used in other tests. Results should be
> > the same
> > - * as for the bulk function called on a single lcore.
> > + * Test that does both enqueue and dequeue on a core using the
> > + burst/bulk API
> > + * calls Results should be the same as for the bulk function called
> > + on a
> > + * single lcore.
> > */
> > -static void
> > -test_burst_enqueue_dequeue(struct rte_ring *r)
> > +static int
> > +test_burst_bulk_enqueue_dequeue(struct rte_ring *r, const int esize,
> > + const unsigned int api_type)
> > {
> > - const unsigned iter_shift = 23;
> > - const unsigned iterations = 1< > - unsigned sz, i = 0;
> > - void *burst[MAX_BURST] = {0};
> > + int ret;
> > + const unsigned int iter_shift = 23;
> > + const unsigned int iterations = 1 << iter_shift;
> > + unsigned int sz, i = 0;
> > + void **burst = NULL;
> >
> > - for (sz = 0; sz < sizeof(bulk_sizes)/sizeof(bulk_sizes[0]); sz++) {
> > - const uint64_t sc_start = rte_rdtsc();
> > - for (i = 0; i < iterations; i++) {
> > - rte_ring_sp_enqueue_burst(r, burst,
> > - bulk_sizes[sz], NULL);
> > - rte_ring_sc_dequeue_burst(r, burst,
> > - bulk_sizes[sz], NULL);
> > - }
> > - const uint64_t sc_end = rte_rdtsc();
> > + (void)ret;
> > + burst = test_ring_calloc(MAX_BURST, esize);
> > + if (burst == NULL)
> > + return -1;
> >
> > - const uint64_t mc_start = rte_rdtsc();
> > + for (sz = 0; sz < RTE_DIM(bulk_sizes); sz++) {
> > + const uint64_t start = rte_rdtsc();
> > for (i = 0; i < iterations; i++) {
> > - rte_ring_mp_enqueue_burst(r, burst,
> > - bulk_sizes[sz], NULL);
> > - rte_ring_mc_dequeue_burst(r, burst,
> > - bulk_sizes[sz], NULL);
> > + TEST_RING_ENQUEUE(r, burst, esize, bulk_sizes[sz],
> > + ret, api_type);
> > + TEST_RING_DEQUEUE(r, burst, esize, bulk_sizes[sz],
> > + ret, api_type);
> > }
> > - const uint64_t mc_end = rte_rdtsc();
> > -
> > - double mc_avg = ((double)(mc_end-mc_start) / iterations) /
> > - bulk_sizes[sz];
> > - double sc_avg = ((double)(sc_end-sc_start) / iterations) /
> > - bulk_sizes[sz];
> > + const uint64_t end = rte_rdtsc();
> >
> > - printf("SP/SC burst enq/dequeue (size: %u): %.2F\n",
> > - bulk_sizes[sz], sc_avg);
> > - printf("MP/MC burst enq/dequeue (size: %u): %.2F\n",
> > - bulk_sizes[sz], mc_avg);
> > + test_ring_print_test_string(api_type, esize, bulk_sizes[sz],
> > + ((double)(end - start)) / iterations);
> > }
> > +
>
> missing rte_free(burst);
> ?
Yes, will fix.
>
> > + return 0;
> > }
> >
Re: [dpdk-dev] [PATCH v7 15/17] test/ring: adjust run-on-all-cores perf test cases
>
> >
> > Adjust run-on-all-cores test case to use legacy APIs.
> >
> > Signed-off-by: Honnappa Nagarahalli
> > Reviewed-by: Gavin Hu
> > ---
> > app/test/test_ring_perf.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/app/test/test_ring_perf.c b/app/test/test_ring_perf.c
> > index b893b5779..fb95e4f2c 100644
> > --- a/app/test/test_ring_perf.c
> > +++ b/app/test/test_ring_perf.c
> > @@ -520,6 +520,9 @@ test_ring_perf(void)
> > dequeue_bulk) < 0)
> > return -1;
> > }
> > + printf("\n### Testing using all slave nodes ###\n");
> > + if (run_on_all_cores(r) < 0)
> > + return -1;
> > rte_ring_free(r);
> >
> > TEST_RING_CREATE(RING_NAME, 16, RING_SIZE, rte_socket_id(), 0,
> r);
> > @@ -567,9 +570,6 @@ test_ring_perf(void)
> > return -1;
> > }
> >
> > - printf("\n### Testing using all slave nodes ###\n");
> > - run_on_all_cores(r);
> > -
>
> No run_on_all_cores() for 16B elems case?
Ok, I can add.
>
> > rte_ring_free(r);
> >
> > return 0;
> >
Re: [dpdk-dev] [PATCH v3 5/6] raw/octeontx2_ep: add dequeue operation
Hi Mahipal, Jerin,
> -Original Message-
> From: Mahipal Challa
> Sent: Monday, January 6, 2020 8:07 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com; Gavin Hu
> Subject: [dpdk-dev] [PATCH v3 5/6] raw/octeontx2_ep: add dequeue
> operation
>
> Add rawdev dequeue operation for SDP VF devices.
>
> Signed-off-by: Mahipal Challa
> ---
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 197
> ++
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 2 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 18 ++-
> 4 files changed, 217 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> index 6910f08..dd270b5 100644
> --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> @@ -260,6 +260,7 @@
> rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
> if (buf == NULL) {
> otx2_err("OQ buffer alloc failed");
> + droq->stats.rx_alloc_failure++;
> /* sdp_droq_destroy_ring_buffers(droq);*/
> return -ENOMEM;
> }
> @@ -645,3 +646,199 @@
> return SDP_IQ_SEND_FAILED;
> }
>
> +static uint32_t
> +sdp_droq_refill(struct sdp_device *sdpvf, struct sdp_droq *droq)
> +{
> + struct sdp_droq_desc *desc_ring;
> + uint32_t desc_refilled = 0;
> + void *buf = NULL;
> +
> + desc_ring = droq->desc_ring;
> +
> + while (droq->refill_count && (desc_refilled < droq->nb_desc)) {
> + /* If a valid buffer exists (happens if there is no dispatch),
> + * reuse the buffer, else allocate.
> + */
> + if (droq->recv_buf_list[droq->refill_idx].buffer != NULL)
> + break;
> +
> + rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
> + /* If a buffer could not be allocated, no point in
> + * continuing
> + */
> + if (buf == NULL) {
> + droq->stats.rx_alloc_failure++;
> + break;
> + }
> +
> + droq->recv_buf_list[droq->refill_idx].buffer = buf;
> + desc_ring[droq->refill_idx].buffer_ptr =
> rte_mem_virt2iova(buf);
> +
> + /* Reset any previous values in the length field. */
> + droq->info_list[droq->refill_idx].length = 0;
> +
> + droq->refill_idx = sdp_incr_index(droq->refill_idx, 1,
> + droq->nb_desc);
> +
> + desc_refilled++;
> + droq->refill_count--;
> +
> + }
> +
> + return desc_refilled;
> +}
> +
> +static int
> +sdp_droq_read_packet(struct sdp_device *sdpvf __rte_unused,
> + struct sdp_droq *droq,
> + struct sdp_droq_pkt *droq_pkt)
> +{
> + struct sdp_droq_info *info;
> + uint32_t total_len = 0;
> + uint32_t pkt_len = 0;
> +
> + info = &droq->info_list[droq->read_idx];
> + sdp_swap_8B_data((uint64_t *)&info->length, 1);
> + if (!info->length) {
> + otx2_err("OQ info_list->length[%ld]", (long)info->length);
> + goto oq_read_fail;
> + }
> +
> + /* Deduce the actual data size */
> + info->length -= SDP_RH_SIZE;
> + total_len += (uint32_t)info->length;
> +
> + otx2_sdp_dbg("OQ: pkt_len[%ld], buffer_size %d",
> + (long)info->length, droq->buffer_size);
> + if (info->length > droq->buffer_size) {
> + otx2_err("This mode is not supported: pkt_len >
> buffer_size");
> + goto oq_read_fail;
> + }
> +
> + if (info->length <= droq->buffer_size) {
> + pkt_len = (uint32_t)info->length;
> + droq_pkt->data = droq->recv_buf_list[droq-
> >read_idx].buffer;
> + droq_pkt->len = pkt_len;
> +
> + droq->recv_buf_list[droq->read_idx].buffer = NULL;
> + droq->read_idx = sdp_incr_index(droq->read_idx, 1,/*
> count */
> + droq->nb_desc /* max rd
> idx */);
> + droq->refill_count++;
> +
> + }
> +
> + info->length = 0;
> +
> + return SDP_OQ_RECV_SUCCESS;
> +
> +oq_read_fail:
> + return SDP_OQ_RECV_FAILED;
> +}
> +
> +static inline uint32_t
> +sdp_check_droq_pkts(struct sdp_droq *droq, uint32_t burst_size)
> +{
> + uint32_t min_pkts = 0;
> + uint32_t new_pkts;
> + uint32_t pkt_count;
> +
> + /* Latest available OQ packets */
> + pkt_count = rte_read32(droq->pkts_sent_reg);
> +
> + /* Newly arrived packets */
> + new_pkts = pkt_count - droq->last_pkt_count;
> + otx2_sdp_dbg("Recvd [%d] new OQ pkts", new_pkts);
> +
> + min_pkts = (new_pkts > burst_size) ? burst_size : new_pkts;
> + if (min_pkts) {
> + rte_atomic64_add(&droq->pkts_pending, min_pk
Re: [dpdk-dev] [PATCH v7 10/17] test/ring: modify single element enq/deq perf test cases
>
> >
> > Add test cases to test rte_ring_xxx_elem APIs for single element
> > enqueue/dequeue test cases.
> >
> > Signed-off-by: Honnappa Nagarahalli
> > Reviewed-by: Gavin Hu
> > ---
> > app/test/test_ring_perf.c | 100
> > ++
> > 1 file changed, 80 insertions(+), 20 deletions(-)
> >
> > diff --git a/app/test/test_ring_perf.c b/app/test/test_ring_perf.c
> > index 6c2aca483..5829718c1 100644
> > --- a/app/test/test_ring_perf.c
> > +++ b/app/test/test_ring_perf.c
> > @@ -13,6 +13,7 @@
> > #include
> >
> > #include "test.h"
> > +#include "test_ring.h"
> >
> > /*
> > * Ring
> > @@ -41,6 +42,35 @@ struct lcore_pair {
> >
> > static volatile unsigned lcore_count = 0;
> >
> > +static void
> > +test_ring_print_test_string(unsigned int api_type, int esize,
> > + unsigned int bsz, double value)
> > +{
> > + if (esize == -1)
> > + printf("legacy APIs");
> > + else
> > + printf("elem APIs: element size %dB", esize);
> > +
> > + if (api_type == TEST_RING_IGNORE_API_TYPE)
> > + return;
> > +
> > + if ((api_type & TEST_RING_N) == TEST_RING_N)
> > + printf(": default enqueue/dequeue: ");
> > + else if ((api_type & TEST_RING_S) == TEST_RING_S)
> > + printf(": SP/SC: ");
> > + else if ((api_type & TEST_RING_M) == TEST_RING_M)
> > + printf(": MP/MC: ");
> > +
> > + if ((api_type & TEST_RING_SL) == TEST_RING_SL)
> > + printf("single: ");
> > + else if ((api_type & TEST_RING_BL) == TEST_RING_BL)
> > + printf("bulk (size: %u): ", bsz);
> > + else if ((api_type & TEST_RING_BR) == TEST_RING_BR)
> > + printf("burst (size: %u): ", bsz);
> > +
> > + printf("%.2F\n", value);
> > +}
> > +
> > / Functions to analyse our core mask to get cores for different
> > tests ***/
> >
> > static int
> > @@ -335,32 +365,35 @@ run_on_all_cores(struct rte_ring *r)
> > * Test function that determines how long an enqueue + dequeue of a
> single item
> > * takes on a single lcore. Result is for comparison with the bulk enq+deq.
> > */
> > -static void
> > -test_single_enqueue_dequeue(struct rte_ring *r)
> > +static int
> > +test_single_enqueue_dequeue(struct rte_ring *r, const int esize,
> > + const unsigned int api_type)
> > {
> > - const unsigned iter_shift = 24;
> > - const unsigned iterations = 1< > - unsigned i = 0;
> > + int ret;
> > + const unsigned int iter_shift = 24;
> > + const unsigned int iterations = 1 << iter_shift;
> > + unsigned int i = 0;
> > void *burst = NULL;
> >
> > - const uint64_t sc_start = rte_rdtsc();
> > - for (i = 0; i < iterations; i++) {
> > - rte_ring_sp_enqueue(r, burst);
> > - rte_ring_sc_dequeue(r, &burst);
> > - }
> > - const uint64_t sc_end = rte_rdtsc();
> > + (void)ret;
>
> Here, and in few other places, looks redundant.
The compiler throws an error since 'ret' is assigned a value, but it is not
used.
>
> > + /* alloc dummy object pointers */
> > + burst = test_ring_calloc(1, esize);
> > + if (burst == NULL)
> > + return -1;
> >
> > - const uint64_t mc_start = rte_rdtsc();
> > + const uint64_t start = rte_rdtsc();
> > for (i = 0; i < iterations; i++) {
> > - rte_ring_mp_enqueue(r, burst);
> > - rte_ring_mc_dequeue(r, &burst);
> > + TEST_RING_ENQUEUE(r, burst, esize, 1, ret, api_type);
> > + TEST_RING_DEQUEUE(r, burst, esize, 1, ret, api_type);
> > }
> > - const uint64_t mc_end = rte_rdtsc();
> > + const uint64_t end = rte_rdtsc();
> > +
> > + test_ring_print_test_string(api_type, esize, 1,
> > + ((double)(end - start)) / iterations);
> > +
> > + rte_free(burst);
> >
> > - printf("SP/SC single enq/dequeue: %.2F\n",
> > - ((double)(sc_end-sc_start)) / iterations);
> > - printf("MP/MC single enq/dequeue: %.2F\n",
> > - ((double)(mc_end-mc_start)) / iterations);
> > + return 0;
> > }
> >
> > /*
Re: [dpdk-dev] [PATCH v3 4/6] raw/octeontx2_ep: add enqueue operation
Hi Mahipal,
> -Original Message-
> From: Mahipal Challa
> Sent: Monday, January 6, 2020 8:07 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com; Gavin Hu
> Subject: [dpdk-dev] [PATCH v3 4/6] raw/octeontx2_ep: add enqueue
> operation
>
> Add rawdev enqueue operation for SDP VF devices.
>
> Signed-off-by: Mahipal Challa
> ---
> doc/guides/rawdevs/octeontx2_ep.rst | 6 +
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 242
> ++
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 39 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 20 +++
> drivers/raw/octeontx2_ep/otx2_ep_vf.c | 24 +++
> 6 files changed, 332 insertions(+)
>
> diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> b/doc/guides/rawdevs/octeontx2_ep.rst
> index 2507fcf..39a7c29 100644
> --- a/doc/guides/rawdevs/octeontx2_ep.rst
> +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> @@ -68,3 +68,9 @@ The following code shows how the device is configured
>
> rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
>
> +Performing Data Transfer
> +
> +
> +To perform data transfer using SDP VF EP rawdev devices use standard
> +``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()``
> APIs.
> +
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> index 584b818..6910f08 100644
> --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> @@ -403,3 +403,245 @@
> return -ENOMEM;
> }
>
> +static inline void
> +sdp_iqreq_delete(struct sdp_device *sdpvf,
> + struct sdp_instr_queue *iq, uint32_t idx)
> +{
> + uint32_t reqtype;
> + void *buf;
> +
> + buf = iq->req_list[idx].buf;
> + reqtype = iq->req_list[idx].reqtype;
> +
> + switch (reqtype) {
> + case SDP_REQTYPE_NORESP:
> + rte_mempool_put(sdpvf->enqdeq_mpool, buf);
> + otx2_sdp_dbg("IQ buffer freed at idx[%d]", idx);
> + break;
> +
> + case SDP_REQTYPE_NORESP_GATHER:
> + case SDP_REQTYPE_NONE:
> + default:
> + otx2_info("This iqreq mode is not supported:%d", reqtype);
> +
> + }
> +
> + /* Reset the request list at this index */
> + iq->req_list[idx].buf = NULL;
> + iq->req_list[idx].reqtype = 0;
> +}
> +
> +static inline void
> +sdp_iqreq_add(struct sdp_instr_queue *iq, void *buf,
> + uint32_t reqtype)
> +{
> + iq->req_list[iq->host_write_index].buf = buf;
> + iq->req_list[iq->host_write_index].reqtype = reqtype;
> +
> + otx2_sdp_dbg("IQ buffer added at idx[%d]", iq->host_write_index);
> +
> +}
> +
> +static void
> +sdp_flush_iq(struct sdp_device *sdpvf,
> + struct sdp_instr_queue *iq,
> + uint32_t pending_thresh __rte_unused)
> +{
> + uint32_t instr_processed = 0;
> +
> + rte_spinlock_lock(&iq->lock);
> +
> + iq->otx_read_index = sdpvf->fn_list.update_iq_read_idx(iq);
> + while (iq->flush_index != iq->otx_read_index) {
> + /* Free the IQ data buffer to the pool */
> + sdp_iqreq_delete(sdpvf, iq, iq->flush_index);
> + iq->flush_index =
> + sdp_incr_index(iq->flush_index, 1, iq->nb_desc);
> +
> + instr_processed++;
> + }
> +
> + iq->stats.instr_processed = instr_processed;
> + rte_atomic64_sub(&iq->instr_pending, instr_processed);
> +
> + rte_spinlock_unlock(&iq->lock);
> +}
> +
> +static inline void
> +sdp_ring_doorbell(struct sdp_device *sdpvf __rte_unused,
> + struct sdp_instr_queue *iq)
> +{
> + otx2_write64(iq->fill_cnt, iq->doorbell_reg);
> +
> + /* Make sure doorbell write goes through */
> + rte_cio_wmb();
I think I commented this in v2.
The barrier should be hoisted up in between the two memory accesses which you
want a definite ordering, by CPU or NIC or both.
I does not guarantee "going through" or completeness(maybe "dsb" can, as it
stalls execution until the preceding memory access instruction complete, but
that is from the point of CPU, not the memory. The early acknowledge mechanism
will induce the CPU to think it is done but in reality it does mean to arrive
at the memory, especially the IO device registers).
Anyway I am not against the comments mentioning "completeness" for "dsb" based
barriers, but for io and cio barriers, they are about observed ordering, not
about "completeness".
> + iq->fill_cnt = 0;
> +
> +}
> +
> +static inline int
> +post_iqcmd(struct sdp_instr_queue *iq, uint8_t *iqcmd)
> +{
> + uint8_t *iqptr, cmdsize;
> +
> + /* This ensures that the read index does not wrap around to
> + * the same position if queue gets full before OCTEON TX2 could
> + * fetch any instr.
> + */
> + if (rte_atomic64_read(&iq->instr_pending) >=
> +
Re: [dpdk-dev] [PATCH v7 02/17] lib/ring: apis to support configurable element size
> > > +
> > > +static __rte_always_inline void
> > > +enqueue_elems_128(struct rte_ring *r, uint32_t prod_head, const
> > > +void *obj_table, uint32_t n) { unsigned int i; const uint32_t size
> > > += r->size; uint32_t idx = prod_head & r->mask; __uint128_t *ring =
> > > +(__uint128_t *)&r[1]; const __uint128_t *obj = (const __uint128_t
> > > +*)obj_table; if (likely(idx + n < size)) { for (i = 0; i < (n &
> > > +~0x1); i += 2, idx += 2) { ring[idx] = obj[i]; ring[idx + 1] =
> > > +obj[i + 1];
> >
> >
> > AFAIK, that implies 16B aligned obj_table...
> > Would it always be the case?
> I am not sure from the compiler perspective.
> At least on Arm architecture, unaligned access (address that is accessed is
> not
> aligned to the size of the data element being accessed) will result in faults
> or
> require additional cycles. So, aligning on 16B should be fine.
Further, I would be changing this to use 'rte_int128_t' as '__uint128_t' is not
defined on 32b systems.
>
> >
> > > +}
> > > +switch (n & 0x1) {
> > > +case 1:
> > > +ring[idx++] = obj[i++];
> > > +}
> > > +} else {
> > > +for (i = 0; idx < size; i++, idx++) ring[idx] = obj[i];
> > > +/* Start at the beginning */
> > > +for (idx = 0; i < n; i++, idx++)
> > > +ring[idx] = obj[i];
> > > +}
> > > +}
> > > +
> > > +/* the actual enqueue of elements on the ring.
> > > + * Placed here since identical code needed in both
> > > + * single and multi producer enqueue functions.
> > > + */
> > > +static __rte_always_inline void
> > > +enqueue_elems(struct rte_ring *r, uint32_t prod_head, const void
> > *obj_table,
> > > +uint32_t esize, uint32_t num)
> > > +{
> > > +uint32_t idx, nr_idx, nr_num;
> > > +
> > > +/* 8B and 16B copies implemented individually to retain
> > > + * the current performance.
> > > + */
> > > +if (esize == 8)
> > > +enqueue_elems_64(r, prod_head, obj_table, num); else if (esize ==
> > > +16) enqueue_elems_128(r, prod_head, obj_table, num); else {
> > > +/* Normalize to uint32_t */
> > > +uint32_t scale = esize / sizeof(uint32_t); nr_num = num * scale;
> > > +idx = prod_head & r->mask; nr_idx = idx * scale;
> > > +enqueue_elems_32(r, nr_idx, obj_table, nr_num); } }
> > > +
Re: [dpdk-dev] [PATCH v3 2/6] raw/octeontx2_ep: add device configuration
Hi Mahipal,
> -Original Message-
> From: Mahipal Challa
> Sent: Monday, January 6, 2020 8:07 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com; Gavin Hu
> Subject: [dpdk-dev] [PATCH v3 2/6] raw/octeontx2_ep: add device
> configuration
>
> Register "dev_configure" API to configure/initialize the SDP
> VF PCIe devices.
>
> Signed-off-by: Mahipal Challa
> ---
> doc/guides/rawdevs/octeontx2_ep.rst| 29 ++
> drivers/common/octeontx2/hw/otx2_sdp.h | 184 +
> drivers/common/octeontx2/otx2_common.c | 9 +
> drivers/common/octeontx2/otx2_common.h | 4 +
> .../octeontx2/rte_common_octeontx2_version.map | 6 +
> drivers/raw/octeontx2_ep/Makefile | 3 +
> drivers/raw/octeontx2_ep/meson.build | 4 +-
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 294 ++
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 11 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 148 +++
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 434
> -
> drivers/raw/octeontx2_ep/otx2_ep_vf.c | 408
> +++
> drivers/raw/octeontx2_ep/otx2_ep_vf.h | 10 +
> 13 files changed, 1542 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> b/doc/guides/rawdevs/octeontx2_ep.rst
> index 5f5ed01..2507fcf 100644
> --- a/doc/guides/rawdevs/octeontx2_ep.rst
> +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> @@ -39,3 +39,32 @@ entry `sriov_numvfs` for the corresponding PF driver.
>
> Once the required VFs are enabled, to be accessible from DPDK, VFs need to
> be
> bound to vfio-pci driver.
> +
> +Device Setup
> +
> +
> +The OCTEON TX2 SDP End Point VF devices will need to be bound to a
> +user-space IO driver for use. The script ``dpdk-devbind.py`` script
> +included with DPDK can be used to view the state of the devices and to bind
> +them to a suitable DPDK-supported kernel driver. When querying the status
> +of the devices, they will appear under the category of "Misc (rawdev)
> +devices", i.e. the command ``dpdk-devbind.py --status-dev misc`` can be
> +used to see the state of those devices alone.
> +
> +Device Configuration
> +
> +
> +Configuring SDP EP rawdev device is done using the
> ``rte_rawdev_configure()``
> +API, which takes the mempool as parameter. PMD uses this pool to
> send/receive
> +packets to/from the HW.
> +
> +The following code shows how the device is configured
> +
> +.. code-block:: c
> +
> + struct sdp_rawdev_info config = {0};
> + struct rte_rawdev_info rdev_info = {.dev_private = &config};
> + config.enqdeq_mpool = (void *)rte_mempool_create(...);
> +
> + rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
> +
> diff --git a/drivers/common/octeontx2/hw/otx2_sdp.h
> b/drivers/common/octeontx2/hw/otx2_sdp.h
> new file mode 100644
> index 000..1e690f8
> --- /dev/null
> +++ b/drivers/common/octeontx2/hw/otx2_sdp.h
> @@ -0,0 +1,184 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + */
> +
> +#ifndef __OTX2_SDP_HW_H_
> +#define __OTX2_SDP_HW_H_
> +
> +/* SDP VF IOQs */
> +#define SDP_MIN_RINGS_PER_VF(1)
> +#define SDP_MAX_RINGS_PER_VF(8)
> +
> +/* SDP VF IQ configuration */
> +#define SDP_VF_MAX_IQ_DESCRIPTORS (512)
> +#define SDP_VF_MIN_IQ_DESCRIPTORS (128)
> +
> +#define SDP_VF_DB_MIN (1)
> +#define SDP_VF_DB_TIMEOUT (1)
> +#define SDP_VF_INTR_THRESHOLD (0x)
> +
> +#define SDP_VF_64BYTE_INSTR (64)
> +#define SDP_VF_32BYTE_INSTR (32)
> +
> +/* SDP VF OQ configuration */
> +#define SDP_VF_MAX_OQ_DESCRIPTORS (512)
> +#define SDP_VF_MIN_OQ_DESCRIPTORS (128)
> +#define SDP_VF_OQ_BUF_SIZE (2048)
> +#define SDP_VF_OQ_REFIL_THRESHOLD (16)
> +
> +#define SDP_VF_OQ_INFOPTR_MODE (1)
> +#define SDP_VF_OQ_BUFPTR_MODE (0)
> +
> +#define SDP_VF_OQ_INTR_PKT (1)
> +#define SDP_VF_OQ_INTR_TIME (10)
> +#define SDP_VF_CFG_IO_QUEUESSDP_MAX_RINGS_PER_VF
> +
> +/* Wait time in milliseconds for FLR */
> +#define SDP_VF_PCI_FLR_WAIT (100)
> +#define SDP_VF_BUSY_LOOP_COUNT (1)
> +
> +#define SDP_VF_MAX_IO_QUEUESSDP_MAX_RINGS_PER_VF
> +#define SDP_VF_MIN_IO_QUEUESSDP_MIN_RINGS_PER_VF
> +
> +/* SDP VF IOQs per rawdev */
> +#define SDP_VF_MAX_IOQS_PER_RAWDEV SDP_VF_MAX_IO_QUEUES
> +#define SDP_VF_DEFAULT_IOQS_PER_RAWDEV SDP_VF_MIN_IO_QUEUES
> +
> +/* SDP VF Register definitions */
> +#define SDP_VF_RING_OFFSET(0x1ull << 17)
> +
> +/* SDP VF IQ Registers */
> +#define SDP_VF_R_IN_CONTROL_START (0x1)
> +#define SDP_VF_R_IN_ENABLE_START (0x10010)
> +#define SDP_VF_R_IN_INSTR_BADDR_START (0x10020)
> +#define SDP_VF_R_IN_INSTR_RSIZE_START (0x10030)
> +#defi
Re: [dpdk-dev] [PATCH 04/14] examples/ipsec-secgw: add Rx adapter support
Hi Konstantin,
Please see inline.
Thanks,
Anoob
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, December 24, 2019 12:18 AM
> To: Anoob Joseph ; Akhil Goyal ;
> Nicolau, Radu ; Thomas Monjalon
>
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Ankur Dwivedi ;
> Archana Muniganti ; Tejasree Kondoj
> ; Vamsi Krishna Attunuru ;
> Lukas Bartosik ; dev@dpdk.org
> Subject: [EXT] RE: [PATCH 04/14] examples/ipsec-secgw: add Rx adapter
> support
>
> External Email
>
> --
> > Add Rx adapter support. The event helper init routine will initialize
> > the Rx adapter according to the configuration. If Rx adapter config is
> > not present it will generate a default config. It will check the
> > available eth ports and event queues and map them 1:1. So one eth port
> > will be connected to one event queue. This way event queue ID could be
> > used to figure out the port on which a packet came in.
> >
> > Signed-off-by: Anoob Joseph
> > Signed-off-by: Lukasz Bartosik
> > ---
> > examples/ipsec-secgw/event_helper.c | 289
> > +++-
> > examples/ipsec-secgw/event_helper.h | 29
> > 2 files changed, 317 insertions(+), 1 deletion(-)
> >
> > diff --git a/examples/ipsec-secgw/event_helper.c
> > b/examples/ipsec-secgw/event_helper.c
> > index d0157f4..f0eca01 100644
> > --- a/examples/ipsec-secgw/event_helper.c
> > +++ b/examples/ipsec-secgw/event_helper.c
> > @@ -4,10 +4,60 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "event_helper.h"
> >
> > +static int
> > +eh_get_enabled_cores(struct rte_bitmap *eth_core_mask) {
> > + int i;
> > + int count = 0;
> > +
> > + RTE_LCORE_FOREACH(i) {
> > + /* Check if this core is enabled in core mask*/
> > + if (rte_bitmap_get(eth_core_mask, i)) {
> > + /* We have found enabled core */
> > + count++;
> > + }
> > + }
> > + return count;
> > +}
> > +
> > +static inline unsigned int
> > +eh_get_next_eth_core(struct eventmode_conf *em_conf) {
> > + static unsigned int prev_core = -1;
> > + unsigned int next_core;
> > +
> > + /*
> > +* Make sure we have at least one eth core running, else the following
> > +* logic would lead to an infinite loop.
> > +*/
> > + if (eh_get_enabled_cores(em_conf->eth_core_mask) == 0) {
> > + EH_LOG_ERR("No enabled eth core found");
> > + return RTE_MAX_LCORE;
> > + }
> > +
> > +get_next_core:
> > + /* Get the next core */
> > + next_core = rte_get_next_lcore(prev_core, 0, 1);
> > +
> > + /* Check if we have reached max lcores */
> > + if (next_core == RTE_MAX_LCORE)
> > + return next_core;
> > +
> > + /* Update prev_core */
> > + prev_core = next_core;
> > +
> > + /* Only some cores are marked as eth cores. Skip others */
> > + if (!(rte_bitmap_get(em_conf->eth_core_mask, next_core)))
> > + goto get_next_core;
>
> Are loops statements forbidden in C now? 😉
> As a generic comment - too many (unnecessary) gotos in this patch series.
> It is not uncommon to see 2-3 labels inside the function and bunch gotos to
> them.
> Would be good to rework the code a bit to get rid of them.
[Anoob] Sure. Will rework the code and see if the gotos can be minimized. In
this case, it seemed more straightforward to have goto instead of the loop.
Will recheck anyway.
>
> > +
> > + return next_core;
> > +}
> > +
> > static inline unsigned int
> > eh_get_next_active_core(struct eventmode_conf *em_conf, unsigned int
> > prev_core) { @@ -154,6 +204,87 @@ eh_set_default_conf_link(struct
> > eventmode_conf *em_conf) }
> >
Re: [dpdk-dev] [PATCH 11/14] examples/ipsec-secgw: add app processing code
Hi Konstantin,
Please see inline.
Thanks,
Anoob
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, December 25, 2019 8:49 PM
> To: Anoob Joseph ; Akhil Goyal ;
> Nicolau, Radu ; Thomas Monjalon
>
> Cc: Lukas Bartosik ; Jerin Jacob Kollanukkaran
> ; Narayana Prasad Raju Athreya
> ; Ankur Dwivedi ; Archana
> Muniganti ; Tejasree Kondoj
> ; Vamsi Krishna Attunuru ;
> dev@dpdk.org
> Subject: [EXT] RE: [PATCH 11/14] examples/ipsec-secgw: add app processing
> code
>
> External Email
>
> --
>
> > +static inline int
> > +process_ipsec_ev_inbound(struct ipsec_ctx *ctx, struct route_table *rt,
> > + struct rte_event *ev)
> > +{
> > + struct ipsec_sa *sa = NULL;
> > + struct rte_mbuf *pkt;
> > + uint16_t port_id = 0;
> > + enum pkt_type type;
> > + uint32_t sa_idx;
> > + uint8_t *nlp;
> > +
> > + /* Get pkt from event */
> > + pkt = ev->mbuf;
> > +
> > + /* Check the packet type */
> > + type = process_ipsec_get_pkt_type(pkt, &nlp);
> > +
> > + switch (type) {
> > + case PKT_TYPE_PLAIN_IPV4:
> > + if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD)
> > + sa = (struct ipsec_sa *) pkt->udata64;
>
>
> Shouldn't packets with PKT_RX_SEC_OFFLOAD_FAIL be handled somehow?
[Anoob] Yes. Will fix this in v2.
> Another question - as I can see from the code, right now event mode supports
> only inline-proto, correct?
> If so, then probably an error should be reported at startup, if in config file
> some other types of sessions were requested.
[Anoob] Okay. Will add this in v2.
>
> > +
> > + /* Check if we have a match */
> > + if (check_sp(ctx->sp4_ctx, nlp, &sa_idx) == 0) {
> > + /* No valid match */
> > + goto drop_pkt_and_exit;
> > + }
> > + break;
> > +
> > + case PKT_TYPE_PLAIN_IPV6:
> > + if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD)
> > + sa = (struct ipsec_sa *) pkt->udata64;
> > +
> > + /* Check if we have a match */
> > + if (check_sp(ctx->sp6_ctx, nlp, &sa_idx) == 0) {
> > + /* No valid match */
> > + goto drop_pkt_and_exit;
> > + }
> > + break;
> > +
> > + default:
> > + RTE_LOG(ERR, IPSEC, "Unsupported packet type = %d\n", type);
> > + goto drop_pkt_and_exit;
> > + }
> > +
> > + /* Check if the packet has to be bypassed */
> > + if (sa_idx == 0)
> > + goto route_and_send_pkt;
> > +
> > + /* Else the packet has to be protected with SA */
> > +
> > + /* If the packet was IPsec processed, then SA pointer should be set */
> > + if (sa == NULL)
> > + goto drop_pkt_and_exit;
> > +
> > + /* SPI on the packet should match with the one in SA */
> > + if (unlikely(sa->spi != sa_idx))
> > + goto drop_pkt_and_exit;
> > +
> > +route_and_send_pkt:
> > + port_id = get_route(pkt, rt, type);
> > + if (unlikely(port_id == RTE_MAX_ETHPORTS)) {
> > + /* no match */
> > + goto drop_pkt_and_exit;
> > + }
> > + /* else, we have a matching route */
> > +
> > + /* Update mac addresses */
> > + update_mac_addrs(pkt, port_id);
> > +
> > + /* Update the event with the dest port */
> > + ipsec_event_pre_forward(pkt, port_id);
> > + return 1;
> > +
> > +drop_pkt_and_exit:
> > + RTE_LOG(ERR, IPSEC, "Inbound packet dropped\n");
> > + rte_pktmbuf_free(pkt);
> > + ev->mbuf = NULL;
> > + return 0;
> > +}
> > +
Re: [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64
> -Original Message-
> From: Aaron Conole
> Sent: Monday, January 6, 2020 21:34
> To: Ruifeng Wang
> Cc: maicolgabr...@hotmail.com; tho...@monjalon.net;
> ferruh.yi...@intel.com; arybche...@solarflare.com; dev@dpdk.org;
> david.march...@redhat.com; Gavin Hu ; Honnappa
> Nagarahalli ; nd
> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
>
> Ruifeng Wang writes:
>
> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
> > static/shared libraries are added.
> >
> > Some limitations for current aarch64 Travis support:
> > 1. Container is used. Huge page is not available due to security reason.
> > 2. Missing kernel header package in Xenial distribution.
> >
> > Solutions to address the limitations:
> > 1. Not to add unit test for now. And run tests with no-huge in future.
> > 2. Use Bionic distribution for all aarch64 jobs.
> >
> > Signed-off-by: Ruifeng Wang
> > Reviewed-by: Gavin Hu
> > ---
>
> Can't we achieve the same thing by setting
>
> arch:
> - amd64
> - arm64
>
> in the build matrix? Or will that also force the intel builds to use the
> container
> infrastructure (in which case the no-huge support needs to be fixed)?
No, container infrastructure will not be imposed to intel builds.
AFAIN, Travis infrastructure for a specific CPU arch is provided as is, and
there is no config option to control.
The problem with just adding 'arch' in build matrix is that RUN_TESTS on arm64
is not supported
by now (Travis limitation). 'env' with RUN_TESTS will fail.
>
> One thing I wonder, isn't is possible to use qemu-user to do the amd64 unit
> tests? Then do we really need some changes to do the native build?
Do you mean to use qemu-user to do unit tests for non-x86 arch?
Changes will be needed as well to enable qemu-user to do unit test.
Since Travis support multi CPU arch, I think native build and test is simpler
and more natural.
> Does it buy us anything *today* given the cost of the hugepage restriction?
> Will that ever be resolved (I didn't see so from the docs on travis)?
The hugepage issue has been reported to Travis. I think it will be resolved.
But no set dates yet.
>
> > .ci/linux-setup.sh | 11 +++
> > .travis.yml| 42 +-
> > 2 files changed, 48 insertions(+), 5 deletions(-)
> >
> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
> > dfb9d4a20..a92978037 100755
> > --- a/.ci/linux-setup.sh
> > +++ b/.ci/linux-setup.sh
> > @@ -3,7 +3,10 @@
> > # need to install as 'root' since some of the unit tests won't run
> > without it sudo python3 -m pip install --upgrade meson
> >
> > -# setup hugepages
> > -cat /proc/meminfo
> > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > -cat /proc/meminfo
> > +# hugepage settings are skipped on aarch64 due to environment
> > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> > +# setup hugepages
> > +cat /proc/meminfo
> > +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > +cat /proc/meminfo
> > +fi
> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
> > 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -115,6 +115,46 @@ matrix:
> >apt:
> > packages:
> >- *extra_packages
> > -
> > + - env: DEF_LIB="static"
> > +arch: arm64
> > +compiler: gcc
> > +dist: bionic
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared"
> > +arch: arm64
> > +compiler: gcc
> > +dist: bionic
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="static"
> > +arch: arm64
> > +dist: bionic
> > +compiler: clang
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared"
> > +arch: arm64
> > +dist: bionic
> > +compiler: clang
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
> > +arch: arm64
> > +compiler: gcc
> > +dist: bionic
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - *doc_packages
> >
> > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
Re: [dpdk-dev] [PATCH 2/2] net/mlx5: add IPv4/IPv6 DSCP rewrite action
Hi
> -Original Message-
> From: Matan Azrad
> Sent: Monday, January 6, 2020 10:37 PM
> To: Suanming Mou ; Shahaf Shuler
> ; Slava Ovsiienko
> Cc: dev@dpdk.org; Ori Kam ;
> arybche...@solarflare.com; ferruh.yi...@intel.com; Thomas Monjalon
>
> Subject: RE: [PATCH 2/2] net/mlx5: add IPv4/IPv6 DSCP rewrite action
>
> Hi
>
> From: Suanming Mou
> > This commit add the IPv4/IPv6 DSCP rewrite actions to the PMD code.
> >
> > Supported actions:
> > RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP
> > RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP
> >
> > Signed-off-by: Suanming Mou
> > ---
> > drivers/net/mlx5/mlx5_flow.h| 6 +-
> > drivers/net/mlx5/mlx5_flow_dv.c | 184
> >
> > 2 files changed, 189 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/mlx5/mlx5_flow.h
> > b/drivers/net/mlx5/mlx5_flow.h index 27d82ac..e42c98a 100644
> > --- a/drivers/net/mlx5/mlx5_flow.h
> > +++ b/drivers/net/mlx5/mlx5_flow.h
> > @@ -196,6 +196,8 @@ enum mlx5_feature_name { #define
> > MLX5_FLOW_ACTION_MARK_EXT (1ull << 33) #define
> > MLX5_FLOW_ACTION_SET_META (1ull << 34) #define
> MLX5_FLOW_ACTION_METER
> > (1ull << 35)
> > +#define MLX5_FLOW_ACTION_SET_IPV4_DSCP (1ull << 36) #define
> > +MLX5_FLOW_ACTION_SET_IPV6_DSCP (1ull << 37)
> >
> > #define MLX5_FLOW_FATE_ACTIONS \
> > (MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_QUEUE | \ @@ -
> 232,7 +234,9
> > @@ enum mlx5_feature_name {
> > MLX5_FLOW_ACTION_OF_SET_VLAN_VID
> > | \
> > MLX5_FLOW_ACTION_SET_TAG | \
> > MLX5_FLOW_ACTION_MARK_EXT | \
> > - MLX5_FLOW_ACTION_SET_META)
> > + MLX5_FLOW_ACTION_SET_META | \
> > + MLX5_FLOW_ACTION_SET_IPV4_DSCP | \
> > + MLX5_FLOW_ACTION_SET_IPV6_DSCP)
>
> I don't think DSCP set is a reg feature... please check...
It does not belong to the mlx5_feature_name, it belongs to the
MLX5_FLOW_MODIFY_HDR_ACTIONS macro.
I don't know why git put the feature_name here. : (
>
> > #define MLX5_FLOW_VLAN_ACTIONS
> > (MLX5_FLOW_ACTION_OF_POP_VLAN | \
> > MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> > diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> > b/drivers/net/mlx5/mlx5_flow_dv.c index 4c16281..15fe726 100644
> > --- a/drivers/net/mlx5/mlx5_flow_dv.c
> > +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> > @@ -157,6 +157,7 @@ struct field_modify_info
> > modify_vlan_out_first_vid[] = { };
> >
> > struct field_modify_info modify_ipv4[] = {
> > + {1, 1, MLX5_MODI_OUT_IP_DSCP},
> > {1, 8, MLX5_MODI_OUT_IPV4_TTL},
> > {4, 12, MLX5_MODI_OUT_SIPV4},
> > {4, 16, MLX5_MODI_OUT_DIPV4},
> > @@ -164,6 +165,7 @@ struct field_modify_info modify_ipv4[] = { };
> >
> > struct field_modify_info modify_ipv6[] = {
> > + {1, 0, MLX5_MODI_OUT_IP_DSCP},
> > {1, 7, MLX5_MODI_OUT_IPV6_HOPLIMIT},
> > {4, 8, MLX5_MODI_OUT_SIPV6_127_96},
> > {4, 12, MLX5_MODI_OUT_SIPV6_95_64},
> > @@ -1191,6 +1193,82 @@ struct field_modify_info modify_tcp[] = { }
> >
> > /**
> > + * Convert modify-header set IPv4 DSCP action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_ipv4_dscp
> > + (struct mlx5_flow_dv_modify_hdr_resource
> > *resource,
> > +const struct rte_flow_action *action,
> > +struct rte_flow_error *error)
> > +{
> > + const struct rte_flow_action_set_dscp *conf =
> > + (const struct rte_flow_action_set_dscp *)(action->conf);
> > + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV4 };
> > + struct rte_flow_item_ipv4 ipv4;
> > + struct rte_flow_item_ipv4 ipv4_mask;
> > +
> > + memset(&ipv4, 0, sizeof(ipv4));
> > + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> > + ipv4.hdr.type_of_service = conf->dscp;
> > + ipv4_mask.hdr.type_of_service = 0x3f;
>
> Please use RTE_IPV4_HDR_DSCP_MASK.
OK.
>
> > + item.spec = &ipv4;
> > + item.mask = &ipv4_mask;
> > + return flow_dv_convert_modify_action(&item, modify_ipv4, NULL,
> > resource,
> > +MLX5_MODIFICATION_TYPE_SET,
> > error); }
> > +
> > +/**
> > + * Convert modify-header set IPv6 DSCP action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is
Re: [dpdk-dev] [PATCH v2] net/mlx5: avoid crash when meter action conf is NULL
On Mon, Dec 16, 2019 at 2:50 PM Suanming Mou wrote:
>
>
> > -Original Message-
> > From: Tonghao Zhang
> > Sent: Monday, December 16, 2019 9:29 AM
> > To: Matan Azrad ; Shahaf Shuler
> >
> > Cc: dev@dpdk.org; Suanming Mou
> > Subject: Re: [PATCH v2] net/mlx5: avoid crash when meter action conf is
> > NULL
> >
> > On Fri, Dec 13, 2019 at 10:21 PM wrote:
> > >
> > > From: Tonghao Zhang
> > >
> > > When offloading the meter, should check the action conf and make sure
> > > it is valid.
> > >
> > > Fixes: f46bf7488705 ("net/mlx5: support meter flow action")
> > > Cc: Suanming Mou
> > >
> > > Signed-off-by: Tonghao Zhang
> > > ---
> > > v2: coding style issues:
> > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> > >
> > es.dpdk.org%2Fpatch%2F63849%2F&data=02%7C01%7Csuanmingm%4
> > 0mellanox
> > > .com%7C65507f811a6c4e942c1d08d781c77b2a%7Ca652971c7d2e4d9ba6a4
> > d149256f
> > >
> > 461b%7C0%7C0%7C637120566090170306&sdata=0qTU8puaLH8IQkUm
> > %2B4nIDG8G
> > > 3dTi9ktvYKp%2BcxJ8dE4%3D&reserved=0
> > > ---
> > > drivers/net/mlx5/mlx5_flow_dv.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> > > b/drivers/net/mlx5/mlx5_flow_dv.c index 73aaea4..7528556 100644
> > > --- a/drivers/net/mlx5/mlx5_flow_dv.c
> > > +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> > > @@ -3402,7 +3402,12 @@ struct field_modify_info modify_tcp[] = { {
> > > struct mlx5_priv *priv = dev->data->dev_private;
> > > const struct rte_flow_action_meter *am = action->conf;
> > > - struct mlx5_flow_meter *fm = mlx5_flow_meter_find(priv, am-
> > >mtr_id);
> > > + struct mlx5_flow_meter *fm;
> > > +
> > > + if (!am)
> > > + return rte_flow_error_set(error, EINVAL,
> > > + RTE_FLOW_ERROR_TYPE_ACTION,
> > > NULL,
> > > + "meter action conf is
> > > + NULL");
> > >
> > > if (action_flags & MLX5_FLOW_ACTION_METER)
> > > return rte_flow_error_set(error, ENOTSUP, @@ -3417,6
> > > +3422,8 @@ struct field_modify_info modify_tcp[] = {
> > > RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> > > NULL,
> > > "meter action not
> > > supported");
> > > +
>
> Redundant empty line.
> Reviewed-by: Suanming Mou
so this patch will be applied ?
> > > + fm = mlx5_flow_meter_find(priv, am->mtr_id);
> > > if (!fm)
> > > return rte_flow_error_set(error, EINVAL,
> > > RTE_FLOW_ERROR_TYPE_ACTION,
> > > NULL,
> > > --
> > > 1.8.3.1
> > >
> > ping
Re: [dpdk-dev] [PATCH v2 1/2] ci: add travis ci support for aarch64
> -Original Message-
> From: dwilder
> Sent: Tuesday, January 7, 2020 04:17
> To: Ruifeng Wang
> Cc: acon...@redhat.com; maicolgabr...@hotmail.com;
> tho...@monjalon.net; ferruh.yi...@intel.com; arybche...@solarflare.com;
> dev@dpdk.org; Gavin Hu ; Honnappa Nagarahalli
> ; nd
> Subject: Re: [dpdk-dev] [PATCH v2 1/2] ci: add travis ci support for aarch64
>
> On 2019-12-20 01:37, Ruifeng Wang wrote:
> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
> > static/shared libraries are added.
> >
> > Some limitations for current aarch64 Travis support:
> > 1. Container is used. Huge page is not available due to security
> > reason.
> > 2. Missing kernel header package in Xenial distribution.
> >
> > Solutions to address the limitations:
> > 1. Not to add unit test for now. And run tests with no-huge in future.
> > 2. Use Bionic distribution for all aarch64 jobs.
> >
> > Signed-off-by: Ruifeng Wang
> > Reviewed-by: Gavin Hu
> > ---
> > .ci/linux-setup.sh | 11 +++
> > .travis.yml| 37 -
> > 2 files changed, 43 insertions(+), 5 deletions(-)
> >
> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
> > dfb9d4a20..a92978037 100755
> > --- a/.ci/linux-setup.sh
> > +++ b/.ci/linux-setup.sh
> > @@ -3,7 +3,10 @@
> > # need to install as 'root' since some of the unit tests won't run
> > without it sudo python3 -m pip install --upgrade meson
> >
> > -# setup hugepages
> > -cat /proc/meminfo
> > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > -cat /proc/meminfo
>
>
> dont test for TRAVIS_ARCH here as multiple archs may need to avoid the
> hugepage setup as well.
>
> How about:
> if [ "$RUN_TESTS" = "1" ]; then
> # setup hugepages
This should work. I can try this approach in next version.
My concern is the name may cause confusion. 'RUN_TESTS' will mean to
run default tests (with hugepage).
>
> If your planning to add a tests using --no-huge option could we add a
> NOHUGEPAGES option to the matrix?
Yes, this will give control to choose test suite. I will take this into
consideration.
>
> > +# hugepage settings are skipped on aarch64 due to environment
> > limitation
> > +if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> > +# setup hugepages
> > +cat /proc/meminfo
> > +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > +cat /proc/meminfo
> > +fi
> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..048cb6ba5
> > 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -115,6 +115,41 @@ matrix:
> >apt:
> > packages:
> >- *extra_packages
> > -
> > + - env: DEF_LIB="static"
> > +arch: arm64
> > +compiler: gcc
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared"
> > +arch: arm64
> > +compiler: gcc
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="static"
> > +arch: arm64
> > +compiler: clang
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared"
> > +arch: arm64
> > +compiler: clang
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
> > +arch: arm64
> > +compiler: gcc
> > +addons:
> > + apt:
> > +packages:
> > + - *required_packages
> > + - *doc_packages
> >
> > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
Re: [dpdk-dev] [PATCH v3 2/6] raw/octeontx2_ep: add device configuration
Hi Gavin,
Please see the response inline.
Thanks,
Mahipal
> -Original Message-
> From: Gavin Hu
> Sent: Tuesday, January 7, 2020 11:31 AM
> To: Mahipal Challa ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Subrahmanyam Nilla
> ; Venkateshwarlu Nalla ; nd
>
> Subject: [EXT] RE: [dpdk-dev] [PATCH v3 2/6] raw/octeontx2_ep: add device
> configuration
>
> External Email
>
> --
> Hi Mahipal,
>
> > -Original Message-
> > From: Mahipal Challa
> > Sent: Monday, January 6, 2020 8:07 PM
> > To: dev@dpdk.org
> > Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> > venk...@marvell.com; Gavin Hu
> > Subject: [dpdk-dev] [PATCH v3 2/6] raw/octeontx2_ep: add device
> > configuration
> >
> > Register "dev_configure" API to configure/initialize the SDP
> > VF PCIe devices.
> >
> > Signed-off-by: Mahipal Challa
> > ---
> > doc/guides/rawdevs/octeontx2_ep.rst| 29 ++
> > drivers/common/octeontx2/hw/otx2_sdp.h | 184 +
> > drivers/common/octeontx2/otx2_common.c | 9 +
> > drivers/common/octeontx2/otx2_common.h | 4 +
> > .../octeontx2/rte_common_octeontx2_version.map | 6 +
> > drivers/raw/octeontx2_ep/Makefile | 3 +
> > drivers/raw/octeontx2_ep/meson.build | 4 +-
> > drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 294 ++
> > drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 11 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 148 +++
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 434
> > -
> > drivers/raw/octeontx2_ep/otx2_ep_vf.c | 408
> > +++
> > drivers/raw/octeontx2_ep/otx2_ep_vf.h | 10 +
> > 13 files changed, 1542 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> > b/doc/guides/rawdevs/octeontx2_ep.rst
> > index 5f5ed01..2507fcf 100644
> > --- a/doc/guides/rawdevs/octeontx2_ep.rst
> > +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> > @@ -39,3 +39,32 @@ entry `sriov_numvfs` for the corresponding PF
> driver.
> >
> > Once the required VFs are enabled, to be accessible from DPDK, VFs need
> to
> > be
> > bound to vfio-pci driver.
> > +
> > +Device Setup
> > +
> > +
> > +The OCTEON TX2 SDP End Point VF devices will need to be bound to a
> > +user-space IO driver for use. The script ``dpdk-devbind.py`` script
> > +included with DPDK can be used to view the state of the devices and to
> bind
> > +them to a suitable DPDK-supported kernel driver. When querying the
> status
> > +of the devices, they will appear under the category of "Misc (rawdev)
> > +devices", i.e. the command ``dpdk-devbind.py --status-dev misc`` can be
> > +used to see the state of those devices alone.
> > +
> > +Device Configuration
> > +
> > +
> > +Configuring SDP EP rawdev device is done using the
> > ``rte_rawdev_configure()``
> > +API, which takes the mempool as parameter. PMD uses this pool to
> > send/receive
> > +packets to/from the HW.
> > +
> > +The following code shows how the device is configured
> > +
> > +.. code-block:: c
> > +
> > + struct sdp_rawdev_info config = {0};
> > + struct rte_rawdev_info rdev_info = {.dev_private = &config};
> > + config.enqdeq_mpool = (void *)rte_mempool_create(...);
> > +
> > + rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
> > +
> > diff --git a/drivers/common/octeontx2/hw/otx2_sdp.h
> > b/drivers/common/octeontx2/hw/otx2_sdp.h
> > new file mode 100644
> > index 000..1e690f8
> > --- /dev/null
> > +++ b/drivers/common/octeontx2/hw/otx2_sdp.h
> > @@ -0,0 +1,184 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2019 Marvell International Ltd.
> > + */
> > +
> > +#ifndef __OTX2_SDP_HW_H_
> > +#define __OTX2_SDP_HW_H_
> > +
> > +/* SDP VF IOQs */
> > +#define SDP_MIN_RINGS_PER_VF(1)
> > +#define SDP_MAX_RINGS_PER_VF(8)
> > +
> > +/* SDP VF IQ configuration */
> > +#define SDP_VF_MAX_IQ_DESCRIPTORS (512)
> > +#define SDP_VF_MIN_IQ_DESCRIPTORS (128)
> > +
> > +#define SDP_VF_DB_MIN (1)
> > +#define SDP_VF_DB_TIMEOUT (1)
> > +#define SDP_VF_INTR_THRESHOLD (0x)
> > +
> > +#define SDP_VF_64BYTE_INSTR (64)
> > +#define SDP_VF_32BYTE_INSTR (32)
> > +
> > +/* SDP VF OQ configuration */
> > +#define SDP_VF_MAX_OQ_DESCRIPTORS (512)
> > +#define SDP_VF_MIN_OQ_DESCRIPTORS (128)
> > +#define SDP_VF_OQ_BUF_SIZE (2048)
> > +#define SDP_VF_OQ_REFIL_THRESHOLD (16)
> > +
> > +#define SDP_VF_OQ_INFOPTR_MODE (1)
> > +#define SDP_VF_OQ_BUFPTR_MODE (0)
> > +
> > +#define SDP_VF_OQ_INTR_PKT (1)
> > +#define SDP_VF_OQ_INTR_TIME (10)
> > +#define SDP_VF_CFG_IO_QUEUESSDP_MAX_RINGS_PER_VF
> > +
> > +/* Wait time in milliseconds for FLR */
> > +#define
Re: [dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add eventmode to ipsec-secgw
Hi Konstantin, Please see inline. Thanks, Anoob > -Original Message- > From: Ananyev, Konstantin > Sent: Monday, January 6, 2020 10:21 PM > To: Anoob Joseph ; Akhil Goyal ; > Nicolau, Radu ; Thomas Monjalon > > Cc: Lukas Bartosik ; Jerin Jacob Kollanukkaran > ; Narayana Prasad Raju Athreya > ; Ankur Dwivedi ; Archana > Muniganti ; Tejasree Kondoj > ; Vamsi Krishna Attunuru ; > dev@dpdk.org > Subject: [EXT] RE: [PATCH 09/14] examples/ipsec-secgw: add eventmode to > ipsec-secgw > > External Email > > -- > > > > Add eventmode support to ipsec-secgw. This uses event helper to > > > > setup and use the eventmode capabilities. Add driver inbound worker. > > > > > > > > Example command: > > > > ./ipsec-secgw -c 0x1 -w 0002:02:00.0,ipsec_in_max_spi=100 -w > > > > 0002:07:00.0 -w 0002:0e:00.0 -w 0002:10:00.1 -- -P -p 0x3 -u 0x1 > > > > --config "(0,0,0),(1,0,0)" -f a-aes-gcm-msa.cfg --transfer-mode 1 > > > > --schedule-type 2 --process-mode drv --process-dir in > > > > > > As I can see new event mode is totally orthogonal to the existing poll > > > mode. > > > Event mode has it is own data-path, and it doesn't reuse any part of > > > poll- mode data-path code. > > > Plus in event mode many poll-mode options: > > > libirary/legacy mode, fragment/reassemble, replay-window, ESN, > > > fall-back session, etc. > > > are simply ignored. > > > > [Anoob] The features are not supported with the initial version. But > > the features are equally applicable to eventmode and is planned for the > > future. > Also, fragment/reassemble, replay-window, ESN, fall-back session etc are not > applicable for non-library mode. > > True, but in poll-mode library-mode support all functionality that legacy-mode > does, plus some extra. > Also I still hope that after perf-problems evaluation with NXP we will be > able to > safely remove legacy poll-mode. > > >We can follow the > > same logic and allow for an extra arg (which is --transfer-mode). > > > > > Also as I can read the current code - right now these modes can't be > > > mixed and used together. > > > User has to use either only event based or poll mode API/devices. > > > > [Anoob] Same like how we cannot mix library and non-library modes. > > > > > > > > If so, then at least we need a check (and report with error exit) > > > for these mutually exclusive option variants. > > > > [Anoob] Will do that. > > Ok. > > > > Probably even better would be to generate two separate binaries Let say: > > > ipsec-secgw-event and ipsec-secgw-poll. > > > We can still keep the same parent directory, makefile, common src files > > > etc. > > > for both. > > > > [Anoob] I would be inclined to not fork the current application. Do > > you see any issues if the same binary could run in both modes. The default > behavior would be poll mode (with existing behavior). > > My main concern here that there will be over-helming number of options (some > of which are mutually exclusive) in the same app. > So it will be really hard to maintain and use such app. > My thought was that it might be cleaner to have two different apps each with > its > own set of options. > [Anoob] Technically event mode would need only one extra argument. The one to specify "scheduling type". The direction can be removed (discussed in another thread) and app-mode can be merged with existing single_sa mode. And we do want the event-mode to be supporting all features supported by poll mode. Just that we will have to take it up gradually (because of the volume of code change). Thomas had opposed the idea of forking example applications for event mode. I also agree with him there. Event-mode just establishes an alternate way to receive and send packets. Entire IPsec processing can be maintained common.
Re: [dpdk-dev] [PATCH v3 4/6] raw/octeontx2_ep: add enqueue operation
Hi Gavin,
Please see the response inline.
> -Original Message-
> From: Gavin Hu
> Sent: Tuesday, January 7, 2020 11:26 AM
> To: Mahipal Challa ; dev@dpdk.org; Honnappa
> Nagarahalli
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Subrahmanyam Nilla
> ; Venkateshwarlu Nalla ; nd
>
> Subject: [EXT] RE: [dpdk-dev] [PATCH v3 4/6] raw/octeontx2_ep: add
> enqueue operation
>
> External Email
>
> --
> Hi Mahipal,
>
> > -Original Message-
> > From: Mahipal Challa
> > Sent: Monday, January 6, 2020 8:07 PM
> > To: dev@dpdk.org
> > Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> > venk...@marvell.com; Gavin Hu
> > Subject: [dpdk-dev] [PATCH v3 4/6] raw/octeontx2_ep: add enqueue
> > operation
> >
> > Add rawdev enqueue operation for SDP VF devices.
> >
> > Signed-off-by: Mahipal Challa
> > ---
> > doc/guides/rawdevs/octeontx2_ep.rst | 6 +
> > drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 242
> > ++
> > drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 39 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 20 +++
> > drivers/raw/octeontx2_ep/otx2_ep_vf.c | 24 +++
> > 6 files changed, 332 insertions(+)
> >
> > diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> > b/doc/guides/rawdevs/octeontx2_ep.rst
> > index 2507fcf..39a7c29 100644
> > --- a/doc/guides/rawdevs/octeontx2_ep.rst
> > +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> > @@ -68,3 +68,9 @@ The following code shows how the device is
> > configured
> >
> > rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
> >
> > +Performing Data Transfer
> > +
> > +
> > +To perform data transfer using SDP VF EP rawdev devices use standard
> > +``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()``
> > APIs.
> > +
> > diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > index 584b818..6910f08 100644
> > --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > @@ -403,3 +403,245 @@
> > return -ENOMEM;
> > }
> >
> > +static inline void
> > +sdp_iqreq_delete(struct sdp_device *sdpvf,
> > + struct sdp_instr_queue *iq, uint32_t idx) {
> > + uint32_t reqtype;
> > + void *buf;
> > +
> > + buf = iq->req_list[idx].buf;
> > + reqtype = iq->req_list[idx].reqtype;
> > +
> > + switch (reqtype) {
> > + case SDP_REQTYPE_NORESP:
> > + rte_mempool_put(sdpvf->enqdeq_mpool, buf);
> > + otx2_sdp_dbg("IQ buffer freed at idx[%d]", idx);
> > + break;
> > +
> > + case SDP_REQTYPE_NORESP_GATHER:
> > + case SDP_REQTYPE_NONE:
> > + default:
> > + otx2_info("This iqreq mode is not supported:%d", reqtype);
> > +
> > + }
> > +
> > + /* Reset the request list at this index */
> > + iq->req_list[idx].buf = NULL;
> > + iq->req_list[idx].reqtype = 0;
> > +}
> > +
> > +static inline void
> > +sdp_iqreq_add(struct sdp_instr_queue *iq, void *buf,
> > + uint32_t reqtype)
> > +{
> > + iq->req_list[iq->host_write_index].buf = buf;
> > + iq->req_list[iq->host_write_index].reqtype = reqtype;
> > +
> > + otx2_sdp_dbg("IQ buffer added at idx[%d]", iq->host_write_index);
> > +
> > +}
> > +
> > +static void
> > +sdp_flush_iq(struct sdp_device *sdpvf,
> > + struct sdp_instr_queue *iq,
> > + uint32_t pending_thresh __rte_unused) {
> > + uint32_t instr_processed = 0;
> > +
> > + rte_spinlock_lock(&iq->lock);
> > +
> > + iq->otx_read_index = sdpvf->fn_list.update_iq_read_idx(iq);
> > + while (iq->flush_index != iq->otx_read_index) {
> > + /* Free the IQ data buffer to the pool */
> > + sdp_iqreq_delete(sdpvf, iq, iq->flush_index);
> > + iq->flush_index =
> > + sdp_incr_index(iq->flush_index, 1, iq->nb_desc);
> > +
> > + instr_processed++;
> > + }
> > +
> > + iq->stats.instr_processed = instr_processed;
> > + rte_atomic64_sub(&iq->instr_pending, instr_processed);
> > +
> > + rte_spinlock_unlock(&iq->lock);
> > +}
> > +
> > +static inline void
> > +sdp_ring_doorbell(struct sdp_device *sdpvf __rte_unused,
> > + struct sdp_instr_queue *iq)
> > +{
> > + otx2_write64(iq->fill_cnt, iq->doorbell_reg);
> > +
> > + /* Make sure doorbell write goes through */
> > + rte_cio_wmb();
> I think I commented this in v2.
> The barrier should be hoisted up in between the two memory accesses which
> you want a definite ordering, by CPU or NIC or both.
> I does not guarantee "going through" or completeness(maybe "dsb" can, as it
> stalls execution until the preceding memory access instruction complete, but
> that is from the point of CPU, not the memory. The early acknowledge
> mechanism will induce the CPU to think it is done but in reality it does mean
> to arrive a
Re: [dpdk-dev] [PATCH] examples/fips_validation: fix parsing of cipher length for AES-GCM
> -Original Message-
> From: Archana Muniganti
> Sent: Monday, January 6, 2020 3:03 PM
> To: marko.kovace...@intel.com; roy.fan.zh...@intel.com;
> akhil.go...@nxp.com
> Cc: Sucharitha Sarananaga ; Anoob Joseph
> ; Abed Mohammad Kamaluddin
> ; Jerin Jacob Kollanukkaran ;
> dev@dpdk.org; sta...@dpdk.org; Archana Muniganti
>
> Subject: [PATCH] examples/fips_validation: fix parsing of cipher length for
> AES-
> GCM
>
> From: Sucharitha Sarananaga
>
> Cipher length need to be updated in case of AES-GCM decryption.
>
> Fixes: 4aaad2995e13 ("examples/fips_validation: support GCM parsing")
>
> Signed-off-by: Archana Muniganti
> Signed-off-by: Sucharitha Sarananaga
Acked-by: Anoob Joseph
[dpdk-dev] eventdev fault handling
Hi, This concerns eventdev being used in a DPDK multi-process mode wherein the PRIMARY process sets up the device, ports, queues and linkages and the SECONDARY processes are the real workers to which the events are load balanced to via the queues. My question (for both the sw evdev PMD and the DSW evdev PMD) is what is the recommended handling when one of the SECONDARY processes dies? In answering this you can assume that the dead process will be restarted in a few seconds (within 10 seconds): 1. Is it worthwhile unlinking that process from the queues it is linked to? 2. If so, do these PMDs support such capabilities? Additionally, what is to be done with (i.e. with respect to telling the eventdev) the events queued to the concerned core but not dequeued AND the burst dequeued held by the process at the time of death? 3. If not, then if there is continuous traffic bound to that process (for reasons e.g. scheduling algorithm of the PMD, flowid state while dying etc.), will the device eventually get backed up due to max-inflight? If so, what is the recommended remedy? 4. For DSW there is the additional aspect of ongoing/future migrations -- what is the design recommendation to compensate for that during a process crash If your answer is sensitive to the restart delay, pls explain for the different delay ranges. Thanks -Venky
Re: [dpdk-dev] [PATCH v3 5/6] raw/octeontx2_ep: add dequeue operation
Hi Gavin,
Please see the response inline.
> -Original Message-
> From: Gavin Hu
> Sent: Tuesday, January 7, 2020 11:13 AM
> To: Mahipal Challa ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju
> Athreya ; Subrahmanyam Nilla
> ; Venkateshwarlu Nalla ; nd
>
> Subject: [EXT] RE: [dpdk-dev] [PATCH v3 5/6] raw/octeontx2_ep: add
> dequeue operation
>
> External Email
>
> --
> Hi Mahipal, Jerin,
>
> > -Original Message-
> > From: Mahipal Challa
> > Sent: Monday, January 6, 2020 8:07 PM
> > To: dev@dpdk.org
> > Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> > venk...@marvell.com; Gavin Hu
> > Subject: [dpdk-dev] [PATCH v3 5/6] raw/octeontx2_ep: add dequeue
> > operation
> >
> > Add rawdev dequeue operation for SDP VF devices.
> >
> > Signed-off-by: Mahipal Challa
> > ---
> > drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 197
> > ++
> > drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 2 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> > drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 18 ++-
> > 4 files changed, 217 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > index 6910f08..dd270b5 100644
> > --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> > @@ -260,6 +260,7 @@
> > rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
> > if (buf == NULL) {
> > otx2_err("OQ buffer alloc failed");
> > + droq->stats.rx_alloc_failure++;
> > /* sdp_droq_destroy_ring_buffers(droq);*/
> > return -ENOMEM;
> > }
> > @@ -645,3 +646,199 @@
> > return SDP_IQ_SEND_FAILED;
> > }
> >
> > +static uint32_t
> > +sdp_droq_refill(struct sdp_device *sdpvf, struct sdp_droq *droq) {
> > + struct sdp_droq_desc *desc_ring;
> > + uint32_t desc_refilled = 0;
> > + void *buf = NULL;
> > +
> > + desc_ring = droq->desc_ring;
> > +
> > + while (droq->refill_count && (desc_refilled < droq->nb_desc)) {
> > + /* If a valid buffer exists (happens if there is no dispatch),
> > +* reuse the buffer, else allocate.
> > +*/
> > + if (droq->recv_buf_list[droq->refill_idx].buffer != NULL)
> > + break;
> > +
> > + rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
> > + /* If a buffer could not be allocated, no point in
> > +* continuing
> > +*/
> > + if (buf == NULL) {
> > + droq->stats.rx_alloc_failure++;
> > + break;
> > + }
> > +
> > + droq->recv_buf_list[droq->refill_idx].buffer = buf;
> > + desc_ring[droq->refill_idx].buffer_ptr =
> > rte_mem_virt2iova(buf);
> > +
> > + /* Reset any previous values in the length field. */
> > + droq->info_list[droq->refill_idx].length = 0;
> > +
> > + droq->refill_idx = sdp_incr_index(droq->refill_idx, 1,
> > + droq->nb_desc);
> > +
> > + desc_refilled++;
> > + droq->refill_count--;
> > +
> > + }
> > +
> > + return desc_refilled;
> > +}
> > +
> > +static int
> > +sdp_droq_read_packet(struct sdp_device *sdpvf __rte_unused,
> > +struct sdp_droq *droq,
> > +struct sdp_droq_pkt *droq_pkt) {
> > + struct sdp_droq_info *info;
> > + uint32_t total_len = 0;
> > + uint32_t pkt_len = 0;
> > +
> > + info = &droq->info_list[droq->read_idx];
> > + sdp_swap_8B_data((uint64_t *)&info->length, 1);
> > + if (!info->length) {
> > + otx2_err("OQ info_list->length[%ld]", (long)info->length);
> > + goto oq_read_fail;
> > + }
> > +
> > + /* Deduce the actual data size */
> > + info->length -= SDP_RH_SIZE;
> > + total_len += (uint32_t)info->length;
> > +
> > + otx2_sdp_dbg("OQ: pkt_len[%ld], buffer_size %d",
> > + (long)info->length, droq->buffer_size);
> > + if (info->length > droq->buffer_size) {
> > + otx2_err("This mode is not supported: pkt_len >
> > buffer_size");
> > + goto oq_read_fail;
> > + }
> > +
> > + if (info->length <= droq->buffer_size) {
> > + pkt_len = (uint32_t)info->length;
> > + droq_pkt->data = droq->recv_buf_list[droq-
> > >read_idx].buffer;
> > + droq_pkt->len = pkt_len;
> > +
> > + droq->recv_buf_list[droq->read_idx].buffer = NULL;
> > + droq->read_idx = sdp_incr_index(droq->read_idx, 1,/*
> > count */
> > + droq->nb_desc /* max rd
> > idx */);
> > + droq->refill_count++;
> > +
> > + }
> > +
> > + info->length = 0;
> > +
> > + return SDP_OQ_RECV_SUCCESS;
> > +
> > +oq_read_fail:
> > + return SDP_OQ_RECV_FAILED;
> > +}
> > +
>
[dpdk-dev] [PATCH v2 1/2] ethdev: add IPv4/IPv6 DSCP rewrite action
For some overlay network, such as VXLAN, the DSCP field in the new outer
IP header after VXLAN decapsulation may need to be updated accordingly.
This commit introduce the DSCP modify action for IPv4 and IPv6.
Signed-off-by: Suanming Mou
Acked-by: Andrew Rybchenko
Acked-by: Ori Kam
---
app/test-pmd/cmdline_flow.c | 50 +
doc/guides/prog_guide/rte_flow.rst | 40 +++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 8 +
lib/librte_ethdev/rte_flow.c| 2 ++
lib/librte_ethdev/rte_flow.h| 31 ++
5 files changed, 131 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 99dade7..77a6141 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -326,6 +326,10 @@ enum index {
ACTION_SET_META,
ACTION_SET_META_DATA,
ACTION_SET_META_MASK,
+ ACTION_SET_IPV4_DSCP,
+ ACTION_SET_IPV4_DSCP_VALUE,
+ ACTION_SET_IPV6_DSCP,
+ ACTION_SET_IPV6_DSCP_VALUE,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1087,6 +1091,8 @@ struct parse_action_priv {
ACTION_RAW_DECAP,
ACTION_SET_TAG,
ACTION_SET_META,
+ ACTION_SET_IPV4_DSCP,
+ ACTION_SET_IPV6_DSCP,
ZERO,
};
@@ -1300,6 +1306,18 @@ struct parse_action_priv {
ZERO,
};
+static const enum index action_set_ipv4_dscp[] = {
+ ACTION_SET_IPV4_DSCP_VALUE,
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_set_ipv6_dscp[] = {
+ ACTION_SET_IPV6_DSCP_VALUE,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -3493,6 +3511,38 @@ static int comp_set_raw_index(struct context *, const
struct token *,
(struct rte_flow_action_set_meta, mask)),
.call = parse_vc_conf,
},
+ [ACTION_SET_IPV4_DSCP] = {
+ .name = "set_ipv4_dscp",
+ .help = "set DSCP value",
+ .priv = PRIV_ACTION(SET_IPV4_DSCP,
+ sizeof(struct rte_flow_action_set_dscp)),
+ .next = NEXT(action_set_ipv4_dscp),
+ .call = parse_vc,
+ },
+ [ACTION_SET_IPV4_DSCP_VALUE] = {
+ .name = "dscp_value",
+ .help = "new IPv4 DSCP value to set",
+ .next = NEXT(action_set_ipv4_dscp, NEXT_ENTRY(UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY
+(struct rte_flow_action_set_dscp, dscp)),
+ .call = parse_vc_conf,
+ },
+ [ACTION_SET_IPV6_DSCP] = {
+ .name = "set_ipv6_dscp",
+ .help = "set DSCP value",
+ .priv = PRIV_ACTION(SET_IPV6_DSCP,
+ sizeof(struct rte_flow_action_set_dscp)),
+ .next = NEXT(action_set_ipv6_dscp),
+ .call = parse_vc,
+ },
+ [ACTION_SET_IPV6_DSCP_VALUE] = {
+ .name = "dscp_value",
+ .help = "new IPv6 DSCP value to set",
+ .next = NEXT(action_set_ipv6_dscp, NEXT_ENTRY(UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY
+(struct rte_flow_action_set_dscp, dscp)),
+ .call = parse_vc_conf,
+ },
};
/** Remove and return last entry from argument stack. */
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index a254c81..2f21309 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2558,6 +2558,46 @@ the other path depending on HW capability.
| ``mask`` | bit-mask applies to "data" |
+--++
+Action: ``SET_IPV4_DSCP``
+^
+
+Set IPv4 DSCP.
+
+Modify DSCP in IPv4 header.
+
+It must be used with RTE_FLOW_ITEM_TYPE_IPV4 in pattern.
+Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned.
+
+.. _table_rte_flow_action_set_ipv4_dscp:
+
+.. table:: SET_IPV4_DSCP
+
+ +---+-+
+ | Field | Value |
+ +===+=+
+ | ``dscp`` | DSCP in low 6 bits, rest ignore |
+ +---+-+
+
+Action: ``SET_IPV6_DSCP``
+^
+
+Set IPv6 DSCP.
+
+Modify DSCP in IPv6 header.
+
+It must be used with RTE_FLOW_ITEM_TYPE_IPV6 in pattern.
+Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned.
+
+.. _table_rte_flow_action_set_ipv6_dscp:
+
+.. table:: SET_IPV6_DSCP
+
+ +---+-+
+ | Field | Value |
+ +===+=+
+ | ``dscp`` | DSCP in low 6 bits, rest ignore |
+ +
[dpdk-dev] [PATCH v2 2/2] net/mlx5: add IPv4/IPv6 DSCP rewrite action
This commit add the IPv4/IPv6 DSCP rewrite actions to the PMD code.
Supported actions:
RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP
RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP
Signed-off-by: Suanming Mou
---
drivers/net/mlx5/mlx5_flow.h| 6 +-
drivers/net/mlx5/mlx5_flow_dv.c | 184
2 files changed, 189 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 27d82ac..e42c98a 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -196,6 +196,8 @@ enum mlx5_feature_name {
#define MLX5_FLOW_ACTION_MARK_EXT (1ull << 33)
#define MLX5_FLOW_ACTION_SET_META (1ull << 34)
#define MLX5_FLOW_ACTION_METER (1ull << 35)
+#define MLX5_FLOW_ACTION_SET_IPV4_DSCP (1ull << 36)
+#define MLX5_FLOW_ACTION_SET_IPV6_DSCP (1ull << 37)
#define MLX5_FLOW_FATE_ACTIONS \
(MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_QUEUE | \
@@ -232,7 +234,9 @@ enum mlx5_feature_name {
MLX5_FLOW_ACTION_OF_SET_VLAN_VID | \
MLX5_FLOW_ACTION_SET_TAG | \
MLX5_FLOW_ACTION_MARK_EXT | \
- MLX5_FLOW_ACTION_SET_META)
+ MLX5_FLOW_ACTION_SET_META | \
+ MLX5_FLOW_ACTION_SET_IPV4_DSCP | \
+ MLX5_FLOW_ACTION_SET_IPV6_DSCP)
#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
MLX5_FLOW_ACTION_OF_PUSH_VLAN)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 4c16281..685fceb 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -157,6 +157,7 @@ struct field_modify_info modify_vlan_out_first_vid[] = {
};
struct field_modify_info modify_ipv4[] = {
+ {1, 1, MLX5_MODI_OUT_IP_DSCP},
{1, 8, MLX5_MODI_OUT_IPV4_TTL},
{4, 12, MLX5_MODI_OUT_SIPV4},
{4, 16, MLX5_MODI_OUT_DIPV4},
@@ -164,6 +165,7 @@ struct field_modify_info modify_ipv4[] = {
};
struct field_modify_info modify_ipv6[] = {
+ {1, 0, MLX5_MODI_OUT_IP_DSCP},
{1, 7, MLX5_MODI_OUT_IPV6_HOPLIMIT},
{4, 8, MLX5_MODI_OUT_SIPV6_127_96},
{4, 12, MLX5_MODI_OUT_SIPV6_95_64},
@@ -1191,6 +1193,82 @@ struct field_modify_info modify_tcp[] = {
}
/**
+ * Convert modify-header set IPv4 DSCP action to DV specification.
+ *
+ * @param[in,out] resource
+ * Pointer to the modify-header resource.
+ * @param[in] action
+ * Pointer to action specification.
+ * @param[out] error
+ * Pointer to the error structure.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_ipv4_dscp
+ (struct mlx5_flow_dv_modify_hdr_resource *resource,
+const struct rte_flow_action *action,
+struct rte_flow_error *error)
+{
+ const struct rte_flow_action_set_dscp *conf =
+ (const struct rte_flow_action_set_dscp *)(action->conf);
+ struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV4 };
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_ipv4 ipv4_mask;
+
+ memset(&ipv4, 0, sizeof(ipv4));
+ memset(&ipv4_mask, 0, sizeof(ipv4_mask));
+ ipv4.hdr.type_of_service = conf->dscp;
+ ipv4_mask.hdr.type_of_service = RTE_IPV4_HDR_DSCP_MASK >> 2;
+ item.spec = &ipv4;
+ item.mask = &ipv4_mask;
+ return flow_dv_convert_modify_action(&item, modify_ipv4, NULL, resource,
+MLX5_MODIFICATION_TYPE_SET, error);
+}
+
+/**
+ * Convert modify-header set IPv6 DSCP action to DV specification.
+ *
+ * @param[in,out] resource
+ * Pointer to the modify-header resource.
+ * @param[in] action
+ * Pointer to action specification.
+ * @param[out] error
+ * Pointer to the error structure.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_ipv6_dscp
+ (struct mlx5_flow_dv_modify_hdr_resource *resource,
+const struct rte_flow_action *action,
+struct rte_flow_error *error)
+{
+ const struct rte_flow_action_set_dscp *conf =
+ (const struct rte_flow_action_set_dscp *)(action->conf);
+ struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV6 };
+ struct rte_flow_item_ipv6 ipv6;
+ struct rte_flow_item_ipv6 ipv6_mask;
+
+ memset(&ipv6, 0, sizeof(ipv6));
+ memset(&ipv6_mask, 0, sizeof(ipv6_mask));
+ /*
+* Even though the DSCP bits offset of IPv6 is not byte aligned,
+* rdma-core only accept the DSCP bits byte aligned start from
+* bit 0 to 5 as to be compatible with IPv4. No need to shift the
+* bits in IPv6
[dpdk-dev] [PATCH v2 0/2] add IPv4/IPv6 DSCP rewrite action
For some overlay network, such as VXLAN, the DSCP field in the new outer IP header after VXLAN decapsulation may need to be updated accordingly. This patchset implements the DSCP rewrite action for IPv4 and IPv6 as RFC[1]. [1] https://inbox.dpdk.org/dev/1575955386-6672-1-git-send-email-suanmi...@mellanox.com/ --- v2: change the magic number 0x3f to RTE_IPV4/6_HDR_DSCP_MASK macro in PMD. Suanming Mou (2): ethdev: add IPv4/IPv6 DSCP rewrite action net/mlx5: add IPv4/IPv6 DSCP rewrite action app/test-pmd/cmdline_flow.c | 50 doc/guides/prog_guide/rte_flow.rst | 40 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 8 ++ drivers/net/mlx5/mlx5_flow.h| 6 +- drivers/net/mlx5/mlx5_flow_dv.c | 184 lib/librte_ethdev/rte_flow.c| 2 + lib/librte_ethdev/rte_flow.h| 31 + 7 files changed, 320 insertions(+), 1 deletion(-) -- 1.8.3.1
Re: [dpdk-dev] [PATCH v2 2/2] net/mlx5: add IPv4/IPv6 DSCP rewrite action
From: Suanming Mou
> This commit add the IPv4/IPv6 DSCP rewrite actions to the PMD code.
>
> Supported actions:
> RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP
> RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP
>
> Signed-off-by: Suanming Mou
Acked-by: Matan Azrad
> ---
> drivers/net/mlx5/mlx5_flow.h| 6 +-
> drivers/net/mlx5/mlx5_flow_dv.c | 184
>
> 2 files changed, 189 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 27d82ac..e42c98a 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -196,6 +196,8 @@ enum mlx5_feature_name { #define
> MLX5_FLOW_ACTION_MARK_EXT (1ull << 33) #define
> MLX5_FLOW_ACTION_SET_META (1ull << 34) #define
> MLX5_FLOW_ACTION_METER (1ull << 35)
> +#define MLX5_FLOW_ACTION_SET_IPV4_DSCP (1ull << 36) #define
> +MLX5_FLOW_ACTION_SET_IPV6_DSCP (1ull << 37)
>
> #define MLX5_FLOW_FATE_ACTIONS \
> (MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_QUEUE | \
> @@ -232,7 +234,9 @@ enum mlx5_feature_name {
> MLX5_FLOW_ACTION_OF_SET_VLAN_VID
> | \
> MLX5_FLOW_ACTION_SET_TAG | \
> MLX5_FLOW_ACTION_MARK_EXT | \
> - MLX5_FLOW_ACTION_SET_META)
> + MLX5_FLOW_ACTION_SET_META | \
> + MLX5_FLOW_ACTION_SET_IPV4_DSCP | \
> + MLX5_FLOW_ACTION_SET_IPV6_DSCP)
>
> #define MLX5_FLOW_VLAN_ACTIONS
> (MLX5_FLOW_ACTION_OF_POP_VLAN | \
> MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 4c16281..685fceb 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -157,6 +157,7 @@ struct field_modify_info modify_vlan_out_first_vid[]
> = { };
>
> struct field_modify_info modify_ipv4[] = {
> + {1, 1, MLX5_MODI_OUT_IP_DSCP},
> {1, 8, MLX5_MODI_OUT_IPV4_TTL},
> {4, 12, MLX5_MODI_OUT_SIPV4},
> {4, 16, MLX5_MODI_OUT_DIPV4},
> @@ -164,6 +165,7 @@ struct field_modify_info modify_ipv4[] = { };
>
> struct field_modify_info modify_ipv6[] = {
> + {1, 0, MLX5_MODI_OUT_IP_DSCP},
> {1, 7, MLX5_MODI_OUT_IPV6_HOPLIMIT},
> {4, 8, MLX5_MODI_OUT_SIPV6_127_96},
> {4, 12, MLX5_MODI_OUT_SIPV6_95_64},
> @@ -1191,6 +1193,82 @@ struct field_modify_info modify_tcp[] = { }
>
> /**
> + * Convert modify-header set IPv4 DSCP action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ipv4_dscp
> + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_dscp *conf =
> + (const struct rte_flow_action_set_dscp *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV4 };
> + struct rte_flow_item_ipv4 ipv4;
> + struct rte_flow_item_ipv4 ipv4_mask;
> +
> + memset(&ipv4, 0, sizeof(ipv4));
> + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> + ipv4.hdr.type_of_service = conf->dscp;
> + ipv4_mask.hdr.type_of_service = RTE_IPV4_HDR_DSCP_MASK >> 2;
> + item.spec = &ipv4;
> + item.mask = &ipv4_mask;
> + return flow_dv_convert_modify_action(&item, modify_ipv4, NULL,
> resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header set IPv6 DSCP action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ipv6_dscp
> + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_dscp *conf =
> + (const struct rte_flow_action_set_dscp *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV6 };
> + struct rte_flow_item_ipv6 ipv6;
> + struct rte_flow_item_ipv6 ipv6_mask;
> +
> + memset(&ipv6, 0, sizeof(ipv6));
> + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> + /*
> + * Even though the DSCP bits of
Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers
Hi all Any comments? From: Matan Azrad > As discussed and as described in RFC "[RFC] net: new vdpa PMD for Mellanox > devices", new vDPA driver is going to be added for Mellanox devices - vDPA > mlx5 and more. > > The only vDPA driver now is the IFC driver that is located in net directory. > > The IFC driver and the new vDPA mlx5 driver provide the vDPA ops > introduced in librte_vhost and not the eth-dev ops. > All the others drivers in net class provide the eth-dev ops. > The set of features is also different. > > Create a new class for vDPA drivers and move IFC to this class. > Later, all the new drivers that implement the vDPA ops will be added to the > vDPA class. > > Also, a vDPA device driver features list was added to vDPA documentation. > > Please review the features list and the series. > > Later on, I'm going to send the vDPA mlx5 driver. > > Thanks. > > > Matan Azrad (3): > drivers: introduce vDPA class > doc: add vDPA feature table > drivers: move ifc driver to the vDPA class > > MAINTAINERS |6 +- > doc/guides/conf.py|5 + > doc/guides/index.rst |1 + > doc/guides/nics/features/ifcvf.ini|8 - > doc/guides/nics/ifc.rst | 106 --- > doc/guides/nics/index.rst |1 - > doc/guides/vdpadevs/features/default.ini | 55 ++ > doc/guides/vdpadevs/features/ifcvf.ini|8 + > doc/guides/vdpadevs/features_overview.rst | 65 ++ > doc/guides/vdpadevs/ifc.rst | 106 +++ > doc/guides/vdpadevs/index.rst | 15 + > drivers/Makefile |2 + > drivers/meson.build |1 + > drivers/net/Makefile |3 - > drivers/net/ifc/Makefile | 34 - > drivers/net/ifc/base/ifcvf.c | 329 > drivers/net/ifc/base/ifcvf.h | 162 > drivers/net/ifc/base/ifcvf_osdep.h| 52 -- > drivers/net/ifc/ifcvf_vdpa.c | 1280 > - > drivers/net/ifc/meson.build |9 - > drivers/net/ifc/rte_pmd_ifc_version.map |3 - > drivers/net/meson.build |1 - > drivers/vdpa/Makefile | 14 + > drivers/vdpa/ifc/Makefile | 34 + > drivers/vdpa/ifc/base/ifcvf.c | 329 > drivers/vdpa/ifc/base/ifcvf.h | 162 > drivers/vdpa/ifc/base/ifcvf_osdep.h | 52 ++ > drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 > + > drivers/vdpa/ifc/meson.build |9 + > drivers/vdpa/ifc/rte_pmd_ifc_version.map |3 + > drivers/vdpa/meson.build |8 + > 31 files changed, 2152 insertions(+), 1991 deletions(-) delete mode 100644 > doc/guides/nics/features/ifcvf.ini > delete mode 100644 doc/guides/nics/ifc.rst create mode 100644 > doc/guides/vdpadevs/features/default.ini > create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini > create mode 100644 doc/guides/vdpadevs/features_overview.rst > create mode 100644 doc/guides/vdpadevs/ifc.rst create mode 100644 > doc/guides/vdpadevs/index.rst delete mode 100644 > drivers/net/ifc/Makefile delete mode 100644 drivers/net/ifc/base/ifcvf.c > delete mode 100644 drivers/net/ifc/base/ifcvf.h delete mode 100644 > drivers/net/ifc/base/ifcvf_osdep.h > delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c delete mode 100644 > drivers/net/ifc/meson.build delete mode 100644 > drivers/net/ifc/rte_pmd_ifc_version.map > create mode 100644 drivers/vdpa/Makefile create mode 100644 > drivers/vdpa/ifc/Makefile create mode 100644 drivers/vdpa/ifc/base/ifcvf.c > create mode 100644 drivers/vdpa/ifc/base/ifcvf.h create mode 100644 > drivers/vdpa/ifc/base/ifcvf_osdep.h > create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c create mode 100644 > drivers/vdpa/ifc/meson.build create mode 100644 > drivers/vdpa/ifc/rte_pmd_ifc_version.map > create mode 100644 drivers/vdpa/meson.build > > -- > 1.8.3.1
