Re: [dpdk-dev] [PATCH] doc: two typos in documentation
04/08/2021 20:26, Henry Nadeau: > -:start-after: Building correct configruration for vdmq. 8< > +:start-after: Building correct configuration for vdmq. 8< While at it, "vmdq" should be "VMDq" I think (to be checked).
Re: [dpdk-dev] [PATCH v2] net/virtio: fix repeated memory free of vq
On 08/04/2021 07:45, Gaoxiang Liu wrote:
When virtio_init_queue returns error, the memory of vq is freed.
But the value of hw->vqs[queue_idx] does not restore.
If hw->vqs[queue_idx] != NULL, the memory of vq is freed again
in virtio_free_queues.
Fixes: 69c80d4ef89b ("net/virtio: allocate queue at init stage")
Cc: sta...@dpdk.org
Signed-off-by: Gaoxiang Liu
v2:
fix spelling warning
---
drivers/net/virtio/virtio_ethdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 056830566..fc72d71cb 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -631,6 +631,7 @@ virtio_init_queue(struct rte_eth_dev *dev, uint16_t
queue_idx)
rte_memzone_free(mz);
free_vq:
rte_free(vq);
+ hw->vqs[queue_idx] = NULL;
return ret;
}
--
2.32.0
[dpdk-dev] [PATCH] doc: announce change in crypto raw data vector
The current crypto raw data vectors need to be extended to support out of place processing. It is proposed to add additional desl_sgl to provide details for destination sgl. The same is also extended to support rte_security usecases, where we need total data length to know how much additional memory space is available in buffer other than data length so that driver/HW can write expanded size data after encryption. Signed-off-by: Gagandeep Singh Signed-off-by: Hemant Agrawal --- doc/guides/rel_notes/deprecation.rst | 12 1 file changed, 12 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index f4a4d00db2..c19a306c93 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -193,3 +193,15 @@ Deprecation Notices reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other information from the crypto/security operation. This field will be used to communicate events such as soft expiry with IPsec in lookaside mode. + +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add + ``dest_sgl`` to support out of place processing. This field will be null for + inplace processing. This change is targeted for DPDK 21.11 + +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add + ``tot_len`` to support total buffer length. This is required for security + cases like IPsec and PDCP encryption offload to know how much additional + memory space is available in buffer other than data length so that driver/HW + can write expanded size data after encryption. This change is targeted for + DPDK 21.11 + -- 2.17.1
Re: [dpdk-dev] [PATCH] doc: announce SA config option struct changes
On 7/31/2021 6:44 PM, Akhil Goyal wrote: From: Archana Muniganti Propose new fields to support offloads like - IPsec inner checksum(L3/L4) - IPsec tunnel header verification - TSO - etc in the structure ``rte_security_ipsec_sa_options``. Signed-off-by: Archana Muniganti Signed-off-by: Tejasree Kondoj Acked-by: Akhil Goyal --- Proposal for changes are floated as per below links. https://mails.dpdk.org/archives/dev/2021-June/212977.html https://mails.dpdk.org/archives/dev/2021-July/213484.html https://mails.dpdk.org/archives/dev/2021-July/214521.html Cc: Radu Nicolau Acked-by: Radu Nicolau
Re: [dpdk-dev] [PATCH] doc: announce change in crypto adapter metadata
On 04/08/2021 19:17, Akhil Goyal wrote: >> Subject: [PATCH] doc: announce change in crypto adapter metadata >> >> In crypto adapter metadata, first 8 bytes of request info is a space >> holder for response info. For better clarity, reserved field should be >> removed from request info. New space for response info can be made by >> changing type of event crypto metadata to structure from union. >> >> Signed-off-by: Shijith Thotton > Acked-by: Akhil Goyal > Acked-by: Ray Kinsella
[dpdk-dev] [PATCH v3] doc: mtr: add API walk through
From: Jerin Jacob Added a diagram to document meter library components and added text for steps performed by the application to configure the traffic meter and policing library. Signed-off-by: Jerin Jacob --- v2: Fix long lines in svg file to avoid patch apply issue v3: Fix all Thomas's comment at http://patches.dpdk.org/project/dpdk/patch/20210804113410.3604616-1-jer...@marvell.com/ doc/guides/prog_guide/img/meter.svg | 1600 + .../traffic_metering_and_policing.rst | 29 + lib/ethdev/rte_mtr.h |4 +- 3 files changed, 1631 insertions(+), 2 deletions(-) create mode 100644 doc/guides/prog_guide/img/meter.svg diff --git a/doc/guides/prog_guide/img/meter.svg b/doc/guides/prog_guide/img/meter.svg new file mode 100644 index 00..7214c5dc2b --- /dev/null +++ b/doc/guides/prog_guide/img/meter.svg @@ -0,0 +1,1600 @@ + + + + +http://purl.org/dc/elements/1.1/"; xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; width="233mm" height="198mm" + viewBox="0 0 233 198" version="1.1" id="svg8" inkscape:version="0.92.4 (5da689c313, + 2019-01-14)" sodipodi:docname="meter_new.svg"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + + + + + + + RTE_FLOW_ITEM + + RTE_FLOW_ACTION_TYPE_METER + + + + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + + CIR + + CBS + + EBS + + PIR + + PBS + + EIR + + + + CIR + + CBS + + EBS + + PIR + + PBS + + EIR + + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + + + CIR + + CBS + + EBS + + PIR + + PBS + + EIR + + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION_METER + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + + + + + + + + + + + + + diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst index c0537e653c..0fe013522f 100644 --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst @@ -20,6 +20,7 @@ The main features are: and RFC 4115 Two Rate Three Color Marker (trTCM) * Policer actions (per meter output color): recolor, drop * Statistics (per policer output color) +* Chaining the meter objects Configuration steps --- @@ -64,3 +65,31 @@ The processing done for each input packet hitting an MTR object is: * Statistics: The set of counters maintained for each MTR object is configurable and subject to the implementation support. This set includes the number of packets and bytes dropped or passed for each output color. + +API Walk-through + + +.. figure:: img/meter.* + + Meter components + +This section will introduce the reader to the critical APIs to use +the traffic meter and policing library. + +In general, the following steps are performed by the application to configure +the traffic meter and policing library. + +#. Application gets the meter driver capabilities using ``rte_mtr_capabilities_get()``. +#. Application identifies the profile(s) needed for metering and creates it with + ``rte_mtr_meter_profile_add()``. +#. Application identifies the policies needed and creates it with ``rte_mtr_meter_policy_add()``. +#. A meter object consists of a profile and a policy. Use above created objects to create + meter object using ``rte_mtr_create()``. Application uses + ``struct rte_mtr_params::meter_profile_id`` and ``struct rte_mtr_params::meter_policy_id`` + to specify the profile (created in step 2) and policy (created in step 3). +#. Once the meter object is created, the application shall use ``rte_flow_create(
Re: [dpdk-dev] [PATCH] doc: announce SA config option struct changes
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH] doc: announce change in crypto adapter metadata
On Thu, Aug 5, 2021 at 3:42 PM Kinsella, Ray wrote: > > > > On 04/08/2021 19:17, Akhil Goyal wrote: > >> Subject: [PATCH] doc: announce change in crypto adapter metadata > >> > >> In crypto adapter metadata, first 8 bytes of request info is a space > >> holder for response info. For better clarity, reserved field should be > >> removed from request info. New space for response info can be made by > >> changing type of event crypto metadata to structure from union. > >> > >> Signed-off-by: Shijith Thotton > > Acked-by: Akhil Goyal > > > Acked-by: Ray Kinsella + @Gujjar, Abhinandan S Acked-by: Jerin Jacob
[dpdk-dev] [PATCH 1/2] doc: announce ipsec rte_ipsec_sa_prm structure changes
Signed-off-by: Radu Nicolau --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index f4a4d00db2..b87fa54e67 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -193,3 +193,6 @@ Deprecation Notices reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other information from the crypto/security operation. This field will be used to communicate events such as soft expiry with IPsec in lookaside mode. + + * ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new + field ``hdr_l3_len`` to configure tunnel l3 header lenght. -- 2.25.1
[dpdk-dev] [PATCH 2/2] doc: announce rte_security_ipsec_xform structure changes
Signed-off-by: Radu Nicolau --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index b87fa54e67..a3493b4dfb 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -196,3 +196,8 @@ Deprecation Notices * ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new field ``hdr_l3_len`` to configure tunnel l3 header lenght. + + * security: The structure ``rte_security_ipsec_xform`` will be extended with + multiple fields: udp structure that will hold the source and destination port + for UDP encapsulation, mss to specify the IPsec payload Maximum Segment Size, + esn structure for Extended Sequence Number. -- 2.25.1
Re: [dpdk-dev] [dpdk-announce] release candidate 21.08-rc3
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, August 4, 2021 8:48 PM > To: Jiang, YuX > Cc: dev (dev@dpdk.org) ; Devlin, Michelle > ; Mcnamara, John > ; Yigit, Ferruh ; Zhang, > Qi Z > Subject: Re: [dpdk-dev] [dpdk-announce] release candidate 21.08-rc3 > > 04/08/2021 13:38, Jiang, YuX: > > Hi Thomas and all, > > Update the test status for Intel part. Till now dpdk21.08-rc3 test is > > finished. > No critical issue is found. > > One bug about https://bugs.dpdk.org/show_bug.cgi?id=768 is found, > Nvidia's Dev. is working on it. > > No, there is no work on NVIDIA side, because it seems to reveal an issue on > Intel driver side, as I said in the mail thread. > Ok. Thanks Thomas, we will check it on Intel side.
Re: [dpdk-dev] [PATCH 1/2] doc: announce ipsec rte_ipsec_sa_prm structure changes
> > Signed-off-by: Radu Nicolau > --- > doc/guides/rel_notes/deprecation.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f4a4d00db2..b87fa54e67 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -193,3 +193,6 @@ Deprecation Notices >reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other >information from the crypto/security operation. This field will be used to >communicate events such as soft expiry with IPsec in lookaside mode. > + > + * ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new > + field ``hdr_l3_len`` to configure tunnel l3 header lenght. > -- Acked-by: Konstantin Ananyev > 2.25.1
Re: [dpdk-dev] [PATCH 2/2] doc: announce rte_security_ipsec_xform structure changes
> Signed-off-by: Radu Nicolau > --- > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index b87fa54e67..a3493b4dfb 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -196,3 +196,8 @@ Deprecation Notices > >* ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new >field ``hdr_l3_len`` to configure tunnel l3 header lenght. > + > + * security: The structure ``rte_security_ipsec_xform`` will be extended > with > + multiple fields: udp structure that will hold the source and destination > port > + for UDP encapsulation, mss to specify the IPsec payload Maximum Segment > Size, > + esn structure for Extended Sequence Number. > -- Acked-by: Konstantin Ananyev > 2.25.1
Re: [dpdk-dev] [WARNING: UNSCANNABLE EXTRACTION FAILED][WARNING: UNSCANNABLE EXTRACTION FAILED] [PATCH v3] doc: mtr: add API walk through
HI Jerin, Thanks for your patch! Initially, it looked like an easy job to review it, but there is actually an elephant in the room on how to chain the meters, see below. > -Original Message- > From: jer...@marvell.com > Sent: Thursday, August 5, 2021 11:11 AM > To: Dumitrescu, Cristian ; Thomas Monjalon > ; Yigit, Ferruh ; Andrew > Rybchenko > Cc: dev@dpdk.org; arybche...@solarflare.com; l...@nvidia.com; > ajit.khapa...@broadcom.com; Singh, Jasvinder > ; ma...@nvidia.com; Jerin Jacob > > Subject: [WARNING: UNSCANNABLE EXTRACTION FAILED][WARNING: > UNSCANNABLE EXTRACTION FAILED][dpdk-dev] [PATCH v3] doc: mtr: add > API walk through > > From: Jerin Jacob > > Added a diagram to document meter library components > and added text for steps performed by the application to > configure the traffic meter and policing library. > > Signed-off-by: Jerin Jacob > --- > v2: Fix long lines in svg file to avoid patch apply issue > v3: Fix all Thomas's comment at > http://patches.dpdk.org/project/dpdk/patch/20210804113410.3604616-1- > jer...@marvell.com/ > > doc/guides/prog_guide/img/meter.svg | 1600 + > .../traffic_metering_and_policing.rst | 29 + > lib/ethdev/rte_mtr.h |4 +- > 3 files changed, 1631 insertions(+), 2 deletions(-) > create mode 100644 doc/guides/prog_guide/img/meter.svg > > diff --git a/doc/guides/prog_guide/img/meter.svg > b/doc/guides/prog_guide/img/meter.svg > new file mode 100644 > index 00..7214c5dc2b > --- /dev/null > +++ b/doc/guides/prog_guide/img/meter.svg Just to avoid confusion with the rte_meter API (from the lib/meter library), may change the name to rte_mtr_meter_chaining.svg ? > diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst > b/doc/guides/prog_guide/traffic_metering_and_policing.rst > index c0537e653c..0fe013522f 100644 > --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst > +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst > @@ -20,6 +20,7 @@ The main features are: >and RFC 4115 Two Rate Three Color Marker (trTCM) > * Policer actions (per meter output color): recolor, drop > * Statistics (per policer output color) > +* Chaining the meter objects How about: Chaining multiple meter objects. > > Configuration steps > --- > @@ -64,3 +65,31 @@ The processing done for each input packet hitting an > MTR object is: > * Statistics: The set of counters maintained for each MTR object is >configurable and subject to the implementation support. This set includes >the number of packets and bytes dropped or passed for each output color. > + > +API Walk-through > + > + > +.. figure:: img/meter.* > + > + Meter components > + > +This section will introduce the reader to the critical APIs to use > +the traffic meter and policing library. > + > +In general, the following steps are performed by the application to > configure > +the traffic meter and policing library. > + > +#. Application gets the meter driver capabilities using > ``rte_mtr_capabilities_get()``. > +#. Application identifies the profile(s) needed for metering and creates it > with > + ``rte_mtr_meter_profile_add()``. How about: The application creates the required meter profiles by using the rte_mtr_meter_profile_add() API function. > +#. Application identifies the policies needed and creates it with > ``rte_mtr_meter_policy_add()``. How about: The application creates the required meter policies by using the rte_mtr_meter_policy_add() API function. > +#. A meter object consists of a profile and a policy. Use above created > objects to create > + meter object using ``rte_mtr_create()``. Application uses > + ``struct rte_mtr_params::meter_profile_id`` and ``struct > rte_mtr_params::meter_policy_id`` > + to specify the profile (created in step 2) and policy (created in step 3). It is mainly the meter object configuration that consists of a profile and a policy, but not exactly the meter object itself. How about: The application creates a meter object using the rte_mtr_create() API function. One of the previously created meter profile and meter policy are provided as arguments at this step. > +#. Once the meter object is created, the application shall use > ``rte_flow_create()`` API to > + instantiate the meter object using ``RTE_FLOW_ACTION_TYPE_METER`` > action. The instantiate word might not be the best word here, as it typically indicates creating an object as opposed linking it to some other entity. How about: The application enables the meter object execution as part of the flow action processing by calling the rte_flow_create() API function with one of the flow action set to ``RTE_FLOW_ACTION_TYPE_METER`` and the associated meter object ID set to this meter object. > +#. The API allows chaining the meter objects to create complex metering > topology > + by specifyi
[dpdk-dev] [PATCH 1/2] rib: announce experimental tag removal of the rib API
This patch announces the experimental tag removal of all rib APIs, which have been experimental for 2 years. API will be promoted to stable in DPDK 21.11 Signed-off-by: Vladimir Medvedkin --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index f4a4d00..afb599a 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -193,3 +193,5 @@ Deprecation Notices reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other information from the crypto/security operation. This field will be used to communicate events such as soft expiry with IPsec in lookaside mode. + +* rib: The ``rib`` library will be promoted from experimental to stable. -- 2.7.4
[dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
This patch announces the experimental tag removal of all fib APIs, which have been experimental for 2 years. API will be promoted to stable in DPDK 21.11 Signed-off-by: Vladimir Medvedkin --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index afb599a..58826a8 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -195,3 +195,5 @@ Deprecation Notices communicate events such as soft expiry with IPsec in lookaside mode. * rib: The ``rib`` library will be promoted from experimental to stable. + +* fib: The ``fib`` library will be promoted from experimental to stable. -- 2.7.4
[dpdk-dev] [Bug 779] cryptodev_virtio_autotest crash
https://bugs.dpdk.org/show_bug.cgi?id=779 Bug ID: 779 Summary: cryptodev_virtio_autotest crash Product: DPDK Version: 21.05 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: cryptodev Assignee: dev@dpdk.org Reporter: ciara.po...@intel.com Target Milestone: --- Created attachment 169 --> https://bugs.dpdk.org/attachment.cgi?id=169&action=edit Screenshot of where the autotest crashes. Unresponsive at this point. When running the cryptodev_virtio_autotest, there is a seg fault and the app crashes. This is seen when executing the ESN testsuite (see attached screenshot). >From basic debugging myself, the problem seems to occur for the first ESN testcase auth_encrypt_AES128CBC_HMAC_SHA1_esn_check() when trying to process the crypto request. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [EXT] [PATCH 2/2] doc: announce rte_security_ipsec_xform structure changes
> Subject: [EXT] [PATCH 2/2] doc: announce rte_security_ipsec_xform > structure changes > > External Email > > -- > Signed-off-by: Radu Nicolau > --- > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index b87fa54e67..a3493b4dfb 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -196,3 +196,8 @@ Deprecation Notices > >* ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new >field ``hdr_l3_len`` to configure tunnel l3 header lenght. > + > + * security: The structure ``rte_security_ipsec_xform`` will be > + extended with multiple fields: udp structure that will hold the > + source and destination port for UDP encapsulation, mss to specify the > + IPsec payload Maximum Segment Size, esn structure for Extended > Sequence Number. > -- Acked-by: Anoob Joseph
Re: [dpdk-dev] [PATCH] net/mlx5: fix Windows port spawn
05/08/2021 11:55, Gregory Etelson:
> mlx5_dev_check_sibling_config() API was updated to allow newly spawned
> port locate existing sibling devices.
> PMD port initialization for Windows OS was not updated for the new
> API prototype.
> The patch fixes mlx5_dev_check_sibling_config call for Windows OS.
>
> Fixes: e9d420dfc2d0 ("net/mlx5: fix find sibling devices")
>
> Signed-off-by: Gregory Etelson
> Acked-by: Viacheslav Ovsiienko
Adding the compilation log:
drivers/net/mlx5/windows/mlx5_os.c:457:50: error:
too few arguments to function call, expected 3, have 2
err = mlx5_dev_check_sibling_config(priv, config);
Changing title to "net/mlx5: fix build on Windows"
I missed the original CI failure in patchwork, sorry.
Applied, thanks.
Re: [dpdk-dev] [WARNING: UNSCANNABLE EXTRACTION FAILED][WARNING: UNSCANNABLE EXTRACTION FAILED] [PATCH v3] doc: mtr: add API walk through
On Thu, Aug 5, 2021 at 4:36 PM Dumitrescu, Cristian wrote: > > HI Jerin, > > Thanks for your patch! > > Initially, it looked like an easy job to review it, but there is actually an > elephant in the room on how to chain the meters, see below. Yes. That's why I send this patch to finalize how to chain the meter. It was hard for me to follow that's why added a digram. > > > -Original Message- > > From: jer...@marvell.com > > Sent: Thursday, August 5, 2021 11:11 AM > > To: Dumitrescu, Cristian ; Thomas Monjalon > > ; Yigit, Ferruh ; Andrew > > Rybchenko > > Cc: dev@dpdk.org; arybche...@solarflare.com; l...@nvidia.com; > > ajit.khapa...@broadcom.com; Singh, Jasvinder > > ; ma...@nvidia.com; Jerin Jacob > > > > Subject: [WARNING: UNSCANNABLE EXTRACTION FAILED][WARNING: > > UNSCANNABLE EXTRACTION FAILED][dpdk-dev] [PATCH v3] doc: mtr: add > > API walk through > > > > From: Jerin Jacob > > > > Added a diagram to document meter library components > > and added text for steps performed by the application to > > configure the traffic meter and policing library. > > > > Signed-off-by: Jerin Jacob > > --- > > v2: Fix long lines in svg file to avoid patch apply issue > > v3: Fix all Thomas's comment at > > http://patches.dpdk.org/project/dpdk/patch/20210804113410.3604616-1- > > jer...@marvell.com/ > > > > doc/guides/prog_guide/img/meter.svg | 1600 + > > .../traffic_metering_and_policing.rst | 29 + > > lib/ethdev/rte_mtr.h |4 +- > > 3 files changed, 1631 insertions(+), 2 deletions(-) > > create mode 100644 doc/guides/prog_guide/img/meter.svg > > > > diff --git a/doc/guides/prog_guide/img/meter.svg > > b/doc/guides/prog_guide/img/meter.svg > > new file mode 100644 > > index 00..7214c5dc2b > > --- /dev/null > > +++ b/doc/guides/prog_guide/img/meter.svg > > > > Just to avoid confusion with the rte_meter API (from the lib/meter library), > may change the name to rte_mtr_meter_chaining.svg ? Will do. > > > > diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst > > b/doc/guides/prog_guide/traffic_metering_and_policing.rst > > index c0537e653c..0fe013522f 100644 > > --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst > > +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst > > @@ -20,6 +20,7 @@ The main features are: > >and RFC 4115 Two Rate Three Color Marker (trTCM) > > * Policer actions (per meter output color): recolor, drop > > * Statistics (per policer output color) > > +* Chaining the meter objects > > How about: > Chaining multiple meter objects. Ack > > > > > Configuration steps > > --- > > @@ -64,3 +65,31 @@ The processing done for each input packet hitting an > > MTR object is: > > * Statistics: The set of counters maintained for each MTR object is > >configurable and subject to the implementation support. This set includes > >the number of packets and bytes dropped or passed for each output color. > > + > > +API Walk-through > > + > > + > > +.. figure:: img/meter.* > > + > > + Meter components > > + > > +This section will introduce the reader to the critical APIs to use > > +the traffic meter and policing library. > > + > > +In general, the following steps are performed by the application to > > configure > > +the traffic meter and policing library. > > + > > +#. Application gets the meter driver capabilities using > > ``rte_mtr_capabilities_get()``. > > +#. Application identifies the profile(s) needed for metering and creates it > > with > > + ``rte_mtr_meter_profile_add()``. > > How about: > The application creates the required meter profiles by using the > rte_mtr_meter_profile_add() API function. Ack. > > > +#. Application identifies the policies needed and creates it with > > ``rte_mtr_meter_policy_add()``. > > How about: > The application creates the required meter policies by using the > rte_mtr_meter_policy_add() API function. Ack > > > +#. A meter object consists of a profile and a policy. Use above created > > objects to create > > + meter object using ``rte_mtr_create()``. Application uses > > + ``struct rte_mtr_params::meter_profile_id`` and ``struct > > rte_mtr_params::meter_policy_id`` > > + to specify the profile (created in step 2) and policy (created in step > > 3). > > It is mainly the meter object configuration that consists of a profile and a > policy, but not exactly the meter object itself. > > How about: > The application creates a meter object using the rte_mtr_create() API > function. One of the previously created meter profile and meter policy are > provided as arguments at this step. Sure. I just though to add exact struct field so that it easy for end users to know. How about your version + struct name. The application creates a meter object using the rte_mtr_create() API function. One of the previously created meter profile (`struct rte_mtr_params
Re: [dpdk-dev] [PATCH v13 4/6] dmadev: introduce DMA device library implementation
> This patch introduce DMA device library implementation which includes
> configuration and I/O with the DMA devices.
>
> Signed-off-by: Chengwen Feng
> Acked-by: Bruce Richardson
> Acked-by: Morten Brørup
> ---
> config/rte_config.h | 3 +
> lib/dmadev/meson.build | 1 +
> lib/dmadev/rte_dmadev.c | 563
> +++
> lib/dmadev/rte_dmadev.h | 118 -
> lib/dmadev/rte_dmadev_core.h | 2 +
> lib/dmadev/version.map | 1 +
> 6 files changed, 676 insertions(+), 12 deletions(-)
> create mode 100644 lib/dmadev/rte_dmadev.c
>
> diff --git a/config/rte_config.h b/config/rte_config.h
> index 590903c..331a431 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -81,6 +81,9 @@
> /* rawdev defines */
> #define RTE_RAWDEV_MAX_DEVS 64
>
> +/* dmadev defines */
> +#define RTE_DMADEV_MAX_DEVS 64
> +
> /* ip_fragmentation defines */
> #define RTE_LIBRTE_IP_FRAG_MAX_FRAG 4
> #undef RTE_LIBRTE_IP_FRAG_TBL_STAT
> diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
> index 833baf7..d2fc85e 100644
> --- a/lib/dmadev/meson.build
> +++ b/lib/dmadev/meson.build
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2021 HiSilicon Limited.
>
> +sources = files('rte_dmadev.c')
> headers = files('rte_dmadev.h')
> indirect_headers += files('rte_dmadev_core.h')
> driver_sdk_headers += files('rte_dmadev_pmd.h')
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> new file mode 100644
> index 000..b4f5498
> --- /dev/null
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -0,0 +1,563 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2021 HiSilicon Limited.
> + * Copyright(c) 2021 Intel Corporation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rte_dmadev.h"
> +#include "rte_dmadev_pmd.h"
> +
> +struct rte_dmadev rte_dmadevices[RTE_DMADEV_MAX_DEVS];
> +
> +static const char *mz_rte_dmadev_data = "rte_dmadev_data";
> +/* Shared memory between primary and secondary processes. */
> +static struct {
> + struct rte_dmadev_data data[RTE_DMADEV_MAX_DEVS];
> +} *dmadev_shared_data;
> +
> +RTE_LOG_REGISTER_DEFAULT(rte_dmadev_logtype, INFO);
> +#define RTE_DMADEV_LOG(level, ...) \
> + rte_log(RTE_LOG_ ## level, rte_dmadev_logtype, "" __VA_ARGS__)
> +
> +/* Macros to check for valid device id */
> +#define RTE_DMADEV_VALID_DEV_ID_OR_ERR_RET(dev_id, retval) do { \
> + if (!rte_dmadev_is_valid_dev(dev_id)) { \
> + RTE_DMADEV_LOG(ERR, "Invalid dev_id=%u\n", dev_id); \
> + return retval; \
> + } \
> +} while (0)
> +
> +static int
> +dmadev_check_name(const char *name)
> +{
> + size_t name_len;
> +
> + if (name == NULL) {
> + RTE_DMADEV_LOG(ERR, "Name can't be NULL\n");
> + return -EINVAL;
> + }
> +
> + name_len = strnlen(name, RTE_DMADEV_NAME_MAX_LEN);
> + if (name_len == 0) {
> + RTE_DMADEV_LOG(ERR, "Zero length DMA device
> name\n");
> + return -EINVAL;
> + }
> + if (name_len >= RTE_DMADEV_NAME_MAX_LEN) {
> + RTE_DMADEV_LOG(ERR, "DMA device name is too long\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static uint16_t
> +dmadev_find_free_dev(void)
> +{
> + uint16_t i;
> +
> + for (i = 0; i < RTE_DMADEV_MAX_DEVS; i++) {
> + if (dmadev_shared_data->data[i].dev_name[0] == '\0')
> + return i;
> + }
> +
> + return RTE_DMADEV_MAX_DEVS;
> +}
> +
> +static struct rte_dmadev*
> +dmadev_find(const char *name)
> +{
> + uint16_t i;
> +
> + for (i = 0; i < RTE_DMADEV_MAX_DEVS; i++) {
> + if ((rte_dmadevices[i].state == RTE_DMADEV_ATTACHED)
> &&
> + (!strcmp(name, rte_dmadevices[i].data->dev_name)))
> + return &rte_dmadevices[i];
> + }
> +
> + return NULL;
> +}
> +
> +static int
> +dmadev_shared_data_prepare(void)
> +{
> + const struct rte_memzone *mz;
> +
> + if (dmadev_shared_data == NULL) {
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> + /* Allocate port data and ownership shared memory.
> */
> + mz = rte_memzone_reserve(mz_rte_dmadev_data,
> + sizeof(*dmadev_shared_data),
> + rte_socket_id(), 0);
> + } else
> + mz = rte_memzone_lookup(mz_rte_dmadev_data);
> + if (mz == NULL)
> + return -ENOMEM;
> +
> + dmadev_shared_data = mz->addr;
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY)
> + memset(dmadev_shared_data->data, 0,
> +sizeof(dmadev_shared_data->data));
> +
Re: [dpdk-dev] DPDK meson build failed on Windows
On Wed, Aug 4, 2021 at 11:45 AM Dmitry Kozlyuk wrote: > > Hi again, > > This is exactly the error with 0.58 that I was talking about. Try 0.57.2. > > On Wed, Aug 4, 2021, 21:32 William Tu wrote: >> >> Hi, >> I got DPDK compiled on Windows, but suddenly I got this error when >> compiling DPDK on windows again. (And I don't know why it worked >> before...) >> [3/183] "clang" @lib/rte_eal-21.dll.rsp >> FAILED: lib/rte_eal-21.dll >> "clang" @lib/rte_eal-21.dll.rsp >> clang: error: no such file or directory: 'librte_kvargs.lib' >> >> Tested on main branch 45633c460c. >> I also tried meson 0.55.0 but still failed. Any suggestions for >> debugging or fixing it? Thanks! I tested again and now I can get meson 0.55.0 works for me. meson 0.59.0 fails consistently. William
Re: [dpdk-dev] [PATCH v13 4/6] dmadev: introduce DMA device library implementation
On 2021/8/5 20:56, Walsh, Conor wrote:
>> This patch introduce DMA device library implementation which includes
>> configuration and I/O with the DMA devices.
[snip]
>>
>> /**
>> * @warning
>> @@ -952,10 +1029,27 @@ rte_dmadev_completed(uint16_t dev_id,
>> uint16_t vchan, const uint16_t nb_cpls,
>> * status array are also set.
>> */
>
> Hi Chenwen,
>
> When completed status is called with status set to NULL the drivers will
> segfault.
> Users may have a valid use case where they pass NULL as status so it needs to
> be
> checked and handled appropriately.
> Could you handle this within dmadev similar to what I've added below?
> If added the doxygen comment will also need to be updated to specify NULL as
> a valid input.
Hi Conor,
The status must be an array pointer, so below status_tmp will not work well.
This API is slow path (vs completed API), and is designed to obtain detailed
status information, so application should pass valid status parameters.
>
> Thanks,
> Conor.
>
>> __rte_experimental
>> -uint16_t
>> +static inline uint16_t
>> rte_dmadev_completed_status(uint16_t dev_id, uint16_t vchan,
>> const uint16_t nb_cpls, uint16_t *last_idx,
>> -enum rte_dma_status_code *status);
>> +enum rte_dma_status_code *status)
>> +{
>> +struct rte_dmadev *dev = &rte_dmadevices[dev_id];
>> +uint16_t idx;
>enum rte_dma_status_code *status_tmp;
>> +
>> +#ifdef RTE_DMADEV_DEBUG
>> +if (!rte_dmadev_is_valid_dev(dev_id) ||
>> +vchan >= dev->data->dev_conf.max_vchans ||
>> +nb_cpls == 0 || status == NULL)
>> +return 0;
>> +RTE_FUNC_PTR_OR_ERR_RET(*dev->completed_status, 0);
>> +#endif
>> +
>> +if (last_idx == NULL)
>> +last_idx = &idx;
>if (status == NULL)
> status = &status_tmp;
>> +
>> +return (*dev->completed_status)(dev, vchan, nb_cpls, last_idx,
>> status);
>> +}
>>
>> #ifdef __cplusplus
>> }
>> diff --git a/lib/dmadev/rte_dmadev_core.h
>> b/lib/dmadev/rte_dmadev_core.h
>> index 599ab15..9272725 100644
>> --- a/lib/dmadev/rte_dmadev_core.h
>> +++ b/lib/dmadev/rte_dmadev_core.h
>> @@ -177,4 +177,6 @@ struct rte_dmadev {
>> uint64_t reserved[2]; /**< Reserved for future fields. */
>> } __rte_cache_aligned;
>>
>> +extern struct rte_dmadev rte_dmadevices[];
>> +
>> #endif /* _RTE_DMADEV_CORE_H_ */
>> diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
>> index 408b93c..86c5e75 100644
>> --- a/lib/dmadev/version.map
>> +++ b/lib/dmadev/version.map
>> @@ -27,6 +27,7 @@ EXPERIMENTAL {
>> INTERNAL {
>> global:
>>
>> +rte_dmadevices;
>> rte_dmadev_get_device_by_name;
>> rte_dmadev_pmd_allocate;
>> rte_dmadev_pmd_release;
>> --
>> 2.8.1
>
Re: [dpdk-dev] [PATCH v13 5/6] doc: add DMA device library guide
On 2021/8/3 22:55, Jerin Jacob wrote: > On Tue, Aug 3, 2021 at 5:03 PM Chengwen Feng wrote: >> >> This patch adds dmadev library guide. >> >> Signed-off-by: Chengwen Feng >> --- >> doc/guides/prog_guide/dmadev.rst| 126 +++ > > > doc build has following warning in my machine > > ninja: Entering directory `build' > [2789/2813] Generating html_guides with a custom command > /export/dpdk.org/doc/guides/prog_guide/dmadev.rst:24: WARNING: Figure > caption must be a paragraph or empty comment. will fix in v14 > > .. figure:: img/dmadev_i1.* > >The model of the DMA framework built on > > * The DMA controller could have multiple hardware DMA channels (aka. hardware >DMA queues), each hardware DMA channel should be represented by a dmadev. > * The dmadev could create multiple virtual DMA channels, each virtual DMA >channel represents a different transfer context. The DMA operation request >must be submitted to the virtual DMA channel. e.g. Application could create >virtual DMA channel 0 for memory-to-memory transfer scenario, and create >virtual DMA channel 1 for memory-to-device transfer scenario. > [2813/2813] Linking target app/dpdk-test-pipeline > >> new file mode 100644 >> index 000..b305beb >> --- /dev/null >> +++ b/doc/guides/prog_guide/img/dmadev_i1.svg > > why _i1 in the name? OK, maybe dmadev.svg is enough. > > >> @@ -0,0 +1,278 @@ >> + >> + > > You could add an SPDX license and your company copyright as well. > See other .svg files. OK > > > Rest looks good to me. > > >> + [snip] >> > . >
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
Hi Jan, The RIB is always used as a control plane struct intended to maintain the correct content of the dataplane struct, such as DIR24_8 for example. So it is always used on _add()/_delete(). For simplicity you can consider it as an LPM's rule_info. But instead of keeping routes in a plane array as it is in LPM, FIB uses RIB which is more suitable binary tree. On 05/08/2021 15:14, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:08:13 +0200 Vladimir Medvedkin wrote: This patch announces the experimental tag removal of all fib APIs, which have been experimental for 2 years. API will be promoted to stable in DPDK 21.11 Hi Vladimir, I have a question related to FIB. I am just learning how to use it and I found that each FIB always creates a new RIB internally. There is no doc about this topic... If I understand correctly, the underlying RIB is only used when dummy_lookup() and dummy_modify() are used. But they are only used when the configured mode is RTE_FIB_DUMMY. Is there any reason to create the RIB with RTE_FIB_DIR24_8? The issue with this is that each RIB allocates a new mempool internally which can waste quite a lot of never used memory that would be unused with DIR24_8 implementation. Regards Jan Signed-off-by: Vladimir Medvedkin --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index afb599a..58826a8 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -195,3 +195,5 @@ Deprecation Notices communicate events such as soft expiry with IPsec in lookaside mode. * rib: The ``rib`` library will be promoted from experimental to stable. + +* fib: The ``fib`` library will be promoted from experimental to stable. -- Regards, Vladimir
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, 5 Aug 2021 15:27:15 +0200 "Medvedkin, Vladimir" wrote: > Hi Jan, > > The RIB is always used as a control plane struct intended to maintain > the correct content of the dataplane struct, such as DIR24_8 for > example. So it is always used on _add()/_delete(). For simplicity you > can consider it as an LPM's rule_info. But instead of keeping routes > in a plane array as it is in LPM, FIB uses RIB which is more suitable > binary tree. OK. I thought that I can have a single RIB, use it for maintaining routes and based on this single RIB, I can build a FIB for the data plane. And when the single RIB is updated (which can take quite a lot of time) I build a new FIB and locklessly give it to the dataplane. Such approach is not considered? Jan > > > On 05/08/2021 15:14, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:08:13 +0200 > > Vladimir Medvedkin wrote: > > > >> This patch announces the experimental tag removal of all fib APIs, > >> which have been experimental for 2 years. > >> API will be promoted to stable in DPDK 21.11 > > > > Hi Vladimir, > > > > I have a question related to FIB. I am just learning how to use it > > and I found that each FIB always creates a new RIB internally. > > There is no doc about this topic... > > > > If I understand correctly, the underlying RIB is only used when > > dummy_lookup() and dummy_modify() are used. But they are only used > > when the configured mode is RTE_FIB_DUMMY. Is there any reason to > > create the RIB with RTE_FIB_DIR24_8? > > > > The issue with this is that each RIB allocates a new mempool > > internally which can waste quite a lot of never used memory that > > would be unused with DIR24_8 implementation. > > > > Regards > > Jan > > > >> > >> > >> Signed-off-by: Vladimir Medvedkin > >> --- > >> doc/guides/rel_notes/deprecation.rst | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index afb599a..58826a8 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -195,3 +195,5 @@ Deprecation Notices > >> communicate events such as soft expiry with IPsec in lookaside > >> mode. > >> * rib: The ``rib`` library will be promoted from experimental to > >> stable. + > >> +* fib: The ``fib`` library will be promoted from experimental to > >> stable. >
Re: [dpdk-dev] [PATCH v13 4/6] dmadev: introduce DMA device library implementation
On 05/08/2021 14:12, fengchengwen wrote:
On 2021/8/5 20:56, Walsh, Conor wrote:
This patch introduce DMA device library implementation which includes
configuration and I/O with the DMA devices.
[snip]
/**
* @warning
@@ -952,10 +1029,27 @@ rte_dmadev_completed(uint16_t dev_id,
uint16_t vchan, const uint16_t nb_cpls,
* status array are also set.
*/
Hi Chenwen,
When completed status is called with status set to NULL the drivers will
segfault.
Users may have a valid use case where they pass NULL as status so it needs to be
checked and handled appropriately.
Could you handle this within dmadev similar to what I've added below?
If added the doxygen comment will also need to be updated to specify NULL as a
valid input.
Hi Conor,
The status must be an array pointer, so below status_tmp will not work well.
This API is slow path (vs completed API), and is designed to obtain detailed
status information, so application should pass valid status parameters.
Thanks for your quick reply.
That is true that it is designed to be slower and return detailed status
info but should we not handle it more gracefully than segfaulting.
I don't have too strong of an opinion either way so it's ok to ignore.
/Conor.
Thanks,
Conor.
__rte_experimental
-uint16_t
+static inline uint16_t
rte_dmadev_completed_status(uint16_t dev_id, uint16_t vchan,
const uint16_t nb_cpls, uint16_t *last_idx,
- enum rte_dma_status_code *status);
+ enum rte_dma_status_code *status)
+{
+ struct rte_dmadev *dev = &rte_dmadevices[dev_id];
+ uint16_t idx;
enum rte_dma_status_code *status_tmp;
+
+#ifdef RTE_DMADEV_DEBUG
+ if (!rte_dmadev_is_valid_dev(dev_id) ||
+ vchan >= dev->data->dev_conf.max_vchans ||
+ nb_cpls == 0 || status == NULL)
+ return 0;
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->completed_status, 0);
+#endif
+
+ if (last_idx == NULL)
+ last_idx = &idx;
if (status == NULL)
status = &status_tmp;
+
+ return (*dev->completed_status)(dev, vchan, nb_cpls, last_idx,
status);
+}
#ifdef __cplusplus
}
diff --git a/lib/dmadev/rte_dmadev_core.h
b/lib/dmadev/rte_dmadev_core.h
index 599ab15..9272725 100644
--- a/lib/dmadev/rte_dmadev_core.h
+++ b/lib/dmadev/rte_dmadev_core.h
@@ -177,4 +177,6 @@ struct rte_dmadev {
uint64_t reserved[2]; /**< Reserved for future fields. */
} __rte_cache_aligned;
+extern struct rte_dmadev rte_dmadevices[];
+
#endif /* _RTE_DMADEV_CORE_H_ */
diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
index 408b93c..86c5e75 100644
--- a/lib/dmadev/version.map
+++ b/lib/dmadev/version.map
@@ -27,6 +27,7 @@ EXPERIMENTAL {
INTERNAL {
global:
+ rte_dmadevices;
rte_dmadev_get_device_by_name;
rte_dmadev_pmd_allocate;
rte_dmadev_pmd_release;
--
2.8.1
Re: [dpdk-dev] [PATCH] doc: announce change in crypto raw data vector
Hi Hemant, > -Original Message- > From: Hemant Agrawal > Sent: Thursday, August 5, 2021 9:06 AM > To: dev@dpdk.org; gak...@marvell.com > Cc: ano...@marvell.com; Nicolau, Radu ; Doherty, > Declan ; ma...@nvidia.com; Ananyev, > Konstantin ; tho...@monjalon.net; Zhang, > Roy Fan ; asoma...@amd.com; > ruifeng.w...@arm.com; ajit.khapa...@broadcom.com; De Lara Guarch, > Pablo ; Trahe, Fiona > ; adwiv...@marvell.com; > jianjay.z...@huawei.com; Gagandeep Singh > Subject: [PATCH] doc: announce change in crypto raw data vector > > The current crypto raw data vectors need to be extended to support > out of place processing. It is proposed to add additional desl_sgl > to provide details for destination sgl. > The same is also extended to support rte_security usecases, where > we need total data length to know how much additional memory space > is available in buffer other than data length so that driver/HW > can write expanded size data after encryption. > > Signed-off-by: Gagandeep Singh > Signed-off-by: Hemant Agrawal > --- > doc/guides/rel_notes/deprecation.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f4a4d00db2..c19a306c93 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -193,3 +193,15 @@ Deprecation Notices >reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other >information from the crypto/security operation. This field will be used to >communicate events such as soft expiry with IPsec in lookaside mode. > + > +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to > add > + ``dest_sgl`` to support out of place processing. This field will be null > for > + inplace processing. This change is targeted for DPDK 21.11 > + > +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add > + ``tot_len`` to support total buffer length. This is required for security > + cases like IPsec and PDCP encryption offload to know how much additional > + memory space is available in buffer other than data length so that > driver/HW > + can write expanded size data after encryption. This change is targeted for > + DPDK 21.11 > + > -- > 2.17.1 To add ``dest_sgl`` to ``rte_crypto_sym_vec`` I suppose it is better to rename ``sgl`` to ``src_sgl`` in this deprecating notice too? Regards, Fan
Re: [dpdk-dev] [PATCH] doc: announce change in crypto raw data vector
> > -Original Message- > > From: Hemant Agrawal > > Sent: Thursday, August 5, 2021 9:06 AM > > To: dev@dpdk.org; gak...@marvell.com > > Cc: ano...@marvell.com; Nicolau, Radu ; > > Doherty, Declan ; ma...@nvidia.com; > Ananyev, > > Konstantin ; tho...@monjalon.net; > Zhang, > > Roy Fan ; asoma...@amd.com; > > ruifeng.w...@arm.com; ajit.khapa...@broadcom.com; De Lara Guarch, > > Pablo ; Trahe, Fiona > > ; adwiv...@marvell.com; > > jianjay.z...@huawei.com; Gagandeep Singh > > Subject: [PATCH] doc: announce change in crypto raw data vector > > > > The current crypto raw data vectors need to be extended to support out > > of place processing. It is proposed to add additional desl_sgl to > > provide details for destination sgl. > > The same is also extended to support rte_security usecases, where we > > need total data length to know how much additional memory space is > > available in buffer other than data length so that driver/HW can write > > expanded size data after encryption. > > > > Signed-off-by: Gagandeep Singh > > Signed-off-by: Hemant Agrawal > > --- > > doc/guides/rel_notes/deprecation.rst | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index f4a4d00db2..c19a306c93 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -193,3 +193,15 @@ Deprecation Notices > >reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and > other > >information from the crypto/security operation. This field will be used > > to > >communicate events such as soft expiry with IPsec in lookaside mode. > > + > > +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to > > add > > + ``dest_sgl`` to support out of place processing. This field will be > > + null for inplace processing. This change is targeted for DPDK 21.11 > > + > > +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add > > + ``tot_len`` to support total buffer length. This is required for > > +security > > + cases like IPsec and PDCP encryption offload to know how much > > +additional > > + memory space is available in buffer other than data length so that > > driver/HW > > + can write expanded size data after encryption. This change is > > + targeted for DPDK 21.11 > > + > > -- > > 2.17.1 > > To add ``dest_sgl`` to ``rte_crypto_sym_vec`` I suppose it is better to rename > ``sgl`` to ``src_sgl`` in this deprecating notice too? [Hemant] I was just trying to minimize the changes. But it can be done. > > Regards, > Fan
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
> This patch announces the experimental tag removal of all fib APIs, > which have been experimental for 2 years. > API will be promoted to stable in DPDK 21.11 > > Signed-off-by: Vladimir Medvedkin > --- > doc/guides/rel_notes/deprecation.rst | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Conor Walsh
Re: [dpdk-dev] [PATCH] maintainers: update for net mlx4/mlx5
From: Slava Ovsiienko > From: Shahaf Shuler > > For net/mlx4: > - removing Shahaf Shuler > - add Viacheslav Ovsiienko > > For net/mlx5: > - removing Shahaf Shuler > > Signed-off-by: Viacheslav Ovsiienko Acked-by: Matan Azrad > --- > MAINTAINERS | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 266f5ac1da..20e76ab9f8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -798,7 +798,7 @@ F: doc/guides/nics/octeontx_ep.rst > > Mellanox mlx4 > M: Matan Azrad > -M: Shahaf Shuler > +M: Viacheslav Ovsiienko > T: git://dpdk.org/next/dpdk-next-net-mlx > F: drivers/net/mlx4/ > F: doc/guides/nics/mlx4.rst > @@ -806,7 +806,6 @@ F: doc/guides/nics/features/mlx4.ini > > Mellanox mlx5 > M: Matan Azrad > -M: Shahaf Shuler > M: Viacheslav Ovsiienko > T: git://dpdk.org/next/dpdk-next-net-mlx > F: drivers/common/mlx5/ > -- > 2.18.1
[dpdk-dev] [PATCH] net/mlx5: fix Windows port spawn
mlx5_dev_check_sibling_config() API was updated to allow newly spawned
port locate existing sibling devices.
PMD port initialization for Windows OS was not updated for the new
API prototype.
The patch fixes mlx5_dev_check_sibling_config call for Windows OS.
Fixes: e9d420dfc2d0 ("net/mlx5: fix find sibling devices")
Signed-off-by: Gregory Etelson
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/windows/mlx5_os.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/windows/mlx5_os.c
b/drivers/net/mlx5/windows/mlx5_os.c
index 5518bc3e76..7e1df1c751 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -454,7 +454,7 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
}
/* Override some values set by hardware configuration. */
mlx5_args(config, dpdk_dev->devargs);
- err = mlx5_dev_check_sibling_config(priv, config);
+ err = mlx5_dev_check_sibling_config(priv, config, dpdk_dev);
if (err)
goto error;
DRV_LOG(DEBUG, "counters are not supported");
--
2.32.0
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On 05/08/2021 15:32, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:27:15 +0200 "Medvedkin, Vladimir" wrote: Hi Jan, The RIB is always used as a control plane struct intended to maintain the correct content of the dataplane struct, such as DIR24_8 for example. So it is always used on _add()/_delete(). For simplicity you can consider it as an LPM's rule_info. But instead of keeping routes in a plane array as it is in LPM, FIB uses RIB which is more suitable binary tree. OK. I thought that I can have a single RIB, use it for maintaining routes and based on this single RIB, I can build a FIB for the data plane. And when the single RIB is updated (which can take quite a lot of time) I build a new FIB and locklessly give it to the dataplane. Such approach is not considered? Jan I'm not sure I understood completely your use case. Do you want to rebuild the entire FIB from scratch every time the RIB changes? On 05/08/2021 15:14, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:08:13 +0200 Vladimir Medvedkin wrote: This patch announces the experimental tag removal of all fib APIs, which have been experimental for 2 years. API will be promoted to stable in DPDK 21.11 Hi Vladimir, I have a question related to FIB. I am just learning how to use it and I found that each FIB always creates a new RIB internally. There is no doc about this topic... If I understand correctly, the underlying RIB is only used when dummy_lookup() and dummy_modify() are used. But they are only used when the configured mode is RTE_FIB_DUMMY. Is there any reason to create the RIB with RTE_FIB_DIR24_8? The issue with this is that each RIB allocates a new mempool internally which can waste quite a lot of never used memory that would be unused with DIR24_8 implementation. Regards Jan Signed-off-by: Vladimir Medvedkin --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index afb599a..58826a8 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -195,3 +195,5 @@ Deprecation Notices communicate events such as soft expiry with IPsec in lookaside mode. * rib: The ``rib`` library will be promoted from experimental to stable. + +* fib: The ``fib`` library will be promoted from experimental to stable. -- Regards, Vladimir
Re: [dpdk-dev] [PATCH v2] doc: announce restructuring of crypto session structs
Hi Akhil, > -Original Message- > From: Akhil Goyal > Sent: Tuesday, August 3, 2021 1:01 PM > To: dev@dpdk.org > Cc: ano...@marvell.com; Nicolau, Radu ; Doherty, > Declan ; hemant.agra...@nxp.com; > ma...@nvidia.com; Ananyev, Konstantin ; > tho...@monjalon.net; Zhang, Roy Fan ; > asoma...@amd.com; ruifeng.w...@arm.com; > ajit.khapa...@broadcom.com; De Lara Guarch, Pablo > ; Trahe, Fiona ; > adwiv...@marvell.com; michae...@marvell.com; > rnagadhee...@marvell.com; jianjay.z...@huawei.com; Akhil Goyal > > Subject: [PATCH v2] doc: announce restructuring of crypto session structs > > The structures rte_cryptodev_sym_session and > rte_cryptodev_asym_session are not used by the > application directly. The application just need > an opaque pointer which it can attach to rte_crypto_op > while enqueue. > Hence, these structures can be internal to library > hidden from the user. > > Signed-off-by: Akhil Goyal > --- > v2: fixed trailing whitespace. > > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f81bd87f10..c540c90f8e 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -151,6 +151,11 @@ Deprecation Notices > * cryptodev: The APIs for interfacing between library and PMD will be > marked >as internal APIs in DPDK 21.11. > > +* cryptodev: Hide structures ``rte_cryptodev_sym_session`` and > + ``rte_cryptodev_asym_session`` to remove unnecessary indirection > between > + session and the private data of session. An opaque pointer can be exposed > + directly to application which can be attached to the ``rte_crypto_op``. > + > * security: The functions ``rte_security_set_pkt_metadata`` and >``rte_security_get_userdata`` will be made inline functions and additional >flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. > -- > 2.25.1 Have you considered how crypto scheduler PMD can support multiple crypto devices' opaque data pointers after the change? Of course it is doable by adding dedicated APIs to the scheduler PMD - shall I assume you will work on it? Regards, Fan
[dpdk-dev] [PATCH v2] doc: announce change in crypto raw data vector
The current crypto raw data vectors need to be extended to support out of place processing. It is proposed to add additional desl_sgl to provide details for destination sgl. The same is also extended to support rte_security usecases, where we need total data length to know how much additional memory space is available in buffer other than data length so that driver/HW can write expanded size data after encryption. Signed-off-by: Gagandeep Singh Signed-off-by: Hemant Agrawal --- doc/guides/rel_notes/deprecation.rst | 12 1 file changed, 12 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index f4a4d00db2..c19a306c93 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -193,3 +193,15 @@ Deprecation Notices reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other information from the crypto/security operation. This field will be used to communicate events such as soft expiry with IPsec in lookaside mode. + +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add + ``dest_sgl`` to support out of place processing. This field will be null for + inplace processing. This change is targeted for DPDK 21.11 + +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add + ``tot_len`` to support total buffer length. This is required for security + cases like IPsec and PDCP encryption offload to know how much additional + memory space is available in buffer other than data length so that driver/HW + can write expanded size data after encryption. This change is targeted for + DPDK 21.11 + -- 2.17.1
Re: [dpdk-dev] [EXT] [PATCH v2] doc: announce change in crypto raw data vector
> The current crypto raw data vectors need to be extended to support > out of place processing. It is proposed to add additional desl_sgl > to provide details for destination sgl. > The same is also extended to support rte_security usecases, where > we need total data length to know how much additional memory space > is available in buffer other than data length so that driver/HW > can write expanded size data after encryption. > > Signed-off-by: Gagandeep Singh > Signed-off-by: Hemant Agrawal > --- > doc/guides/rel_notes/deprecation.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f4a4d00db2..c19a306c93 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -193,3 +193,15 @@ Deprecation Notices >reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other >information from the crypto/security operation. This field will be used to >communicate events such as soft expiry with IPsec in lookaside mode. > + > +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add > + ``dest_sgl`` to support out of place processing. This field will be null > for > + inplace processing. This change is targeted for DPDK 21.11 > + > +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add > + ``tot_len`` to support total buffer length. This is required for security > + cases like IPsec and PDCP encryption offload to know how much additional > + memory space is available in buffer other than data length so that > driver/HW > + can write expanded size data after encryption. This change is targeted for > + DPDK 21.11 > + Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, 5 Aug 2021 15:57:14 +0200 "Medvedkin, Vladimir" wrote: > On 05/08/2021 15:32, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:27:15 +0200 > > "Medvedkin, Vladimir" wrote: > > > >> Hi Jan, > >> > >> The RIB is always used as a control plane struct intended to > >> maintain the correct content of the dataplane struct, such as > >> DIR24_8 for example. So it is always used on _add()/_delete(). For > >> simplicity you can consider it as an LPM's rule_info. But instead > >> of keeping routes in a plane array as it is in LPM, FIB uses RIB > >> which is more suitable binary tree. > > > > OK. I thought that I can have a single RIB, use it for maintaining > > routes and based on this single RIB, I can build a FIB for the data > > plane. And when the single RIB is updated (which can take quite a > > lot of time) I build a new FIB and locklessly give it to the > > dataplane. Such approach is not considered? > > > > Jan > > > > I'm not sure I understood completely your use case. Do you want to > rebuild the entire FIB from scratch every time the RIB changes? The idea was to maintain a single RIB and two FIBs. One FIB is active and under heavy load and when a route change arrives, it is first written to RIB. When RIB is ready, it is used to quickly construct/update the second inactive FIB. Then I swap with the current active FIB. The old one can be edited/updated/recreated and new one is active. I've got one place where all routes are placed (RIB). And two FIBs that contain only routes that are relevant. (Well, yes, not all routes in RIB might be relevant, this depends on other conditions.) Jan > > >> > >> > >> On 05/08/2021 15:14, Jan Viktorin wrote: > >>> On Thu, 5 Aug 2021 15:08:13 +0200 > >>> Vladimir Medvedkin wrote: > >>> > This patch announces the experimental tag removal of all fib > APIs, which have been experimental for 2 years. > API will be promoted to stable in DPDK 21.11 > >>> > >>> Hi Vladimir, > >>> > >>> I have a question related to FIB. I am just learning how to use it > >>> and I found that each FIB always creates a new RIB internally. > >>> There is no doc about this topic... > >>> > >>> If I understand correctly, the underlying RIB is only used when > >>> dummy_lookup() and dummy_modify() are used. But they are only used > >>> when the configured mode is RTE_FIB_DUMMY. Is there any reason to > >>> create the RIB with RTE_FIB_DIR24_8? > >>> > >>> The issue with this is that each RIB allocates a new mempool > >>> internally which can waste quite a lot of never used memory that > >>> would be unused with DIR24_8 implementation. > >>> > >>> Regards > >>> Jan > >>> > > > Signed-off-by: Vladimir Medvedkin > --- > doc/guides/rel_notes/deprecation.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index afb599a..58826a8 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -195,3 +195,5 @@ Deprecation Notices > communicate events such as soft expiry with IPsec in > lookaside mode. > * rib: The ``rib`` library will be promoted from experimental > to stable. + > +* fib: The ``fib`` library will be promoted from experimental to > stable. > >> > > >
Re: [dpdk-dev] [PATCH v2] doc: announce restructuring of crypto session structs
Hi Fan, > Hi Akhil, > > > The structures rte_cryptodev_sym_session and > > rte_cryptodev_asym_session are not used by the > > application directly. The application just need > > an opaque pointer which it can attach to rte_crypto_op > > while enqueue. > > Hence, these structures can be internal to library > > hidden from the user. > > > > Signed-off-by: Akhil Goyal > > --- > > v2: fixed trailing whitespace. > > > > doc/guides/rel_notes/deprecation.rst | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index f81bd87f10..c540c90f8e 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -151,6 +151,11 @@ Deprecation Notices > > * cryptodev: The APIs for interfacing between library and PMD will be > > marked > >as internal APIs in DPDK 21.11. > > > > +* cryptodev: Hide structures ``rte_cryptodev_sym_session`` and > > + ``rte_cryptodev_asym_session`` to remove unnecessary indirection > > between > > + session and the private data of session. An opaque pointer can be > exposed > > + directly to application which can be attached to the ``rte_crypto_op``. > > + > > * security: The functions ``rte_security_set_pkt_metadata`` and > >``rte_security_get_userdata`` will be made inline functions and > > additional > >flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. > > -- > > 2.25.1 > > Have you considered how crypto scheduler PMD can support multiple crypto > devices' opaque data pointers after the change? Of course it is doable by > adding dedicated APIs to the scheduler PMD - shall I assume you will work on > it? I haven't considered about the scheduler PMD yet. Would need your help in aligning that. The deprecation notice is to allow us change in 21.11 timeframe. Thanks, Akhil
[dpdk-dev] [PATCH] eal/windows: add sys/queue.h.
When compiling OVS, lib/dpdk.c, found the missing header.
In file included from ../lib/dpdk.c:27:
C:\temp\dpdk\include\rte_log.h:24:10: fatal error: 'sys/queue.h' file
not found
^
1 warning and 1 error generated.
Signed-off-by: William Tu
---
lib/eal/windows/include/meson.build | 4
lib/eal/windows/include/sys/meson.build | 6 ++
2 files changed, 10 insertions(+)
create mode 100644 lib/eal/windows/include/sys/meson.build
diff --git a/lib/eal/windows/include/meson.build
b/lib/eal/windows/include/meson.build
index b3534b025f..875cc1cf0d 100644
--- a/lib/eal/windows/include/meson.build
+++ b/lib/eal/windows/include/meson.build
@@ -8,3 +8,7 @@ headers += files(
'rte_virt2phys.h',
'rte_windows.h',
)
+
+sys_headers = []
+subdir('sys')
+install_headers(sys_headers, subdir: 'sys')
diff --git a/lib/eal/windows/include/sys/meson.build
b/lib/eal/windows/include/sys/meson.build
new file mode 100644
index 00..6896cbf678
--- /dev/null
+++ b/lib/eal/windows/include/sys/meson.build
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2021 VMware, Inc
+
+sys_headers += files(
+'queue.h',
+)
--
2.32.0.windows.2
Re: [dpdk-dev] [PATCH v2] doc: announce changes to eventdev library
03/08/2021 06:12, Jerin Jacob: > On Tue, Aug 3, 2021 at 2:46 AM wrote: > > > > From: Pavan Nikhilesh > > > > Make driver layer as internal, remove unnecessary rte_ prefix for > > structures and functions that are not a part of public API. > > Promote experimental trace and vector APIs to stable. > > Add reserved field to `rte_event_timer` structure. > > > > Signed-off-by: Pavan Nikhilesh > > Acked-by: Jerin Jacob > > > ++ Eventdev driver Maintainers. > > This list is based on items identified for 21.11 ABI improvement at > https://docs.google.com/spreadsheets/d/1betlC000ua5SsSiJIcC54mCCCJnW6voH5Dqv9UxeyfE/edit#gid=0 Acked-by: Hemant Agrawal Acked-by: Mattias Rönnblom Acked-by: Jay Jayatheerthan Acked-by: Abhinandan Gujjar > > +* eventdev: The file ``rte_eventdev_pmd.h`` will be renamed to > > ``eventdev_driver.h`` > > + to make the driver interface as internal and the structures > > ``rte_eventdev_data``, > > + ``rte_eventdev`` and ``rte_eventdevs`` will be moved to a new file named > > + ``rte_eventdev_core.h`` in DPDK 21.11. > > + The ``rte_`` prefix for internal structures and functions will be > > removed across the > > + library. If a function is used outside of the library (in drivers), it is better to keep rte_ prefix to avoid possible clash with some driver dependencies. > > + The experimental eventdev trace APIs and > > ``rte_event_vector_pool_create``, > > + ``rte_event_eth_rx_adapter_vector_limits_get`` will be promoted to > > stable. > > + An 8byte reserved field will be added to the structure > > ``rte_event_timer`` to > > + support future extensions. Applied, thanks.
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On 05/08/2021 16:07, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:57:14 +0200 "Medvedkin, Vladimir" wrote: On 05/08/2021 15:32, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:27:15 +0200 "Medvedkin, Vladimir" wrote: Hi Jan, The RIB is always used as a control plane struct intended to maintain the correct content of the dataplane struct, such as DIR24_8 for example. So it is always used on _add()/_delete(). For simplicity you can consider it as an LPM's rule_info. But instead of keeping routes in a plane array as it is in LPM, FIB uses RIB which is more suitable binary tree. OK. I thought that I can have a single RIB, use it for maintaining routes and based on this single RIB, I can build a FIB for the data plane. And when the single RIB is updated (which can take quite a lot of time) I build a new FIB and locklessly give it to the dataplane. Such approach is not considered? Jan I'm not sure I understood completely your use case. Do you want to rebuild the entire FIB from scratch every time the RIB changes? The idea was to maintain a single RIB and two FIBs. One FIB is active and under heavy load and when a route change arrives, it is first written to RIB. When RIB is ready, it is used to quickly construct/update the second inactive FIB. Then I swap with the current active FIB. The old one can be edited/updated/recreated and new one is active. I've got one place where all routes are placed (RIB). And two FIBs that contain only routes that are relevant. (Well, yes, not all routes in RIB might be relevant, this depends on other conditions.) Jan This technique is used for data structures that do not support incremental updates. However FIB supports incremental updates. You can keep a separate rib struct and reflect changes to the fib. Also, using rte_fib_get_rib() you can get the corresponding RIB struct and work with it directly using rib API. However you need to be cautious, all adding/deletion and next hop changing must be done using fib API. On 05/08/2021 15:14, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:08:13 +0200 Vladimir Medvedkin wrote: This patch announces the experimental tag removal of all fib APIs, which have been experimental for 2 years. API will be promoted to stable in DPDK 21.11 Hi Vladimir, I have a question related to FIB. I am just learning how to use it and I found that each FIB always creates a new RIB internally. There is no doc about this topic... If I understand correctly, the underlying RIB is only used when dummy_lookup() and dummy_modify() are used. But they are only used when the configured mode is RTE_FIB_DUMMY. Is there any reason to create the RIB with RTE_FIB_DIR24_8? The issue with this is that each RIB allocates a new mempool internally which can waste quite a lot of never used memory that would be unused with DIR24_8 implementation. Regards Jan Signed-off-by: Vladimir Medvedkin --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index afb599a..58826a8 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -195,3 +195,5 @@ Deprecation Notices communicate events such as soft expiry with IPsec in lookaside mode. * rib: The ``rib`` library will be promoted from experimental to stable. + +* fib: The ``fib`` library will be promoted from experimental to stable. -- Regards, Vladimir
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, 5 Aug 2021 16:29:50 +0200 "Medvedkin, Vladimir" wrote: > On 05/08/2021 16:07, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:57:14 +0200 > > "Medvedkin, Vladimir" wrote: > > > >> On 05/08/2021 15:32, Jan Viktorin wrote: > >>> On Thu, 5 Aug 2021 15:27:15 +0200 > >>> "Medvedkin, Vladimir" wrote: > >>> > Hi Jan, > > The RIB is always used as a control plane struct intended to > maintain the correct content of the dataplane struct, such as > DIR24_8 for example. So it is always used on _add()/_delete(). > For simplicity you can consider it as an LPM's rule_info. But > instead of keeping routes in a plane array as it is in LPM, FIB > uses RIB which is more suitable binary tree. > >>> > >>> OK. I thought that I can have a single RIB, use it for maintaining > >>> routes and based on this single RIB, I can build a FIB for the > >>> data plane. And when the single RIB is updated (which can take > >>> quite a lot of time) I build a new FIB and locklessly give it to > >>> the dataplane. Such approach is not considered? > >>> > >>> Jan > >>> > >> > >> I'm not sure I understood completely your use case. Do you want to > >> rebuild the entire FIB from scratch every time the RIB changes? > > > > The idea was to maintain a single RIB and two FIBs. One FIB is > > active and under heavy load and when a route change arrives, it is > > first written to RIB. When RIB is ready, it is used to quickly > > construct/update the second inactive FIB. Then I swap with the > > current active FIB. The old one can be edited/updated/recreated and > > new one is active. > > > > I've got one place where all routes are placed (RIB). And two FIBs > > that contain only routes that are relevant. (Well, yes, not all > > routes in RIB might be relevant, this depends on other conditions.) > > > > Jan > > > > This technique is used for data structures that do not support > incremental updates. However FIB supports incremental updates. > > You can keep a separate rib struct and reflect changes to the fib. But reflecting the changes is sometimes really more difficult than just rebuilding from scratch. > > Also, using rte_fib_get_rib() you can get the corresponding RIB > struct and work with it directly using rib API. However you need to But than I've got two RIBs that I have to keep in sync with each other which is quite difficult. > be cautious, all adding/deletion and next hop changing must be done > using fib API. Because, otherwise the DIR24_8 is not in sync, right? Jan > > >> > > > On 05/08/2021 15:14, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:08:13 +0200 > > Vladimir Medvedkin wrote: > > > >> This patch announces the experimental tag removal of all fib > >> APIs, which have been experimental for 2 years. > >> API will be promoted to stable in DPDK 21.11 > > > > Hi Vladimir, > > > > I have a question related to FIB. I am just learning how to use > > it and I found that each FIB always creates a new RIB > > internally. There is no doc about this topic... > > > > If I understand correctly, the underlying RIB is only used when > > dummy_lookup() and dummy_modify() are used. But they are only > > used when the configured mode is RTE_FIB_DUMMY. Is there any > > reason to create the RIB with RTE_FIB_DIR24_8? > > > > The issue with this is that each RIB allocates a new mempool > > internally which can waste quite a lot of never used memory that > > would be unused with DIR24_8 implementation. > > > > Regards > > Jan > > > >> > >> > >> Signed-off-by: Vladimir Medvedkin > >> --- > >> doc/guides/rel_notes/deprecation.rst | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index afb599a..58826a8 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -195,3 +195,5 @@ Deprecation Notices > >> communicate events such as soft expiry with IPsec in > >> lookaside mode. > >> * rib: The ``rib`` library will be promoted from > >> experimental to stable. + > >> +* fib: The ``fib`` library will be promoted from experimental > >> to stable. > > >>> > >> > > >
[dpdk-dev] [PATCH] eal/windows: expose symbol rte_version
When OVS inits, it calls rte_version to get the DPDK's version.
The patch fixes the error below by exposing rte_version symbol.
libopenvswitch.a(dpdk.c.obj) : error LNK2019: unresolved external symbol
rte_version referenced in function dpdk_init
Signed-off-by: William Tu
---
lib/eal/version.map | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/eal/version.map b/lib/eal/version.map
index 887012d02a..3de59910cd 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -198,7 +198,7 @@ DPDK_21 {
rte_uuid_is_null; # WINDOWS_NO_EXPORT
rte_uuid_parse; # WINDOWS_NO_EXPORT
rte_uuid_unparse; # WINDOWS_NO_EXPORT
- rte_version; # WINDOWS_NO_EXPORT
+ rte_version;
rte_vfio_clear_group; # WINDOWS_NO_EXPORT
rte_vfio_container_create; # WINDOWS_NO_EXPORT
rte_vfio_container_destroy; # WINDOWS_NO_EXPORT
--
2.32.0.windows.2
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On 05/08/2021 16:34, Jan Viktorin wrote: On Thu, 5 Aug 2021 16:29:50 +0200 "Medvedkin, Vladimir" wrote: On 05/08/2021 16:07, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:57:14 +0200 "Medvedkin, Vladimir" wrote: On 05/08/2021 15:32, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:27:15 +0200 "Medvedkin, Vladimir" wrote: Hi Jan, The RIB is always used as a control plane struct intended to maintain the correct content of the dataplane struct, such as DIR24_8 for example. So it is always used on _add()/_delete(). For simplicity you can consider it as an LPM's rule_info. But instead of keeping routes in a plane array as it is in LPM, FIB uses RIB which is more suitable binary tree. OK. I thought that I can have a single RIB, use it for maintaining routes and based on this single RIB, I can build a FIB for the data plane. And when the single RIB is updated (which can take quite a lot of time) I build a new FIB and locklessly give it to the dataplane. Such approach is not considered? Jan I'm not sure I understood completely your use case. Do you want to rebuild the entire FIB from scratch every time the RIB changes? The idea was to maintain a single RIB and two FIBs. One FIB is active and under heavy load and when a route change arrives, it is first written to RIB. When RIB is ready, it is used to quickly construct/update the second inactive FIB. Then I swap with the current active FIB. The old one can be edited/updated/recreated and new one is active. I've got one place where all routes are placed (RIB). And two FIBs that contain only routes that are relevant. (Well, yes, not all routes in RIB might be relevant, this depends on other conditions.) Jan This technique is used for data structures that do not support incremental updates. However FIB supports incremental updates. You can keep a separate rib struct and reflect changes to the fib. But reflecting the changes is sometimes really more difficult than just rebuilding from scratch. Why? Could you provide an example? Also, using rte_fib_get_rib() you can get the corresponding RIB struct and work with it directly using rib API. However you need to But than I've got two RIBs that I have to keep in sync with each other which is quite difficult. In this case you'll only have a single rib embedded into the fib be cautious, all adding/deletion and next hop changing must be done using fib API. Because, otherwise the DIR24_8 is not in sync, right? Yes Jan On 05/08/2021 15:14, Jan Viktorin wrote: On Thu, 5 Aug 2021 15:08:13 +0200 Vladimir Medvedkin wrote: This patch announces the experimental tag removal of all fib APIs, which have been experimental for 2 years. API will be promoted to stable in DPDK 21.11 Hi Vladimir, I have a question related to FIB. I am just learning how to use it and I found that each FIB always creates a new RIB internally. There is no doc about this topic... If I understand correctly, the underlying RIB is only used when dummy_lookup() and dummy_modify() are used. But they are only used when the configured mode is RTE_FIB_DUMMY. Is there any reason to create the RIB with RTE_FIB_DIR24_8? The issue with this is that each RIB allocates a new mempool internally which can waste quite a lot of never used memory that would be unused with DIR24_8 implementation. Regards Jan Signed-off-by: Vladimir Medvedkin --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index afb599a..58826a8 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -195,3 +195,5 @@ Deprecation Notices communicate events such as soft expiry with IPsec in lookaside mode. * rib: The ``rib`` library will be promoted from experimental to stable. + +* fib: The ``fib`` library will be promoted from experimental to stable. -- Regards, Vladimir
Re: [dpdk-dev] [PATCH v2] doc: announce restructuring of crypto session structs
Hi Akhil, No problem. Glad to help. If you have code ready to share please let me know. Regards, Fan > -Original Message- > From: Akhil Goyal > Sent: Thursday, August 5, 2021 3:10 PM > To: Zhang, Roy Fan ; dev@dpdk.org > Cc: Anoob Joseph ; Nicolau, Radu > ; Doherty, Declan ; > hemant.agra...@nxp.com; ma...@nvidia.com; Ananyev, Konstantin > ; tho...@monjalon.net; > asoma...@amd.com; ruifeng.w...@arm.com; > ajit.khapa...@broadcom.com; De Lara Guarch, Pablo > ; Trahe, Fiona ; > Ankur Dwivedi ; Michael Shamis > ; Nagadheeraj Rottela > ; jianjay.z...@huawei.com > Subject: RE: [PATCH v2] doc: announce restructuring of crypto session structs > > Hi Fan, > > Hi Akhil, > > > > > The structures rte_cryptodev_sym_session and > > > rte_cryptodev_asym_session are not used by the > > > application directly. The application just need > > > an opaque pointer which it can attach to rte_crypto_op > > > while enqueue. > > > Hence, these structures can be internal to library > > > hidden from the user. > > > > > > Signed-off-by: Akhil Goyal > > > --- > > > v2: fixed trailing whitespace. > > > > > > doc/guides/rel_notes/deprecation.rst | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > b/doc/guides/rel_notes/deprecation.rst > > > index f81bd87f10..c540c90f8e 100644 > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > @@ -151,6 +151,11 @@ Deprecation Notices > > > * cryptodev: The APIs for interfacing between library and PMD will be > > > marked > > >as internal APIs in DPDK 21.11. > > > > > > +* cryptodev: Hide structures ``rte_cryptodev_sym_session`` and > > > + ``rte_cryptodev_asym_session`` to remove unnecessary indirection > > > between > > > + session and the private data of session. An opaque pointer can be > > exposed > > > + directly to application which can be attached to the ``rte_crypto_op``. > > > + > > > * security: The functions ``rte_security_set_pkt_metadata`` and > > >``rte_security_get_userdata`` will be made inline functions and > additional > > >flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. > > > -- > > > 2.25.1 > > > > Have you considered how crypto scheduler PMD can support multiple > crypto > > devices' opaque data pointers after the change? Of course it is doable by > > adding dedicated APIs to the scheduler PMD - shall I assume you will work > on > > it? > > I haven't considered about the scheduler PMD yet. Would need your help in > aligning that. > The deprecation notice is to allow us change in 21.11 timeframe. > > Thanks, > Akhil
[dpdk-dev] [Bug 780] Phoenix American Financial Services
https://bugs.dpdk.org/show_bug.cgi?id=780 Bug ID: 780 Summary: Phoenix American Financial Services Product: DPDK Version: 21.08 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: robertleemax...@gmail.com Target Milestone: --- Phoenix American Financial Services provides leading-edge fund administration, accounting and technology for the alternative assets industry. Visit site: https://www.phxa.com/fund-accounting/ -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v2] doc: announce restructuring of crypto session structs
> Hi Akhil, > > No problem. Glad to help. If you have code ready to share please let me > know. > I haven't started work on this yet. There are a few items in ABI improvements, If you could pick some of them, it would be helpful. I am currently working on PMD interface. - Security and crypto session structs are next inline. If you can spend some time, you could work on rte_cryptodev and rte_cryptodev_data split and hide.
Re: [dpdk-dev] [PATCH] net: announce changes in TCP header
Nobody rejected this change but there is not enough ack to make it an accepted announce of change. 02/08/2021 12:42, Gregory Etelson: > Announce change to add a union that will provide byte and bitfield > access to TCP flags. > > Signed-off-by: Gregory Etelson > --- > +* net: structure ``rte_tcp_hdr`` will have a union that will provide > + byte access to existing ``tcp_flags`` and add a bitfield for TCP flags.
[dpdk-dev] [Bug 780] Phoenix American Financial Services
https://bugs.dpdk.org/show_bug.cgi?id=780 Ajit Khaparde (ajit.khapa...@broadcom.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ajit.khapa...@broadcom.com Resolution|--- |INVALID --- Comment #1 from Ajit Khaparde (ajit.khapa...@broadcom.com) --- SPAM -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] Windows community call: MoM 2021-08-04
# About The meeting takes place in MS Teams every two weeks on Wednesday 15:00 UTC. Ask Harini Ramakrishnan for invitation. # Attendees * Microsoft: - Khoa To - Narcisa Ana Maria Vasile (Naty) - Omar Cordona - Tyler Retzlaff * NVIDIA: - Dmitry Kozlyuk (DmitryK) - Tal Shnaiderman * VMWare: - Cheng-Chung William Tu (VMWare) - Sergey Madaminov (VMWare) * Mark Cheatham (Boulder Imaging) * Nick Connolly (Datapath) * Pallavi Kadam (Intel) * Yan Vugenfirer (Daynix) # Agenda * Patch status review * Porting OvS build system to meson status report * Windows 21.11 roadmap planning * Misc # Patch review 1. eal: Add EAL API for threading v13 DmitryK to finish the review and ack. Naty to follow up with Thomas if the series can be merged without the next one once acked because the code is used in unit tests at least. 2. Enable the internal EAL thread API v2 Naty to send v3. 3. [v2] eal/windows: ensure all enabled CPUs are counted v2 DmitryK acked, but suggested a shorted working. Naty to track the patch (maybe send v3 following suggestion). 4. windows/virt2phys: fix paging issue v2 (DmitryK) Tyler to do a security-centered review and/or ping DmitryM. # Porting OvS build system to meson (William Tu) Status: OvS compiles with some features disabled, with a lot of warnings. Issues: * vhost-user is Linux-specific. [Omar] Microsoft is working on functional equivalent. * rte_version* not exported. AI William to send patches. * rte_open_logstream() implementation relies on Linux-specific fopencookie(). We need a more generic facility to redirect logs. AI William and DmitryK to discuss. * meson not finding DPDK with pkg-config, maybe meson bug. AI William and DmitryK to investigate. [Omar] What are the use cases for OvS on Windows? [William]: 1. VMWare NSX on Windows; 2. AF_XDP replacement (fast data path); [Omar] Windows now has its own experimental AF_XDP 3. Kubernetes containers scenario. # Windows 21.11 roadmap AI DmitryK to send a roadmap patch, below are brief notes. 1. Harini, Omar, and Tyler will work on establishing the process of signing and publishing netuio and virt2phys. Likely some form of external signing will be used, i.e. not by Microsoft name. Audit before signing must be aligned with DPDK releases. CI for signing is also currently missing. Microsoft will discuss the topic externally and reach more people of needed. 2. DmitryK will work on interrupt support in DPDK and netuio. Intel will help with testing on their HW. Microsoft will help with code review. 3. Naty will finish the work on threading API. DmitryK to track them and review on time. 4. Tyler will work on enabling shared build of DPDK, mostly solving the issues with thread-local storage. At least patches will be sent by 21.11, not sure if merged. DmitryK will help with review. 6. DmitryK will replace SetupAPI with cfgmgr32 API in lib/eal and bus/pci. 7. Harini will expedite investigation by Microsoft, why netuio doesn't work with vmxnet3 HW in VMWare hypervisor. 8. External issues to track: 8.1) wpcap lacks pkg-config file: https://github.com/nmap/npcap/issues/299 8.2) meson 0.58 unable to build DPDK: https://github.com/mesonbuild/meson/issues/8981 # Misc * We need to better automation scripts for things in Windows GSG: - to setup development environment; - to enable "Lock pages in memory privilege"; - to install drivers. * netuio needs tracing (logging), maybe it will be WPP tracing, maybe Microsoft will advise a better technology.
[dpdk-dev] [PATCH 0/4] cryptodev: expose driver interface as internal
rte_cryptodev_pmd.* files are meant to be used for
DPDK internal usage only, but it was used illegally by
applications.
There is one API which can be used by applications to
check if the dev_id has a valid device or not.
This API is exposed and modified as rte_cryptodev_is_valid_dev()
from rte_cryptodev_pmd_is_valid_dev().
Akhil Goyal (4):
test/crypto: remove illegal header include
cryptodev: change valid dev API
examples/fips_validation: remove illegal usage of APIs
cryptodev: expose driver interface as internal
app/test/test_cryptodev.c | 1 -
app/test/test_cryptodev_asym.c| 1 -
app/test/test_cryptodev_blockcipher.c | 1 -
app/test/test_cryptodev_security_pdcp.c | 1 -
app/test/test_ipsec.c | 1 -
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 2 +-
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 2 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c| 2 +-
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c| 2 +-
drivers/crypto/armv8/rte_armv8_pmd.c | 2 +-
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_pmd.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_session.h | 2 +-
drivers/crypto/caam_jr/caam_jr.c | 2 +-
drivers/crypto/ccp/ccp_crypto.c | 2 +-
drivers/crypto/ccp/ccp_pmd_ops.c | 2 +-
drivers/crypto/ccp/rte_ccp_pmd.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev_ops.h | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev.c | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev_ops.h | 2 +-
drivers/crypto/cnxk/cnxk_cryptodev_ops.c | 2 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 2 +-
drivers/crypto/dpaa_sec/dpaa_sec.c| 2 +-
drivers/crypto/kasumi/rte_kasumi_pmd.c| 2 +-
drivers/crypto/kasumi/rte_kasumi_pmd_ops.c| 2 +-
drivers/crypto/mlx5/mlx5_crypto.h | 2 +-
drivers/crypto/mvsam/rte_mrvl_pmd.c | 2 +-
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 2 +-
drivers/crypto/nitrox/nitrox_sym.c| 2 +-
drivers/crypto/null/null_crypto_pmd.c | 2 +-
drivers/crypto/null/null_crypto_pmd_ops.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.h | 2 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 2 +-
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_asym.h | 2 +-
drivers/crypto/qat/qat_asym_pmd.c | 2 +-
drivers/crypto/qat/qat_sym.h | 2 +-
drivers/crypto/qat/qat_sym_hw_dp.c| 2 +-
drivers/crypto/qat/qat_sym_pmd.c | 2 +-
drivers/crypto/qat/qat_sym_session.h | 2 +-
.../scheduler/rte_cryptodev_scheduler.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 2 +-
drivers/crypto/snow3g/rte_snow3g_pmd.c| 2 +-
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c| 2 +-
drivers/crypto/virtio/virtio_cryptodev.c | 2 +-
drivers/crypto/virtio/virtio_rxtx.c | 2 +-
drivers/crypto/zuc/rte_zuc_pmd.c | 2 +-
drivers/crypto/zuc/rte_zuc_pmd_ops.c | 2 +-
.../octeontx2/otx2_evdev_crypto_adptr_rx.h| 2 +-
.../octeontx2/otx2_evdev_crypto_adptr_tx.h| 2 +-
.../net/softnic/rte_eth_softnic_cryptodev.c | 4 +-
examples/fips_validation/fips_dev_self_test.c | 19 +--
examples/fips_validation/main.c | 9 ++--
examples/ip_pipeline/cryptodev.c | 3 +-
.../{rte_cryptodev_pmd.c => cryptodev_pmd.c} | 2 +-
.../{rte_cryptodev_pmd.h => cryptodev_pmd.h} | 27 +-
lib/cryptodev/meson.build | 18 +--
lib/cryptodev/rte_cryptodev.c | 52 +--
lib/cryptodev/rte_cryptodev.h | 11
lib/cryptodev/version.map | 27 ++
lib/eventdev/rte_event_crypto_adapter.c | 6 +--
lib/eventdev/rte_eventdev.c | 4 +-
lib/pipeline/rte_table_action.c | 4 +-
71 files changed, 149 insertions(+), 148 deletions(-)
rename lib/cryptodev/{rte_cryptodev_pmd.c => cryptodev_pmd.c} (99%)
rename lib/cryptodev/{rte_cryptodev_pmd.h => cryptodev_pmd.h} (97%)
--
2.25.1
[dpdk-dev] [PATCH 2/4] cryptodev: change valid dev API
The API rte_cryptodev_pmd_is_valid_dev, can be used
by the application as well as PMD to check whether
the device is valid or not. Hence, _pmd is removed
from the API.
The applications and drivers which use this API are
also updated.
Signed-off-by: Akhil Goyal
---
.../net/softnic/rte_eth_softnic_cryptodev.c | 2 +-
examples/fips_validation/main.c | 2 +-
examples/ip_pipeline/cryptodev.c | 3 +-
lib/cryptodev/rte_cryptodev.c | 50 +--
lib/cryptodev/rte_cryptodev.h | 11
lib/cryptodev/rte_cryptodev_pmd.h | 11
lib/cryptodev/version.map | 2 +-
lib/eventdev/rte_event_crypto_adapter.c | 4 +-
lib/eventdev/rte_eventdev.c | 2 +-
lib/pipeline/rte_table_action.c | 2 +-
10 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
index a1a4ca5650..8e278801c5 100644
--- a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
+++ b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
@@ -82,7 +82,7 @@ softnic_cryptodev_create(struct pmd_internals *p,
dev_id = (uint32_t)status;
} else {
- if (rte_cryptodev_pmd_is_valid_dev(params->dev_id) == 0)
+ if (rte_cryptodev_is_valid_dev(params->dev_id) == 0)
return NULL;
dev_id = params->dev_id;
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index c175fe6ac2..e892078f0e 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -196,7 +196,7 @@ parse_cryptodev_id_arg(char *arg)
}
- if (!rte_cryptodev_pmd_is_valid_dev(cryptodev_id)) {
+ if (!rte_cryptodev_is_valid_dev(cryptodev_id)) {
RTE_LOG(ERR, USER1, "Error %i: invalid cryptodev id %s\n",
cryptodev_id, arg);
return -1;
diff --git a/examples/ip_pipeline/cryptodev.c b/examples/ip_pipeline/cryptodev.c
index b0d9f3d217..9997d97456 100644
--- a/examples/ip_pipeline/cryptodev.c
+++ b/examples/ip_pipeline/cryptodev.c
@@ -6,7 +6,6 @@
#include
#include
-#include
#include
#include "cryptodev.h"
@@ -74,7 +73,7 @@ cryptodev_create(const char *name, struct cryptodev_params
*params)
dev_id = (uint32_t)status;
} else {
- if (rte_cryptodev_pmd_is_valid_dev(params->dev_id) == 0)
+ if (rte_cryptodev_is_valid_dev(params->dev_id) == 0)
return NULL;
dev_id = params->dev_id;
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 447aa9d519..37502b9b3c 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -663,7 +663,7 @@ rte_cryptodev_is_valid_device_data(uint8_t dev_id)
}
unsigned int
-rte_cryptodev_pmd_is_valid_dev(uint8_t dev_id)
+rte_cryptodev_is_valid_dev(uint8_t dev_id)
{
struct rte_cryptodev *dev = NULL;
@@ -761,7 +761,7 @@ rte_cryptodev_socket_id(uint8_t dev_id)
{
struct rte_cryptodev *dev;
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
+ if (!rte_cryptodev_is_valid_dev(dev_id))
return -1;
dev = rte_cryptodev_pmd_get_dev(dev_id);
@@ -1032,7 +1032,7 @@ rte_cryptodev_configure(uint8_t dev_id, struct
rte_cryptodev_config *config)
struct rte_cryptodev *dev;
int diag;
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return -EINVAL;
}
@@ -1080,7 +1080,7 @@ rte_cryptodev_start(uint8_t dev_id)
CDEV_LOG_DEBUG("Start dev_id=%" PRIu8, dev_id);
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return -EINVAL;
}
@@ -1110,7 +1110,7 @@ rte_cryptodev_stop(uint8_t dev_id)
{
struct rte_cryptodev *dev;
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return;
}
@@ -1136,7 +1136,7 @@ rte_cryptodev_close(uint8_t dev_id)
struct rte_cryptodev *dev;
int retval;
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return -1;
}
@@ -1176,7 +1176,7 @@ rte_cryptodev_get_qp_status(uint8_t dev_id, uint16_t
queue_pair_id)
{
struct rte_cryptodev *dev;
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
[dpdk-dev] [PATCH 1/4] test/crypto: remove illegal header include
rte_cryptodev_pmd.h is an interface between driver and library and it is mentioned in the file that application cannot use it directly. Hence, removing the include. Signed-off-by: Akhil Goyal --- app/test/test_cryptodev.c | 1 - app/test/test_cryptodev_asym.c | 1 - app/test/test_cryptodev_blockcipher.c | 1 - app/test/test_cryptodev_security_pdcp.c | 1 - app/test/test_ipsec.c | 1 - 5 files changed, 5 deletions(-) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index 9ad0b37473..e8d63b2bc3 100644 --- a/app/test/test_cryptodev.c +++ b/app/test/test_cryptodev.c @@ -16,7 +16,6 @@ #include #include -#include #include #ifdef RTE_CRYPTO_SCHEDULER diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c index afa0e91a45..603b2e4609 100644 --- a/app/test/test_cryptodev_asym.c +++ b/app/test/test_cryptodev_asym.c @@ -12,7 +12,6 @@ #include #include -#include #include #include "test_cryptodev.h" diff --git a/app/test/test_cryptodev_blockcipher.c b/app/test/test_cryptodev_blockcipher.c index 53fd4718af..1c948eb008 100644 --- a/app/test/test_cryptodev_blockcipher.c +++ b/app/test/test_cryptodev_blockcipher.c @@ -11,7 +11,6 @@ #include #include -#include #include "test.h" #include "test_cryptodev.h" diff --git a/app/test/test_cryptodev_security_pdcp.c b/app/test/test_cryptodev_security_pdcp.c index 30f3eb892c..a7641bab7a 100644 --- a/app/test/test_cryptodev_security_pdcp.c +++ b/app/test/test_cryptodev_security_pdcp.c @@ -17,7 +17,6 @@ #include #include -#include #include #include diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c index fb90130ae2..c6d6b88d6d 100644 --- a/app/test/test_ipsec.c +++ b/app/test/test_ipsec.c @@ -15,7 +15,6 @@ #include #include -#include #include #include #include -- 2.25.1
[dpdk-dev] [PATCH 3/4] examples/fips_validation: remove illegal usage of APIs
Some of the cryptodev APIs are not allowed to be used
by application directly. Hence removing the usage of
1. queue_pair_release: it is not required, as configure
of queue pair release the previous queue pairs and the
dev is not directly exposed to application, hence cannot
use its ops from app.
2. rte_cryptodev_stop: it can be used directly without
checking if the device is started or not.
3. rte_cryptodev_pmd_destroy: application should use
rte_cryptodev_close instead.
Signed-off-by: Akhil Goyal
---
examples/fips_validation/fips_dev_self_test.c | 19 ++-
examples/fips_validation/main.c | 7 ++-
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/examples/fips_validation/fips_dev_self_test.c
b/examples/fips_validation/fips_dev_self_test.c
index 17e85973c0..b4eab05a98 100644
--- a/examples/fips_validation/fips_dev_self_test.c
+++ b/examples/fips_validation/fips_dev_self_test.c
@@ -3,7 +3,7 @@
*/
#include
-#include
+#include
#include "fips_dev_self_test.h"
@@ -1523,12 +1523,6 @@ static void
fips_dev_auto_test_uninit(uint8_t dev_id,
struct fips_dev_auto_test_env *env)
{
- struct rte_cryptodev *dev = rte_cryptodev_pmd_get_dev(dev_id);
- uint32_t i;
-
- if (!dev)
- return;
-
if (env->mbuf)
rte_pktmbuf_free(env->mbuf);
if (env->op)
@@ -1542,16 +1536,7 @@ fips_dev_auto_test_uninit(uint8_t dev_id,
if (env->sess_priv_pool)
rte_mempool_free(env->sess_priv_pool);
- if (dev->data->dev_started)
- rte_cryptodev_stop(dev_id);
-
- if (dev->data->nb_queue_pairs) {
- for (i = 0; i < dev->data->nb_queue_pairs; i++)
- (*dev->dev_ops->queue_pair_release)(dev, i);
- dev->data->nb_queue_pairs = 0;
- rte_free(dev->data->queue_pairs);
- dev->data->queue_pairs = NULL;
- }
+ rte_cryptodev_stop(dev_id);
}
static int
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index e892078f0e..a8daad1f48 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -7,7 +7,7 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -73,10 +73,7 @@ cryptodev_fips_validate_app_int(void)
if (env.self_test) {
ret = fips_dev_self_test(env.dev_id, env.broken_test_config);
if (ret < 0) {
- struct rte_cryptodev *cryptodev =
- rte_cryptodev_pmd_get_dev(env.dev_id);
-
- rte_cryptodev_pmd_destroy(cryptodev);
+ rte_cryptodev_close(env.dev_id);
return ret;
}
--
2.25.1
[dpdk-dev] [PATCH 4/4] cryptodev: expose driver interface as internal
The rte_cryptodev_pmd.* files are for drivers only and should be
private to DPDK, and not installed for app use.
Signed-off-by: Akhil Goyal
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 2 +-
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 2 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c| 2 +-
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c| 2 +-
drivers/crypto/armv8/rte_armv8_pmd.c | 2 +-
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_pmd.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_session.h | 2 +-
drivers/crypto/caam_jr/caam_jr.c | 2 +-
drivers/crypto/ccp/ccp_crypto.c | 2 +-
drivers/crypto/ccp/ccp_pmd_ops.c | 2 +-
drivers/crypto/ccp/rte_ccp_pmd.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev_ops.h | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev.c | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev_ops.h | 2 +-
drivers/crypto/cnxk/cnxk_cryptodev_ops.c | 2 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 2 +-
drivers/crypto/dpaa_sec/dpaa_sec.c| 2 +-
drivers/crypto/kasumi/rte_kasumi_pmd.c| 2 +-
drivers/crypto/kasumi/rte_kasumi_pmd_ops.c| 2 +-
drivers/crypto/mlx5/mlx5_crypto.h | 2 +-
drivers/crypto/mvsam/rte_mrvl_pmd.c | 2 +-
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 2 +-
drivers/crypto/nitrox/nitrox_sym.c| 2 +-
drivers/crypto/null/null_crypto_pmd.c | 2 +-
drivers/crypto/null/null_crypto_pmd_ops.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.h | 2 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 2 +-
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_asym.h | 2 +-
drivers/crypto/qat/qat_asym_pmd.c | 2 +-
drivers/crypto/qat/qat_sym.h | 2 +-
drivers/crypto/qat/qat_sym_hw_dp.c| 2 +-
drivers/crypto/qat/qat_sym_pmd.c | 2 +-
drivers/crypto/qat/qat_sym_session.h | 2 +-
.../scheduler/rte_cryptodev_scheduler.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 2 +-
drivers/crypto/snow3g/rte_snow3g_pmd.c| 2 +-
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c| 2 +-
drivers/crypto/virtio/virtio_cryptodev.c | 2 +-
drivers/crypto/virtio/virtio_rxtx.c | 2 +-
drivers/crypto/zuc/rte_zuc_pmd.c | 2 +-
drivers/crypto/zuc/rte_zuc_pmd_ops.c | 2 +-
.../octeontx2/otx2_evdev_crypto_adptr_rx.h| 2 +-
.../octeontx2/otx2_evdev_crypto_adptr_tx.h| 2 +-
.../net/softnic/rte_eth_softnic_cryptodev.c | 2 +-
.../{rte_cryptodev_pmd.c => cryptodev_pmd.c} | 2 +-
.../{rte_cryptodev_pmd.h => cryptodev_pmd.h} | 16 +---
lib/cryptodev/meson.build | 18 ++---
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/cryptodev/version.map | 25 +++
lib/eventdev/rte_event_crypto_adapter.c | 2 +-
lib/eventdev/rte_eventdev.c | 2 +-
lib/pipeline/rte_table_action.c | 2 +-
62 files changed, 101 insertions(+), 76 deletions(-)
rename lib/cryptodev/{rte_cryptodev_pmd.c => cryptodev_pmd.c} (99%)
rename lib/cryptodev/{rte_cryptodev_pmd.h => cryptodev_pmd.h} (98%)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 886e2a5aaa..330aad8157 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -5,7 +5,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index 18dbc4c18c..edb7275e76 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -6,7 +6,7 @@
#include
#include
-#include
+#include
#include "aesni_gcm_pmd_private.h"
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index a01c826a3c..60963a8208 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -7,7 +7,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index fc7fdfec8e..48a8f91868 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_o
[dpdk-dev] [PATCH v1] doc: update release notes for 21.08
Fix grammar, spelling and formatting of DPDK 21.08 release notes. Signed-off-by: John McNamara --- doc/guides/rel_notes/release_21_08.rst | 78 -- 1 file changed, 24 insertions(+), 54 deletions(-) diff --git a/doc/guides/rel_notes/release_21_08.rst b/doc/guides/rel_notes/release_21_08.rst index d7559ec6bf..0a7b817d9f 100644 --- a/doc/guides/rel_notes/release_21_08.rst +++ b/doc/guides/rel_notes/release_21_08.rst @@ -57,20 +57,20 @@ New Features * **Added auxiliary bus support.** - Auxiliary bus provides a way to split function into child-devices + An auxiliary bus provides a way to split a function into child-devices representing sub-domains of functionality. Each auxiliary device represents a part of its parent functionality. * **Added XZ compressed firmware support.** - Using ``rte_firmware_read``, a driver can now handle XZ compressed firmware - in a transparent way, with EAL uncompressing using libarchive if this library + Using ``rte_firmware_read`` a driver can now handle XZ compressed firmware + in a transparent way, with EAL uncompressing using libarchive, if this library is available when building DPDK. * **Updated Amazon ENA PMD.** - The new driver version (v2.4.0) introduced bug fixes and improvements, - including: + Updated the Amazon ENA PMD. The new driver version (v2.4.0) introduced bug + fixes and improvements, including: * Added Rx interrupt support. * RSS hash function key reconfiguration support. @@ -78,20 +78,20 @@ New Features * **Updated Intel iavf driver.** * Added Tx QoS VF queue TC mapping. - * Added FDIR and RSS for GTPoGRE, support filter based on GTPU TEID/QFI, -outer most L3 or inner most l3/l4. + * Added FDIR and RSS for GTPoGRE, and support for filters based on GTPU TEID/QFI, +outermost L3 or innermost L3/L4. * **Updated Intel ice driver.** - * In AVX2 code, added the new RX and TX paths to use the HW offload + * Added new RX and TX paths in the AVX2 code to use HW offload features. When the HW offload features are configured to be used, the offload paths are chosen automatically. In parallel the support for HW offload features was removed from the legacy AVX2 paths. * Added Tx QoS TC bandwidth configuration in DCF. -* **Added support for Marvell CN10K SoC ethernet device.** +* **Added support for Marvell CN10K SoC Ethernet device.** - * Added net/cnxk driver which provides the support for the integrated ethernet + * Added net/cnxk driver which provides the support for the integrated Ethernet device. * **Updated Mellanox mlx5 driver.** @@ -100,44 +100,44 @@ New Features * Added support for meter hierarchy. * Added support for metering policy actions of yellow color. * Added support for metering trTCM RFC2698 and RFC4115. - * Added devargs options ``allow_duplicate_pattern``. + * Added devargs option ``allow_duplicate_pattern``. * Added matching on IPv4 Internet Header Length (IHL). * Added support for matching on VXLAN header last 8-bits reserved field. * Optimized multi-thread flow rule insertion rate. * **Added Wangxun ngbe PMD.** - Added a new PMD driver for Wangxun 1 Gigabit Ethernet NICs. + Added a new PMD driver for Wangxun 1Gb Ethernet NICs. See the :doc:`../nics/ngbe` for more details. * **Updated Solarflare network PMD.** Updated the Solarflare ``sfc_efx`` driver with changes including: - * Added COUNT action support for SN1000 NICs + * Added COUNT action support for SN1000 NICs. * **Added inflight packets clear API in vhost library.** - Added an API which can clear the inflight packets submitted to DMA - engine in vhost async data path. + Added an API which can clear the inflight packets submitted to the DMA + engine in the vhost async data path. * **Updated Intel QuickAssist crypto PMD.** Added fourth generation of QuickAssist Technology(QAT) devices support. - Only symmetric crypto has been currently enabled, compression and asymmetric + Only symmetric crypto has been currently enabled. Compression and asymmetric crypto PMD will fail to create. * **Added support for Marvell CNXK crypto driver.** * Added cnxk crypto PMD which provides support for an integrated crypto driver for CN9K and CN10K series of SOCs. Support for -symmetric crypto algorithms is added to both the PMDs. +symmetric crypto algorithms was added to both the PMDs. * Added support for lookaside protocol (IPsec) offload in cn10k PMD. * Added support for asymmetric crypto operations in cn9k and cn10k PMD. * **Updated Marvell OCTEON TX crypto PMD.** - Added support for crypto adapter OP_FORWARD mode. + Added support for crypto adapter ``OP_FORWARD`` mode. * **Added support for Nvidia crypto device driver.** @@ -150,14 +150,14 @@ New Features * **Added Baseband PHY CNXK PMD.** - Added Baseband PHY PMD which allows to configure BPHY hardware block + Added Baseband PHY
Re: [dpdk-dev] [WARNING: UNSCANNABLE EXTRACTION FAILED][WARNING: UNSCANNABLE EXTRACTION FAILED] [PATCH v3] doc: mtr: add API walk through
Hi Jerin, > > On Thu, Aug 5, 2021 at 4:36 PM Dumitrescu, Cristian > wrote: > > > > HI Jerin, > > > > Thanks for your patch! > > > > Initially, it looked like an easy job to review it, but there is actually an > elephant in the room on how to chain the meters, see below. > > Yes. That's why I send this patch to finalize how to chain the meter. > It was hard for me to follow that's why added a digram. > OK, got it :) > > > +#. A meter object consists of a profile and a policy. Use above created > > > objects to create > > > + meter object using ``rte_mtr_create()``. Application uses > > > + ``struct rte_mtr_params::meter_profile_id`` and ``struct > > > rte_mtr_params::meter_policy_id`` > > > + to specify the profile (created in step 2) and policy (created in > > > step 3). > > > > It is mainly the meter object configuration that consists of a profile and a > policy, but not exactly the meter object itself. > > > > How about: > > The application creates a meter object using the rte_mtr_create() > > API > function. One of the previously created meter profile and meter policy are > provided as arguments at this step. > > Sure. I just though to add exact struct field so that it easy for end > users to know. > > How about your version + struct name. > > The application creates a meter object using the rte_mtr_create() API > function. > One of the previously created meter profile (`struct > rte_mtr_params::meter_profile_id``) and meter policy > ``struct rte_mtr_params::meter_policy_id`` are provided as arguments > at this step. > Great, thanks! > > > +#. The API allows chaining the meter objects to create complex > metering > > > topology > > > + by specifying ``struct rte_mtr_meter_policy_params::actions`` action > as > > > + ``RTE_FLOW_ACTION_TYPE_METER`` to the parent meter object > encoded > > > as > > > + ``struct rte_flow_action_meter::mtr_id``. > > > > Now this could be the elephant in the room: > > > > With the latest API changes that went in recently, the rte_mtr API now > allows for a list of (any) rte_flow actions to be specified per color for each > meter object, which opens up the door for a meter action to call one (or > more) subsequent meter actions (on the same or different meter objects) > conditional of a specific color. Which is another (new) way to chain meters, > right? Let's refer to this as the Meter Chaining - Approach B. > > Yes, my diagram is approach B. > > > > > Before these API changes, the only way to chain meters was by specifying > multiple meter actions (action on the same or different meter object) for the > same rte_flow. Let's refer to this as the Meter Chaining - Approach A. > > Yes. Me too was assuming that way. But no one really implemented the > chaining. With the MLX patch that got changed. > > > > > The Meter Chaining - Approach A is valid. After a bit of thinking, I don't > > see > any reason to invalidate the approach you describe, so I agree that Meter > Chaining - Approach B is also valid, with the (small) advantage that is > conditional of a specific color. > > > > So, I think we should describe here both approaches. How about adding a > new distinct section for Meter Chaining, where we describe both approaches > as valid? It would be great if you could have a separate diagram for each > approach :) > > This is the exact reason to send the patch. Approach B is a superset. > Should we allow two approaches ? It will complicate the driver as it > needs to track two ways of changing. > Can we keep only the new approach, Just to make everyone's life easy? > We started implementing this driver and realized two paths are painful > for the driver. > I agree the latest API changes push more complexity into the driver, but both approaches logically make sense and are already part of the API, so I think it is better to implement them both, if possible, and also describe them both in the doc. Supporting both will avoid confusing the users. Also this problem that you mention is true for any action, not just for the meter action: now there are two different paths to enable any action type, one is enablement as a flow action, and the other one is enablement as a meter action; allowing just one path for the meter action leads to allowing just one path for all the other actions as well, which defeats the purpose of the API update, right? Regards, Cristian
[dpdk-dev] [PATCH 0/4] net/ice: support IEEE 1588
[PATCH 1/4] add 1588 capability probe. [PATCH 2/4] add low level functions for device clock control. [PATCH 3/4] add clock initialization function. [PATCH 4/4] add ethdev APIs to enable 1588 timesync. Qi Zhang (3): net/ice/base: add 1588 capability probe net/ice/base: add low level functions for device clock control net/ice/base: add clock initialization function Simei Su (1): net/ice: support IEEE 1588 PTP drivers/net/ice/base/ice_adminq_cmd.h |2 + drivers/net/ice/base/ice_cgu_regs.h | 117 ++ drivers/net/ice/base/ice_common.c | 254 drivers/net/ice/base/ice_common.h | 11 + drivers/net/ice/base/ice_controlq.c | 52 +- drivers/net/ice/base/ice_controlq.h |2 + drivers/net/ice/base/ice_ptp_consts.h | 160 +++ drivers/net/ice/base/ice_ptp_hw.c | 2369 + drivers/net/ice/base/ice_ptp_hw.h | 400 ++ drivers/net/ice/base/ice_type.h | 75 ++ drivers/net/ice/base/meson.build |1 + drivers/net/ice/ice_ethdev.c | 226 +++- drivers/net/ice/ice_ethdev.h |5 + drivers/net/ice/ice_rxtx.c| 42 +- drivers/net/ice/ice_rxtx.h|1 + 15 files changed, 3714 insertions(+), 3 deletions(-) create mode 100644 drivers/net/ice/base/ice_cgu_regs.h create mode 100644 drivers/net/ice/base/ice_ptp_consts.h create mode 100644 drivers/net/ice/base/ice_ptp_hw.c create mode 100644 drivers/net/ice/base/ice_ptp_hw.h -- 2.9.5
[dpdk-dev] [PATCH 1/4] net/ice/base: add 1588 capability probe
From: Qi Zhang
Parse 1588 timesync capability during device capability probing.
Signed-off-by: Jacob Keller
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 1 +
drivers/net/ice/base/ice_common.c | 111 ++
drivers/net/ice/base/ice_type.h | 72 ++
3 files changed, 184 insertions(+)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index 3805fc9..a0af35c 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -108,6 +108,7 @@ struct ice_aqc_list_caps_elem {
#define ICE_AQC_CAPS_TXQS 0x0042
#define ICE_AQC_CAPS_MSIX 0x0043
#define ICE_AQC_CAPS_FD0x0045
+#define ICE_AQC_CAPS_1588 0x0046
#define ICE_AQC_CAPS_MAX_MTU 0x0047
#define ICE_AQC_CAPS_IWARP 0x0051
#define ICE_AQC_CAPS_PCIE_RESET_AVOIDANCE 0x0076
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index cf0a7d4..56a4696 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -2091,6 +2091,60 @@ ice_parse_vsi_func_caps(struct ice_hw *hw, struct
ice_hw_func_caps *func_p,
}
/**
+ * ice_parse_1588_func_caps - Parse ICE_AQC_CAPS_1588 function caps
+ * @hw: pointer to the HW struct
+ * @func_p: pointer to function capabilities structure
+ * @cap: pointer to the capability element to parse
+ *
+ * Extract function capabilities for ICE_AQC_CAPS_1588.
+ */
+static void
+ice_parse_1588_func_caps(struct ice_hw *hw, struct ice_hw_func_caps *func_p,
+struct ice_aqc_list_caps_elem *cap)
+{
+ struct ice_ts_func_info *info = &func_p->ts_func_info;
+ u32 number = LE32_TO_CPU(cap->number);
+
+ info->ena = ((number & ICE_TS_FUNC_ENA_M) != 0);
+ func_p->common_cap.ieee_1588 = info->ena;
+
+ info->src_tmr_owned = ((number & ICE_TS_SRC_TMR_OWND_M) != 0);
+ info->tmr_ena = ((number & ICE_TS_TMR_ENA_M) != 0);
+ info->tmr_index_owned = ((number & ICE_TS_TMR_IDX_OWND_M) != 0);
+ info->tmr_index_assoc = ((number & ICE_TS_TMR_IDX_ASSOC_M) != 0);
+
+ info->clk_freq = (number & ICE_TS_CLK_FREQ_M) >> ICE_TS_CLK_FREQ_S;
+ info->clk_src = ((number & ICE_TS_CLK_SRC_M) != 0);
+
+ if (info->clk_freq < NUM_ICE_TIME_REF_FREQ) {
+ info->time_ref = (enum ice_time_ref_freq)info->clk_freq;
+ } else {
+ /* Unknown clock frequency, so assume a (probably incorrect)
+* default to avoid out-of-bounds look ups of frequency
+* related information.
+*/
+ ice_debug(hw, ICE_DBG_INIT, "1588 func caps: unknown clock
frequency %u\n",
+ info->clk_freq);
+ info->time_ref = ICE_TIME_REF_FREQ_25_000;
+ }
+
+ ice_debug(hw, ICE_DBG_INIT, "func caps: ieee_1588 = %u\n",
+ func_p->common_cap.ieee_1588);
+ ice_debug(hw, ICE_DBG_INIT, "func caps: src_tmr_owned = %u\n",
+ info->src_tmr_owned);
+ ice_debug(hw, ICE_DBG_INIT, "func caps: tmr_ena = %u\n",
+ info->tmr_ena);
+ ice_debug(hw, ICE_DBG_INIT, "func caps: tmr_index_owned = %u\n",
+ info->tmr_index_owned);
+ ice_debug(hw, ICE_DBG_INIT, "func caps: tmr_index_assoc = %u\n",
+ info->tmr_index_assoc);
+ ice_debug(hw, ICE_DBG_INIT, "func caps: clk_freq = %u\n",
+ info->clk_freq);
+ ice_debug(hw, ICE_DBG_INIT, "func caps: clk_src = %u\n",
+ info->clk_src);
+}
+
+/**
* ice_parse_fdir_func_caps - Parse ICE_AQC_CAPS_FD function caps
* @hw: pointer to the HW struct
* @func_p: pointer to function capabilities structure
@@ -2155,6 +2209,9 @@ ice_parse_func_caps(struct ice_hw *hw, struct
ice_hw_func_caps *func_p,
case ICE_AQC_CAPS_VSI:
ice_parse_vsi_func_caps(hw, func_p, &cap_resp[i]);
break;
+ case ICE_AQC_CAPS_1588:
+ ice_parse_1588_func_caps(hw, func_p, &cap_resp[i]);
+ break;
case ICE_AQC_CAPS_FD:
ice_parse_fdir_func_caps(hw, func_p);
break;
@@ -2209,6 +2266,57 @@ ice_parse_vsi_dev_caps(struct ice_hw *hw, struct
ice_hw_dev_caps *dev_p,
}
/**
+ * ice_parse_1588_dev_caps - Parse ICE_AQC_CAPS_1588 device caps
+ * @hw: pointer to the HW struct
+ * @dev_p: pointer to device capabilities structure
+ * @cap: capability element to parse
+ *
+ * Parse ICE_AQC_CAPS_1588 for device capabilities.
+ */
+static void
+ice_parse_1588_dev_caps(struct ice_hw *hw, struct ice_hw_dev_caps *dev_p,
+ struct ice_aqc_list_caps_elem *cap)
+{
+ struct ice_ts_dev_i
[dpdk-dev] [PATCH 2/4] net/ice/base: add low level functions for device clock control
From: Qi Zhang
The ice hardware supports exposing a hardware clock for high precision
timestamping. This is primarily intended for accelerating the Precision
Time Protocol.
Add several low level functions intended to be used as the basis for
enabling the device clock, and ensuring that the port timers are
synchronized properly.
Signed-off-by: Jacob Keller
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h |1 +
drivers/net/ice/base/ice_common.c | 143 +++
drivers/net/ice/base/ice_common.h | 11 +
drivers/net/ice/base/ice_controlq.c | 52 +-
drivers/net/ice/base/ice_controlq.h |2 +
drivers/net/ice/base/ice_ptp_consts.h | 86 ++
drivers/net/ice/base/ice_ptp_hw.c | 2023 +
drivers/net/ice/base/ice_ptp_hw.h | 376 ++
drivers/net/ice/base/ice_type.h |3 +
drivers/net/ice/base/meson.build |1 +
10 files changed, 2697 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ice/base/ice_ptp_consts.h
create mode 100644 drivers/net/ice/base/ice_ptp_hw.c
create mode 100644 drivers/net/ice/base/ice_ptp_hw.h
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index a0af35c..470aa89 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -3120,6 +3120,7 @@ enum ice_adminq_opc {
ice_aqc_opc_set_event_mask = 0x0613,
ice_aqc_opc_set_mac_lb = 0x0620,
ice_aqc_opc_get_link_topo = 0x06E0,
+ ice_aqc_opc_get_link_topo_pin = 0x06E1,
ice_aqc_opc_read_i2c= 0x06E2,
ice_aqc_opc_write_i2c = 0x06E3,
ice_aqc_opc_set_port_id_led = 0x06E9,
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index 56a4696..4748ca5 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -65,6 +65,28 @@ static enum ice_status ice_set_mac_type(struct ice_hw *hw)
}
/**
+ * ice_is_generic_mac
+ * @hw: pointer to the hardware structure
+ *
+ * returns true if mac_type is ICE_MAC_GENERIC, false if not
+ */
+bool ice_is_generic_mac(struct ice_hw *hw)
+{
+ return hw->mac_type == ICE_MAC_GENERIC;
+}
+
+/**
+ * ice_is_e810
+ * @hw: pointer to the hardware structure
+ *
+ * returns true if the device is E810 based, false if not.
+ */
+bool ice_is_e810(struct ice_hw *hw)
+{
+ return hw->mac_type == ICE_MAC_E810;
+}
+
+/**
* ice_clear_pf_cfg - Clear PF configuration
* @hw: pointer to the hardware structure
*
@@ -1354,6 +1376,127 @@ ice_clear_tx_drbell_q_ctx(struct ice_hw *hw, u32
tx_drbell_q_index)
return ICE_SUCCESS;
}
+/* Sideband Queue command wrappers */
+
+/**
+ * ice_get_sbq - returns the right control queue to use for sideband
+ * @hw: pointer to the hardware structure
+ */
+static struct ice_ctl_q_info *ice_get_sbq(struct ice_hw *hw)
+{
+ if (!ice_is_generic_mac(hw))
+ return &hw->adminq;
+ return &hw->sbq;
+}
+
+/**
+ * ice_sbq_send_cmd - send Sideband Queue command to Sideband Queue
+ * @hw: pointer to the HW struct
+ * @desc: descriptor describing the command
+ * @buf: buffer to use for indirect commands (NULL for direct commands)
+ * @buf_size: size of buffer for indirect commands (0 for direct commands)
+ * @cd: pointer to command details structure
+ */
+static enum ice_status
+ice_sbq_send_cmd(struct ice_hw *hw, struct ice_sbq_cmd_desc *desc,
+void *buf, u16 buf_size, struct ice_sq_cd *cd)
+{
+ return ice_sq_send_cmd(hw, ice_get_sbq(hw), (struct ice_aq_desc *)desc,
+ buf, buf_size, cd);
+}
+
+/**
+ * ice_sbq_send_cmd_nolock - send Sideband Queue command to Sideband Queue
+ * but do not lock sq_lock
+ * @hw: pointer to the HW struct
+ * @desc: descriptor describing the command
+ * @buf: buffer to use for indirect commands (NULL for direct commands)
+ * @buf_size: size of buffer for indirect commands (0 for direct commands)
+ * @cd: pointer to command details structure
+ */
+static enum ice_status
+ice_sbq_send_cmd_nolock(struct ice_hw *hw, struct ice_sbq_cmd_desc *desc,
+ void *buf, u16 buf_size, struct ice_sq_cd *cd)
+{
+ return ice_sq_send_cmd_nolock(hw, ice_get_sbq(hw),
+ (struct ice_aq_desc *)desc, buf,
+ buf_size, cd);
+}
+
+/**
+ * ice_sbq_rw_reg_lp - Fill Sideband Queue command, with lock parameter
+ * @hw: pointer to the HW struct
+ * @in: message info to be filled in descriptor
+ * @lock: true to lock the sq_lock (the usual case); false if the sq_lock has
+ *already been locked at a higher level
+ */
+enum ice_status ice_sbq_rw_reg_lp(struct ice_hw *hw,
+ struct ice_sbq_msg_input *in, bool lock)
+{
+
[dpdk-dev] [PATCH 3/4] net/ice/base: add clock initialization function
From: Qi Zhang
Before the device PTP hardware clock can be initialized, some steps must
be taken by the driver. This includes writing some registers and
initializing the PHY.
Some of these steps are distinct depending on the device type (E810 or
E822). Additionally, a future change will introduce more steps for E822
devices to program the Clock Generation Unit.
Introduce ice_ptp_init_phc as well as device-specific sub-functions for
e810 and e822 devices.
Signed-off-by: Jacob Keller
Signed-off-by: Qi Zhang
tmp
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_cgu_regs.h | 117
drivers/net/ice/base/ice_ptp_consts.h | 74
drivers/net/ice/base/ice_ptp_hw.c | 348 +-
drivers/net/ice/base/ice_ptp_hw.h | 24 +++
4 files changed, 562 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ice/base/ice_cgu_regs.h
diff --git a/drivers/net/ice/base/ice_cgu_regs.h
b/drivers/net/ice/base/ice_cgu_regs.h
new file mode 100644
index 000..6751481
--- /dev/null
+++ b/drivers/net/ice/base/ice_cgu_regs.h
@@ -0,0 +1,117 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2001-2021 Intel Corporation
+ */
+
+#ifndef _ICE_CGU_REGS_H_
+#define _ICE_CGU_REGS_H_
+
+#define NAC_CGU_DWORD9 0x24
+union nac_cgu_dword9 {
+ struct {
+ u32 time_ref_freq_sel : 3;
+ u32 clk_eref1_en : 1;
+ u32 clk_eref0_en : 1;
+ u32 time_ref_en : 1;
+ u32 time_sync_en : 1;
+ u32 one_pps_out_en : 1;
+ u32 clk_ref_synce_en : 1;
+ u32 clk_synce1_en : 1;
+ u32 clk_synce0_en : 1;
+ u32 net_clk_ref1_en : 1;
+ u32 net_clk_ref0_en : 1;
+ u32 clk_synce1_amp : 2;
+ u32 misc6 : 1;
+ u32 clk_synce0_amp : 2;
+ u32 one_pps_out_amp : 2;
+ u32 misc24 : 12;
+ } field;
+ u32 val;
+};
+
+#define NAC_CGU_DWORD19 0x4c
+union nac_cgu_dword19 {
+ struct {
+ u32 tspll_fbdiv_intgr : 8;
+ u32 fdpll_ulck_thr : 5;
+ u32 misc15 : 3;
+ u32 tspll_ndivratio : 4;
+ u32 tspll_iref_ndivratio : 3;
+ u32 misc19 : 1;
+ u32 japll_ndivratio : 4;
+ u32 japll_iref_ndivratio : 3;
+ u32 misc27 : 1;
+ } field;
+ u32 val;
+};
+
+#define NAC_CGU_DWORD22 0x58
+union nac_cgu_dword22 {
+ struct {
+ u32 fdpll_frac_div_out_nc : 2;
+ u32 fdpll_lock_int_for : 1;
+ u32 synce_hdov_int_for : 1;
+ u32 synce_lock_int_for : 1;
+ u32 fdpll_phlead_slip_nc : 1;
+ u32 fdpll_acc1_ovfl_nc : 1;
+ u32 fdpll_acc2_ovfl_nc : 1;
+ u32 synce_status_nc : 6;
+ u32 fdpll_acc1f_ovfl : 1;
+ u32 misc18 : 1;
+ u32 fdpllclk_div : 4;
+ u32 time1588clk_div : 4;
+ u32 synceclk_div : 4;
+ u32 synceclk_sel_div2 : 1;
+ u32 fdpllclk_sel_div2 : 1;
+ u32 time1588clk_sel_div2 : 1;
+ u32 misc3 : 1;
+ } field;
+ u32 val;
+};
+
+#define NAC_CGU_DWORD24 0x60
+union nac_cgu_dword24 {
+ struct {
+ u32 tspll_fbdiv_frac : 22;
+ u32 misc20 : 2;
+ u32 ts_pll_enable : 1;
+ u32 time_sync_tspll_align_sel : 1;
+ u32 ext_synce_sel : 1;
+ u32 ref1588_ck_div : 4;
+ u32 time_ref_sel : 1;
+ } field;
+ u32 val;
+};
+
+#define TSPLL_CNTR_BIST_SETTINGS 0x344
+union tspll_cntr_bist_settings {
+ struct {
+ u32 i_irefgen_settling_time_cntr_7_0 : 8;
+ u32 i_irefgen_settling_time_ro_standby_1_0 : 2;
+ u32 reserved195 : 5;
+ u32 i_plllock_sel_0 : 1;
+ u32 i_plllock_sel_1 : 1;
+ u32 i_plllock_cnt_6_0 : 7;
+ u32 i_plllock_cnt_10_7 : 4;
+ u32 reserved200 : 4;
+ } field;
+ u32 val;
+};
+
+#define TSPLL_RO_BWM_LF 0x370
+union tspll_ro_bwm_lf {
+ struct {
+ u32 bw_freqov_high_cri_7_0 : 8;
+ u32 bw_freqov_high_cri_9_8 : 2;
+ u32 biascaldone_cri : 1;
+ u32 plllock_gain_tran_cri : 1;
+ u32 plllock_true_lock_cri : 1;
+ u32 pllunlock_flag_cri : 1;
+ u32 afcerr_cri : 1;
+ u32 afcdone_cri : 1;
+ u32 feedfwrdgain_cal_cri_7_0 : 8;
+ u32 m2fbdivmod_cri_7_0 : 8;
+ } field;
+ u32 val;
+};
+
+#endif /* _ICE_CGU_REGS_H_ */
diff --git a/drivers/net/ice/base/ice_ptp_consts.h
b/drivers/net/ice/base/ice_ptp_consts.h
index 2bd338c..4583dd4 100644
--- a/drivers/net/ice/base/ice_ptp_consts.h
+++ b/drivers/net/ice/base/ice_ptp_consts.h
@@ -83,4 +83,78 @@ const struct ice_time_
[dpdk-dev] [PATCH 4/4] net/ice: support IEEE 1588 PTP
Add ice support for new ethdev APIs to enable and read IEEE1588
PTP timstamps. Currently, only normal path supports 1588 PTP,
vector path doesn't.
The example command for running ptpclinet is as below:
./build/examples/dpdk-ptpclient -c 1 -n 3 --force-max-simd-bitwidth=64 --
-T 0 -p 0x1
Signed-off-by: Simei Su
---
drivers/net/ice/ice_ethdev.c | 226 ++-
drivers/net/ice/ice_ethdev.h | 5 +
drivers/net/ice/ice_rxtx.c | 42 +++-
drivers/net/ice/ice_rxtx.h | 1 +
4 files changed, 272 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 5fd5f99..1e76628 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -16,6 +16,7 @@
#include "base/ice_flow.h"
#include "base/ice_dcb.h"
#include "base/ice_common.h"
+#include "base/ice_ptp_hw.h"
#include "rte_pmd_ice.h"
#include "ice_ethdev.h"
@@ -27,6 +28,8 @@
#define ICE_PIPELINE_MODE_SUPPORT_ARG "pipeline-mode-support"
#define ICE_PROTO_XTR_ARG "proto_xtr"
+#define ICE_CYCLECOUNTER_MASK 0xULL
+
static const char * const ice_valid_args[] = {
ICE_SAFE_MODE_SUPPORT_ARG,
ICE_PIPELINE_MODE_SUPPORT_ARG,
@@ -137,6 +140,18 @@ static int ice_dev_udp_tunnel_port_add(struct rte_eth_dev
*dev,
struct rte_eth_udp_tunnel *udp_tunnel);
static int ice_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
struct rte_eth_udp_tunnel *udp_tunnel);
+static int ice_timesync_enable(struct rte_eth_dev *dev);
+static int ice_timesync_read_rx_timestamp(struct rte_eth_dev *dev,
+ struct timespec *timestamp,
+ uint32_t flags);
+static int ice_timesync_read_tx_timestamp(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+static int ice_timesync_adjust_time(struct rte_eth_dev *dev, int64_t delta);
+static int ice_timesync_read_time(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+static int ice_timesync_write_time(struct rte_eth_dev *dev,
+ const struct timespec *timestamp);
+static int ice_timesync_disable(struct rte_eth_dev *dev);
static const struct rte_pci_id pci_id_ice_map[] = {
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823L_BACKPLANE) },
@@ -220,6 +235,13 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
.udp_tunnel_port_del = ice_dev_udp_tunnel_port_del,
.tx_done_cleanup = ice_tx_done_cleanup,
.get_monitor_addr = ice_get_monitor_addr,
+ .timesync_enable = ice_timesync_enable,
+ .timesync_read_rx_timestamp = ice_timesync_read_rx_timestamp,
+ .timesync_read_tx_timestamp = ice_timesync_read_tx_timestamp,
+ .timesync_adjust_time = ice_timesync_adjust_time,
+ .timesync_read_time = ice_timesync_read_time,
+ .timesync_write_time = ice_timesync_write_time,
+ .timesync_disable = ice_timesync_disable,
};
/* store statistics names and its offset in stats structure */
@@ -3442,7 +3464,8 @@ ice_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
DEV_RX_OFFLOAD_QINQ_STRIP |
DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM |
DEV_RX_OFFLOAD_VLAN_EXTEND |
- DEV_RX_OFFLOAD_RSS_HASH;
+ DEV_RX_OFFLOAD_RSS_HASH |
+ DEV_RX_OFFLOAD_TIMESTAMP;
dev_info->tx_offload_capa |=
DEV_TX_OFFLOAD_QINQ_INSERT |
DEV_TX_OFFLOAD_IPV4_CKSUM |
@@ -5254,6 +5277,207 @@ ice_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
}
static int
+ice_timesync_enable(struct rte_eth_dev *dev)
+{
+ struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct ice_adapter *ad =
+ ICE_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
+ int ret;
+
+ if (hw->func_caps.ts_func_info.src_tmr_owned) {
+ ret = ice_ptp_init_phc(hw);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Failed to initialize PHC\n");
+ return -1;
+ }
+
+ ret = ice_ptp_write_incval(hw, ICE_PTP_NOMINAL_INCVAL_E810);
+ if (ret) {
+ PMD_DRV_LOG(ERR,
+ "Failed to write PHC increment time
value\n");
+ return -1;
+ }
+ }
+
+ /* Initialize cycle counters for system time/RX/TX timestamp */
+ memset(&ad->systime_tc, 0, sizeof(struct rte_timecounter));
+ memset(&ad->rx_tstamp_tc, 0, sizeof(struct rte_timecounter));
+ memset(&ad->tx_tstamp_tc, 0, sizeof(struct rte_timecounter));
+
+ ad->systime_tc.c
Re: [dpdk-dev] [PATCH v2] doc: announce change in crypto raw data vector
ping for review. On 8/5/2021 7:25 PM, Hemant Agrawal wrote: The current crypto raw data vectors need to be extended to support out of place processing. It is proposed to add additional desl_sgl to provide details for destination sgl. The same is also extended to support rte_security usecases, where we need total data length to know how much additional memory space is available in buffer other than data length so that driver/HW can write expanded size data after encryption. Signed-off-by: Gagandeep Singh Signed-off-by: Hemant Agrawal --- doc/guides/rel_notes/deprecation.rst | 12 1 file changed, 12 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index f4a4d00db2..c19a306c93 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -193,3 +193,15 @@ Deprecation Notices reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other information from the crypto/security operation. This field will be used to communicate events such as soft expiry with IPsec in lookaside mode. + +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add + ``dest_sgl`` to support out of place processing. This field will be null for + inplace processing. This change is targeted for DPDK 21.11 + +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add + ``tot_len`` to support total buffer length. This is required for security + cases like IPsec and PDCP encryption offload to know how much additional + memory space is available in buffer other than data length so that driver/HW + can write expanded size data after encryption. This change is targeted for + DPDK 21.11 +
