* RE: [PATCH 1/2] security: introduce per session event metadata
@ 2022-04-18 19:36 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-04-18 19:36 UTC (permalink / raw)
To: Gujjar, Abhinandan S, Volodymyr Fialko, dev, Jayatheerthan, Jay,
Vangati, Narender
Cc: Jerin Jacob Kollanukkaran, Anoob Joseph
Hi Abhinandan and others,
> We may need to stick to the approach introduced in this patch only.
> As if we propose, a new single API for all type of sessions, the driver would need
> to
> Get the event metadata from the session private data. This is not possible with
> Your use case which gets it inside the eventdev library for sw adapter case as it
> cannot
> Get the session private data without knowing the cdev_id.
>
> Hence, we will take this patch as is in next release for security sessions(as it is an
> ABI break)
> And would also introduce a similar change for crypto sessions in next release.
> This way we can get rid of using userdata which is wrong implementation.
On another thought, we have posted a new patchset to use event crypto adapter.
Please review and provide feedback.
Thanks,
Akhil
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
@ 2022-04-19 8:58 3% ` Thomas Monjalon
2022-04-19 10:14 3% ` [EXT] " Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-04-19 8:58 UTC (permalink / raw)
To: Akhil Goyal
Cc: dev, david.marchand, hemant.agrawal, anoobj, konstantin.ananyev,
ciara.power, ferruh.yigit, andrew.rybchenko, ndabilpuram,
vattunuru
16/04/2022 21:25, Akhil Goyal:
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -3828,6 +3828,12 @@ enum rte_eth_event_ipsec_subtype {
> RTE_ETH_EVENT_IPSEC_SA_TIME_EXPIRY,
> /** Soft byte expiry of SA */
> RTE_ETH_EVENT_IPSEC_SA_BYTE_EXPIRY,
> + /** Soft packet expiry of SA */
Is there a reference explaining what exactly is a "soft packet expiry"?
I think you should also mention what should be done
in the event handler.
> + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
> + /** Hard byte expiry of SA */
> + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
> + /** Hard packet expiry of SA */
> + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
Same comment for the 3 events.
> /** Max value of this enum */
> RTE_ETH_EVENT_IPSEC_MAX
> };
What is the impact of this "MAX" value on ABI compatibility?
^ permalink raw reply [relevance 3%]
* [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
@ 2022-04-19 9:01 15% Stephen Coleman
2022-04-19 15:44 0% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Stephen Coleman @ 2022-04-19 9:01 UTC (permalink / raw)
To: dev; +Cc: Ray Kinsella
From 1871ee6f7b98ef89b7c4893d90b5ea264660c201 Mon Sep 17 00:00:00 2001
From: youcai <omegacoleman@gmail.com>
Date: Tue, 19 Apr 2022 14:38:36 +0800
Subject: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
Cc: Ray Kinsella <mdr@ashroe.eu>
Same issue was fixed in ABI policy in ec5c0f8, but more of this
misuse persist in comments and docs. 'depreciated' means diminish
in value over a period of time. It should not appear here.
Signed-off-by: youcai <omegacoleman@gmail.com>
---
doc/guides/contributing/abi_policy.rst | 2 +-
doc/guides/contributing/abi_versioning.rst | 2 +-
lib/kni/rte_kni.h | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/guides/contributing/abi_policy.rst
b/doc/guides/contributing/abi_policy.rst
index 64919b6a2b..5fd4052585 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -167,7 +167,7 @@ The requirements for changing the ABI are:
API becomes non-experimental, then the old one is marked with
``__rte_deprecated``.
- - The depreciated API should follow the notification process to be removed,
+ - The deprecated API should follow the notification process to be removed,
see :ref:`deprecation_notices`.
- At the declaration of the next major ABI version, those ABI changes then
diff --git a/doc/guides/contributing/abi_versioning.rst
b/doc/guides/contributing/abi_versioning.rst
index dd96527ee5..7afd1c1886 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -94,7 +94,7 @@ that library.
...
However when a new ABI version is declared, for example DPDK ``22``, old
-depreciated functions may be safely removed at this point and the entire old
+deprecated functions may be safely removed at this point and the entire old
major ABI version removed, see the section :ref:`deprecating_entire_abi` on
how this may be done.
diff --git a/lib/kni/rte_kni.h b/lib/kni/rte_kni.h
index b85d3dd32b..f6ef572a82 100644
--- a/lib/kni/rte_kni.h
+++ b/lib/kni/rte_kni.h
@@ -64,8 +64,8 @@ struct rte_kni_conf {
uint32_t core_id; /* Core ID to bind kernel thread on */
uint16_t group_id; /* Group ID */
unsigned mbuf_size; /* mbuf size */
- struct rte_pci_addr addr; /* depreciated */
- struct rte_pci_id id; /* depreciated */
+ struct rte_pci_addr addr; /* deprecated */
+ struct rte_pci_id id; /* deprecated */
__extension__
uint8_t force_bind : 1; /* Flag to bind kernel thread */
--
2.17.1
^ permalink raw reply [relevance 15%]
* RE: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
2022-04-19 8:58 3% ` Thomas Monjalon
@ 2022-04-19 10:14 3% ` Akhil Goyal
2022-04-19 10:19 0% ` Anoob Joseph
2022-04-19 10:47 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2022-04-19 10:14 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, david.marchand, hemant.agrawal, Anoob Joseph,
konstantin.ananyev, ciara.power, ferruh.yigit, andrew.rybchenko,
Nithin Kumar Dabilpuram, Vamsi Krishna Attunuru
Hi Thomas,
> 16/04/2022 21:25, Akhil Goyal:
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -3828,6 +3828,12 @@ enum rte_eth_event_ipsec_subtype {
> > RTE_ETH_EVENT_IPSEC_SA_TIME_EXPIRY,
> > /** Soft byte expiry of SA */
> > RTE_ETH_EVENT_IPSEC_SA_BYTE_EXPIRY,
> > + /** Soft packet expiry of SA */
>
> Is there a reference explaining what exactly is a "soft packet expiry"?
SA expiry is a very common procedure in case of IPsec.
And all stacks must support this feature.
You can refer https://docs.strongswan.org/strongswan-docs/5.9/config/rekeying.html
For details.
Time expiry means after x seconds SA will expire.
Packet expiry means after x packets processing SA will expire.
Byte expiry means after x bytes of packet processing SA will expire.
> I think you should also mention what should be done
> in the event handler.
I believe this is quite obvious as per IPsec specifications.
Application need to start rekeying or SA need to be created again.
>
> > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
> > + /** Hard byte expiry of SA */
> > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
> > + /** Hard packet expiry of SA */
> > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
>
> Same comment for the 3 events.
>
> > /** Max value of this enum */
> > RTE_ETH_EVENT_IPSEC_MAX
> > };
>
> What is the impact of this "MAX" value on ABI compatibility?
I see no issues reported while running ABI check.
There is no array being used inside library based on MAX.
^ permalink raw reply [relevance 3%]
* RE: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
2022-04-19 10:14 3% ` [EXT] " Akhil Goyal
@ 2022-04-19 10:19 0% ` Anoob Joseph
2022-04-19 10:47 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Anoob Joseph @ 2022-04-19 10:19 UTC (permalink / raw)
To: Akhil Goyal, Thomas Monjalon
Cc: dev, david.marchand, hemant.agrawal, konstantin.ananyev,
ciara.power, ferruh.yigit, andrew.rybchenko,
Nithin Kumar Dabilpuram, Vamsi Krishna Attunuru
Hi Thomas, Akhil,
> Is there a reference explaining what exactly is a "soft packet expiry"?
The SA lifetime/expiry is described in security library.
https://elixir.bootlin.com/dpdk/latest/source/lib/security/rte_security.h#L295
Thanks,
Anoob
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, April 19, 2022 3:44 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; Anoob Joseph <anoobj@marvell.com>;
> konstantin.ananyev@intel.com; ciara.power@intel.com;
> ferruh.yigit@intel.com; andrew.rybchenko@oktetlabs.ru; Nithin Kumar
> Dabilpuram <ndabilpuram@marvell.com>; Vamsi Krishna Attunuru
> <vattunuru@marvell.com>
> Subject: RE: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event
> subtypes
>
> Hi Thomas,
>
> > 16/04/2022 21:25, Akhil Goyal:
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -3828,6 +3828,12 @@ enum rte_eth_event_ipsec_subtype {
> > > RTE_ETH_EVENT_IPSEC_SA_TIME_EXPIRY,
> > > /** Soft byte expiry of SA */
> > > RTE_ETH_EVENT_IPSEC_SA_BYTE_EXPIRY,
> > > + /** Soft packet expiry of SA */
> >
> > Is there a reference explaining what exactly is a "soft packet expiry"?
>
> SA expiry is a very common procedure in case of IPsec.
> And all stacks must support this feature.
> You can refer https://docs.strongswan.org/strongswan-
> docs/5.9/config/rekeying.html
> For details.
> Time expiry means after x seconds SA will expire.
> Packet expiry means after x packets processing SA will expire.
> Byte expiry means after x bytes of packet processing SA will expire.
>
> > I think you should also mention what should be done in the event
> > handler.
>
> I believe this is quite obvious as per IPsec specifications.
> Application need to start rekeying or SA need to be created again.
>
> >
> > > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
> > > + /** Hard byte expiry of SA */
> > > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
> > > + /** Hard packet expiry of SA */
> > > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
> >
> > Same comment for the 3 events.
> >
> > > /** Max value of this enum */
> > > RTE_ETH_EVENT_IPSEC_MAX
> > > };
> >
> > What is the impact of this "MAX" value on ABI compatibility?
> I see no issues reported while running ABI check.
> There is no array being used inside library based on MAX.
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
2022-04-19 10:14 3% ` [EXT] " Akhil Goyal
2022-04-19 10:19 0% ` Anoob Joseph
@ 2022-04-19 10:47 0% ` Thomas Monjalon
2022-04-19 12:27 0% ` Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-04-19 10:47 UTC (permalink / raw)
To: Akhil Goyal
Cc: dev, david.marchand, hemant.agrawal, Anoob Joseph,
konstantin.ananyev, ciara.power, ferruh.yigit, andrew.rybchenko,
Nithin Kumar Dabilpuram, Vamsi Krishna Attunuru, mdr
19/04/2022 12:14, Akhil Goyal:
> Hi Thomas,
>
> > 16/04/2022 21:25, Akhil Goyal:
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -3828,6 +3828,12 @@ enum rte_eth_event_ipsec_subtype {
> > > RTE_ETH_EVENT_IPSEC_SA_TIME_EXPIRY,
> > > /** Soft byte expiry of SA */
> > > RTE_ETH_EVENT_IPSEC_SA_BYTE_EXPIRY,
> > > + /** Soft packet expiry of SA */
> >
> > Is there a reference explaining what exactly is a "soft packet expiry"?
>
> SA expiry is a very common procedure in case of IPsec.
> And all stacks must support this feature.
> You can refer https://docs.strongswan.org/strongswan-docs/5.9/config/rekeying.html
> For details.
> Time expiry means after x seconds SA will expire.
> Packet expiry means after x packets processing SA will expire.
> Byte expiry means after x bytes of packet processing SA will expire.
I think you should use the syntax @ref packets_soft_limit
so it is clear where the event come from.
> > I think you should also mention what should be done
> > in the event handler.
>
> I believe this is quite obvious as per IPsec specifications.
> Application need to start rekeying or SA need to be created again.
Yes indeed.
> > > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
> > > + /** Hard byte expiry of SA */
> > > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
> > > + /** Hard packet expiry of SA */
> > > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
> >
> > Same comment for the 3 events.
> >
> > > /** Max value of this enum */
> > > RTE_ETH_EVENT_IPSEC_MAX
> > > };
> >
> > What is the impact of this "MAX" value on ABI compatibility?
>
> I see no issues reported while running ABI check.
> There is no array being used inside library based on MAX.
No need of array inside the library, the events are exposed to the app.
I'm surprised libabigail is OK with changing an enum value.
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
2022-04-19 10:47 0% ` Thomas Monjalon
@ 2022-04-19 12:27 0% ` Akhil Goyal
2022-04-19 15:41 0% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-04-19 12:27 UTC (permalink / raw)
To: Thomas Monjalon, mdr
Cc: dev, david.marchand, hemant.agrawal, Anoob Joseph,
konstantin.ananyev, ciara.power, ferruh.yigit, andrew.rybchenko,
Nithin Kumar Dabilpuram, Vamsi Krishna Attunuru
> > Time expiry means after x seconds SA will expire.
> > Packet expiry means after x packets processing SA will expire.
> > Byte expiry means after x bytes of packet processing SA will expire.
>
> I think you should use the syntax @ref packets_soft_limit
> so it is clear where the event come from.
OK will update the comments.
>
>
> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
> > > > + /** Hard byte expiry of SA */
> > > > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
> > > > + /** Hard packet expiry of SA */
> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
> > >
> > > Same comment for the 3 events.
> > >
> > > > /** Max value of this enum */
> > > > RTE_ETH_EVENT_IPSEC_MAX
> > > > };
> > >
> > > What is the impact of this "MAX" value on ABI compatibility?
> >
> > I see no issues reported while running ABI check.
> > There is no array being used inside library based on MAX.
>
> No need of array inside the library, the events are exposed to the app.
> I'm surprised libabigail is OK with changing an enum value.
>
@Ray Can you please check if it is an issue to add more values in this enum?
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
2022-04-19 12:27 0% ` Akhil Goyal
@ 2022-04-19 15:41 0% ` Ray Kinsella
2022-04-20 13:51 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-04-19 15:41 UTC (permalink / raw)
To: Akhil Goyal
Cc: Thomas Monjalon, dev, david.marchand, hemant.agrawal,
Anoob Joseph, konstantin.ananyev, ciara.power, ferruh.yigit,
andrew.rybchenko, Nithin Kumar Dabilpuram,
Vamsi Krishna Attunuru
Akhil Goyal <gakhil@marvell.com> writes:
>> > Time expiry means after x seconds SA will expire.
>> > Packet expiry means after x packets processing SA will expire.
>> > Byte expiry means after x bytes of packet processing SA will expire.
>>
>> I think you should use the syntax @ref packets_soft_limit
>> so it is clear where the event come from.
>
> OK will update the comments.
>
>>
>>
>> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
>> > > > + /** Hard byte expiry of SA */
>> > > > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
>> > > > + /** Hard packet expiry of SA */
>> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
>> > >
>> > > Same comment for the 3 events.
>> > >
>> > > > /** Max value of this enum */
>> > > > RTE_ETH_EVENT_IPSEC_MAX
>> > > > };
>> > >
>> > > What is the impact of this "MAX" value on ABI compatibility?
>> >
>> > I see no issues reported while running ABI check.
>> > There is no array being used inside library based on MAX.
>>
>> No need of array inside the library, the events are exposed to the app.
>> I'm surprised libabigail is OK with changing an enum value.
>>
> @Ray Can you please check if it is an issue to add more values in this enum?
Well look there is two seperate things going on here.
Why isn't libabigail complaining about the _MAX value changing. I'll
need to look at libabigail to see what the issue is, so lets put this
one aside for a moment.
This second issue is it safe for the _MAX value to change?
We have a lot of back and forth argument on these, and previously
concluded that we should probably look to remove _MAX values in the
22.11 release.
The core issue is that we need look at how a user is likely to use
rte_eth_event_ipsec_subtype. Take a look at the example below:-
/root/src/dpdk/examples/ipsec-secgw/ipsec-secgw.c:2592:0
For instance, can we guarantee that an application built against DPDK
21.11, but running against 22.xx will never recieve one of the new
values in event_desc->subtype (or by any other means)?
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
2022-04-19 9:01 15% [PATCH] doc: fix typos 'depreciated' instead of 'deprecated' Stephen Coleman
@ 2022-04-19 15:44 0% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2022-04-19 15:44 UTC (permalink / raw)
To: Stephen Coleman; +Cc: dev
Stephen Coleman <omegacoleman@gmail.com> writes:
> From 1871ee6f7b98ef89b7c4893d90b5ea264660c201 Mon Sep 17 00:00:00 2001
> From: youcai <omegacoleman@gmail.com>
> Date: Tue, 19 Apr 2022 14:38:36 +0800
> Subject: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
> Cc: Ray Kinsella <mdr@ashroe.eu>
>
> Same issue was fixed in ABI policy in ec5c0f8, but more of this
> misuse persist in comments and docs. 'depreciated' means diminish
> in value over a period of time. It should not appear here.
>
> Signed-off-by: youcai <omegacoleman@gmail.com>
> ---
> doc/guides/contributing/abi_policy.rst | 2 +-
> doc/guides/contributing/abi_versioning.rst | 2 +-
> lib/kni/rte_kni.h | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 0%]
* Re: 21.11.1 patches review and test
@ 2022-04-20 5:50 3% ` Christian Ehrhardt
2022-04-25 13:39 0% ` Kevin Traynor
0 siblings, 1 reply; 200+ results
From: Christian Ehrhardt @ 2022-04-20 5:50 UTC (permalink / raw)
To: Kevin Traynor
Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, hariprasad.govindharajan, Hemant Agrawal,
Ian Stokes, Jerin Jacob, John McNamara, Ju-Hyoung Lee,
Luca Boccassi, Pei Zhang, qian.q.xu, Raslan Darawsheh,
Thomas Monjalon, yuan.peng, zhaoyan.chen
On Fri, Apr 1, 2022 at 12:22 PM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.1.
>
> Please try and complete validation by April 13th.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.1-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
Hi Kevin,
now that the ABI change discussion has somewhat settled I have run the
tests ignoring the symbols changes for now.
All LGTM on Ubuntu 22.04 + OVS 2.17 + DPDK 21.11.1-rc1
1.0.0 (11:42:53): phys (BM) tests
1.1.0 (11:42:53): initialize environment
1.1.1 (11:44:54): testpmd => Pass
1.1.2 (11:45:43): check testpmd output => Pass
2.0.0 (11:45:43): prep virtual test environment
1.0.0 (11:48:05): virt tests
1.1.0 (11:48:05): initialize environment
3.0.0 (11:49:30): performance tests
3.1.0 (11:49:30): prep benchmarks
3.2.0 (11:49:51): performance tests
3.2.1 (11:50:02): test guest-openvswitch for OVS-5CPU => Pass
3.2.2 (12:09:30): test guest-dpdk-vhost-user-client-multiq for
OVSDPDK-VUC => Pass
4.0.0 (12:28:54): VUC endurance checks
4.1.0 (12:28:54): prep VUC endurance tests
4.1.1 (12:41:59): start stop guests (client) => Pass
4.1.2 (13:48:30): add/remove ports (client) => Pass
4.2.0 (13:58:11): Final cleanup
The above is kind of a high level test log, for the validation section
of a stable release I usually use:
* Build tests of DPDK & OVS 2.13.3 on Ubuntu 20.04 (meson based)
* Functional and performance tests based on OVS-DPDK on x86_64
* Autopkgtests for DPDK and OpenvSwitch
> Thanks.
>
> Kevin
>
> ---
> Adham Masarwah (2):
> net/mlx5: fix destroying empty matchers list
> app/testpmd: fix show RSS RETA on Windows
>
> Ajit Khaparde (7):
> net/bnxt: fix ring teardown
> net/bnxt: fix PAM4 mask setting
> net/bnxt: fix crash by validating pointer
> net/bnxt: check VF representor pointer before access
> net/bnxt: fix VF resource allocation strategy
> net/bnxt: set HW coalescing parameters
> net/bnxt: fix ring calculation for representors
>
> Alexander Kozyrev (4):
> net/mlx5: fix maximum packet headers size for TSO
> net/mlx5: fix MPRQ WQE size assertion
> net/mlx5: fix committed bucket size
> net/mlx5: fix meter capabilities reporting
>
> Ali Alnubani (1):
> doc: fix typos and punctuation in flow API guide
>
> Anatoly Burakov (1):
> net/qede: fix redundant condition in debug code
>
> Andy Pei (1):
> vdpa/ifc: fix log info mismatch
>
> Ankur Dwivedi (1):
> common/cnxk: fix NPC key extraction validation
>
> Anoob Joseph (4):
> common/cnxk: fix reset of fields
> crypto/cnxk: fix inflight count calculation
> crypto/cnxk: fix extend tail calculation
> crypto/cnxk: fix update of number of descriptors
>
> Arek Kusztal (1):
> cryptodev: fix RSA key type name
>
> Asaf Ravid (1):
> net/cnxk: fix promiscuous mode in multicast enable flow
>
> Ashwin Sekhar T K (1):
> mempool/cnxk: fix batch allocation failure path
>
> Bin Zheng (1):
> net/ixgbe: add vector Rx parameter check
>
> Bing Zhao (5):
> common/mlx5: fix probing failure code
> app/testpmd: fix raw encap of GENEVE option
> net/mlx5: fix matcher priority with ICMP or ICMPv6
> net/mlx5: remove unused reference counter
> net/mlx5: fix configuration without Rx queue
>
> Brian Dooley (13):
> eal: add missing C++ guards
> telemetry: add missing C++ guards
> ethdev: add missing C++ guards
> metrics: add missing C++ guards
> acl: add missing C++ guards
> compressdev: add missing C++ guards
> eventdev: add missing C++ guards
> kni: add missing C++ guards
> vhost: add missing C++ guards
> bpf: add missing C++ guards
> cryptodev: add missing C++ guards
> examples/l2fwd-crypto: fix port mask overflow
> crypto/virtio: fix out-of-bounds access
>
> Bruce Richardson (23):
> doc: remove dependency on findutils on FreeBSD
> dma/idxd: fix burst capacity calculation
> dma/idxd: fix paths to driver sysfs directory
> dma/idxd: fix wrap-around in burst capacity calculation
> build: fix warnings when running external commands
> build: remove deprecated Meson functions
> eal: fix C++ include
> eventdev: fix C++ include
> graph: fix C++ include
> ipsec: fix C++ include
> table: fix C++ include
> vhost: fix C++ include
> ethdev: fix cast for C++ compatibility
> test/dma: fix missing checks for device capacity
> dma/idxd: configure maximum batch size to high value
> doc: improve configuration examples in idxd guide
> distributor: fix potential overflow
> eal/freebsd: add missing C++ include guards
> compressdev: fix missing space in log macro
> cryptodev: fix clang C++ include
> eventdev: fix clang C++ include
> doc: replace characters for (R) symbol in Linux guide
> doc: fix missing note on UIO module in Linux guide
>
> Chandubabu Namburu (1):
> net/axgbe: use PCI root complex device to distinguish device
>
> Chenbo Xia (1):
> vhost: fix queue number check when setting inflight FD
>
> Chengchang Tang (1):
> net/bonding: fix offloading configuration
>
> Chengwen Feng (2):
> net/hns3: delete duplicated RSS type
> dma/hisilicon: use common PCI device naming
>
> Chuanshe Zhang (1):
> examples/flow_classify: fix failure message
>
> Ciara Loftus (2):
> net/af_xdp: fix build with -Wunused-function
> net/af_xdp: ensure socket is deleted on Rx queue setup error
>
> Ciara Power (4):
> crypto/ipsec_mb: fix queue setup null pointer dereference
> crypto/ipsec_mb: fix queue cleanup null pointer dereference
> crypto/ipsec_mb: fix tainted data for session
> crypto/ipsec_mb: remove useless check
>
> Cristian Dumitrescu (2):
> pipeline: fix annotation checks
> pipeline: fix table state memory allocation
>
> Dapeng Yu (2):
> net/ice: track DCF state of PF
> net/i40e: enable maximum frame size at port level
>
> Dariusz Sosnowski (3):
> net/mlx5: fix inline length for multi-segment TSO
> net/mlx5: fix MPLS/GRE Verbs spec ordering
> net/mlx5: fix VLAN push action validation
>
> David Marchand (8):
> devtools: fix comment detection in forbidden token check
> stack: fix stubs header export
> test/mbuf: fix mbuf data content check
> ethdev: fix MAC address in telemetry device info
> net/af_xdp: add missing trailing newline in logs
> devtools: remove event/dlb exception in ABI check
> vhost: fix FD leak with inflight messages
> bpf: fix build with some libpcap version on FreeBSD
>
> Dawid Gorecki (2):
> net/ena: fix reset reason being overwritten
> net/ena: check memory BAR before initializing LLQ
>
> Devendra Singh Rawat (3):
> net/qede: fix Tx completion
> net/qede: fix Rx bulk
> net/qede: fix maximum Rx packet length
>
> Dmitry Kozlyuk (8):
> net/mlx5: fix GCC uninitialized variable warning
> net/mlx5: relax headroom assertion
> app/testpmd: fix external buffer allocation
> common/mlx5: fix MR lookup for non-contiguous mempool
> common/mlx5: add Netlink event helpers
> net/mlx5: fix link status change detection
> net/mlx5: fix initial link status detection
> net/mlx5: fix modify port action validation
>
> Elena Agostini (3):
> gpu/cuda: fix memory list cleanup
> doc: add CUDA driver features
> gpu/cuda: fix dependency loading path
>
> Ferruh Yigit (2):
> net/bonding: fix MTU set for slaves
> ethdev: fix doxygen comments for device info struct
>
> Geoffrey Le Gourriérec (1):
> net/bnxt: restore dependency on kernel modules
>
> Gerry Gribbon (1):
> app/regex: fix number of matches
>
> Gowrishankar Muthukrishnan (6):
> event/cnxk: fix variables casting
> event/cnxk: fix uninitialized local variables
> common/cnxk: add missing checks of return values
> common/cnxk fix unintended sign extension
> common/cnxk: fix uninitialized pointer read
> net/cnxk: fix uninitialized local variable
>
> Gregory Etelson (10):
> net/mlx5: fix RSS expansion with explicit next protocol
> net/mlx5: fix GRE protocol type translation for Verbs
> net/mlx5: fix GRE item translation in Verbs
> net/mlx5: reduce flex item flow handle size
> net/mlx5: fix flex item header length translation
> net/mlx5: fix inet IPIP protocol type
> net/mlx5: fix next protocol RSS expansion
> net/mlx5: fix flex item availability
> app/testpmd: fix GTP header parsing in checksum engine
> app/testpmd: fix flow rule with flex input link
>
> Haiyue Wang (2):
> net/iavf: remove git residue symbol
> doc: fix KNI PMD name typo
>
> Harman Kalra (3):
> common/cnxk: reset stale values on error debug registers
> common/cnxk: always use single interrupt ID with NIX
> common/cnxk: fix mbuf data offset for VF
>
> Harold Huang (2):
> net/virtio-user: fix resource leak on probing failure
> net/kni: fix config initialization
>
> Heinrich Kuhn (1):
> net/nfp: free HW ring memzone on queue release
>
> Hemant Agrawal (1):
> crypto/dpaax_sec: fix auth/cipher xform chain checks
>
> Honnappa Nagarahalli (3):
> examples/distributor: reduce Tx queue number to 1
> examples/l3fwd: share queue size variables
> examples/l3fwd: make Rx and Tx queue size configurable
>
> Huisong Li (10):
> net/hns3: fix mailbox wait time
> net/hns3: fix using enum as boolean
> net/hns3: fix max packet size rollback in PF
> net/hns3: fix insecure way to query MAC statistics
> net/hns3: fix double decrement of secondary count
> net/hns3: fix operating queue when TCAM table is invalid
> kni: fix freeing order in device release
> net/hns3: fix RSS TC mode entry
> net/hns3: fix VF RSS TC mode entry
> net/hns3: increase time waiting for PF reset completion
>
> Ivan Malov (8):
> net/sfc: validate queue span when parsing flow action RSS
> net/sfc: fix lock releases
> net/sfc: do not push fast free offload to default TxQ config
> net/sfc: demand Tx fast free offload on EF10 simple datapath
> common/sfc_efx/base: fix recirculation ID set in outer rules
> common/sfc_efx/base: add missing handler for 1-byte fields
> net/sfc: fix flow tunnel support detection
> net/sfc: reduce log level of tunnel restore info error
>
> Jakub Poczatek (1):
> doc: fix FIPS guide
>
> Jiawei Wang (4):
> net/mlx5: fix NIC egress flow mismatch in switchdev mode
> net/mlx5: fix sample flow action on trusted device
> net/mlx5: fix implicit tag insertion with sample action
> net/mlx5: fix port matching in sample flow rule
>
> Jiawen Wu (8):
> net/ngbe: fix Rx by initializing packet buffer early
> net/ngbe: fix missed link interrupt
> net/ngbe: fix Tx hang on queue disable
> net/ngbe: fix packet statistics
> net/txgbe: fix link up and down
> net/txgbe: fix KR auto-negotiation
> net/ngbe: fix debug logs
> net/txgbe: fix debug logs
>
> Jie Hai (1):
> net/hns3: remove duplicate macro definition
>
> Jie Wang (1):
> net: fix L2TPv2 common header
>
> Jie Zhou (2):
> eal/windows: fix error code for not supported API
> test/mem: fix error check
>
> Josh Soref (1):
> fix spelling in comments and strings
>
> Junfeng Guo (3):
> net/ice: fix pattern check for flow director parser
> net/ice: fix pattern check in flow director
> raw/ntb: clear all valid doorbell bits on init
>
> Junjie Wan (1):
> net/bonding: fix slaves initializing on MTU setting
>
> Junxiao Shi (1):
> net/af_xdp: fix custom program loading with multiple queues
>
> Juraj Linkeš (1):
> config/arm: add values for native armv7
>
> Kai Ji (2):
> test/crypto: fix out-of-place SGL in raw datapath
> crypto/qat: fix GEN4 AEAD job in raw data path
>
> Kalesh AP (15):
> net/bnxt: fix multicast address set
> net/bnxt: fix multicast MAC restore during reset recovery
> net/bnxt: fix queue stop operation
> net/bnxt: restore RSS configuration after reset recovery
> net/bnxt: fix restoring VLAN filtering after recovery
> net/bnxt: cap maximum number of unicast MAC addresses
> net/bnxt: set fast-path pointers only if recovery succeeds
> net/bnxt: add null check for mark table
> net/bnxt: fix flow create when RSS is disabled
> net/bnxt: get maximum supported multicast filters count
> net/bnxt: fix handling of VF configuration change
> net/bnxt: fix xstats query
> net/bnxt: fix check for autoneg enablement
> net/bnxt: handle ring cleanup in case of error
> net/bnxt: fix memzone allocation per VNIC
>
> Karl Bonde Torp (1):
> build: fix build on FreeBSD with Meson 0.61.1
>
> Kathleen Capella (2):
> net/iavf: count continuous DD bits for Arm
> net/iavf: count continuous DD bits for Arm in flex Rx
>
> Kevin Liu (2):
> net/ice: fix Tx checksum offload
> net/ice: fix Tx offload path choice
>
> Kevin Traynor (4):
> maintainers: update for stable branches
> build: suppress rte_crypto_asym_op abi check
> Revert "crypto/ipsec_mb: fix length and offset settings"
> Revert "net/mlx5: fix flex item availability"
>
> Kumara Parameshwaran (2):
> ethdev: add internal function to device struct from name
> net/tap: fix to populate FDs in secondary process
>
> Lance Richardson (2):
> buildtools: fix AVX512 check for Python 3.5
> net/bnxt: fix xstats names query overrun
>
> Leyi Rong (1):
> net/iavf: fix potential out-of-bounds access
>
> Lijun Ou (1):
> net/hns3: fix RSS key with null
>
> Lior Margalit (1):
> net/mlx5: fix assertion on flags set in packet mbuf
>
> Madhuker Mythri (1):
> devargs: fix crash with uninitialized parsing
>
> Martijn Bakker (1):
> pflock: fix header file installation
>
> Martin Spinler (2):
> net/nfb: fix array indexes in deinit functions
> net/nfb: fix multicast/promiscuous mode switching
>
> Marvin Liu (1):
> net/virtio: fix slots number when indirect feature on
>
> Matan Azrad (1):
> vdpa/mlx5: workaround queue stop with traffic
>
> Maxime Coquelin (1):
> vhost: fix unsafe vring addresses modifications
>
> Maxime Gouin (3):
> bus/ifpga: remove useless check while browsing devices
> net/nfp: remove duplicated check when setting MAC address
> net/nfp: remove useless range checks
>
> Megha Ajmera (1):
> examples/qos_sched: fix core mask overflow
>
> Michael Baum (17):
> common/mlx5: add minimum WQE size for striding RQ
> net/mlx5: improve stride parameter names
> net/mlx5: fix MPRQ stride devargs adjustment
> common/mlx5: fix error handling in multi-class probe
> net/mlx5: fix memory socket selection in ASO management
> common/mlx5: fix missing validation in devargs parsing
> net/mlx5: fix sibling device config check
> net/mlx5: fix ineffective metadata argument adjustment
> net/mlx5: fix ASO CT object release
> net/mlx5: fix errno update in shared context creation
> net/mlx5: fix entry in shared Rx queues list
> doc: remove obsolete vector Tx explanations from mlx5 guide
> doc: replace broken links in mlx guides
> doc: correct name of BlueField-2 in mlx5 guide
> net/mlx5: fix shared counter flag in flow validation
> net/mlx5: fix check in count action validation
> common/mlx5: consider local functions as internal
>
> Michal Krawczyk (6):
> net/ena: remove unused enumeration
> net/ena: remove unused offload variables
> net/ena: skip timer if reset is triggered
> net/ena: fix meta descriptor DF flag setup
> net/ena: fix checksum flag for L4
> bus/pci: assign driver pointer before mapping
>
> Michal Wilczynski (1):
> net/ice: fix overwriting of LSE bit by DCF
>
> Min Hu (Connor) (6):
> net/hns3: fix Rx/Tx functions update
> net/hns3: fix vector Rx/Tx when PTP enabled
> net/bonding: fix promiscuous and allmulticast state
> net/bonding: fix reference count on mbufs
> app/testpmd: fix bonding mode set
> app/testpmd: check starting port is not in bonding
>
> Naga Harish K S V (2):
> eventdev/eth_tx: fix queue add error code
> eventdev/eth_rx: fix queue config query
>
> Nicolas Chautru (1):
> baseband/acc100: avoid out-of-bounds access
>
> Nipun Gupta (1):
> examples/l3fwd: fix Rx burst size for event mode
>
> Nithin Dabilpuram (11):
> examples/ipsec-secgw: fix eventdev start sequence
> examples/ipsec-secgw: fix default flow rule creation
> common/cnxk: fix shift offset for TL3 length disable
> common/cnxk: fix byte order of frag sizes and infos
> common/cnxk: fix null pointer dereferences
> common/cnxk: fix uninitialized variables
> examples/ipsec-secgw: fix buffer freeing in vector mode
> net/cnxk: fix inline device RQ tag mask
> net/cnxk: register callback early to handle initial packets
> net/cnxk: fix inline IPsec security error handling
> common/cnxk: fix bitmap usage for TM
>
> Pablo de Lara (9):
> crypto/ipsec_mb: fix buffer overrun
> crypto/ipsec_mb: check missing operation types
> crypto/ipsec_mb: fix ZUC authentication verify
> crypto/ipsec_mb: fix ZUC operation overwrite
> crypto/ipsec_mb: fix length and offset settings
> test/efd: fix sockets mask size
> efd: fix uninitialized structure
> crypto/ipsec_mb: fix length and offset settings
> crypto/ipsec_mb: fix GMAC parameters setting
>
> Pavan Nikhilesh (6):
> eventdev/eth_rx: fix missing internal port checks
> event/cnxk: fix QoS devargs parsing
> common/cnxk: add workaround for vWQE flush
> config: align mempool elements to 128 bytes on CN10K
> event/cnxk: fix sub-event clearing mask length
> event/cnxk: fix Rx adapter config check
>
> Peng Yu (1):
> vhost: fix linker script syntax
>
> Piotr Bronowski (2):
> crypto/ipsec_mb: fix premature dereference
> crypto/ipsec_mb: fix GCM requested digest length
>
> Qi Zhang (2):
> net/ice: fix Tx checksum offload capability
> doc: update matching versions in ice guide
>
> Radu Nicolau (5):
> examples/ipsec-secgw: fix offload flag used for TSO IPv6
> net/iavf: fix segmentation offload condition
> net/iavf: fix segmentation offload buffer size
> net/iavf: support NAT-T / UDP encapsulation
> net/iavf: fix AES-GMAC IV size
>
> Rahul Bhansali (2):
> net/cnxk: fix mbuf data length
> examples/l3fwd: fix buffer overflow in Tx
>
> Rahul Lakkireddy (1):
> net/cxgbe: fix dangling pointer by mailbox access rework
>
> Raja Zidane (8):
> net/mlx5: fix mark enabling for Rx
> app/testpmd: fix GENEVE parsing in checksum mode
> app/compress-perf: fix cycle count operations allocation
> app/compress-perf: optimize operations pool allocation
> compress/mlx5: support out-of-space status
> app/compress-perf: fix socket ID type during init
> app/compress-perf: fix number of queue pairs to setup
> compressdev: fix socket ID type
>
> Rakesh Kudurumalla (2):
> net/cnxk: fix build with GCC 12
> net/cnxk: fix RSS RETA table update
>
> Rashmi Shetty (1):
> doc: fix dlb2 guide
>
> Reshma Pattan (1):
> app/pdump: abort on multi-core capture limit
>
> Rongwei Liu (3):
> net/mlx5: fix shared RSS destroy
> net/mlx5: fix meter creation default state
> net/mlx5: forbid multiple ASO actions in a single rule
>
> Ruifeng Wang (1):
> config: add arch define for Arm
>
> Satheesh Paul (5):
> common/cnxk: fix nibble parsing order when dumping MCAM
> common/cnxk: fix flow deletion
> common/cnxk: fix log level during MCAM allocation
> common/cnxk: fix base rule merge
> net/cnxk: fix Rx/Tx function update
>
> Sean Morrissey (2):
> app/testpmd: fix dereference before null check
> doc: fix telemetry example in cryptodev guide
>
> Shijith Thotton (1):
> crypto/cnxk: enable allocated queues only
>
> Shun Hao (3):
> net/mlx5: fix meter sub-policy creation
> net/mlx5: fix E-Switch manager vport ID
> net/mlx5: fix meter policy creation assert
>
> Simei Su (1):
> net/ice: fix mbuf offload flag for Rx timestamp
>
> Srikanth Yalavarthi (1):
> dma/cnxk: fix installing internal headers
>
> Stephen Douthit (1):
> net/ixgbe: fix FSP check for X550EM devices
>
> Stephen Hemminger (7):
> eal/linux: log hugepage create errors with filename
> net/memif: remove unnecessary Rx interrupt stub
> ipc: end multiprocess thread during cleanup
> vfio: cleanup the multiprocess sync handle
> pcapng: handle failure of link status query
> test/bpf: skip dump if conversion fails
> app/dumpcap: check for failure to set promiscuous
>
> Steve Yang (4):
> app/testpmd: fix stack overflow for EEPROM display
> net/i40e: fix unintentional integer overflow
> eal/linux: fix illegal memory access in uevent handler
> net/iavf: fix function pointer in multi-process
>
> Suanming Mou (3):
> net/mlx5: set flow error for hash list create
> net/mlx5: remove unused function
> net/mlx5: fix indexed pool fetch overlap
>
> Thinh Tran (1):
> net/mlx5: fix CPU socket ID for Rx queue creation
>
> Thomas Monjalon (6):
> doc: replace deprecated distutils version parsing
> dmadev: add missing header include
> app/testpmd: fix build without drivers
> regexdev: fix section attribute of symbols
> build: hide local symbols in shared libraries
> devtools: fix symbols check
>
> Tianfei Zhang (2):
> raw/ifpga/base: fix SPI transaction
> raw/ifpga: fix thread closing
>
> Tianli Lai (1):
> examples/kni: add missing trailing newline in log
>
> Timothy McDaniel (3):
> event/dlb2: update rolling mask used for dequeue
> event/dlb2: poll HW CQ inflights before mapping queue
> event/dlb2: add shift value check in sparse dequeue
>
> Vanshika Shukla (2):
> net/dpaa2: fix unregistering interrupt handler
> net/dpaa2: fix timestamping for IEEE1588
>
> Viacheslav Ovsiienko (4):
> net/mlx5: fix modify field MAC address offset
> app/testpmd: fix Tx scheduling interval
> net/mlx5: fix metadata endianness in modify field action
> doc: fix modify field action description for mlx5
>
> Vladimir Medvedkin (1):
> app/fib: fix division by zero
>
> Wei Huang (5):
> raw/ifpga/base: fix port feature ID
> raw/ifpga: fix variable initialization in probing
> raw/ifpga: fix interrupt handle allocation
> raw/ifpga: fix monitor thread
> raw/ifpga: fix build with optimization
>
> Weiguo Li (14):
> common/cnxk: fix error checking
> net/enic: fix dereference before null check
> net/dpaa2: fix null pointer dereference
> regex/mlx5: fix memory allocation check
> net/memif: remove pointer deference before null check
> net/iavf: fix null pointer dereference
> vdpa/sfc: fix null dereference during config
> vdpa/sfc: fix null dereference during removal
> compress/octeontx: fix null pointer dereference
> eventdev/eth_rx: fix parameters parsing memory leak
> net/sfc: fix memory allocation size for cache
> net/txgbe: fix queue statistics mapping
> sched: remove useless malloc in PIE data init
> net/bnxt: fix null dereference in session cleanup
>
> Wenwu Ma (1):
> examples/vhost: fix launch with physical port
>
> Wenxuan Wu (1):
> eal/linux: fix device monitor stop return
>
> Xiaoyu Min (1):
> net/mlx5: reject jump to root table
>
> Xuan Ding (2):
> vhost: fix field naming in guest page struct
> vhost: fix physical address mapping
>
> Xueming Li (1):
> net/virtio: fix Tx queue 0 overriden by queue 128
>
> Yajun Wu (1):
> common/mlx5: fix queue pair ack timeout configuration
>
> Yiding Zhou (1):
> net/ice: fix build with 16-byte Rx descriptor
>
> Yu Wenjun (1):
> net/bonding: fix RSS with early configure
>
> Yuan Wang (1):
> vhost: fix guest to host physical address mapping
>
> Yunjian Wang (12):
> net/bonding: fix mode type mismatch
> ethdev: fix Rx queue telemetry memory leak on failure
> net/ice: fix link up when starting device
> net/virtio-user: check FD flags getting failure
> net/virtio: fix uninitialized RSS key
> ring: fix error code when creating ring
> net/ixgbe: check filter init failure
> mem: check allocation in dynamic hugepage init
> ethdev: remove unnecessary null check
> net/ixgbe: reset security context pointer on close
> net/txgbe: reset security context pointer on close
> net/iavf: reset security context pointer on stop
>
> Yuying Zhang (1):
> net/ice/base: add profile validation on switch filter
>
> Zhihong Wang (1):
> ring: fix overflow in memory size calculation
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
^ permalink raw reply [relevance 3%]
* RE: [RFC] eal: add bus cleanup to eal cleanup
@ 2022-04-20 6:55 4% ` Morten Brørup
2022-04-22 9:18 4% ` Kevin Laatz
1 sibling, 1 reply; 200+ results
From: Morten Brørup @ 2022-04-20 6:55 UTC (permalink / raw)
To: Kevin Laatz, dev
> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
> Sent: Tuesday, 19 April 2022 18.15
>
> During EAL init, all buses are probed and the devices found are
> initialized. On eal_cleanup(), the inverse does not happen, meaning any
> allocated memory and other configuration will not be cleaned up
> appropriately on exit.
>
> Currently, in order for device cleanup to take place, applications must
> call the driver-relevant functions to ensure proper cleanup is done
> before
> the application exits. Since initialization occurs for all devices on
> the
> bus, not just the devices used by an application, it requires a)
> application awareness of all bus devices that could have been probed on
> the
> system, and b) code duplication across applications to ensure cleanup
> is
> performed. An example of this is rte_eth_dev_close() which is commonly
> used
> across the example applications.
>
> This RFC proposes adding bus cleanup to the eal_cleanup() to make EAL's
> init/exit more symmetrical, ensuring all bus devices are cleaned up
> appropriately without the application needing to be aware of all bus
> types
> that may have been probed during initialization.
>
> Contained in this RFC are the changes required to perform cleanup for
> devices on the PCI bus during eal_cleanup(). This can be expanded in
> subsequent versions if these changes are desired. There would be an ask
> for
> bus maintainers to add the relevant cleanup for their buses since they
> have
> the domain expertise.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> ---
[...]
> + RTE_LOG(INFO, EAL,
> + "Clean up PCI driver: %s (%x:%x) device:
> "PCI_PRI_FMT" (socket %i)\n",
> + drv->driver.name, dev->id.vendor_id, dev-
> >id.device_id,
> + loc->domain, loc->bus, loc->devid, loc-
> >function,
> + dev->device.numa_node);
I agree with Stephen, this message might as well be DEBUG level. You could argue for symmetry: If the "alloc" message during startup is INFO level, it makes sense using INFO level for the "free" message during cleanup too. However, the message probably has far lower information value during cleanup (because this driver cleanup is expected to happen), so I would degrade it to DEBUG level. Symmetry is not always the strongest argument. I have no strong preference, so I'll leave it up to you, Kevin.
[...]
> @@ -263,6 +275,7 @@ struct rte_bus {
> const char *name; /**< Name of the bus */
> rte_bus_scan_t scan; /**< Scan for devices attached to
> bus */
> rte_bus_probe_t probe; /**< Probe devices on bus */
> + rte_bus_cleanup_t cleanup; /**< Cleanup devices on bus */
> rte_bus_find_device_t find_device; /**< Find a device on the bus
> */
> rte_bus_plug_t plug; /**< Probe single device for drivers
> */
> rte_bus_unplug_t unplug; /**< Remove single device from
> driver */
Have you considered if modifying the rte_bus structure in /lib/eal/include/rte_bus.h breaks the ABI or not?
Overall, this patch is certainly a good idea!
On the condition that modifying the rte_bus structure does not break the ABI...
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 4%]
* RE: [EXT] Re: [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes
2022-04-19 15:41 0% ` Ray Kinsella
@ 2022-04-20 13:51 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-04-20 13:51 UTC (permalink / raw)
To: Ray Kinsella
Cc: Thomas Monjalon, dev, david.marchand, hemant.agrawal,
Anoob Joseph, konstantin.ananyev, ciara.power, ferruh.yigit,
andrew.rybchenko, Nithin Kumar Dabilpuram,
Vamsi Krishna Attunuru
Hi Ray,
> >> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
> >> > > > + /** Hard byte expiry of SA */
> >> > > > + RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY,
> >> > > > + /** Hard packet expiry of SA */
> >> > > > + RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY,
> >> > >
> >> > > Same comment for the 3 events.
> >> > >
> >> > > > /** Max value of this enum */
> >> > > > RTE_ETH_EVENT_IPSEC_MAX
> >> > > > };
> >> > >
> >> > > What is the impact of this "MAX" value on ABI compatibility?
> >> >
> >> > I see no issues reported while running ABI check.
> >> > There is no array being used inside library based on MAX.
> >>
> >> No need of array inside the library, the events are exposed to the app.
> >> I'm surprised libabigail is OK with changing an enum value.
> >>
> > @Ray Can you please check if it is an issue to add more values in this enum?
>
> Well look there is two seperate things going on here.
>
> Why isn't libabigail complaining about the _MAX value changing. I'll
> need to look at libabigail to see what the issue is, so lets put this
> one aside for a moment.
>
> This second issue is it safe for the _MAX value to change?
> We have a lot of back and forth argument on these, and previously
> concluded that we should probably look to remove _MAX values in the
> 22.11 release.
Agreed.
>
> The core issue is that we need look at how a user is likely to use
> rte_eth_event_ipsec_subtype. Take a look at the example below:-
>
> /root/src/dpdk/examples/ipsec-secgw/ipsec-secgw.c:2592:0
>
> For instance, can we guarantee that an application built against DPDK
> 21.11, but running against 22.xx will never recieve one of the new
> values in event_desc->subtype (or by any other means)?
ok we can defer the 7/10, 8/10, 9/10 patch to next release then.
^ permalink raw reply [relevance 0%]
* kni: check abi version between kmod and lib
@ 2022-04-21 4:38 16% Stephen Coleman
2022-04-21 14:16 4% ` Ray Kinsella
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Stephen Coleman @ 2022-04-21 4:38 UTC (permalink / raw)
To: dev; +Cc: Ray Kinsella, Ferruh Yigit
KNI ioctl functions copy data from userspace lib, and this interface
of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
bad things happen: sometimes various fields contain garbage value,
sometimes it cause a kmod soft lockup.
Some common distros ship their own rte_kni.ko, so this is likely to
happen.
This patch add abi version checking between userland lib and kmod so
that:
* if kmod ioctl got a wrong abi magic, it refuse to go on
* if userland lib, probed a wrong abi version via newly added ioctl, it
also refuse to go on
Bugzilla ID: 998
Signed-off-by: youcai <omegacoleman@gmail.com>
---
kernel/linux/kni/kni_misc.c | 38 +++++++++++++++++++++++++++++++++++++
lib/kni/rte_kni.c | 16 ++++++++++++++++
lib/kni/rte_kni_common.h | 11 +++++++++++
3 files changed, 65 insertions(+)
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 780187d8bf..cd9a05d8c1 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -236,12 +236,24 @@ kni_release(struct inode *inode, struct file *file)
return 0;
}
+static int kni_check_abi_version_magic(uint16_t abi_version_magic) {
+ if (abi_version_magic != RTE_KNI_ABI_VERSION_MAGIC) {
+ pr_err("KNI kmod ABI incompatible with librte_kni -- %u\n",
+ RTE_KNI_ABI_VERSION_FROM_MAGIC(abi_version_magic));
+ return -1;
+ }
+ return 0;
+}
+
static int
kni_check_param(struct kni_dev *kni, struct rte_kni_device_info *dev)
{
if (!kni || !dev)
return -1;
+ if (kni_check_abi_version_magic(dev->abi_version_magic) < 0)
+ return -1;
+
/* Check if network name has been used */
if (!strncmp(kni->name, dev->name, RTE_KNI_NAMESIZE)) {
pr_err("KNI name %s duplicated\n", dev->name);
@@ -301,12 +313,19 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
struct rte_kni_device_info dev_info;
struct net_device *net_dev = NULL;
struct kni_dev *kni, *dev, *n;
+ uint16_t abi_version_magic;
pr_info("Creating kni...\n");
/* Check the buffer size, to avoid warning */
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
+ /* perform abi check ahead of copy, to avoid possible violation */
+ if (copy_from_user(&abi_version_magic, (void *)ioctl_param,
sizeof(uint16_t)))
+ return -EFAULT;
+ if (kni_check_abi_version_magic(abi_version_magic) < 0)
+ return -EINVAL;
+
/* Copy kni info from user space */
if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
return -EFAULT;
@@ -451,10 +470,17 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
int ret = -EINVAL;
struct kni_dev *dev, *n;
struct rte_kni_device_info dev_info;
+ uint16_t abi_version_magic;
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
+ /* perform abi check ahead of copy, to avoid possible violation */
+ if (copy_from_user(&abi_version_magic, (void *)ioctl_param,
sizeof(uint16_t)))
+ return -EFAULT;
+ if (kni_check_abi_version_magic(abi_version_magic) < 0)
+ return -EINVAL;
+
if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
return -EFAULT;
@@ -484,6 +510,15 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
return ret;
}
+static int
+kni_ioctl_abi_version(struct net *net, uint32_t ioctl_num,
+ unsigned long ioctl_param)
+{
+ uint16_t abi_version = RTE_KNI_ABI_VERSION;
+ copy_to_user((void *)ioctl_param, &abi_version, sizeof(uint16_t));
+ return 0;
+}
+
static long
kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long ioctl_param)
{
@@ -505,6 +540,9 @@ kni_ioctl(struct file *file, unsigned int
ioctl_num, unsigned long ioctl_param)
case _IOC_NR(RTE_KNI_IOCTL_RELEASE):
ret = kni_ioctl_release(net, ioctl_num, ioctl_param);
break;
+ case _IOC_NR(RTE_KNI_IOCTL_ABI_VERSION):
+ ret = kni_ioctl_abi_version(net, ioctl_num, ioctl_param);
+ break;
default:
pr_debug("IOCTL default\n");
break;
diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 7971c56bb4..d7116e582c 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -113,6 +113,19 @@ rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
}
}
+ uint16_t abi_version;
+ int ret = ioctl(kni_fd, RTE_KNI_IOCTL_ABI_VERSION, &abi_version);
+ if (ret < 0) {
+ RTE_LOG(ERR, KNI, "Cannot verify rte_kni kmod ABI version:
ioctl failed\n");
+ return -1;
+ }
+ if (abi_version != RTE_KNI_ABI_VERSION) {
+ RTE_LOG(ERR, KNI,
+ "rte_kni kmod ABI version mismatch: "
+ "need %" PRIu16 " got %" PRIu16 "\n", RTE_KNI_ABI_VERSION,
abi_version);
+ return -1;
+ }
+
return 0;
}
@@ -255,6 +268,7 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
kni->ops.port_id = UINT16_MAX;
memset(&dev_info, 0, sizeof(dev_info));
+ dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
dev_info.core_id = conf->core_id;
dev_info.force_bind = conf->force_bind;
dev_info.group_id = conf->group_id;
@@ -409,6 +423,8 @@ rte_kni_release(struct rte_kni *kni)
if (!kni)
return -1;
+ dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
+
kni_list = RTE_TAILQ_CAST(rte_kni_tailq.head, rte_kni_list);
rte_mcfg_tailq_write_lock();
diff --git a/lib/kni/rte_kni_common.h b/lib/kni/rte_kni_common.h
index 8d3ee0fa4f..c353043cb6 100644
--- a/lib/kni/rte_kni_common.h
+++ b/lib/kni/rte_kni_common.h
@@ -26,6 +26,14 @@ extern "C" {
#define RTE_CACHE_LINE_MIN_SIZE 64
+/*
+ * Ascend this number if ABI is altered between kmod and userland lib
+ */
+#define RTE_KNI_ABI_VERSION 1
+#define RTE_KNI_ABI_VERSION_MAGIC_MASK 0xAAAA
+#define RTE_KNI_ABI_VERSION_MAGIC (((RTE_KNI_ABI_VERSION) ^
RTE_KNI_ABI_VERSION_MAGIC_MASK))
+#define RTE_KNI_ABI_VERSION_FROM_MAGIC(__magic) (((__magic) ^
RTE_KNI_ABI_VERSION_MAGIC_MASK))
+
/*
* Request id.
*/
@@ -102,6 +110,8 @@ struct rte_kni_mbuf {
*/
struct rte_kni_device_info {
+ uint16_t abi_version_magic;
+
char name[RTE_KNI_NAMESIZE]; /**< Network device name for KNI */
phys_addr_t tx_phys;
@@ -139,6 +149,7 @@ struct rte_kni_device_info {
#define RTE_KNI_IOCTL_TEST _IOWR(0, 1, int)
#define RTE_KNI_IOCTL_CREATE _IOWR(0, 2, struct rte_kni_device_info)
#define RTE_KNI_IOCTL_RELEASE _IOWR(0, 3, struct rte_kni_device_info)
+#define RTE_KNI_IOCTL_ABI_VERSION _IOWR(0, 4, uint16_t)
#ifdef __cplusplus
}
--
2.30.1
^ permalink raw reply [relevance 16%]
* Re: kni: check abi version between kmod and lib
2022-04-21 4:38 16% kni: check abi version between kmod and lib Stephen Coleman
@ 2022-04-21 14:16 4% ` Ray Kinsella
2022-04-21 14:54 4% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2022-04-21 14:16 UTC (permalink / raw)
To: Stephen Coleman; +Cc: dev, Ferruh Yigit
Stephen Coleman <omegacoleman@gmail.com> writes:
> KNI ioctl functions copy data from userspace lib, and this interface
> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
> bad things happen: sometimes various fields contain garbage value,
> sometimes it cause a kmod soft lockup.
>
> Some common distros ship their own rte_kni.ko, so this is likely to
> happen.
>
> This patch add abi version checking between userland lib and kmod so
> that:
>
> * if kmod ioctl got a wrong abi magic, it refuse to go on
> * if userland lib, probed a wrong abi version via newly added ioctl, it
> also refuse to go on
>
> Bugzilla ID: 998
>
> Signed-off-by: youcai <omegacoleman@gmail.com>
> ---
> kernel/linux/kni/kni_misc.c | 38 +++++++++++++++++++++++++++++++++++++
> lib/kni/rte_kni.c | 16 ++++++++++++++++
> lib/kni/rte_kni_common.h | 11 +++++++++++
> 3 files changed, 65 insertions(+)
>
> diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
> index 780187d8bf..cd9a05d8c1 100644
> --- a/kernel/linux/kni/kni_misc.c
> +++ b/kernel/linux/kni/kni_misc.c
> @@ -236,12 +236,24 @@ kni_release(struct inode *inode, struct file *file)
> return 0;
> }
>
> +static int kni_check_abi_version_magic(uint16_t abi_version_magic) {
> + if (abi_version_magic != RTE_KNI_ABI_VERSION_MAGIC) {
> + pr_err("KNI kmod ABI incompatible with librte_kni -- %u\n",
> + RTE_KNI_ABI_VERSION_FROM_MAGIC(abi_version_magic));
> + return -1;
> + }
> + return 0;
> +}
> +
> static int
> kni_check_param(struct kni_dev *kni, struct rte_kni_device_info *dev)
> {
> if (!kni || !dev)
> return -1;
>
> + if (kni_check_abi_version_magic(dev->abi_version_magic) < 0)
> + return -1;
> +
> /* Check if network name has been used */
> if (!strncmp(kni->name, dev->name, RTE_KNI_NAMESIZE)) {
> pr_err("KNI name %s duplicated\n", dev->name);
> @@ -301,12 +313,19 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
> struct rte_kni_device_info dev_info;
> struct net_device *net_dev = NULL;
> struct kni_dev *kni, *dev, *n;
> + uint16_t abi_version_magic;
>
> pr_info("Creating kni...\n");
> /* Check the buffer size, to avoid warning */
> if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
> return -EINVAL;
>
> + /* perform abi check ahead of copy, to avoid possible violation */
> + if (copy_from_user(&abi_version_magic, (void *)ioctl_param,
> sizeof(uint16_t)))
> + return -EFAULT;
> + if (kni_check_abi_version_magic(abi_version_magic) < 0)
> + return -EINVAL;
> +
> /* Copy kni info from user space */
> if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
> return -EFAULT;
> @@ -451,10 +470,17 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
> int ret = -EINVAL;
> struct kni_dev *dev, *n;
> struct rte_kni_device_info dev_info;
> + uint16_t abi_version_magic;
>
> if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
> return -EINVAL;
>
> + /* perform abi check ahead of copy, to avoid possible violation */
> + if (copy_from_user(&abi_version_magic, (void *)ioctl_param,
> sizeof(uint16_t)))
> + return -EFAULT;
> + if (kni_check_abi_version_magic(abi_version_magic) < 0)
> + return -EINVAL;
> +
> if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
> return -EFAULT;
>
> @@ -484,6 +510,15 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
> return ret;
> }
>
> +static int
> +kni_ioctl_abi_version(struct net *net, uint32_t ioctl_num,
> + unsigned long ioctl_param)
> +{
> + uint16_t abi_version = RTE_KNI_ABI_VERSION;
> + copy_to_user((void *)ioctl_param, &abi_version, sizeof(uint16_t));
> + return 0;
> +}
> +
> static long
> kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long ioctl_param)
> {
> @@ -505,6 +540,9 @@ kni_ioctl(struct file *file, unsigned int
> ioctl_num, unsigned long ioctl_param)
> case _IOC_NR(RTE_KNI_IOCTL_RELEASE):
> ret = kni_ioctl_release(net, ioctl_num, ioctl_param);
> break;
> + case _IOC_NR(RTE_KNI_IOCTL_ABI_VERSION):
> + ret = kni_ioctl_abi_version(net, ioctl_num, ioctl_param);
> + break;
> default:
> pr_debug("IOCTL default\n");
> break;
> diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
> index 7971c56bb4..d7116e582c 100644
> --- a/lib/kni/rte_kni.c
> +++ b/lib/kni/rte_kni.c
> @@ -113,6 +113,19 @@ rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
> }
> }
>
> + uint16_t abi_version;
> + int ret = ioctl(kni_fd, RTE_KNI_IOCTL_ABI_VERSION, &abi_version);
> + if (ret < 0) {
> + RTE_LOG(ERR, KNI, "Cannot verify rte_kni kmod ABI version:
> ioctl failed\n");
> + return -1;
> + }
> + if (abi_version != RTE_KNI_ABI_VERSION) {
> + RTE_LOG(ERR, KNI,
> + "rte_kni kmod ABI version mismatch: "
> + "need %" PRIu16 " got %" PRIu16 "\n", RTE_KNI_ABI_VERSION,
> abi_version);
> + return -1;
> + }
> +
> return 0;
> }
>
> @@ -255,6 +268,7 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
> kni->ops.port_id = UINT16_MAX;
>
> memset(&dev_info, 0, sizeof(dev_info));
> + dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
> dev_info.core_id = conf->core_id;
> dev_info.force_bind = conf->force_bind;
> dev_info.group_id = conf->group_id;
> @@ -409,6 +423,8 @@ rte_kni_release(struct rte_kni *kni)
> if (!kni)
> return -1;
>
> + dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
> +
> kni_list = RTE_TAILQ_CAST(rte_kni_tailq.head, rte_kni_list);
>
> rte_mcfg_tailq_write_lock();
> diff --git a/lib/kni/rte_kni_common.h b/lib/kni/rte_kni_common.h
> index 8d3ee0fa4f..c353043cb6 100644
> --- a/lib/kni/rte_kni_common.h
> +++ b/lib/kni/rte_kni_common.h
> @@ -26,6 +26,14 @@ extern "C" {
>
> #define RTE_CACHE_LINE_MIN_SIZE 64
>
> +/*
> + * Ascend this number if ABI is altered between kmod and userland lib
> + */
> +#define RTE_KNI_ABI_VERSION 1
Instead of creating a new magic number, could you reference the
ABI_VERSION instead.
> +#define RTE_KNI_ABI_VERSION_MAGIC_MASK 0xAAAA
> +#define RTE_KNI_ABI_VERSION_MAGIC (((RTE_KNI_ABI_VERSION) ^
> RTE_KNI_ABI_VERSION_MAGIC_MASK))
> +#define RTE_KNI_ABI_VERSION_FROM_MAGIC(__magic) (((__magic) ^
> RTE_KNI_ABI_VERSION_MAGIC_MASK))
> +
> /*
> * Request id.
> */
> @@ -102,6 +110,8 @@ struct rte_kni_mbuf {
> */
>
> struct rte_kni_device_info {
> + uint16_t abi_version_magic;
> +
> char name[RTE_KNI_NAMESIZE]; /**< Network device name for KNI */
>
> phys_addr_t tx_phys;
> @@ -139,6 +149,7 @@ struct rte_kni_device_info {
> #define RTE_KNI_IOCTL_TEST _IOWR(0, 1, int)
> #define RTE_KNI_IOCTL_CREATE _IOWR(0, 2, struct rte_kni_device_info)
> #define RTE_KNI_IOCTL_RELEASE _IOWR(0, 3, struct rte_kni_device_info)
> +#define RTE_KNI_IOCTL_ABI_VERSION _IOWR(0, 4, uint16_t)
>
> #ifdef __cplusplus
> }
--
Regards, Ray K
^ permalink raw reply [relevance 4%]
* [PATCH v3 0/7] Add new cryptodev op for event metadata
@ 2022-04-21 14:37 4% ` Akhil Goyal
2022-04-21 14:37 2% ` [PATCH v3 1/7] cryptodev: add APIs to get/set " Akhil Goyal
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Akhil Goyal @ 2022-04-21 14:37 UTC (permalink / raw)
To: dev
Cc: anoobj, jerinj, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, vfialko, Akhil Goyal
For using event crypto metadata, event metadata need to be set
in session. For this session user data was used for symmetric
crypto sessions and no support was present for asymmetric and
security sessions.
The use of userdata to store event metadata (which is dereferenced
in PMD) is not correct as it is meant for the application to use it.
Hence, a new API is created to set and get event crypto metadata which
is scalable to all sessions supported by the crypto PMD.
The application can use the set API to set event metadata and the
PMD may store that inside the session private data and PMD need not
use the get API as it would be internal to the PMD.
For the software event crypto adapter implementation, the eventdev
library can use the get API to get the event metadata stored inside
the session structure.
For Asymmetric sessions, a new field is added inside the session
struct which is internal to library.
For symmetric and security sessions, new field cannot be added as
it would be ABI break. Hence, session userdata is being used to
store that as it was used earlier. In next ABI break release this
would be fixed similar to asymmetric crypto case.
The patchset also add support for asymmetric crypto adapter
in the test applications and the crypto/cnxk implementation of
the new cryptodev op and corresponding changes in the eventdev lib.
Changes in v3:
- fix SW adapter case of memory allocation/free of mdata. mdata is
allocated in set API and freed in session clear/destroy.
- mark rte_cryptodev_session_event_mdata_get as internal API
as it is only needed for the app or the PMD.
changes in v2:
- v1 patchset only fixed security sessions and also caused ABI breakage.
This is fixed in v2.
- added new API for setting event metadata.
- added new cryptodev op which can handle all sessions
Akhil Goyal (5):
crypto/octeontx: use new API for event metadata
test/event: use new API to set event crypto metadata
eventdev: use new API to get event crypto metadata
test/event: add asymmetric cases for crypto adapter
test-eventdev: support asym ops for crypto adapter
Volodymyr Fialko (2):
cryptodev: add APIs to get/set event metadata
crypto/cnxk: add event metadata set operation
app/test-eventdev/evt_common.h | 2 +
app/test-eventdev/evt_options.c | 17 +
app/test-eventdev/evt_options.h | 4 +
app/test-eventdev/test_perf_atq.c | 12 +-
app/test-eventdev/test_perf_common.c | 254 ++++++++--
app/test-eventdev/test_perf_common.h | 45 +-
app/test-eventdev/test_perf_queue.c | 12 +-
app/test/test_event_crypto_adapter.c | 503 +++++++++++++++++++-
doc/guides/tools/testeventdev.rst | 5 +
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++++-
drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 +++++-
drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
drivers/crypto/cnxk/cnxk_ae.h | 2 +
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 -
drivers/crypto/cnxk/cnxk_se.h | 2 +
drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +-
lib/cryptodev/cryptodev_pmd.c | 16 +
lib/cryptodev/cryptodev_pmd.h | 36 ++
lib/cryptodev/rte_cryptodev.c | 41 ++
lib/cryptodev/rte_cryptodev.h | 22 +
lib/cryptodev/version.map | 4 +
lib/eventdev/rte_event_crypto_adapter.c | 55 +--
23 files changed, 1168 insertions(+), 188 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 4%]
* [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
2022-04-21 14:37 4% ` [PATCH v3 " Akhil Goyal
@ 2022-04-21 14:37 2% ` Akhil Goyal
2022-04-27 15:38 0% ` Zhang, Roy Fan
2022-04-28 14:42 0% ` Gujjar, Abhinandan S
2022-04-27 15:37 0% ` [PATCH v3 0/7] Add new cryptodev op for " Zhang, Roy Fan
` (2 subsequent siblings)
3 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2022-04-21 14:37 UTC (permalink / raw)
To: dev
Cc: anoobj, jerinj, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, vfialko, Akhil Goyal
From: Volodymyr Fialko <vfialko@marvell.com>
Currently, crypto session userdata is used to set event crypto
metadata from the application and the driver is dereferencing it
in driver which is not correct. User data is meant to be opaque
to the driver.
To support this, new API is added to get and set event crypto
metadata. The new API, rte_cryptodev_set_session_event_mdata,
allows setting event metadata in session private data which is
filled inside PMD using a new cryptodev op. This operation
can be performed on any of the PMD supported sessions
(sym/asym/security).
For SW abstraction of event crypto adapter to be used by
eventdev library, a new field is added in asymmetric crypto
session for now and for symmetric case, current implementation
of using userdata is used. Symmetric cases cannot be fixed now,
as it will be ABI breakage which will be resolved in DPDK 22.11.
Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
lib/cryptodev/cryptodev_pmd.c | 16 ++++++++++++++
lib/cryptodev/cryptodev_pmd.h | 36 ++++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 41 +++++++++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.h | 22 +++++++++++++++++++
lib/cryptodev/version.map | 4 ++++
5 files changed, 119 insertions(+)
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 739a0b3f34..1903ade388 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -227,3 +227,19 @@ cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
fp_ops->qp.enq_cb = dev->enq_cbs;
fp_ops->qp.deq_cb = dev->deq_cbs;
}
+
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op)
+{
+ if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return rte_cryptodev_sym_session_get_user_data(op->sym->session);
+ else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return op->asym->session->event_mdata;
+ else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
+ op->private_data_offset)
+ return ((uint8_t *)op + op->private_data_offset);
+ else
+ return NULL;
+}
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 2b1ce2da2d..7969944b66 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -398,6 +398,25 @@ typedef int (*cryptodev_sym_configure_raw_dp_ctx_t)(
enum rte_crypto_op_sess_type sess_type,
union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
+/**
+ * Typedef that the driver provided to set event crypto meta data.
+ *
+ * @param dev Crypto device pointer.
+ * @param sess Crypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdata Pointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @return
+ * - On success return 0.
+ * - On failure return negative integer.
+ */
+typedef int (*cryptodev_session_event_mdata_set_t)(
+ struct rte_cryptodev *dev, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata);
+
/** Crypto device operations function pointer table */
struct rte_cryptodev_ops {
cryptodev_configure_t dev_configure; /**< Configure device. */
@@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
/**< Initialize raw data path context data. */
};
};
+ cryptodev_session_event_mdata_set_t session_ev_mdata_set;
+ /**< Set a Crypto or Security session even meta data. */
};
@@ -603,6 +624,19 @@ void
cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
const struct rte_cryptodev *dev);
+/**
+ * Get session event meta data (aka *union rte_event_crypto_metadata*)
+ *
+ * @param op pointer to *rte_crypto_op* structure.
+ *
+ * @return
+ * - On success, pointer to event crypto metadata
+ * - On failure, a negative value.
+ */
+__rte_internal
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
+
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
@@ -636,6 +670,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
/**< Size of private data used when creating mempool */
uint16_t user_data_sz;
/**< Session user data will be placed after sess_data */
+ void *event_mdata;
+ /**< Event crypto adapter metadata */
uint8_t padding[3];
uint8_t sess_private_data[0];
};
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 3500a2d470..a070cb2a00 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2051,6 +2051,9 @@ rte_cryptodev_asym_session_free(uint8_t dev_id, void *sess)
dev->dev_ops->asym_session_clear(dev, sess);
+ if (((struct rte_cryptodev_asym_session *)sess)->event_mdata)
+ rte_free(((struct rte_cryptodev_asym_session *)sess)->event_mdata);
+
/* Return session to mempool */
sess_mp = rte_mempool_from_obj(sess);
rte_mempool_put(sess_mp, sess);
@@ -2259,6 +2262,44 @@ rte_cryptodev_configure_raw_dp_ctx(uint8_t dev_id, uint16_t qp_id,
sess_type, session_ctx, is_update);
}
+int
+rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata,
+ uint16_t size)
+{
+ struct rte_cryptodev *dev;
+
+ if (!rte_cryptodev_is_valid_dev(dev_id))
+ goto skip_pmd_op;
+
+ dev = rte_cryptodev_pmd_get_dev(dev_id);
+ if (dev->dev_ops->session_ev_mdata_set == NULL)
+ goto skip_pmd_op;
+
+ return (*dev->dev_ops->session_ev_mdata_set)(dev, sess, op_type,
+ sess_type, ev_mdata);
+
+skip_pmd_op:
+ if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+ return rte_cryptodev_sym_session_set_user_data(sess, ev_mdata,
+ size);
+ else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
+ struct rte_cryptodev_asym_session *s = sess;
+
+ if (s->event_mdata == NULL) {
+ s->event_mdata = rte_malloc(NULL, size, 0);
+ if (s->event_mdata == NULL)
+ return -ENOMEM;
+ }
+ rte_memcpy(s->event_mdata, ev_mdata, size);
+
+ return 0;
+ } else
+ return -ENOTSUP;
+}
+
uint32_t
rte_cryptodev_raw_enqueue_burst(struct rte_crypto_raw_dp_ctx *ctx,
struct rte_crypto_sym_vec *vec, union rte_crypto_sym_ofs ofs,
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 45d33f4a50..2c2c2edeb7 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -1269,6 +1269,28 @@ __rte_experimental
int
rte_cryptodev_get_raw_dp_ctx_size(uint8_t dev_id);
+/**
+ * Set session event meta data
+ *
+ * @param dev_id The device identifier.
+ * @param sess Crypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdata Pointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @param size Size of ev_mdata.
+ *
+ * @return
+ * - On success, zero.
+ * - On failure, a negative value.
+ */
+__rte_experimental
+int
+rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata, uint16_t size);
+
/**
* Union of different crypto session types, including session-less xform
* pointer.
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index c7c5aefceb..f0abfaa47d 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -105,6 +105,9 @@ EXPERIMENTAL {
rte_cryptodev_asym_session_pool_create;
rte_cryptodev_asym_session_set_user_data;
__rte_cryptodev_trace_asym_session_pool_create;
+
+ #added in 22.07
+ rte_cryptodev_session_event_mdata_set;
};
INTERNAL {
@@ -123,5 +126,6 @@ INTERNAL {
rte_cryptodev_pmd_parse_input_args;
rte_cryptodev_pmd_probing_finish;
rte_cryptodev_pmd_release_device;
+ rte_cryptodev_session_event_mdata_get;
rte_cryptodevs;
};
--
2.25.1
^ permalink raw reply [relevance 2%]
* Re: kni: check abi version between kmod and lib
2022-04-21 4:38 16% kni: check abi version between kmod and lib Stephen Coleman
2022-04-21 14:16 4% ` Ray Kinsella
@ 2022-04-21 14:54 4% ` Stephen Hemminger
2022-04-21 15:40 8% ` Ray Kinsella
2022-04-21 16:34 15% ` [PATCH v2] " youcai
2022-04-24 8:51 15% ` [PATCH v3] " youcai
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-04-21 14:54 UTC (permalink / raw)
To: Stephen Coleman; +Cc: dev, Ray Kinsella, Ferruh Yigit
On Thu, 21 Apr 2022 12:38:26 +0800
Stephen Coleman <omegacoleman@gmail.com> wrote:
> KNI ioctl functions copy data from userspace lib, and this interface
> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
> bad things happen: sometimes various fields contain garbage value,
> sometimes it cause a kmod soft lockup.
>
> Some common distros ship their own rte_kni.ko, so this is likely to
> happen.
>
> This patch add abi version checking between userland lib and kmod so
> that:
>
> * if kmod ioctl got a wrong abi magic, it refuse to go on
> * if userland lib, probed a wrong abi version via newly added ioctl, it
> also refuse to go on
>
> Bugzilla ID: 998
Kernel API's are supposed to be 99% stable.
If this driver was playing by the upstream kernel rules this would not
have happened.
^ permalink raw reply [relevance 4%]
* Re: kni: check abi version between kmod and lib
2022-04-21 14:54 4% ` Stephen Hemminger
@ 2022-04-21 15:40 8% ` Ray Kinsella
2022-04-21 15:50 4% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-04-21 15:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Coleman, dev, Ferruh Yigit
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Thu, 21 Apr 2022 12:38:26 +0800
> Stephen Coleman <omegacoleman@gmail.com> wrote:
>
>> KNI ioctl functions copy data from userspace lib, and this interface
>> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
>> bad things happen: sometimes various fields contain garbage value,
>> sometimes it cause a kmod soft lockup.
>>
>> Some common distros ship their own rte_kni.ko, so this is likely to
>> happen.
>>
>> This patch add abi version checking between userland lib and kmod so
>> that:
>>
>> * if kmod ioctl got a wrong abi magic, it refuse to go on
>> * if userland lib, probed a wrong abi version via newly added ioctl, it
>> also refuse to go on
>>
>> Bugzilla ID: 998
>
>
> Kernel API's are supposed to be 99% stable.
> If this driver was playing by the upstream kernel rules this would not
> have happened.
Well look, it is out-of-tree and never likely to be in-tree, so those
rules don't apply. Making sure the ABI doesn't change during the ABI
stablity period, should be good enough?
--
Regards, Ray K
^ permalink raw reply [relevance 8%]
* Re: kni: check abi version between kmod and lib
2022-04-21 15:40 8% ` Ray Kinsella
@ 2022-04-21 15:50 4% ` Stephen Hemminger
2022-04-22 8:46 8% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-04-21 15:50 UTC (permalink / raw)
To: Ray Kinsella; +Cc: Stephen Coleman, dev, Ferruh Yigit
On Thu, 21 Apr 2022 11:40:00 -0400
Ray Kinsella <mdr@ashroe.eu> wrote:
> Stephen Hemminger <stephen@networkplumber.org> writes:
>
> > On Thu, 21 Apr 2022 12:38:26 +0800
> > Stephen Coleman <omegacoleman@gmail.com> wrote:
> >
> >> KNI ioctl functions copy data from userspace lib, and this interface
> >> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
> >> bad things happen: sometimes various fields contain garbage value,
> >> sometimes it cause a kmod soft lockup.
> >>
> >> Some common distros ship their own rte_kni.ko, so this is likely to
> >> happen.
> >>
> >> This patch add abi version checking between userland lib and kmod so
> >> that:
> >>
> >> * if kmod ioctl got a wrong abi magic, it refuse to go on
> >> * if userland lib, probed a wrong abi version via newly added ioctl, it
> >> also refuse to go on
> >>
> >> Bugzilla ID: 998
> >
> >
> > Kernel API's are supposed to be 99% stable.
> > If this driver was playing by the upstream kernel rules this would not
> > have happened.
>
> Well look, it is out-of-tree and never likely to be in-tree, so those
> rules don't apply. Making sure the ABI doesn't change during the ABI
> stablity period, should be good enough?
>
I think if KNI changes, it should just add more ioctl numbers and
be compatible, it is not that hard.
^ permalink raw reply [relevance 4%]
* [PATCH v2] kni: check abi version between kmod and lib
2022-04-21 4:38 16% kni: check abi version between kmod and lib Stephen Coleman
2022-04-21 14:16 4% ` Ray Kinsella
2022-04-21 14:54 4% ` Stephen Hemminger
@ 2022-04-21 16:34 15% ` youcai
2022-04-24 8:51 15% ` [PATCH v3] " youcai
3 siblings, 0 replies; 200+ results
From: youcai @ 2022-04-21 16:34 UTC (permalink / raw)
To: dev; +Cc: Ray Kinsella, Stephen Hemminger, Ferruh Yigit, youcai
KNI ioctl functions copy data from userspace lib, and this interface
of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
bad things happen: sometimes various fields contain garbage value,
sometimes it cause a kmod soft lockup.
Some common distros ship their own rte_kni.ko, so this is likely to
happen.
This patch add abi version checking between userland lib and kmod so
that:
* if kmod ioctl got a wrong abi magic, it refuse to go on
* if userland lib, probed a wrong abi version via newly added ioctl, it
also refuse to go on
Bugzilla ID: 998
Signed-off-by: youcai <omegacoleman@gmail.com>
---
V2: use ABI_VERSION instead of a new magic
V2: fix some indent
---
kernel/linux/kni/kni_misc.c | 40 ++++++++++++++++++++++++++++++++++++
kernel/linux/kni/meson.build | 4 ++--
lib/kni/meson.build | 1 +
lib/kni/rte_kni.c | 17 +++++++++++++++
lib/kni/rte_kni_abi.h | 17 +++++++++++++++
lib/kni/rte_kni_common.h | 3 +++
6 files changed, 80 insertions(+), 2 deletions(-)
create mode 100644 lib/kni/rte_kni_abi.h
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 780187d8bf..9a1ed22fed 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -17,6 +17,7 @@
#include <net/netns/generic.h>
#include <rte_kni_common.h>
+#include <rte_kni_abi.h>
#include "compat.h"
#include "kni_dev.h"
@@ -236,12 +237,24 @@ kni_release(struct inode *inode, struct file *file)
return 0;
}
+static int kni_check_abi_version_magic(uint16_t abi_version_magic) {
+ if (abi_version_magic != RTE_KNI_ABI_VERSION_MAGIC) {
+ pr_err("KNI kmod ABI incompatible with librte_kni -- %u\n",
+ RTE_KNI_ABI_VERSION_FROM_MAGIC(abi_version_magic));
+ return -1;
+ }
+ return 0;
+}
+
static int
kni_check_param(struct kni_dev *kni, struct rte_kni_device_info *dev)
{
if (!kni || !dev)
return -1;
+ if (kni_check_abi_version_magic(dev->abi_version_magic) < 0)
+ return -1;
+
/* Check if network name has been used */
if (!strncmp(kni->name, dev->name, RTE_KNI_NAMESIZE)) {
pr_err("KNI name %s duplicated\n", dev->name);
@@ -301,12 +314,19 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
struct rte_kni_device_info dev_info;
struct net_device *net_dev = NULL;
struct kni_dev *kni, *dev, *n;
+ uint16_t abi_version_magic;
pr_info("Creating kni...\n");
/* Check the buffer size, to avoid warning */
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
+ /* perform abi check ahead of copy, to avoid possible violation */
+ if (copy_from_user(&abi_version_magic, (void *)ioctl_param, sizeof(uint16_t)))
+ return -EFAULT;
+ if (kni_check_abi_version_magic(abi_version_magic) < 0)
+ return -EINVAL;
+
/* Copy kni info from user space */
if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
return -EFAULT;
@@ -451,10 +471,17 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
int ret = -EINVAL;
struct kni_dev *dev, *n;
struct rte_kni_device_info dev_info;
+ uint16_t abi_version_magic;
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
+ /* perform abi check ahead of copy, to avoid possible violation */
+ if (copy_from_user(&abi_version_magic, (void *)ioctl_param, sizeof(uint16_t)))
+ return -EFAULT;
+ if (kni_check_abi_version_magic(abi_version_magic) < 0)
+ return -EINVAL;
+
if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
return -EFAULT;
@@ -484,6 +511,16 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
return ret;
}
+static int
+kni_ioctl_abi_version(struct net *net, uint32_t ioctl_num,
+ unsigned long ioctl_param)
+{
+ uint16_t abi_version = ABI_VERSION_MAJOR;
+ if (copy_to_user((void *)ioctl_param, &abi_version, sizeof(uint16_t)))
+ return -EFAULT;
+ return 0;
+}
+
static long
kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long ioctl_param)
{
@@ -505,6 +542,9 @@ kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long ioctl_param)
case _IOC_NR(RTE_KNI_IOCTL_RELEASE):
ret = kni_ioctl_release(net, ioctl_num, ioctl_param);
break;
+ case _IOC_NR(RTE_KNI_IOCTL_ABI_VERSION):
+ ret = kni_ioctl_abi_version(net, ioctl_num, ioctl_param);
+ break;
default:
pr_debug("IOCTL default\n");
break;
diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
index 4c90069e99..c8cd23acd9 100644
--- a/kernel/linux/kni/meson.build
+++ b/kernel/linux/kni/meson.build
@@ -3,12 +3,12 @@
# For SUSE build check function arguments of ndo_tx_timeout API
# Ref: https://jira.devtools.intel.com/browse/DPDK-29263
-kmod_cflags = ''
+kmod_cflags = '-DABI_VERSION_MAJOR=@0@'.format(abi_version.split('.')[0])
file_path = kernel_source_dir + '/include/linux/netdevice.h'
run_cmd = run_command('grep', 'ndo_tx_timeout', file_path, check: false)
if run_cmd.stdout().contains('txqueue') == true
- kmod_cflags = '-DHAVE_ARG_TX_QUEUE'
+ kmod_cflags += ' -DHAVE_ARG_TX_QUEUE'
endif
diff --git a/lib/kni/meson.build b/lib/kni/meson.build
index 8a71d8ba6f..f22a27b15b 100644
--- a/lib/kni/meson.build
+++ b/lib/kni/meson.build
@@ -14,3 +14,4 @@ endif
sources = files('rte_kni.c')
headers = files('rte_kni.h', 'rte_kni_common.h')
deps += ['ethdev', 'pci']
+cflags += ['-DABI_VERSION_MAJOR=@0@'.format(abi_version.split('.')[0])]
diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 7971c56bb4..1c8a610bd4 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -22,6 +22,7 @@
#include <rte_eal_memconfig.h>
#include <rte_kni_common.h>
#include "rte_kni_fifo.h"
+#include "rte_kni_abi.h"
#define MAX_MBUF_BURST_NUM 32
@@ -113,6 +114,19 @@ rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
}
}
+ uint16_t abi_version;
+ int ret = ioctl(kni_fd, RTE_KNI_IOCTL_ABI_VERSION, &abi_version);
+ if (ret < 0) {
+ RTE_LOG(ERR, KNI, "Cannot verify rte_kni kmod ABI version: ioctl failed\n");
+ return -1;
+ }
+ if (abi_version != ABI_VERSION_MAJOR) {
+ RTE_LOG(ERR, KNI,
+ "rte_kni kmod ABI version mismatch: "
+ "need %" PRIu16 " got %" PRIu16 "\n", ABI_VERSION_MAJOR, abi_version);
+ return -1;
+ }
+
return 0;
}
@@ -255,6 +269,7 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
kni->ops.port_id = UINT16_MAX;
memset(&dev_info, 0, sizeof(dev_info));
+ dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
dev_info.core_id = conf->core_id;
dev_info.force_bind = conf->force_bind;
dev_info.group_id = conf->group_id;
@@ -409,6 +424,8 @@ rte_kni_release(struct rte_kni *kni)
if (!kni)
return -1;
+ dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
+
kni_list = RTE_TAILQ_CAST(rte_kni_tailq.head, rte_kni_list);
rte_mcfg_tailq_write_lock();
diff --git a/lib/kni/rte_kni_abi.h b/lib/kni/rte_kni_abi.h
new file mode 100644
index 0000000000..7dde394c72
--- /dev/null
+++ b/lib/kni/rte_kni_abi.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: (BSD-3-Clause OR LGPL-2.1) */
+/*
+ * Copyright(c) 2007-2014 Intel Corporation.
+ */
+
+#ifndef _RTE_KNI_ABI_H_
+#define _RTE_KNI_ABI_H_
+
+#ifndef ABI_VERSION_MAJOR
+#error Need ABI_VERSION_MAJOR being the major part of dpdk/ABI_VERSION
+#endif
+#define RTE_KNI_ABI_VERSION_MAGIC_MASK 0xAAAA
+#define RTE_KNI_ABI_VERSION_MAGIC (((ABI_VERSION_MAJOR) ^ RTE_KNI_ABI_VERSION_MAGIC_MASK))
+#define RTE_KNI_ABI_VERSION_FROM_MAGIC(__magic) (((__magic) ^ RTE_KNI_ABI_VERSION_MAGIC_MASK))
+
+#endif
+
diff --git a/lib/kni/rte_kni_common.h b/lib/kni/rte_kni_common.h
index 8d3ee0fa4f..f9432b742c 100644
--- a/lib/kni/rte_kni_common.h
+++ b/lib/kni/rte_kni_common.h
@@ -102,6 +102,8 @@ struct rte_kni_mbuf {
*/
struct rte_kni_device_info {
+ uint16_t abi_version_magic;
+
char name[RTE_KNI_NAMESIZE]; /**< Network device name for KNI */
phys_addr_t tx_phys;
@@ -139,6 +141,7 @@ struct rte_kni_device_info {
#define RTE_KNI_IOCTL_TEST _IOWR(0, 1, int)
#define RTE_KNI_IOCTL_CREATE _IOWR(0, 2, struct rte_kni_device_info)
#define RTE_KNI_IOCTL_RELEASE _IOWR(0, 3, struct rte_kni_device_info)
+#define RTE_KNI_IOCTL_ABI_VERSION _IOWR(0, 4, uint16_t)
#ifdef __cplusplus
}
--
2.35.1
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
@ 2022-04-21 18:02 5% ` jerinj
2022-04-26 10:19 0% ` Ray Kinsella
2022-05-01 14:46 5% ` [dpdk-dev] [PATCH v5] " jerinj
0 siblings, 2 replies; 200+ results
From: jerinj @ 2022-04-21 18:02 UTC (permalink / raw)
To: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and
support for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port.
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v4..v3:
- Aligned with community meeting call which is documented in
https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
as last message. With following exception,
- Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
Changing above symbols break existing application for no good.
- Updated 22.07 release notes
- Remove testpmd changes from series to finalize the API spec first and
then we can send testpmd changes.
v3..v2:
- Fix input color flags as a bitmask
- Add definitions for newly added API
v2..v1:
- Fix seperate typo
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
- Moved to v22.07 release
- Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner
cases
- Added input_color_method
- Removed union between vlan_table and dscp_table
- Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3
bits)
.../traffic_metering_and_policing.rst | 33 ++++
doc/guides/rel_notes/release_22_07.rst | 10 +
lib/ethdev/rte_mtr.c | 23 +++
lib/ethdev/rte_mtr.h | 186 +++++++++++++++++-
lib/ethdev/rte_mtr_driver.h | 19 ++
lib/ethdev/version.map | 4 +
6 files changed, 265 insertions(+), 10 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..75deabbaf1 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Protocol based input color selection
Configuration steps
-------------------
@@ -105,3 +106,35 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Protocol based input color selection
+------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the protocol based input color selection device capabilities using
+ following parameter using ``rte_mtr_capabilities_get()`` API.
+
+ * ``struct rte_mtr_capabilities::input_color_proto_mask;``
+ * ``struct rte_mtr_capabilities::separate_input_color_table_per_port``
+
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Input color protocols with ``struct rte_mtr_params::input_color_proto_mask``
+
+ * If ``struct rte_mtr_params::input_color_proto_mask`` has multiple bits set then
+ ``rte_mtr_color_in_protocol_priority_set()`` shall be used to set the priority,
+ in the order, in which protocol to be used to find the input color.
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::vlan_table`` based on input color selected.
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method.
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 42a5f2d990..746622f9b3 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -55,6 +55,13 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added protocol based input color for meter.**
+
+ Added new APIs ``rte_mtr_color_in_protocol_priority_set()``,
+ ``rte_mtr_meter_vlan_table_update()`` and updated ``struct rte_mtr_params``
+ and ``struct rte_mtr_capabilities`` to support protocol based
+ input color for meter.
+
Removed Items
-------------
@@ -102,6 +109,9 @@ ABI Changes
* No ABI change that would break compatibility with 21.11.
+* Experimental structures ``struct rte_mtr_params``
+ and ``struct rte_mtr_capabilities`` updated to support
+ protocol based input color for meter.
Known Issues
------------
diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
index e49fcf271c..a112fe65f5 100644
--- a/lib/ethdev/rte_mtr.c
+++ b/lib/ethdev/rte_mtr.c
@@ -207,6 +207,29 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
mtr_id, dscp_table, error);
}
+/** MTR object meter VLAN table update */
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
+ mtr_id, vlan_table, error);
+}
+
+/** Set the priority for input color protocol on MTR object */
+int
+rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_prio_set)(dev,
+ mtr_id, proto, priority, error);
+}
+
/** MTR object enabled stats update */
int
rte_mtr_stats_update(uint16_t port_id,
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..76ffbcf724 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color protocol method
+ */
+enum rte_mtr_color_in_protocol {
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,20 +279,58 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP protocol field.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
- * Point (DSCP) input packet field. When NULL: it is equivalent to
- * setting this parameter to an all-green populated table (i.e. table
- * with all the 64 elements set to green color). The color blind mode
- * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
- * to either NULL or to an all-green populated table. When
- * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
- * at least one yellow or red color element, then the color aware mode
- * is configured.
+ * Point (DSCP) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an all-green
+ * populated table (i.e. table with all the 64 elements set to green
+ * color). The color blind mode is configured by setting
+ * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
+ * all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value or when *dscp_table*
+ * contains at least one yellow or red color element, then the color
+ * aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
+ * @see struct rte_mtr_params::input_color_proto_mask
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
+ * fields.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ * @see struct rte_mtr_params::input_color_proto_mask
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +345,25 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Set of input color protocols to be enabled.
+ *
+ * Set value to zero to configure as color blind mode.
+ *
+ * When multiple bits set then rte_mtr_color_in_protocol_priority_set()
+ * shall be used to set the priority, in the order, in which protocol
+ * to be used to find the inpput color.
+ *
+ * @see enum rte_mtr_color_in_protocol
+ * @see rte_mtr_color_in_protocol_priority_set()
+ */
+ uint64_t input_color_proto_mask;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this when *input_color_proto_mask* set to zero.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +520,16 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Set of supported input color protocol.
+ * @see enum rte_mtr_color_in_protocol
+ */
+ uint64_t input_color_proto_mask;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int separate_input_color_table_per_port;
};
/**
@@ -832,6 +945,59 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+/**
+ * Set the priority for input color protocol
+ *
+ * When multiple bits set in struct rte_mtr_params::input_color_proto_mask
+ * then this API shall be used to set the priority, in the order, in
+ * which protocol to be used to find the input color.
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] proto
+ * Input color protocol to apply priority.
+ * MTR object's *input_color_proto_mask* should be configured
+ * with proto value.
+ * @param[in] priority
+ * Input color protocol priority. Value zero indicates
+ * the highest priority.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ *
+ * @see rte_mtr_params::input_color_proto_mask
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto, uint32_t priority,
+ struct rte_mtr_error *error);
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
index ee8c6ef7ad..827952adc6 100644
--- a/lib/ethdev/rte_mtr_driver.h
+++ b/lib/ethdev/rte_mtr_driver.h
@@ -97,6 +97,19 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/** @internal mtr object meter vlan table update. */
+typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
+/** @internal Set the priority for input color protocol on MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_prio_set_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error);
+
/** @internal MTR object enabled stats update. */
typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
@@ -139,6 +152,12 @@ struct rte_mtr_ops {
/** MTR object meter DSCP table update */
rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
+ /** MTR object meter VLAN table update */
+ rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
+
+ /** Set the priority for input color protocol on MTR object. */
+ rte_mtr_meter_color_in_proto_prio_set_t in_proto_prio_set;
+
/** MTR object enabled stats update */
rte_mtr_stats_update_t stats_update;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 20391ab29e..cccbf6dee5 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -279,6 +279,10 @@ EXPERIMENTAL {
rte_flow_async_action_handle_create;
rte_flow_async_action_handle_destroy;
rte_flow_async_action_handle_update;
+
+ # added in 22.07
+ rte_mtr_meter_vlan_table_update;
+ rte_mtr_color_in_protocol_priority_set;
};
INTERNAL {
--
2.36.0
^ permalink raw reply [relevance 5%]
* Re: kni: check abi version between kmod and lib
2022-04-21 15:50 4% ` Stephen Hemminger
@ 2022-04-22 8:46 8% ` Ray Kinsella
2022-04-22 10:07 4% ` Stephen Coleman
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-04-22 8:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Coleman, dev, Ferruh Yigit
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Thu, 21 Apr 2022 11:40:00 -0400
> Ray Kinsella <mdr@ashroe.eu> wrote:
>
>> Stephen Hemminger <stephen@networkplumber.org> writes:
>>
>> > On Thu, 21 Apr 2022 12:38:26 +0800
>> > Stephen Coleman <omegacoleman@gmail.com> wrote:
>> >
>> >> KNI ioctl functions copy data from userspace lib, and this interface
>> >> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
>> >> bad things happen: sometimes various fields contain garbage value,
>> >> sometimes it cause a kmod soft lockup.
>> >>
>> >> Some common distros ship their own rte_kni.ko, so this is likely to
>> >> happen.
>> >>
>> >> This patch add abi version checking between userland lib and kmod so
>> >> that:
>> >>
>> >> * if kmod ioctl got a wrong abi magic, it refuse to go on
>> >> * if userland lib, probed a wrong abi version via newly added ioctl, it
>> >> also refuse to go on
>> >>
>> >> Bugzilla ID: 998
>> >
>> >
>> > Kernel API's are supposed to be 99% stable.
>> > If this driver was playing by the upstream kernel rules this would not
>> > have happened.
>>
>> Well look, it is out-of-tree and never likely to be in-tree, so those
>> rules don't apply. Making sure the ABI doesn't change during the ABI
>> stablity period, should be good enough?
>>
>
> I think if KNI changes, it should just add more ioctl numbers and
> be compatible, it is not that hard.
True, fair point, I am unsure what that buys us though. My thinking was
that we should be doing the minimal amount of work on KNI, and directing
people to use upstream alternatives where possible.
For me minimizing means DPDK ABI alignment. However I see your point,
let KNI maintain it own ABI versioning independent of DPDK, with
stricter kernel-like guarantees is probably not much more work.
--
Regards, Ray K
^ permalink raw reply [relevance 8%]
* Re: [RFC] eal: add bus cleanup to eal cleanup
2022-04-20 6:55 4% ` Morten Brørup
@ 2022-04-22 9:18 4% ` Kevin Laatz
2022-04-22 12:14 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Kevin Laatz @ 2022-04-22 9:18 UTC (permalink / raw)
To: Morten Brørup, dev
On 20/04/2022 07:55, Morten Brørup wrote:
>> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
>> Sent: Tuesday, 19 April 2022 18.15
>>
>> During EAL init, all buses are probed and the devices found are
>> initialized. On eal_cleanup(), the inverse does not happen, meaning any
>> allocated memory and other configuration will not be cleaned up
>> appropriately on exit.
>>
>> Currently, in order for device cleanup to take place, applications must
>> call the driver-relevant functions to ensure proper cleanup is done
>> before
>> the application exits. Since initialization occurs for all devices on
>> the
>> bus, not just the devices used by an application, it requires a)
>> application awareness of all bus devices that could have been probed on
>> the
>> system, and b) code duplication across applications to ensure cleanup
>> is
>> performed. An example of this is rte_eth_dev_close() which is commonly
>> used
>> across the example applications.
>>
>> This RFC proposes adding bus cleanup to the eal_cleanup() to make EAL's
>> init/exit more symmetrical, ensuring all bus devices are cleaned up
>> appropriately without the application needing to be aware of all bus
>> types
>> that may have been probed during initialization.
>>
>> Contained in this RFC are the changes required to perform cleanup for
>> devices on the PCI bus during eal_cleanup(). This can be expanded in
>> subsequent versions if these changes are desired. There would be an ask
>> for
>> bus maintainers to add the relevant cleanup for their buses since they
>> have
>> the domain expertise.
>>
>> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
>> ---
> [...]
>
>> + RTE_LOG(INFO, EAL,
>> + "Clean up PCI driver: %s (%x:%x) device:
>> "PCI_PRI_FMT" (socket %i)\n",
>> + drv->driver.name, dev->id.vendor_id, dev-
>>> id.device_id,
>> + loc->domain, loc->bus, loc->devid, loc-
>>> function,
>> + dev->device.numa_node);
> I agree with Stephen, this message might as well be DEBUG level. You could argue for symmetry: If the "alloc" message during startup is INFO level, it makes sense using INFO level for the "free" message during cleanup too. However, the message probably has far lower information value during cleanup (because this driver cleanup is expected to happen), so I would degrade it to DEBUG level. Symmetry is not always the strongest argument. I have no strong preference, so I'll leave it up to you, Kevin.
Thanks for the feedback.
+1, will change to debug for v2.
>
> [...]
>
>> @@ -263,6 +275,7 @@ struct rte_bus {
>> const char *name; /**< Name of the bus */
>> rte_bus_scan_t scan; /**< Scan for devices attached to
>> bus */
>> rte_bus_probe_t probe; /**< Probe devices on bus */
>> + rte_bus_cleanup_t cleanup; /**< Cleanup devices on bus */
>> rte_bus_find_device_t find_device; /**< Find a device on the bus
>> */
>> rte_bus_plug_t plug; /**< Probe single device for drivers
>> */
>> rte_bus_unplug_t unplug; /**< Remove single device from
>> driver */
> Have you considered if modifying the rte_bus structure in /lib/eal/include/rte_bus.h breaks the ABI or not?
I've looked into this and have run test-meson-builds with ABI checks
enabled.
The output of those checks flagged some potential breaks, however I
believe these are false positives. The output indicated 2 potential
breaks (in multiple places, but the root is the same)
1. Member has been added to the rte_bus struct. This is flagged as a
sub-type change, however since rte_bus is only ever reference by
pointer, it is not a break.
2. Offset of members changes in 'rte_pci_bus' and 'rte_vmbus_bus'
structs. These structs are only used internally so also do no break ABI.
Since the ABI checks do flag the addition, I will add an entry to the
abignore for the v2.
>
>
> Overall, this patch is certainly a good idea!
>
> On the condition that modifying the rte_bus structure does not break the ABI...
>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>
^ permalink raw reply [relevance 4%]
* Re: kni: check abi version between kmod and lib
2022-04-22 8:46 8% ` Ray Kinsella
@ 2022-04-22 10:07 4% ` Stephen Coleman
0 siblings, 0 replies; 200+ results
From: Stephen Coleman @ 2022-04-22 10:07 UTC (permalink / raw)
To: Ray Kinsella; +Cc: Stephen Hemminger, dev, Ferruh Yigit
thanks for your replies
I'm aware that kernel guidelines propose ascending ioctl numbers to
max out compatibility, but this will not work with dpdk, especially
our case here.
If you look into kni_net.c you'll see the module is actually
internally depending on the memory layout of mbuf and a few other
structs, you will need to change ioctl numbers if those change, and
that's very implicit and requires extra effort. Plus the compatibility
is almost impossible to maintain across dpdk releases, as the module
won't know which version of mbuf layout it is working with.
In short, rte_kni.ko is part of dpdk rather than part of kernel, and
different parts of different dpdk releases do not work together -- so
we reject them early in the first before it make a disaster.
p.s. working on v3 to fix code format issues
p.p.s. forgot to 'reply all' last time, sorry for the duplication
>
>
> Stephen Hemminger <stephen@networkplumber.org> writes:
>
> > On Thu, 21 Apr 2022 11:40:00 -0400
> > Ray Kinsella <mdr@ashroe.eu> wrote:
> >
> >> Stephen Hemminger <stephen@networkplumber.org> writes:
> >>
> >> > On Thu, 21 Apr 2022 12:38:26 +0800
> >> > Stephen Coleman <omegacoleman@gmail.com> wrote:
> >> >
> >> >> KNI ioctl functions copy data from userspace lib, and this interface
> >> >> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
> >> >> bad things happen: sometimes various fields contain garbage value,
> >> >> sometimes it cause a kmod soft lockup.
> >> >>
> >> >> Some common distros ship their own rte_kni.ko, so this is likely to
> >> >> happen.
> >> >>
> >> >> This patch add abi version checking between userland lib and kmod so
> >> >> that:
> >> >>
> >> >> * if kmod ioctl got a wrong abi magic, it refuse to go on
> >> >> * if userland lib, probed a wrong abi version via newly added ioctl, it
> >> >> also refuse to go on
> >> >>
> >> >> Bugzilla ID: 998
> >> >
> >> >
> >> > Kernel API's are supposed to be 99% stable.
> >> > If this driver was playing by the upstream kernel rules this would not
> >> > have happened.
> >>
> >> Well look, it is out-of-tree and never likely to be in-tree, so those
> >> rules don't apply. Making sure the ABI doesn't change during the ABI
> >> stablity period, should be good enough?
> >>
> >
> > I think if KNI changes, it should just add more ioctl numbers and
> > be compatible, it is not that hard.
>
> True, fair point, I am unsure what that buys us though. My thinking was
> that we should be doing the minimal amount of work on KNI, and directing
> people to use upstream alternatives where possible.
>
> For me minimizing means DPDK ABI alignment. However I see your point,
> let KNI maintain it own ABI versioning independent of DPDK, with
> stricter kernel-like guarantees is probably not much more work.
>
> --
> Regards, Ray K
^ permalink raw reply [relevance 4%]
* RE: [RFC] eal: add bus cleanup to eal cleanup
2022-04-22 9:18 4% ` Kevin Laatz
@ 2022-04-22 12:14 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-04-22 12:14 UTC (permalink / raw)
To: Kevin Laatz, dev
> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
> Sent: Friday, 22 April 2022 11.18
>
> On 20/04/2022 07:55, Morten Brørup wrote:
> >> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
> >> Sent: Tuesday, 19 April 2022 18.15
> >>
> >> During EAL init, all buses are probed and the devices found are
> >> initialized. On eal_cleanup(), the inverse does not happen, meaning
> any
> >> allocated memory and other configuration will not be cleaned up
> >> appropriately on exit.
> >>
> >> Currently, in order for device cleanup to take place, applications
> must
> >> call the driver-relevant functions to ensure proper cleanup is done
> >> before
> >> the application exits. Since initialization occurs for all devices
> on
> >> the
> >> bus, not just the devices used by an application, it requires a)
> >> application awareness of all bus devices that could have been probed
> on
> >> the
> >> system, and b) code duplication across applications to ensure
> cleanup
> >> is
> >> performed. An example of this is rte_eth_dev_close() which is
> commonly
> >> used
> >> across the example applications.
> >>
> >> This RFC proposes adding bus cleanup to the eal_cleanup() to make
> EAL's
> >> init/exit more symmetrical, ensuring all bus devices are cleaned up
> >> appropriately without the application needing to be aware of all bus
> >> types
> >> that may have been probed during initialization.
> >>
> >> Contained in this RFC are the changes required to perform cleanup
> for
> >> devices on the PCI bus during eal_cleanup(). This can be expanded in
> >> subsequent versions if these changes are desired. There would be an
> ask
> >> for
> >> bus maintainers to add the relevant cleanup for their buses since
> they
> >> have
> >> the domain expertise.
> >>
> >> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> >> ---
> > [...]
> >
> >> + RTE_LOG(INFO, EAL,
> >> + "Clean up PCI driver: %s (%x:%x) device:
> >> "PCI_PRI_FMT" (socket %i)\n",
> >> + drv->driver.name, dev->id.vendor_id, dev-
> >>> id.device_id,
> >> + loc->domain, loc->bus, loc->devid, loc-
> >>> function,
> >> + dev->device.numa_node);
> > I agree with Stephen, this message might as well be DEBUG level. You
> could argue for symmetry: If the "alloc" message during startup is INFO
> level, it makes sense using INFO level for the "free" message during
> cleanup too. However, the message probably has far lower information
> value during cleanup (because this driver cleanup is expected to
> happen), so I would degrade it to DEBUG level. Symmetry is not always
> the strongest argument. I have no strong preference, so I'll leave it
> up to you, Kevin.
>
> Thanks for the feedback.
>
> +1, will change to debug for v2.
>
>
> >
> > [...]
> >
> >> @@ -263,6 +275,7 @@ struct rte_bus {
> >> const char *name; /**< Name of the bus */
> >> rte_bus_scan_t scan; /**< Scan for devices attached to
> >> bus */
> >> rte_bus_probe_t probe; /**< Probe devices on bus */
> >> + rte_bus_cleanup_t cleanup; /**< Cleanup devices on bus */
> >> rte_bus_find_device_t find_device; /**< Find a device on the bus
> >> */
> >> rte_bus_plug_t plug; /**< Probe single device for drivers
> >> */
> >> rte_bus_unplug_t unplug; /**< Remove single device from
> >> driver */
> > Have you considered if modifying the rte_bus structure in
> /lib/eal/include/rte_bus.h breaks the ABI or not?
>
> I've looked into this and have run test-meson-builds with ABI checks
> enabled.
>
> The output of those checks flagged some potential breaks, however I
> believe these are false positives. The output indicated 2 potential
> breaks (in multiple places, but the root is the same)
>
> 1. Member has been added to the rte_bus struct. This is flagged as a
> sub-type change, however since rte_bus is only ever reference by
> pointer, it is not a break.
>
> 2. Offset of members changes in 'rte_pci_bus' and 'rte_vmbus_bus'
> structs. These structs are only used internally so also do no break
> ABI.
>
Sounds good! Then there should be no more worries. :-)
>
> Since the ABI checks do flag the addition, I will add an entry to the
> abignore for the v2.
>
>
> >
> >
> > Overall, this patch is certainly a good idea!
> >
> > On the condition that modifying the rte_bus structure does not break
> the ABI...
> >
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >
^ permalink raw reply [relevance 0%]
* [PATCH v3] kni: check abi version between kmod and lib
2022-04-21 4:38 16% kni: check abi version between kmod and lib Stephen Coleman
` (2 preceding siblings ...)
2022-04-21 16:34 15% ` [PATCH v2] " youcai
@ 2022-04-24 8:51 15% ` youcai
2022-04-24 10:35 4% ` Stephen Coleman
3 siblings, 1 reply; 200+ results
From: youcai @ 2022-04-24 8:51 UTC (permalink / raw)
To: dev; +Cc: Ray Kinsella, Stephen Hemminger, Ferruh Yigit, youcai
KNI ioctl functions copy data from userspace lib, and this interface
of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
bad things happen: sometimes various fields contain garbage value,
sometimes it cause a kmod soft lockup.
Some common distros ship their own rte_kni.ko, so this is likely to
happen.
This patch add abi version checking between userland lib and kmod so
that:
* if kmod ioctl got a wrong abi magic, it refuse to go on
* if userland lib, probed a wrong abi version via newly added ioctl, it
also refuse to go on
Bugzilla ID: 998
Signed-off-by: youcai <omegacoleman@gmail.com>
---
V3: fix code format issues
V2: use ABI_VERSION instead of a new magic
V2: fix some indent
---
kernel/linux/kni/kni_misc.c | 42 ++++++++++++++++++++++++++++++++++++
kernel/linux/kni/meson.build | 4 ++--
lib/kni/meson.build | 1 +
lib/kni/rte_kni.c | 18 ++++++++++++++++
lib/kni/rte_kni_abi.h | 17 +++++++++++++++
lib/kni/rte_kni_common.h | 3 +++
6 files changed, 83 insertions(+), 2 deletions(-)
create mode 100644 lib/kni/rte_kni_abi.h
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 780187d8bf..d92500414d 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -17,6 +17,7 @@
#include <net/netns/generic.h>
#include <rte_kni_common.h>
+#include <rte_kni_abi.h>
#include "compat.h"
#include "kni_dev.h"
@@ -236,12 +237,26 @@ kni_release(struct inode *inode, struct file *file)
return 0;
}
+static int
+kni_check_abi_version_magic(uint16_t abi_version_magic)
+{
+ if (abi_version_magic != RTE_KNI_ABI_VERSION_MAGIC) {
+ pr_err("KNI kmod ABI incompatible with librte_kni -- %u\n",
+ RTE_KNI_ABI_VERSION_FROM_MAGIC(abi_version_magic));
+ return -1;
+ }
+ return 0;
+}
+
static int
kni_check_param(struct kni_dev *kni, struct rte_kni_device_info *dev)
{
if (!kni || !dev)
return -1;
+ if (kni_check_abi_version_magic(dev->abi_version_magic) < 0)
+ return -1;
+
/* Check if network name has been used */
if (!strncmp(kni->name, dev->name, RTE_KNI_NAMESIZE)) {
pr_err("KNI name %s duplicated\n", dev->name);
@@ -301,12 +316,19 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
struct rte_kni_device_info dev_info;
struct net_device *net_dev = NULL;
struct kni_dev *kni, *dev, *n;
+ uint16_t abi_version_magic;
pr_info("Creating kni...\n");
/* Check the buffer size, to avoid warning */
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
+ /* perform abi check ahead of copy, to avoid possible violation */
+ if (copy_from_user(&abi_version_magic, (void *)ioctl_param, sizeof(uint16_t)))
+ return -EFAULT;
+ if (kni_check_abi_version_magic(abi_version_magic) < 0)
+ return -EINVAL;
+
/* Copy kni info from user space */
if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
return -EFAULT;
@@ -451,10 +473,17 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
int ret = -EINVAL;
struct kni_dev *dev, *n;
struct rte_kni_device_info dev_info;
+ uint16_t abi_version_magic;
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
+ /* perform abi check ahead of copy, to avoid possible violation */
+ if (copy_from_user(&abi_version_magic, (void *)ioctl_param, sizeof(uint16_t)))
+ return -EFAULT;
+ if (kni_check_abi_version_magic(abi_version_magic) < 0)
+ return -EINVAL;
+
if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
return -EFAULT;
@@ -484,6 +513,16 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
return ret;
}
+static int
+kni_ioctl_abi_version(struct net *net, uint32_t ioctl_num,
+ unsigned long ioctl_param)
+{
+ uint16_t abi_version = ABI_VERSION_MAJOR;
+ if (copy_to_user((void *)ioctl_param, &abi_version, sizeof(uint16_t)))
+ return -EFAULT;
+ return 0;
+}
+
static long
kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long ioctl_param)
{
@@ -505,6 +544,9 @@ kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long ioctl_param)
case _IOC_NR(RTE_KNI_IOCTL_RELEASE):
ret = kni_ioctl_release(net, ioctl_num, ioctl_param);
break;
+ case _IOC_NR(RTE_KNI_IOCTL_ABI_VERSION):
+ ret = kni_ioctl_abi_version(net, ioctl_num, ioctl_param);
+ break;
default:
pr_debug("IOCTL default\n");
break;
diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
index 4c90069e99..c8cd23acd9 100644
--- a/kernel/linux/kni/meson.build
+++ b/kernel/linux/kni/meson.build
@@ -3,12 +3,12 @@
# For SUSE build check function arguments of ndo_tx_timeout API
# Ref: https://jira.devtools.intel.com/browse/DPDK-29263
-kmod_cflags = ''
+kmod_cflags = '-DABI_VERSION_MAJOR=@0@'.format(abi_version.split('.')[0])
file_path = kernel_source_dir + '/include/linux/netdevice.h'
run_cmd = run_command('grep', 'ndo_tx_timeout', file_path, check: false)
if run_cmd.stdout().contains('txqueue') == true
- kmod_cflags = '-DHAVE_ARG_TX_QUEUE'
+ kmod_cflags += ' -DHAVE_ARG_TX_QUEUE'
endif
diff --git a/lib/kni/meson.build b/lib/kni/meson.build
index 8a71d8ba6f..f22a27b15b 100644
--- a/lib/kni/meson.build
+++ b/lib/kni/meson.build
@@ -14,3 +14,4 @@ endif
sources = files('rte_kni.c')
headers = files('rte_kni.h', 'rte_kni_common.h')
deps += ['ethdev', 'pci']
+cflags += ['-DABI_VERSION_MAJOR=@0@'.format(abi_version.split('.')[0])]
diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 7971c56bb4..9bdeeb3806 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -22,6 +22,7 @@
#include <rte_eal_memconfig.h>
#include <rte_kni_common.h>
#include "rte_kni_fifo.h"
+#include "rte_kni_abi.h"
#define MAX_MBUF_BURST_NUM 32
@@ -113,6 +114,20 @@ rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
}
}
+ uint16_t abi_version;
+ int ret = ioctl(kni_fd, RTE_KNI_IOCTL_ABI_VERSION, &abi_version);
+ if (ret < 0) {
+ RTE_LOG(ERR, KNI, "Cannot verify rte_kni kmod ABI version: ioctl failed\n");
+ return -1;
+ }
+ if (abi_version != ABI_VERSION_MAJOR) {
+ RTE_LOG(ERR, KNI,
+ "rte_kni kmod ABI version mismatch: "
+ "need %" PRIu16 " got %" PRIu16 "\n",
+ ABI_VERSION_MAJOR, abi_version);
+ return -1;
+ }
+
return 0;
}
@@ -255,6 +270,7 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
kni->ops.port_id = UINT16_MAX;
memset(&dev_info, 0, sizeof(dev_info));
+ dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
dev_info.core_id = conf->core_id;
dev_info.force_bind = conf->force_bind;
dev_info.group_id = conf->group_id;
@@ -409,6 +425,8 @@ rte_kni_release(struct rte_kni *kni)
if (!kni)
return -1;
+ dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
+
kni_list = RTE_TAILQ_CAST(rte_kni_tailq.head, rte_kni_list);
rte_mcfg_tailq_write_lock();
diff --git a/lib/kni/rte_kni_abi.h b/lib/kni/rte_kni_abi.h
new file mode 100644
index 0000000000..7dde394c72
--- /dev/null
+++ b/lib/kni/rte_kni_abi.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: (BSD-3-Clause OR LGPL-2.1) */
+/*
+ * Copyright(c) 2007-2014 Intel Corporation.
+ */
+
+#ifndef _RTE_KNI_ABI_H_
+#define _RTE_KNI_ABI_H_
+
+#ifndef ABI_VERSION_MAJOR
+#error Need ABI_VERSION_MAJOR being the major part of dpdk/ABI_VERSION
+#endif
+#define RTE_KNI_ABI_VERSION_MAGIC_MASK 0xAAAA
+#define RTE_KNI_ABI_VERSION_MAGIC (((ABI_VERSION_MAJOR) ^ RTE_KNI_ABI_VERSION_MAGIC_MASK))
+#define RTE_KNI_ABI_VERSION_FROM_MAGIC(__magic) (((__magic) ^ RTE_KNI_ABI_VERSION_MAGIC_MASK))
+
+#endif
+
diff --git a/lib/kni/rte_kni_common.h b/lib/kni/rte_kni_common.h
index 8d3ee0fa4f..f9432b742c 100644
--- a/lib/kni/rte_kni_common.h
+++ b/lib/kni/rte_kni_common.h
@@ -102,6 +102,8 @@ struct rte_kni_mbuf {
*/
struct rte_kni_device_info {
+ uint16_t abi_version_magic;
+
char name[RTE_KNI_NAMESIZE]; /**< Network device name for KNI */
phys_addr_t tx_phys;
@@ -139,6 +141,7 @@ struct rte_kni_device_info {
#define RTE_KNI_IOCTL_TEST _IOWR(0, 1, int)
#define RTE_KNI_IOCTL_CREATE _IOWR(0, 2, struct rte_kni_device_info)
#define RTE_KNI_IOCTL_RELEASE _IOWR(0, 3, struct rte_kni_device_info)
+#define RTE_KNI_IOCTL_ABI_VERSION _IOWR(0, 4, uint16_t)
#ifdef __cplusplus
}
--
2.35.1
^ permalink raw reply [relevance 15%]
* Re: kni: check abi version between kmod and lib
2022-04-24 8:51 15% ` [PATCH v3] " youcai
@ 2022-04-24 10:35 4% ` Stephen Coleman
0 siblings, 0 replies; 200+ results
From: Stephen Coleman @ 2022-04-24 10:35 UTC (permalink / raw)
To: dev; +Cc: Ray Kinsella, Stephen Hemminger, Ferruh Yigit, youcai
[-- Attachment #1: Type: text/plain, Size: 9534 bytes --]
execuse me, one of the Windows check is failing but I didn't find where's
the build log, nor to determine whether it is related.
> KNI ioctl functions copy data from userspace lib, and this interface
> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko
> bad things happen: sometimes various fields contain garbage value,
> sometimes it cause a kmod soft lockup.
>
> Some common distros ship their own rte_kni.ko, so this is likely to
> happen.
>
> This patch add abi version checking between userland lib and kmod so
> that:
>
> * if kmod ioctl got a wrong abi magic, it refuse to go on
> * if userland lib, probed a wrong abi version via newly added ioctl, it
> also refuse to go on
>
> Bugzilla ID: 998
>
> Signed-off-by: youcai <omegacoleman@gmail.com>
>
> ---
> V3: fix code format issues
>
> V2: use ABI_VERSION instead of a new magic
> V2: fix some indent
> ---
> kernel/linux/kni/kni_misc.c | 42 ++++++++++++++++++++++++++++++++++++
> kernel/linux/kni/meson.build | 4 ++--
> lib/kni/meson.build | 1 +
> lib/kni/rte_kni.c | 18 ++++++++++++++++
> lib/kni/rte_kni_abi.h | 17 +++++++++++++++
> lib/kni/rte_kni_common.h | 3 +++
> 6 files changed, 83 insertions(+), 2 deletions(-)
> create mode 100644 lib/kni/rte_kni_abi.h
>
> diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
> index 780187d8bf..d92500414d 100644
> --- a/kernel/linux/kni/kni_misc.c
> +++ b/kernel/linux/kni/kni_misc.c
> @@ -17,6 +17,7 @@
> #include <net/netns/generic.h>
>
> #include <rte_kni_common.h>
> +#include <rte_kni_abi.h>
>
> #include "compat.h"
> #include "kni_dev.h"
> @@ -236,12 +237,26 @@ kni_release(struct inode *inode, struct file *file)
> return 0;
> }
>
> +static int
> +kni_check_abi_version_magic(uint16_t abi_version_magic)
> +{
> + if (abi_version_magic != RTE_KNI_ABI_VERSION_MAGIC) {
> + pr_err("KNI kmod ABI incompatible with librte_kni --
%u\n",
> +
RTE_KNI_ABI_VERSION_FROM_MAGIC(abi_version_magic));
> + return -1;
> + }
> + return 0;
> +}
> +
> static int
> kni_check_param(struct kni_dev *kni, struct rte_kni_device_info *dev)
> {
> if (!kni || !dev)
> return -1;
>
> + if (kni_check_abi_version_magic(dev->abi_version_magic) < 0)
> + return -1;
> +
> /* Check if network name has been used */
> if (!strncmp(kni->name, dev->name, RTE_KNI_NAMESIZE)) {
> pr_err("KNI name %s duplicated\n", dev->name);
> @@ -301,12 +316,19 @@ kni_ioctl_create(struct net *net, uint32_t
ioctl_num,
> struct rte_kni_device_info dev_info;
> struct net_device *net_dev = NULL;
> struct kni_dev *kni, *dev, *n;
> + uint16_t abi_version_magic;
>
> pr_info("Creating kni...\n");
> /* Check the buffer size, to avoid warning */
> if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
> return -EINVAL;
>
> + /* perform abi check ahead of copy, to avoid possible violation */
> + if (copy_from_user(&abi_version_magic, (void *)ioctl_param,
sizeof(uint16_t)))
> + return -EFAULT;
> + if (kni_check_abi_version_magic(abi_version_magic) < 0)
> + return -EINVAL;
> +
> /* Copy kni info from user space */
> if (copy_from_user(&dev_info, (void *)ioctl_param,
sizeof(dev_info)))
> return -EFAULT;
> @@ -451,10 +473,17 @@ kni_ioctl_release(struct net *net, uint32_t
ioctl_num,
> int ret = -EINVAL;
> struct kni_dev *dev, *n;
> struct rte_kni_device_info dev_info;
> + uint16_t abi_version_magic;
>
> if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
> return -EINVAL;
>
> + /* perform abi check ahead of copy, to avoid possible violation */
> + if (copy_from_user(&abi_version_magic, (void *)ioctl_param,
sizeof(uint16_t)))
> + return -EFAULT;
> + if (kni_check_abi_version_magic(abi_version_magic) < 0)
> + return -EINVAL;
> +
> if (copy_from_user(&dev_info, (void *)ioctl_param,
sizeof(dev_info)))
> return -EFAULT;
>
> @@ -484,6 +513,16 @@ kni_ioctl_release(struct net *net, uint32_t
ioctl_num,
> return ret;
> }
>
> +static int
> +kni_ioctl_abi_version(struct net *net, uint32_t ioctl_num,
> + unsigned long ioctl_param)
> +{
> + uint16_t abi_version = ABI_VERSION_MAJOR;
> + if (copy_to_user((void *)ioctl_param, &abi_version,
sizeof(uint16_t)))
> + return -EFAULT;
> + return 0;
> +}
> +
> static long
> kni_ioctl(struct file *file, unsigned int ioctl_num, unsigned long
ioctl_param)
> {
> @@ -505,6 +544,9 @@ kni_ioctl(struct file *file, unsigned int ioctl_num,
unsigned long ioctl_param)
> case _IOC_NR(RTE_KNI_IOCTL_RELEASE):
> ret = kni_ioctl_release(net, ioctl_num, ioctl_param);
> break;
> + case _IOC_NR(RTE_KNI_IOCTL_ABI_VERSION):
> + ret = kni_ioctl_abi_version(net, ioctl_num, ioctl_param);
> + break;
> default:
> pr_debug("IOCTL default\n");
> break;
> diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
> index 4c90069e99..c8cd23acd9 100644
> --- a/kernel/linux/kni/meson.build
> +++ b/kernel/linux/kni/meson.build
> @@ -3,12 +3,12 @@
>
> # For SUSE build check function arguments of ndo_tx_timeout API
> # Ref: https://jira.devtools.intel.com/browse/DPDK-29263
> -kmod_cflags = ''
> +kmod_cflags = '-DABI_VERSION_MAJOR=@0@'.format(abi_version.split('.')[0])
> file_path = kernel_source_dir + '/include/linux/netdevice.h'
> run_cmd = run_command('grep', 'ndo_tx_timeout', file_path, check: false)
>
> if run_cmd.stdout().contains('txqueue') == true
> - kmod_cflags = '-DHAVE_ARG_TX_QUEUE'
> + kmod_cflags += ' -DHAVE_ARG_TX_QUEUE'
> endif
>
>
> diff --git a/lib/kni/meson.build b/lib/kni/meson.build
> index 8a71d8ba6f..f22a27b15b 100644
> --- a/lib/kni/meson.build
> +++ b/lib/kni/meson.build
> @@ -14,3 +14,4 @@ endif
> sources = files('rte_kni.c')
> headers = files('rte_kni.h', 'rte_kni_common.h')
> deps += ['ethdev', 'pci']
> +cflags += ['-DABI_VERSION_MAJOR=@0@'.format(abi_version.split('.')[0])]
> diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
> index 7971c56bb4..9bdeeb3806 100644
> --- a/lib/kni/rte_kni.c
> +++ b/lib/kni/rte_kni.c
> @@ -22,6 +22,7 @@
> #include <rte_eal_memconfig.h>
> #include <rte_kni_common.h>
> #include "rte_kni_fifo.h"
> +#include "rte_kni_abi.h"
>
> #define MAX_MBUF_BURST_NUM 32
>
> @@ -113,6 +114,20 @@ rte_kni_init(unsigned int max_kni_ifaces
__rte_unused)
> }
> }
>
> + uint16_t abi_version;
> + int ret = ioctl(kni_fd, RTE_KNI_IOCTL_ABI_VERSION, &abi_version);
> + if (ret < 0) {
> + RTE_LOG(ERR, KNI, "Cannot verify rte_kni kmod ABI
version: ioctl failed\n");
> + return -1;
> + }
> + if (abi_version != ABI_VERSION_MAJOR) {
> + RTE_LOG(ERR, KNI,
> + "rte_kni kmod ABI version mismatch: "
> + "need %" PRIu16 " got %" PRIu16 "\n",
> + ABI_VERSION_MAJOR, abi_version);
> + return -1;
> + }
> +
> return 0;
> }
>
> @@ -255,6 +270,7 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
> kni->ops.port_id = UINT16_MAX;
>
> memset(&dev_info, 0, sizeof(dev_info));
> + dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
> dev_info.core_id = conf->core_id;
> dev_info.force_bind = conf->force_bind;
> dev_info.group_id = conf->group_id;
> @@ -409,6 +425,8 @@ rte_kni_release(struct rte_kni *kni)
> if (!kni)
> return -1;
>
> + dev_info.abi_version_magic = RTE_KNI_ABI_VERSION_MAGIC;
> +
> kni_list = RTE_TAILQ_CAST(rte_kni_tailq.head, rte_kni_list);
>
> rte_mcfg_tailq_write_lock();
> diff --git a/lib/kni/rte_kni_abi.h b/lib/kni/rte_kni_abi.h
> new file mode 100644
> index 0000000000..7dde394c72
> --- /dev/null
> +++ b/lib/kni/rte_kni_abi.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: (BSD-3-Clause OR LGPL-2.1) */
> +/*
> + * Copyright(c) 2007-2014 Intel Corporation.
> + */
> +
> +#ifndef _RTE_KNI_ABI_H_
> +#define _RTE_KNI_ABI_H_
> +
> +#ifndef ABI_VERSION_MAJOR
> +#error Need ABI_VERSION_MAJOR being the major part of dpdk/ABI_VERSION
> +#endif
> +#define RTE_KNI_ABI_VERSION_MAGIC_MASK 0xAAAA
> +#define RTE_KNI_ABI_VERSION_MAGIC (((ABI_VERSION_MAJOR) ^
RTE_KNI_ABI_VERSION_MAGIC_MASK))
> +#define RTE_KNI_ABI_VERSION_FROM_MAGIC(__magic) (((__magic) ^
RTE_KNI_ABI_VERSION_MAGIC_MASK))
> +
> +#endif
> +
> diff --git a/lib/kni/rte_kni_common.h b/lib/kni/rte_kni_common.h
> index 8d3ee0fa4f..f9432b742c 100644
> --- a/lib/kni/rte_kni_common.h
> +++ b/lib/kni/rte_kni_common.h
> @@ -102,6 +102,8 @@ struct rte_kni_mbuf {
> */
>
> struct rte_kni_device_info {
> + uint16_t abi_version_magic;
> +
> char name[RTE_KNI_NAMESIZE]; /**< Network device name for KNI */
>
> phys_addr_t tx_phys;
> @@ -139,6 +141,7 @@ struct rte_kni_device_info {
> #define RTE_KNI_IOCTL_TEST _IOWR(0, 1, int)
> #define RTE_KNI_IOCTL_CREATE _IOWR(0, 2, struct rte_kni_device_info)
> #define RTE_KNI_IOCTL_RELEASE _IOWR(0, 3, struct rte_kni_device_info)
> +#define RTE_KNI_IOCTL_ABI_VERSION _IOWR(0, 4, uint16_t)
>
> #ifdef __cplusplus
> }
> --
> 2.35.1
>
>
[-- Attachment #2: Type: text/html, Size: 12224 bytes --]
^ permalink raw reply [relevance 4%]
* Re: 21.11.1 patches review and test
2022-04-20 5:50 3% ` Christian Ehrhardt
@ 2022-04-25 13:39 0% ` Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2022-04-25 13:39 UTC (permalink / raw)
To: Christian Ehrhardt
Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, hariprasad.govindharajan, Hemant Agrawal,
Ian Stokes, Jerin Jacob, John McNamara, Ju-Hyoung Lee,
Luca Boccassi, Pei Zhang, qian.q.xu, Raslan Darawsheh,
Thomas Monjalon, yuan.peng, zhaoyan.chen
On 20/04/2022 06:50, Christian Ehrhardt wrote:
> On Fri, Apr 1, 2022 at 12:22 PM Kevin Traynor<ktraynor@redhat.com> wrote:
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 21.11.1.
>>
>> Please try and complete validation by April 13th.
>>
>> Please help with testing and validation of your use cases and report
>> any issues/results with reply-all to this mail. For the final release
>> the fixes and reported validations will be added to the release notes.
>>
>> A release candidate tarball can be found at:
>>
>> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.1-rc1
>>
>> These patches are located at branch 21.11 of dpdk-stable repo:
>> https://dpdk.org/browse/dpdk-stable/
> Hi Kevin,
> now that the ABI change discussion has somewhat settled I have run the
> tests ignoring the symbols changes for now.
> All LGTM on Ubuntu 22.04 + OVS 2.17 + DPDK 21.11.1-rc1
>
> 1.0.0 (11:42:53): phys (BM) tests
> 1.1.0 (11:42:53): initialize environment
> 1.1.1 (11:44:54): testpmd => Pass
> 1.1.2 (11:45:43): check testpmd output => Pass
> 2.0.0 (11:45:43): prep virtual test environment
>
> 1.0.0 (11:48:05): virt tests
> 1.1.0 (11:48:05): initialize environment
> 3.0.0 (11:49:30): performance tests
> 3.1.0 (11:49:30): prep benchmarks
> 3.2.0 (11:49:51): performance tests
> 3.2.1 (11:50:02): test guest-openvswitch for OVS-5CPU => Pass
> 3.2.2 (12:09:30): test guest-dpdk-vhost-user-client-multiq for
> OVSDPDK-VUC => Pass
> 4.0.0 (12:28:54): VUC endurance checks
> 4.1.0 (12:28:54): prep VUC endurance tests
> 4.1.1 (12:41:59): start stop guests (client) => Pass
> 4.1.2 (13:48:30): add/remove ports (client) => Pass
> 4.2.0 (13:58:11): Final cleanup
>
> The above is kind of a high level test log, for the validation section
> of a stable release I usually use:
>
> * Build tests of DPDK & OVS 2.13.3 on Ubuntu 20.04 (meson based)
> * Functional and performance tests based on OVS-DPDK on x86_64
> * Autopkgtests for DPDK and OpenvSwitch
>
>
Thanks for the testing and Christian. I will add your summary to the
validation section.
^ permalink raw reply [relevance 0%]
* [PATCH 1/2] ci: switch to Ubuntu 20.04
@ 2022-04-26 7:18 4% David Marchand
2022-05-06 11:57 4% ` [PATCH v2 " David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-04-26 7:18 UTC (permalink / raw)
To: dev
Cc: Aaron Conole, Michael Santana, Ruifeng Wang, Jan Viktorin,
Bruce Richardson, David Christensen
Ubuntu 18.04 is now rather old.
Besides, other entities in our CI are also testing this distribution.
Switch to a newer Ubuntu release and benefit from more recent
tool(chain)s: for example, net/cnxk now builds fine and can be
re-enabled.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 7 ++----
.github/workflows/build.yml | 22 +++++++++----------
config/arm/arm64_armv8_linux_clang_ubuntu2004 | 1 +
.../ppc/ppc64le-power8-linux-gcc-ubuntu2004 | 1 +
4 files changed, 14 insertions(+), 17 deletions(-)
create mode 120000 config/arm/arm64_armv8_linux_clang_ubuntu2004
create mode 120000 config/ppc/ppc64le-power8-linux-gcc-ubuntu2004
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 6a937611fa..30119b61ba 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -38,18 +38,15 @@ catch_coredump() {
}
if [ "$AARCH64" = "true" ]; then
- # Note: common/cnxk is disabled for Ubuntu 18.04
- # https://bugs.dpdk.org/show_bug.cgi?id=697
- OPTS="$OPTS -Ddisable_drivers=common/cnxk"
if [ "${CC%%clang}" != "$CC" ]; then
- OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_clang_ubuntu1804"
+ OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_clang_ubuntu2004"
else
OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_gcc"
fi
fi
if [ "$PPC64LE" = "true" ]; then
- OPTS="$OPTS --cross-file config/ppc/ppc64le-power8-linux-gcc-ubuntu1804"
+ OPTS="$OPTS --cross-file config/ppc/ppc64le-power8-linux-gcc-ubuntu2004"
fi
if [ "$BUILD_DOCS" = "true" ]; then
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 22daaabb91..812aa7055d 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -30,43 +30,41 @@ jobs:
fail-fast: false
matrix:
config:
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
mini: mini
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
checks: abi+doc+tests
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: clang
library: static
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: clang
library: shared
checks: doc+tests
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
cross: i386
- # Note: common/cnxk is disabled for Ubuntu 18.04
- # https://bugs.dpdk.org/show_bug.cgi?id=697
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
cross: aarch64
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
cross: aarch64
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
cross: ppc64le
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
cross: ppc64le
diff --git a/config/arm/arm64_armv8_linux_clang_ubuntu2004 b/config/arm/arm64_armv8_linux_clang_ubuntu2004
new file mode 120000
index 0000000000..01f5b7643e
--- /dev/null
+++ b/config/arm/arm64_armv8_linux_clang_ubuntu2004
@@ -0,0 +1 @@
+arm64_armv8_linux_clang_ubuntu1804
\ No newline at end of file
diff --git a/config/ppc/ppc64le-power8-linux-gcc-ubuntu2004 b/config/ppc/ppc64le-power8-linux-gcc-ubuntu2004
new file mode 120000
index 0000000000..9d6139a19b
--- /dev/null
+++ b/config/ppc/ppc64le-power8-linux-gcc-ubuntu2004
@@ -0,0 +1 @@
+ppc64le-power8-linux-gcc-ubuntu1804
\ No newline at end of file
--
2.23.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
2022-04-21 18:02 5% ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
@ 2022-04-26 10:19 0% ` Ray Kinsella
2022-05-01 14:46 5% ` [dpdk-dev] [PATCH v5] " jerinj
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2022-04-26 10:19 UTC (permalink / raw)
To: jerinj
Cc: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, ajit.khaparde, aboyer, beilei.xing,
bruce.richardson, chas3, chenbo.xia, ciara.loftus, dsinghrawat,
ed.czeck, evgenys, grive, g.singh, zhouguoyang, haiyue.wang,
hkalra, heinrich.kuhn, hemant.agrawal, hyonkim, igorch,
irusskikh, jgrajcia, jasvinder.singh, jianwang, jiawenwu,
jingjing.wu, johndale, john.miller, linville, keith.wiles,
kirankumark, oulijun, lironh, longli, mw, spinler, matan,
matt.peters, maxime.coquelin, mk, humin29, pnalla, ndabilpuram,
qiming.yang, qi.z.zhang, radhac, rahul.lakkireddy, rmody,
rosen.xu, sachin.saxena, skoteshwar, shshaikh, shaibran,
shepard.siegel, asomalap, somnath.kotur, sthemmin,
steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2
jerinj@marvell.com writes:
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and
> support for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> v4..v3:
>
> - Aligned with community meeting call which is documented in
> https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
> as last message. With following exception,
> - Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
> there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
> Changing above symbols break existing application for no good.
> - Updated 22.07 release notes
> - Remove testpmd changes from series to finalize the API spec first and
> then we can send testpmd changes.
>
> v3..v2:
>
> - Fix input color flags as a bitmask
> - Add definitions for newly added API
>
> v2..v1:
> - Fix seperate typo
>
> v1..RFC:
>
> Address the review comments by Cristian at
> https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
>
> - Moved to v22.07 release
> - Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner
> cases
> - Added input_color_method
> - Removed union between vlan_table and dscp_table
> - Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3
> bits)
>
> .../traffic_metering_and_policing.rst | 33 ++++
> doc/guides/rel_notes/release_22_07.rst | 10 +
> lib/ethdev/rte_mtr.c | 23 +++
> lib/ethdev/rte_mtr.h | 186 +++++++++++++++++-
> lib/ethdev/rte_mtr_driver.h | 19 ++
> lib/ethdev/version.map | 4 +
> 6 files changed, 265 insertions(+), 10 deletions(-)
>
> diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> index ceb5a96488..75deabbaf1 100644
> --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> @@ -21,6 +21,7 @@ The main features are:
> * Policer actions (per meter output color): recolor, drop
> * Statistics (per policer output color)
> * Chaining multiple meter objects
> +* Protocol based input color selection
>
> Configuration steps
> -------------------
> @@ -105,3 +106,35 @@ traffic meter and policing library.
> * Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
> to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
> specified per color as show in :numref:`figure_rte_mtr_chaining`.
> +
> +Protocol based input color selection
> +------------------------------------
> +
> +The API supports selecting the input color based on the packet content.
> +Following is the API usage model for the same.
> +
> +#. Probe the protocol based input color selection device capabilities using
> + following parameter using ``rte_mtr_capabilities_get()`` API.
> +
> + * ``struct rte_mtr_capabilities::input_color_proto_mask;``
> + * ``struct rte_mtr_capabilities::separate_input_color_table_per_port``
> +
> +#. When creating the meter object using ``rte_mtr_create()``, configure
> + relevant input color selection parameters such as
> +
> + * Input color protocols with ``struct rte_mtr_params::input_color_proto_mask``
> +
> + * If ``struct rte_mtr_params::input_color_proto_mask`` has multiple bits set then
> + ``rte_mtr_color_in_protocol_priority_set()`` shall be used to set the priority,
> + in the order, in which protocol to be used to find the input color.
> +
> + * Fill the tables ``struct rte_mtr_params::dscp_table``,
> + ``struct rte_mtr_params::vlan_table`` based on input color selected.
> +
> + * Update the ``struct rte_mtr_params::default_input_color`` to determine
> + the default input color in case the input packet does not match
> + the input color method.
> +
> + * If needed, update the input color table at runtime using
> + ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
> + APIs.
> diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
> index 42a5f2d990..746622f9b3 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -55,6 +55,13 @@ New Features
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* **Added protocol based input color for meter.**
> +
> + Added new APIs ``rte_mtr_color_in_protocol_priority_set()``,
> + ``rte_mtr_meter_vlan_table_update()`` and updated ``struct rte_mtr_params``
> + and ``struct rte_mtr_capabilities`` to support protocol based
> + input color for meter.
> +
>
> Removed Items
> -------------
> @@ -102,6 +109,9 @@ ABI Changes
>
> * No ABI change that would break compatibility with 21.11.
>
> +* Experimental structures ``struct rte_mtr_params``
> + and ``struct rte_mtr_capabilities`` updated to support
> + protocol based input color for meter.
>
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
> index e49fcf271c..a112fe65f5 100644
> --- a/lib/ethdev/rte_mtr.c
> +++ b/lib/ethdev/rte_mtr.c
> @@ -207,6 +207,29 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> mtr_id, dscp_table, error);
> }
>
> +/** MTR object meter VLAN table update */
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
> + mtr_id, vlan_table, error);
> +}
> +
> +/** Set the priority for input color protocol on MTR object */
> +int
> +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto,
> + uint32_t priority,
> + struct rte_mtr_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + return RTE_MTR_FUNC(port_id, in_proto_prio_set)(dev,
> + mtr_id, proto, priority, error);
> +}
> +
> /** MTR object enabled stats update */
> int
> rte_mtr_stats_update(uint16_t port_id,
> diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> index 40df0888c8..76ffbcf724 100644
> --- a/lib/ethdev/rte_mtr.h
> +++ b/lib/ethdev/rte_mtr.h
> @@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
> const struct rte_flow_action *actions[RTE_COLORS];
> };
>
> +/**
> + * Input color protocol method
> + */
> +enum rte_mtr_color_in_protocol {
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
> +};
> +
> /**
> * Parameters for each traffic metering & policing object
> *
> @@ -233,20 +279,58 @@ struct rte_mtr_params {
> */
> int use_prev_mtr_color;
>
> - /** Meter input color. When non-NULL: it points to a pre-allocated and
> + /** Meter input color based on IP DSCP protocol field.
> + *
> + * Valid when *input_color_proto_mask* set to any of the following
> + * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
> + * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> + *
> + * When non-NULL: it points to a pre-allocated and
> * pre-populated table with exactly 64 elements providing the input
> * color for each value of the IPv4/IPv6 Differentiated Services Code
> - * Point (DSCP) input packet field. When NULL: it is equivalent to
> - * setting this parameter to an all-green populated table (i.e. table
> - * with all the 64 elements set to green color). The color blind mode
> - * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
> - * to either NULL or to an all-green populated table. When
> - * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
> - * at least one yellow or red color element, then the color aware mode
> - * is configured.
> + * Point (DSCP) input packet field.
> + *
> + * When NULL: it is equivalent to setting this parameter to an all-green
> + * populated table (i.e. table with all the 64 elements set to green
> + * color). The color blind mode is configured by setting
> + * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
> + * all-green populated table.
> + *
> + * When *use_prev_mtr_color* is non-zero value or when *dscp_table*
> + * contains at least one yellow or red color element, then the color
> + * aware mode is configured.
> + *
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> + * @see struct rte_mtr_params::input_color_proto_mask
> */
> enum rte_color *dscp_table;
> -
> + /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
> + * fields.
> + *
> + * Valid when *input_color_proto_mask* set to any of the following
> + * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
> + * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> + *
> + * When non-NULL: it points to a pre-allocated and pre-populated
> + * table with exactly 16 elements providing the input color for
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + *
> + * When NULL: it is equivalent to setting this parameter to an
> + * all-green populated table (i.e. table with
> + * all the 16 elements set to green color). The color blind mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *vlan_table* to either NULL or to an all-green populated table.
> + *
> + * When *use_prev_mtr_color* is non-zero value
> + * or when *vlan_table* contains at least one yellow or
> + * red color element, then the color aware mode is configured.
> + *
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> + * @see struct rte_mtr_params::input_color_proto_mask
> + */
> + enum rte_color *vlan_table;
> /** Non-zero to enable the meter, zero to disable the meter at the time
> * of MTR object creation. Ignored when the meter profile indicated by
> * *meter_profile_id* is set to NONE.
> @@ -261,6 +345,25 @@ struct rte_mtr_params {
>
> /** Meter policy ID. @see rte_mtr_meter_policy_add() */
> uint32_t meter_policy_id;
> +
> + /** Set of input color protocols to be enabled.
> + *
> + * Set value to zero to configure as color blind mode.
> + *
> + * When multiple bits set then rte_mtr_color_in_protocol_priority_set()
> + * shall be used to set the priority, in the order, in which protocol
> + * to be used to find the inpput color.
> + *
> + * @see enum rte_mtr_color_in_protocol
> + * @see rte_mtr_color_in_protocol_priority_set()
> + */
> + uint64_t input_color_proto_mask;
> +
> + /** Input color to be set for the input packet when none of the
> + * enabled input color methods is applicable to the input packet.
> + * Ignored when this when *input_color_proto_mask* set to zero.
> + */
> + enum rte_color default_input_color;
> };
>
> /**
> @@ -417,6 +520,16 @@ struct rte_mtr_capabilities {
> * @see enum rte_mtr_stats_type
> */
> uint64_t stats_mask;
> +
> + /** Set of supported input color protocol.
> + * @see enum rte_mtr_color_in_protocol
> + */
> + uint64_t input_color_proto_mask;
> +
> + /** When non-zero, it indicates that driver supports separate
> + * input color table for given ethdev port.
> + */
> + int separate_input_color_table_per_port;
> };
>
> /**
> @@ -832,6 +945,59 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/**
> + * MTR object VLAN table update
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] vlan_table
> + * When non-NULL: it points to a pre-allocated and pre-populated table with
> + * exactly 16 elements providing the input color for each value of the
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an "all-green"
> + * populated table (i.e. table with all the 16 elements set to green color).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> +/**
> + * Set the priority for input color protocol
> + *
> + * When multiple bits set in struct rte_mtr_params::input_color_proto_mask
> + * then this API shall be used to set the priority, in the order, in
> + * which protocol to be used to find the input color.
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] proto
> + * Input color protocol to apply priority.
> + * MTR object's *input_color_proto_mask* should be configured
> + * with proto value.
> + * @param[in] priority
> + * Input color protocol priority. Value zero indicates
> + * the highest priority.
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + *
> + * @see rte_mtr_params::input_color_proto_mask
> + */
> +__rte_experimental
> +int
> +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto, uint32_t priority,
> + struct rte_mtr_error *error);
> /**
> * MTR object enabled statistics counters update
> *
> diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
> index ee8c6ef7ad..827952adc6 100644
> --- a/lib/ethdev/rte_mtr_driver.h
> +++ b/lib/ethdev/rte_mtr_driver.h
> @@ -97,6 +97,19 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/** @internal mtr object meter vlan table update. */
> +typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> +
> +/** @internal Set the priority for input color protocol on MTR object. */
> +typedef int (*rte_mtr_meter_color_in_proto_prio_set_t)(struct rte_eth_dev *dev,
> + uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto,
> + uint32_t priority,
> + struct rte_mtr_error *error);
> +
> /** @internal MTR object enabled stats update. */
> typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
> uint32_t mtr_id,
> @@ -139,6 +152,12 @@ struct rte_mtr_ops {
> /** MTR object meter DSCP table update */
> rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
>
> + /** MTR object meter VLAN table update */
> + rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
> +
> + /** Set the priority for input color protocol on MTR object. */
> + rte_mtr_meter_color_in_proto_prio_set_t in_proto_prio_set;
> +
> /** MTR object enabled stats update */
> rte_mtr_stats_update_t stats_update;
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 20391ab29e..cccbf6dee5 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -279,6 +279,10 @@ EXPERIMENTAL {
> rte_flow_async_action_handle_create;
> rte_flow_async_action_handle_destroy;
> rte_flow_async_action_handle_update;
> +
> + # added in 22.07
Symbols are not in alphabetical order.
> + rte_mtr_meter_vlan_table_update;
> + rte_mtr_color_in_protocol_priority_set;
> };
>
> INTERNAL {
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* DPDK 21.11.1 released
@ 2022-04-26 13:58 1% Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2022-04-26 13:58 UTC (permalink / raw)
To: announce
Hi all,
Here is a new stable release:
https://fast.dpdk.org/rel/dpdk-21.11.1.tar.xz
The git tree is at:
https://dpdk.org/browse/dpdk-stable/?h=21.11
This is the first stable release of 21.11 LTS and contains
~400 fixes.
See the release notes for details:
http://doc.dpdk.org/guides-21.11/rel_notes/release_21_11.html#fixes
Thanks to the authors who helped with backports and to the
following who helped with validation:
Nvidia, Intel, Canonical and Red Hat.
Kevin
---
MAINTAINERS | 2 +
VERSION | 2 +-
app/dumpcap/main.c | 9 +-
app/pdump/main.c | 16 +-
app/proc-info/main.c | 6 +-
app/test-acl/main.c | 6 +-
app/test-compress-perf/comp_perf_test_cyclecount.c | 9 +-
app/test-compress-perf/comp_perf_test_throughput.c | 2 +-
app/test-compress-perf/comp_perf_test_verify.c | 2 +-
app/test-compress-perf/main.c | 5 +-
app/test-crypto-perf/cperf_test_pmd_cyclecount.c | 2 +-
app/test-eventdev/evt_options.c | 2 +-
app/test-eventdev/test_order_common.c | 2 +-
app/test-fib/main.c | 12 +-
app/test-flow-perf/config.h | 2 +-
app/test-flow-perf/main.c | 2 +-
app/test-pmd/cmd_flex_item.c | 3 +-
app/test-pmd/cmdline.c | 18 +-
app/test-pmd/cmdline_flow.c | 13 +-
app/test-pmd/cmdline_tm.c | 4 +-
app/test-pmd/config.c | 22 +-
app/test-pmd/csumonly.c | 24 +-
app/test-pmd/parameters.c | 2 +-
app/test-pmd/testpmd.c | 28 +-
app/test-pmd/testpmd.h | 1 +
app/test-pmd/txonly.c | 24 +-
app/test-regex/main.c | 38 +-
app/test/meson.build | 2 +-
app/test/test_barrier.c | 2 +-
app/test/test_bpf.c | 10 +-
app/test/test_compressdev.c | 2 +-
app/test/test_cryptodev.c | 13 +-
app/test/test_cryptodev_asym.c | 2 +-
app/test/test_cryptodev_rsa_test_vectors.h | 2 +-
app/test/test_dmadev.c | 8 +-
app/test/test_efd.c | 2 +-
app/test/test_fib_perf.c | 2 +-
app/test/test_kni.c | 4 +-
app/test/test_kvargs.c | 16 +-
app/test/test_link_bonding.c | 4 +
app/test/test_link_bonding_rssconf.c | 4 +
app/test/test_lpm6_data.h | 2 +-
app/test/test_mbuf.c | 4 -
app/test/test_member.c | 2 +-
app/test/test_memory.c | 2 +-
app/test/test_mempool.c | 4 +-
app/test/test_memzone.c | 6 +-
app/test/test_metrics.c | 2 +-
app/test/test_pcapng.c | 2 +-
app/test/test_power_cpufreq.c | 2 +-
app/test/test_rcu_qsbr.c | 4 +-
app/test/test_red.c | 8 +-
app/test/test_security.c | 2 +-
app/test/test_table_pipeline.c | 2 +-
app/test/test_thash.c | 2 +-
buildtools/binutils-avx512-check.py | 4 +-
buildtools/call-sphinx-build.py | 4 +-
buildtools/meson.build | 5 +-
config/arm/meson.build | 10 +-
config/meson.build | 5 +-
config/x86/meson.build | 2 +-
devtools/check-abi.sh | 4 -
devtools/check-forbidden-tokens.awk | 3 +
devtools/check-symbol-change.sh | 6 +-
devtools/check-symbol-maps.sh | 7 +
devtools/libabigail.abignore | 20 +
doc/api/generate_examples.sh | 14 +-
doc/api/meson.build | 10 +-
doc/guides/compressdevs/mlx5.rst | 6 +-
doc/guides/conf.py | 6 +-
doc/guides/cryptodevs/mlx5.rst | 6 +-
doc/guides/dmadevs/hisilicon.rst | 4 +-
doc/guides/dmadevs/idxd.rst | 29 +-
doc/guides/eventdevs/dlb2.rst | 19 +-
doc/guides/gpus/features/cuda.ini | 10 +
.../img/virtio_user_for_container_networking.svg | 2 +-
doc/guides/linux_gsg/enable_func.rst | 8 +-
doc/guides/linux_gsg/linux_drivers.rst | 11 +-
doc/guides/linux_gsg/sys_reqs.rst | 6 +-
doc/guides/nics/af_packet.rst | 2 +-
doc/guides/nics/features/ice_dcf.ini | 5 +
doc/guides/nics/hns3.rst | 5 +
doc/guides/nics/ice.rst | 4 +
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 6 +-
doc/guides/nics/mlx5.rst | 33 +-
doc/guides/prog_guide/cryptodev_lib.rst | 3 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 4 +-
...{flow_tru_droppper.png => flow_tru_dropper.png} | Bin
doc/guides/prog_guide/img/turbo_tb_decode.svg | 2 +-
doc/guides/prog_guide/img/turbo_tb_encode.svg | 2 +-
doc/guides/prog_guide/qos_framework.rst | 6 +-
doc/guides/prog_guide/rte_flow.rst | 8 +-
doc/guides/rawdevs/cnxk_bphy.rst | 2 +-
doc/guides/regexdevs/features_overview.rst | 2 +-
doc/guides/regexdevs/mlx5.rst | 8 +-
doc/guides/rel_notes/release_16_07.rst | 2 +-
doc/guides/rel_notes/release_17_08.rst | 2 +-
doc/guides/rel_notes/release_21_11.rst | 518 +++++++++++++++++++++
doc/guides/rel_notes/release_2_1.rst | 2 +-
doc/guides/sample_app_ug/fips_validation.rst | 3 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 4 +-
doc/guides/sample_app_ug/l2_forward_cat.rst | 2 +-
doc/guides/sample_app_ug/server_node_efd.rst | 2 +-
doc/guides/sample_app_ug/skeleton.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
drivers/baseband/acc100/rte_acc100_pmd.c | 3 +-
drivers/baseband/acc100/rte_acc100_pmd.h | 1 +
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 8 +-
drivers/baseband/null/bbdev_null.c | 2 +-
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 2 +-
drivers/bus/auxiliary/version.map | 2 +
drivers/bus/dpaa/dpaa_bus.c | 2 +-
drivers/bus/dpaa/include/fsl_qman.h | 6 +-
drivers/bus/dpaa/include/fsl_usd.h | 2 +-
drivers/bus/dpaa/include/process.h | 2 +-
drivers/bus/fslmc/fslmc_bus.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 2 +-
drivers/bus/fslmc/qbman/include/fsl_qbman_portal.h | 20 +-
drivers/bus/ifpga/ifpga_bus.c | 6 +-
drivers/bus/pci/linux/pci_vfio.c | 2 +-
drivers/bus/pci/pci_common.c | 5 +-
drivers/bus/vdev/rte_bus_vdev.h | 2 +-
drivers/bus/vmbus/vmbus_common.c | 2 +-
drivers/common/cnxk/cnxk_security.c | 4 -
drivers/common/cnxk/cnxk_telemetry_nix.c | 3 +
drivers/common/cnxk/hw/cpt.h | 14 +-
drivers/common/cnxk/roc_bphy_cgx.c | 2 +-
drivers/common/cnxk/roc_bphy_irq.c | 2 +-
drivers/common/cnxk/roc_cpt.c | 10 +-
drivers/common/cnxk/roc_dev.c | 21 +-
drivers/common/cnxk/roc_irq.c | 5 +-
drivers/common/cnxk/roc_nix.h | 1 +
drivers/common/cnxk/roc_nix_bpf.c | 2 +-
drivers/common/cnxk/roc_nix_debug.c | 10 +-
drivers/common/cnxk/roc_nix_fc.c | 12 +
drivers/common/cnxk/roc_nix_inl.c | 5 +-
drivers/common/cnxk/roc_nix_inl_dev.c | 12 +
drivers/common/cnxk/roc_nix_inl_priv.h | 1 +
drivers/common/cnxk/roc_nix_irq.c | 5 +-
drivers/common/cnxk/roc_nix_npc.c | 2 +-
drivers/common/cnxk/roc_nix_priv.h | 1 +
drivers/common/cnxk/roc_nix_ptp.c | 8 +
drivers/common/cnxk/roc_nix_queue.c | 93 +++-
drivers/common/cnxk/roc_nix_stats.c | 18 +
drivers/common/cnxk/roc_nix_tm.c | 8 +-
drivers/common/cnxk/roc_nix_tm_ops.c | 2 +-
drivers/common/cnxk/roc_nix_tm_utils.c | 3 +-
drivers/common/cnxk/roc_npc.c | 14 +-
drivers/common/cnxk/roc_npc_mcam.c | 4 +-
drivers/common/cnxk/roc_npc_mcam_dump.c | 40 +-
drivers/common/cnxk/roc_npc_parse.c | 13 +-
drivers/common/cnxk/roc_npc_priv.h | 2 +-
drivers/common/cnxk/roc_npc_utils.c | 7 +-
drivers/common/cnxk/version.map | 1 +
drivers/common/cpt/cpt_ucode.h | 4 +-
drivers/common/cpt/cpt_ucode_asym.h | 2 +-
drivers/common/dpaax/caamflib/desc/algo.h | 2 +-
drivers/common/dpaax/caamflib/desc/sdap.h | 6 +-
drivers/common/dpaax/dpaax_iova_table.c | 2 +-
drivers/common/iavf/iavf_type.h | 2 +-
drivers/common/iavf/virtchnl.h | 2 +-
drivers/common/iavf/virtchnl_inline_ipsec.h | 9 +
drivers/common/mlx5/linux/meson.build | 2 +-
drivers/common/mlx5/linux/mlx5_common_os.c | 2 +-
drivers/common/mlx5/linux/mlx5_common_os.h | 2 +
drivers/common/mlx5/linux/mlx5_nl.c | 102 +++-
drivers/common/mlx5/linux/mlx5_nl.h | 8 +-
drivers/common/mlx5/mlx5_common.c | 22 +-
drivers/common/mlx5/mlx5_common_mr.c | 11 +-
drivers/common/mlx5/mlx5_devx_cmds.c | 32 +-
drivers/common/mlx5/mlx5_devx_cmds.h | 3 +
drivers/common/mlx5/mlx5_malloc.c | 4 +-
drivers/common/mlx5/mlx5_malloc.h | 2 +-
drivers/common/mlx5/mlx5_prm.h | 30 +-
drivers/common/mlx5/version.map | 5 +
drivers/common/mlx5/windows/meson.build | 4 +-
drivers/common/mlx5/windows/mlx5_common_os.c | 4 +-
drivers/common/mlx5/windows/mlx5_common_os.h | 2 +-
.../qat/qat_adf/adf_transport_access_macros.h | 2 +-
drivers/common/sfc_efx/base/efx_mae.c | 11 +-
drivers/common/sfc_efx/efsys.h | 2 +-
drivers/compress/mlx5/mlx5_compress.c | 13 +-
drivers/compress/octeontx/include/zip_regs.h | 4 +-
drivers/compress/octeontx/otx_zip.h | 2 +-
drivers/compress/octeontx/otx_zip_pmd.c | 6 +-
drivers/compress/qat/qat_comp_pmd.c | 2 +-
drivers/crypto/bcmfs/bcmfs_device.h | 2 +-
drivers/crypto/bcmfs/bcmfs_qp.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_defs.h | 6 +-
drivers/crypto/bcmfs/bcmfs_sym_engine.h | 2 +-
drivers/crypto/bcmfs/hw/bcmfs5_rm.c | 2 +-
drivers/crypto/caam_jr/caam_jr_hw_specific.h | 4 +-
drivers/crypto/caam_jr/caam_jr_pvt.h | 4 +-
drivers/crypto/caam_jr/caam_jr_uio.c | 2 +-
drivers/crypto/ccp/ccp_crypto.c | 2 +-
drivers/crypto/ccp/ccp_crypto.h | 2 +-
drivers/crypto/ccp/ccp_dev.h | 2 +-
drivers/crypto/cnxk/cn9k_ipsec_la_ops.h | 6 +-
drivers/crypto/cnxk/cnxk_cryptodev_ops.c | 21 +-
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 6 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 6 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 8 +-
drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 10 +-
drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 +-
drivers/crypto/ipsec_mb/pmd_aesni_gcm.c | 16 +-
drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 134 ++++--
drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h | 4 +-
drivers/crypto/ipsec_mb/pmd_zuc.c | 22 +-
drivers/crypto/ipsec_mb/pmd_zuc_priv.h | 2 +-
drivers/crypto/octeontx/otx_cryptodev_hw_access.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev_mbox.h | 2 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 2 +-
drivers/crypto/qat/qat_asym.c | 6 +-
drivers/crypto/qat/qat_sym.c | 2 +-
drivers/crypto/qat/qat_sym_hw_dp.c | 16 +-
drivers/crypto/virtio/virtio_rxtx.c | 3 +
drivers/crypto/virtio/virtqueue.h | 2 +-
drivers/dma/cnxk/meson.build | 1 -
drivers/dma/hisilicon/hisi_dmadev.c | 23 +-
drivers/dma/idxd/dpdk_idxd_cfg.py | 19 +-
drivers/dma/idxd/idxd_common.c | 10 +-
drivers/dma/skeleton/skeleton_dmadev.c | 2 +-
drivers/event/cnxk/cn10k_eventdev.c | 4 +-
drivers/event/cnxk/cn10k_worker.h | 2 -
drivers/event/cnxk/cn9k_eventdev.c | 11 +-
drivers/event/cnxk/cn9k_worker.h | 2 -
drivers/event/cnxk/cnxk_eventdev.c | 2 +-
drivers/event/cnxk/cnxk_eventdev.h | 8 +-
drivers/event/cnxk/cnxk_eventdev_adptr.c | 2 +-
drivers/event/cnxk/cnxk_eventdev_selftest.c | 4 +-
drivers/event/cnxk/cnxk_tim_worker.c | 2 +-
drivers/event/cnxk/cnxk_tim_worker.h | 4 +-
drivers/event/dlb2/dlb2.c | 32 +-
drivers/event/dlb2/dlb2_priv.h | 2 +-
drivers/event/dlb2/dlb2_selftest.c | 2 +-
drivers/event/dlb2/pf/base/dlb2_resource.c | 23 +-
drivers/event/dlb2/rte_pmd_dlb2.h | 2 +-
drivers/event/dpaa2/dpaa2_eventdev_selftest.c | 2 +-
drivers/event/dsw/dsw_evdev.h | 4 +-
drivers/event/dsw/dsw_event.c | 4 +-
drivers/event/octeontx/ssovf_evdev.h | 2 +-
drivers/event/octeontx/ssovf_evdev_selftest.c | 2 +-
drivers/event/octeontx2/otx2_evdev_selftest.c | 2 +-
drivers/event/octeontx2/otx2_worker_dual.h | 2 +-
drivers/event/opdl/opdl_evdev.c | 2 +-
drivers/event/opdl/opdl_test.c | 2 +-
drivers/event/sw/sw_evdev.h | 2 +-
drivers/event/sw/sw_evdev_selftest.c | 2 +-
drivers/gpu/cuda/cuda.c | 8 +-
drivers/mempool/cnxk/cn10k_mempool_ops.c | 2 +-
drivers/mempool/dpaa/dpaa_mempool.c | 2 +-
drivers/mempool/octeontx/octeontx_fpavf.c | 4 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 167 +++----
drivers/net/ark/ark_global.h | 2 +-
drivers/net/atlantic/atl_ethdev.c | 2 +-
drivers/net/atlantic/atl_rxtx.c | 2 +-
drivers/net/atlantic/hw_atl/hw_atl_b0.c | 2 +-
drivers/net/axgbe/axgbe_dev.c | 2 +-
drivers/net/axgbe/axgbe_ethdev.c | 41 +-
drivers/net/axgbe/axgbe_ethdev.h | 2 +-
drivers/net/axgbe/axgbe_phy_impl.c | 4 +-
drivers/net/axgbe/axgbe_rxtx_vec_sse.c | 2 +-
drivers/net/bnx2x/bnx2x.c | 38 +-
drivers/net/bnx2x/bnx2x.h | 10 +-
drivers/net/bnx2x/bnx2x_stats.c | 2 +-
drivers/net/bnx2x/bnx2x_stats.h | 4 +-
drivers/net/bnx2x/bnx2x_vfpf.c | 2 +-
drivers/net/bnx2x/bnx2x_vfpf.h | 2 +-
drivers/net/bnx2x/ecore_fw_defs.h | 2 +-
drivers/net/bnx2x/ecore_hsi.h | 26 +-
drivers/net/bnx2x/ecore_init_ops.h | 6 +-
drivers/net/bnx2x/ecore_reg.h | 28 +-
drivers/net/bnx2x/ecore_sp.c | 6 +-
drivers/net/bnx2x/ecore_sp.h | 6 +-
drivers/net/bnx2x/elink.c | 20 +-
drivers/net/bnxt/bnxt.h | 18 +-
drivers/net/bnxt/bnxt_cpr.c | 25 +-
drivers/net/bnxt/bnxt_ethdev.c | 133 ++++--
drivers/net/bnxt/bnxt_flow.c | 14 +-
drivers/net/bnxt/bnxt_hwrm.c | 123 +++--
drivers/net/bnxt/bnxt_hwrm.h | 7 +-
drivers/net/bnxt/bnxt_reps.c | 33 +-
drivers/net/bnxt/bnxt_ring.c | 3 +
drivers/net/bnxt/bnxt_rxq.c | 9 +-
drivers/net/bnxt/bnxt_rxr.c | 6 +
drivers/net/bnxt/bnxt_stats.c | 105 +++--
drivers/net/bnxt/bnxt_txr.c | 3 +
drivers/net/bnxt/bnxt_vnic.c | 84 ++--
drivers/net/bnxt/bnxt_vnic.h | 7 +-
drivers/net/bnxt/tf_core/tf_session.c | 8 +-
drivers/net/bnxt/tf_core/tfp.c | 2 +-
drivers/net/bnxt/tf_core/tfp.h | 2 +-
drivers/net/bonding/eth_bond_8023ad_private.h | 2 +-
drivers/net/bonding/eth_bond_private.h | 8 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 20 +-
drivers/net/bonding/rte_eth_bond_8023ad.h | 4 +-
drivers/net/bonding/rte_eth_bond_alb.h | 2 +-
drivers/net/bonding/rte_eth_bond_api.c | 12 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 163 ++++++-
drivers/net/cnxk/cn10k_ethdev.c | 6 +
drivers/net/cnxk/cn10k_ethdev.h | 5 +-
drivers/net/cnxk/cn10k_ethdev_sec.c | 42 +-
drivers/net/cnxk/cn10k_rx.c | 4 +
drivers/net/cnxk/cn10k_rx.h | 9 +-
drivers/net/cnxk/cn10k_tx.c | 4 +
drivers/net/cnxk/cn10k_tx.h | 6 +-
drivers/net/cnxk/cn9k_rx.c | 4 +
drivers/net/cnxk/cn9k_rx.h | 14 +-
drivers/net/cnxk/cn9k_tx.c | 4 +
drivers/net/cnxk/cn9k_tx.h | 6 +-
drivers/net/cnxk/cnxk_ethdev.c | 15 +-
drivers/net/cnxk/cnxk_ethdev.h | 9 +-
drivers/net/cnxk/cnxk_ethdev_mtr.c | 59 ++-
drivers/net/cnxk/cnxk_ethdev_ops.c | 5 +-
drivers/net/cnxk/cnxk_ptp.c | 2 +-
drivers/net/cxgbe/base/adapter.h | 2 -
drivers/net/cxgbe/base/t4_hw.c | 83 ++--
drivers/net/cxgbe/base/t4vf_hw.c | 28 +-
drivers/net/cxgbe/cxgbe_flow.c | 2 +-
drivers/net/cxgbe/cxgbevf_main.c | 2 +-
drivers/net/cxgbe/sge.c | 8 +-
drivers/net/dpaa/dpaa_ethdev.c | 6 +-
drivers/net/dpaa/dpaa_rxtx.c | 4 +-
drivers/net/dpaa/fmlib/fm_ext.h | 2 +-
drivers/net/dpaa/fmlib/fm_pcd_ext.h | 8 +-
drivers/net/dpaa/fmlib/fm_port_ext.h | 14 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 23 +-
drivers/net/dpaa2/dpaa2_ethdev.h | 4 +-
drivers/net/dpaa2/dpaa2_flow.c | 8 +-
drivers/net/dpaa2/dpaa2_mux.c | 2 +-
drivers/net/dpaa2/dpaa2_ptp.c | 8 +-
drivers/net/dpaa2/dpaa2_rxtx.c | 45 +-
drivers/net/dpaa2/mc/fsl_dpni.h | 10 +-
drivers/net/e1000/e1000_ethdev.h | 4 +-
drivers/net/e1000/em_ethdev.c | 10 +-
drivers/net/e1000/em_rxtx.c | 6 +-
drivers/net/e1000/igb_ethdev.c | 18 +-
drivers/net/e1000/igb_flow.c | 4 +-
drivers/net/e1000/igb_pf.c | 2 +-
drivers/net/e1000/igb_rxtx.c | 14 +-
drivers/net/ena/ena_ethdev.c | 71 +--
drivers/net/ena/ena_ethdev.h | 7 +-
drivers/net/enetfec/enet_regs.h | 2 +-
drivers/net/enic/enic_flow.c | 18 +-
drivers/net/enic/enic_fm_flow.c | 12 +-
drivers/net/enic/enic_main.c | 2 +-
drivers/net/enic/enic_rxtx.c | 2 +-
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 12 +-
drivers/net/fm10k/fm10k_rxtx_vec.c | 10 +-
drivers/net/hinic/hinic_pmd_ethdev.c | 4 +-
drivers/net/hinic/hinic_pmd_ethdev.h | 2 +-
drivers/net/hinic/hinic_pmd_flow.c | 4 +-
drivers/net/hinic/hinic_pmd_tx.c | 2 +-
drivers/net/hns3/hns3_cmd.c | 4 +-
drivers/net/hns3/hns3_cmd.h | 1 -
drivers/net/hns3/hns3_common.c | 10 +-
drivers/net/hns3/hns3_dcb.c | 10 +-
drivers/net/hns3/hns3_ethdev.c | 53 ++-
drivers/net/hns3/hns3_ethdev.h | 9 +-
drivers/net/hns3/hns3_ethdev_vf.c | 14 +-
drivers/net/hns3/hns3_fdir.h | 2 +-
drivers/net/hns3/hns3_flow.c | 27 +-
drivers/net/hns3/hns3_mbx.c | 4 +-
drivers/net/hns3/hns3_mbx.h | 2 +-
drivers/net/hns3/hns3_mp.c | 7 +-
drivers/net/hns3/hns3_ptp.c | 1 +
drivers/net/hns3/hns3_rss.c | 62 ++-
drivers/net/hns3/hns3_rss.h | 2 +-
drivers/net/hns3/hns3_rxtx.c | 73 ++-
drivers/net/hns3/hns3_rxtx.h | 2 +-
drivers/net/hns3/hns3_rxtx_vec.c | 20 +-
drivers/net/hns3/hns3_stats.c | 124 +++--
drivers/net/hns3/hns3_stats.h | 11 +-
drivers/net/i40e/i40e_ethdev.c | 53 ++-
drivers/net/i40e/i40e_ethdev.h | 10 +-
drivers/net/i40e/i40e_fdir.c | 10 +-
drivers/net/i40e/i40e_flow.c | 2 +-
drivers/net/i40e/i40e_pf.c | 8 +-
drivers/net/i40e/i40e_rxtx.c | 20 +-
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 2 +-
drivers/net/i40e/i40e_rxtx_vec_neon.c | 4 +-
drivers/net/i40e/i40e_rxtx_vec_sse.c | 6 +-
drivers/net/i40e/rte_pmd_i40e.c | 2 +-
drivers/net/iavf/iavf_ethdev.c | 6 +-
drivers/net/iavf/iavf_ipsec_crypto.c | 38 +-
drivers/net/iavf/iavf_ipsec_crypto.h | 6 +-
drivers/net/iavf/iavf_rxtx.c | 104 +++--
drivers/net/iavf/iavf_rxtx.h | 2 -
drivers/net/iavf/iavf_rxtx_vec_sse.c | 4 +-
drivers/net/iavf/iavf_vchnl.c | 6 +-
drivers/net/ice/base/ice_flex_pipe.c | 11 +-
drivers/net/ice/base/ice_flex_type.h | 1 +
drivers/net/ice/base/ice_protocol_type.h | 1 +
drivers/net/ice/base/ice_switch.c | 1 +
drivers/net/ice/ice_dcf.c | 2 +-
drivers/net/ice/ice_dcf_ethdev.c | 15 +-
drivers/net/ice/ice_dcf_ethdev.h | 1 +
drivers/net/ice/ice_dcf_parent.c | 18 +-
drivers/net/ice/ice_ethdev.c | 14 +-
drivers/net/ice/ice_ethdev.h | 2 +
drivers/net/ice/ice_fdir_filter.c | 32 ++
drivers/net/ice/ice_generic_flow.c | 4 +-
drivers/net/ice/ice_rxtx.c | 27 +-
drivers/net/ice/ice_rxtx_vec_common.h | 5 +-
drivers/net/ice/ice_rxtx_vec_sse.c | 4 +-
drivers/net/ice/ice_switch_filter.c | 45 +-
drivers/net/igc/igc_filter.c | 2 +-
drivers/net/igc/igc_txrx.c | 4 +-
drivers/net/ionic/ionic_if.h | 6 +-
drivers/net/ipn3ke/ipn3ke_ethdev.c | 2 +-
drivers/net/ipn3ke/ipn3ke_ethdev.h | 4 +-
drivers/net/ipn3ke/ipn3ke_flow.c | 2 +-
drivers/net/ipn3ke/ipn3ke_representor.c | 12 +-
drivers/net/ipn3ke/meson.build | 2 +-
drivers/net/ixgbe/ixgbe_bypass.c | 2 +-
drivers/net/ixgbe/ixgbe_bypass_api.h | 4 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 65 ++-
drivers/net/ixgbe/ixgbe_ethdev.h | 2 +-
drivers/net/ixgbe/ixgbe_fdir.c | 2 +-
drivers/net/ixgbe/ixgbe_flow.c | 4 +-
drivers/net/ixgbe/ixgbe_ipsec.c | 2 +-
drivers/net/ixgbe/ixgbe_pf.c | 2 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 10 +-
drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 13 +-
drivers/net/kni/rte_eth_kni.c | 2 +-
drivers/net/memif/memif_socket.c | 5 +-
drivers/net/memif/rte_eth_memif.c | 21 +-
drivers/net/mlx4/meson.build | 2 +-
drivers/net/mlx4/mlx4.h | 2 +-
drivers/net/mlx4/mlx4_ethdev.c | 2 +-
drivers/net/mlx5/linux/mlx5_ethdev_os.c | 63 ++-
drivers/net/mlx5/linux/mlx5_flow_os.c | 3 +-
drivers/net/mlx5/linux/mlx5_os.c | 203 ++++----
drivers/net/mlx5/linux/mlx5_verbs.c | 4 +-
drivers/net/mlx5/linux/mlx5_vlan_os.c | 2 +-
drivers/net/mlx5/mlx5.c | 43 +-
drivers/net/mlx5/mlx5.h | 27 +-
drivers/net/mlx5/mlx5_defs.h | 6 +-
drivers/net/mlx5/mlx5_devx.c | 6 +-
drivers/net/mlx5/mlx5_ethdev.c | 2 +-
drivers/net/mlx5/mlx5_flow.c | 403 ++++++++++------
drivers/net/mlx5/mlx5_flow.h | 24 +-
drivers/net/mlx5/mlx5_flow_aso.c | 117 ++---
drivers/net/mlx5/mlx5_flow_dv.c | 234 ++++++----
drivers/net/mlx5/mlx5_flow_flex.c | 14 +-
drivers/net/mlx5/mlx5_flow_meter.c | 39 +-
drivers/net/mlx5/mlx5_flow_verbs.c | 89 +++-
drivers/net/mlx5/mlx5_rx.c | 24 +-
drivers/net/mlx5/mlx5_rx.h | 15 +-
drivers/net/mlx5/mlx5_rxq.c | 269 +++++++----
drivers/net/mlx5/mlx5_rxtx_vec.c | 8 +-
drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 2 +-
drivers/net/mlx5/mlx5_trigger.c | 12 +-
drivers/net/mlx5/mlx5_tx.c | 2 +-
drivers/net/mlx5/mlx5_tx.h | 1 -
drivers/net/mlx5/mlx5_utils.c | 43 +-
drivers/net/mlx5/mlx5_utils.h | 30 +-
drivers/net/mlx5/windows/mlx5_flow_os.c | 4 +-
drivers/net/mlx5/windows/mlx5_os.c | 54 ++-
drivers/net/mvneta/mvneta_ethdev.c | 2 +-
drivers/net/mvpp2/mrvl_ethdev.c | 2 +-
drivers/net/mvpp2/mrvl_qos.c | 4 +-
drivers/net/netvsc/hn_nvs.c | 2 +-
drivers/net/netvsc/hn_rxtx.c | 4 +-
drivers/net/netvsc/hn_vf.c | 2 +-
drivers/net/nfb/nfb.h | 4 -
drivers/net/nfb/nfb_ethdev.c | 15 +-
drivers/net/nfb/nfb_rxmode.c | 20 +-
drivers/net/nfp/nfp_common.c | 4 -
drivers/net/nfp/nfp_ethdev.c | 2 +
drivers/net/nfp/nfp_ethdev_vf.c | 2 +
drivers/net/nfp/nfp_rxtx.c | 2 +
drivers/net/nfp/nfpcore/nfp-common/nfp_resid.h | 6 +-
drivers/net/nfp/nfpcore/nfp_cppcore.c | 2 +-
drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +-
drivers/net/nfp/nfpcore/nfp_resource.c | 2 +-
drivers/net/nfp/nfpcore/nfp_rtsym.c | 2 +-
drivers/net/nfp/nfpcore/nfp_target.h | 26 +-
drivers/net/ngbe/base/ngbe_dummy.h | 4 +
drivers/net/ngbe/base/ngbe_eeprom.c | 22 +-
drivers/net/ngbe/base/ngbe_hw.c | 247 +++++-----
drivers/net/ngbe/base/ngbe_hw.h | 3 +
drivers/net/ngbe/base/ngbe_mbx.c | 22 -
drivers/net/ngbe/base/ngbe_mng.c | 71 ++-
drivers/net/ngbe/base/ngbe_mng.h | 21 +
drivers/net/ngbe/base/ngbe_phy.c | 30 +-
drivers/net/ngbe/base/ngbe_phy_mvl.c | 13 +-
drivers/net/ngbe/base/ngbe_phy_rtl.c | 10 +-
drivers/net/ngbe/base/ngbe_phy_yt.c | 16 +-
drivers/net/ngbe/base/ngbe_regs.h | 51 +-
drivers/net/ngbe/base/ngbe_type.h | 10 +
drivers/net/ngbe/ngbe_ethdev.c | 133 ++----
drivers/net/ngbe/ngbe_ethdev.h | 1 +
drivers/net/ngbe/ngbe_logs.h | 7 +-
drivers/net/ngbe/ngbe_pf.c | 2 +-
drivers/net/octeontx/octeontx_ethdev.c | 2 +-
drivers/net/octeontx2/otx2_ethdev_irq.c | 2 +-
drivers/net/octeontx2/otx2_ptp.c | 2 +-
drivers/net/octeontx2/otx2_tx.h | 4 +-
drivers/net/octeontx2/otx2_vlan.c | 2 +-
drivers/net/octeontx_ep/otx2_ep_vf.c | 2 +-
drivers/net/octeontx_ep/otx_ep_vf.c | 2 +-
drivers/net/pfe/pfe_ethdev.c | 2 +-
drivers/net/pfe/pfe_hal.c | 2 +-
drivers/net/pfe/pfe_hif.c | 4 +-
drivers/net/pfe/pfe_hif.h | 2 +-
drivers/net/pfe/pfe_hif_lib.c | 8 +-
drivers/net/qede/qede_debug.c | 6 +-
drivers/net/qede/qede_ethdev.c | 2 +-
drivers/net/qede/qede_rxtx.c | 161 +++----
drivers/net/qede/qede_rxtx.h | 2 +-
drivers/net/sfc/sfc.c | 2 +-
drivers/net/sfc/sfc_dp.c | 2 +-
drivers/net/sfc/sfc_dp_rx.h | 4 +-
drivers/net/sfc/sfc_ef100.h | 2 +-
drivers/net/sfc/sfc_ef100_rx.c | 2 +-
drivers/net/sfc/sfc_ef10_essb_rx.c | 2 +-
drivers/net/sfc/sfc_ef10_rx_ev.h | 2 +-
drivers/net/sfc/sfc_ethdev.c | 6 -
drivers/net/sfc/sfc_flow.c | 8 +-
drivers/net/sfc/sfc_flow_tunnel.c | 4 +-
drivers/net/sfc/sfc_intr.c | 2 +-
drivers/net/sfc/sfc_repr_proxy.c | 5 +
drivers/net/sfc/sfc_rx.c | 6 +-
drivers/net/sfc/sfc_sw_stats.c | 2 +-
drivers/net/sfc/sfc_tx.c | 10 +-
drivers/net/softnic/rte_eth_softnic_flow.c | 2 +-
drivers/net/tap/rte_eth_tap.c | 82 +++-
drivers/net/tap/tap_bpf_api.c | 4 +-
drivers/net/tap/tap_flow.c | 4 +-
drivers/net/thunderx/nicvf_svf.c | 2 +-
drivers/net/txgbe/base/meson.build | 2 +-
drivers/net/txgbe/base/txgbe_eeprom.c | 41 +-
drivers/net/txgbe/base/txgbe_hw.c | 202 ++------
drivers/net/txgbe/base/txgbe_mbx.c | 38 --
drivers/net/txgbe/base/txgbe_mng.c | 15 +-
drivers/net/txgbe/base/txgbe_osdep.h | 1 +
drivers/net/txgbe/base/txgbe_phy.c | 88 +---
drivers/net/txgbe/base/txgbe_vf.c | 12 +-
drivers/net/txgbe/txgbe_ethdev.c | 11 +-
drivers/net/txgbe/txgbe_ethdev_vf.c | 6 +-
drivers/net/txgbe/txgbe_ipsec.c | 2 +-
drivers/net/txgbe/txgbe_logs.h | 7 +-
drivers/net/txgbe/txgbe_pf.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 7 +-
drivers/net/virtio/virtio_pci.c | 2 +-
drivers/net/virtio/virtio_rxtx.c | 6 +-
drivers/net/virtio/virtio_rxtx_packed.h | 3 +-
drivers/net/virtio/virtio_rxtx_packed_avx.h | 2 +-
drivers/net/virtio/virtio_user/vhost_user.c | 6 +-
drivers/net/virtio/virtio_user_ethdev.c | 1 +
drivers/net/virtio/virtqueue.c | 2 +-
drivers/net/virtio/virtqueue.h | 4 +-
drivers/raw/dpaa2_qdma/dpaa2_qdma.c | 2 +-
drivers/raw/dpaa2_qdma/dpaa2_qdma.h | 4 +-
drivers/raw/ifpga/base/ifpga_defines.h | 6 +-
drivers/raw/ifpga/base/opae_spi.c | 12 +
drivers/raw/ifpga/base/opae_spi.h | 4 +
drivers/raw/ifpga/base/opae_spi_transaction.c | 215 +++++----
drivers/raw/ifpga/ifpga_rawdev.c | 173 ++++---
drivers/raw/ifpga/ifpga_rawdev.h | 9 +-
drivers/raw/ntb/ntb.c | 4 +
drivers/raw/ntb/ntb.h | 2 +-
drivers/regex/mlx5/mlx5_rxp.c | 2 +-
drivers/vdpa/ifc/base/ifcvf.c | 14 +-
drivers/vdpa/mlx5/mlx5_vdpa.c | 4 +-
drivers/vdpa/mlx5/mlx5_vdpa_mem.c | 2 +-
drivers/vdpa/mlx5/mlx5_vdpa_virtq.c | 2 +-
drivers/vdpa/sfc/sfc_vdpa.c | 3 +-
drivers/vdpa/sfc/sfc_vdpa_ops.c | 4 +-
examples/bbdev_app/main.c | 2 +-
examples/bond/main.c | 4 +-
examples/distributor/main.c | 2 +-
examples/dma/dmafwd.c | 2 +-
examples/ethtool/lib/rte_ethtool.c | 2 +-
examples/ethtool/lib/rte_ethtool.h | 4 +-
examples/flow_classify/flow_classify.c | 2 +-
examples/ip_reassembly/main.c | 8 +-
examples/ipsec-secgw/event_helper.c | 19 +-
examples/ipsec-secgw/ipsec-secgw.c | 21 +-
examples/ipsec-secgw/ipsec_process.c | 6 +-
examples/ipsec-secgw/ipsec_worker.c | 15 +-
examples/ipsec-secgw/sa.c | 6 +-
examples/ipsec-secgw/sp4.c | 2 +-
examples/ipsec-secgw/sp6.c | 2 +-
examples/ipsec-secgw/test/common_defs.sh | 4 +-
examples/kni/main.c | 4 +-
examples/l2fwd-cat/l2fwd-cat.c | 2 +-
examples/l2fwd-crypto/main.c | 2 +-
examples/l2fwd-event/l2fwd_event_generic.c | 2 +-
examples/l2fwd-event/l2fwd_event_internal_port.c | 2 +-
examples/l2fwd-jobstats/main.c | 2 +-
examples/l3fwd-acl/main.c | 6 +-
examples/l3fwd-power/main.c | 4 +-
examples/l3fwd/l3fwd.h | 4 +
examples/l3fwd/l3fwd_common.h | 8 +-
examples/l3fwd/l3fwd_event.c | 2 -
examples/l3fwd/l3fwd_event_internal_port.c | 2 +
examples/l3fwd/l3fwd_neon.h | 2 +-
examples/l3fwd/l3fwd_sse.h | 2 +-
examples/l3fwd/main.c | 59 ++-
examples/multi_process/hotplug_mp/commands.c | 2 +-
examples/multi_process/simple_mp/main.c | 2 +-
examples/multi_process/symmetric_mp/main.c | 2 +-
examples/ntb/ntb_fwd.c | 2 +-
examples/packet_ordering/main.c | 2 +-
examples/performance-thread/common/lthread.c | 6 +-
examples/performance-thread/common/lthread_diag.c | 2 +-
examples/performance-thread/common/lthread_int.h | 2 +-
examples/performance-thread/common/lthread_tls.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 12 +-
.../performance-thread/pthread_shim/pthread_shim.h | 2 +-
examples/pipeline/examples/registers.spec | 2 +-
examples/qos_sched/args.c | 5 +-
examples/qos_sched/cmdline.c | 2 +-
examples/server_node_efd/node/node.c | 2 +-
examples/skeleton/basicfwd.c | 2 +-
examples/vhost/main.c | 93 ++--
examples/vm_power_manager/channel_monitor.c | 2 +-
examples/vm_power_manager/power_manager.h | 2 +-
examples/vmdq/main.c | 2 +-
kernel/freebsd/meson.build | 4 +-
kernel/linux/kni/kni_fifo.h | 2 +-
kernel/linux/kni/kni_misc.c | 12 +-
kernel/linux/kni/meson.build | 10 +-
kernel/linux/meson.build | 9 +-
lib/acl/acl_bld.c | 2 +-
lib/acl/acl_run_altivec.h | 2 +-
lib/acl/acl_run_avx512.c | 2 +-
lib/acl/acl_run_avx512x16.h | 14 +-
lib/acl/acl_run_avx512x8.h | 12 +-
lib/acl/rte_acl_osdep.h | 8 +
lib/bpf/bpf_convert.c | 4 +-
lib/bpf/bpf_def.h | 8 +
lib/bpf/bpf_impl.h | 6 +-
lib/compressdev/rte_compressdev_internal.h | 13 +-
lib/cryptodev/cryptodev_pmd.h | 8 +
lib/cryptodev/rte_crypto.h | 9 +
lib/cryptodev/rte_crypto_asym.h | 2 +-
lib/distributor/rte_distributor_single.c | 3 +-
lib/dmadev/rte_dmadev.h | 4 +-
lib/dmadev/rte_dmadev_pmd.h | 2 +
lib/eal/arm/include/rte_cycles_32.h | 2 +-
lib/eal/common/eal_common_devargs.c | 1 +
lib/eal/common/eal_common_dynmem.c | 4 +
lib/eal/common/eal_common_proc.c | 20 +-
lib/eal/freebsd/eal_interrupts.c | 4 +-
lib/eal/freebsd/include/rte_os.h | 8 +
lib/eal/include/generic/rte_pflock.h | 2 +-
lib/eal/include/generic/rte_ticketlock.h | 14 +-
lib/eal/include/meson.build | 1 +
lib/eal/include/rte_bitops.h | 8 +
lib/eal/include/rte_branch_prediction.h | 8 +
lib/eal/include/rte_compat.h | 8 +
lib/eal/include/rte_hypervisor.h | 8 +
lib/eal/include/rte_keepalive.h | 8 +
lib/eal/include/rte_malloc.h | 4 +-
lib/eal/include/rte_pci_dev_feature_defs.h | 8 +
lib/eal/include/rte_pci_dev_features.h | 8 +
lib/eal/include/rte_time.h | 8 +
lib/eal/include/rte_trace_point.h | 2 +-
lib/eal/include/rte_trace_point_register.h | 8 +
lib/eal/linux/eal.c | 4 +
lib/eal/linux/eal_dev.c | 5 +-
lib/eal/linux/eal_interrupts.c | 4 +-
lib/eal/linux/eal_memalloc.c | 8 +-
lib/eal/linux/eal_vfio.h | 3 +-
lib/eal/linux/eal_vfio_mp_sync.c | 8 +
lib/eal/linux/include/rte_os.h | 8 +
lib/eal/windows/eal_memalloc.c | 6 +-
lib/eal/windows/eal_windows.h | 2 +-
lib/eal/windows/include/dirent.h | 4 +-
lib/eal/windows/include/fnmatch.h | 4 +-
lib/eal/x86/include/rte_atomic.h | 2 +-
lib/efd/rte_efd.c | 2 +-
lib/ethdev/ethdev_driver.h | 26 ++
lib/ethdev/ethdev_pci.h | 13 +-
lib/ethdev/ethdev_vdev.h | 8 +
lib/ethdev/rte_dev_info.h | 8 +
lib/ethdev/rte_ethdev.c | 28 +-
lib/ethdev/rte_ethdev.h | 4 +-
lib/ethdev/version.map | 1 +
lib/eventdev/eventdev_pmd.h | 4 +
lib/eventdev/eventdev_pmd_pci.h | 8 +
lib/eventdev/eventdev_pmd_vdev.h | 8 +
lib/eventdev/rte_event_eth_rx_adapter.c | 142 ++++--
lib/eventdev/rte_event_eth_tx_adapter.c | 14 +-
lib/eventdev/rte_event_ring.h | 9 +
lib/eventdev/rte_event_timer_adapter.h | 4 +
lib/eventdev/rte_eventdev.h | 14 +-
lib/fib/rte_fib.c | 6 +-
lib/fib/rte_fib.h | 4 +-
lib/fib/rte_fib6.c | 6 +-
lib/fib/rte_fib6.h | 4 +-
lib/gpudev/version.map | 2 +
lib/graph/rte_graph_worker.h | 2 +-
lib/ipsec/ipsec_telemetry.c | 2 +-
lib/ipsec/rte_ipsec_group.h | 4 +-
lib/ipsec/rte_ipsec_sad.h | 2 +-
lib/ipsec/sa.c | 2 +-
lib/kni/rte_kni_common.h | 8 +
lib/mbuf/rte_mbuf_core.h | 2 +-
lib/meson.build | 2 +-
lib/metrics/rte_metrics_telemetry.h | 7 +
lib/net/rte_l2tpv2.h | 36 +-
lib/pcapng/rte_pcapng.c | 4 +-
lib/pipeline/rte_swx_ctl.c | 52 ++-
lib/pipeline/rte_swx_ctl.h | 4 +-
lib/pipeline/rte_swx_pipeline.c | 2 +-
lib/pipeline/rte_swx_pipeline_internal.h | 4 +-
lib/pipeline/rte_swx_pipeline_spec.c | 2 +-
lib/power/power_cppc_cpufreq.c | 2 +-
lib/regexdev/rte_regexdev.h | 10 +-
lib/regexdev/rte_regexdev_driver.h | 3 +
lib/regexdev/version.map | 11 +
lib/ring/rte_ring.c | 4 +-
lib/ring/rte_ring_core.h | 2 +-
lib/sched/rte_pie.c | 22 +-
lib/sched/rte_pie.h | 6 +-
lib/sched/rte_red.h | 4 +-
lib/sched/rte_sched.c | 2 +-
lib/sched/rte_sched.h | 2 +-
lib/stack/meson.build | 1 +
lib/table/rte_swx_table.h | 2 +-
lib/table/rte_swx_table_selector.h | 2 +-
lib/table/rte_table_hash_func.h | 32 +-
lib/telemetry/rte_telemetry.h | 8 +
lib/telemetry/telemetry.c | 2 +-
lib/telemetry/telemetry_json.h | 2 +-
lib/vhost/rte_vdpa.h | 9 +
lib/vhost/rte_vhost.h | 2 +
lib/vhost/rte_vhost_async.h | 8 +
lib/vhost/rte_vhost_crypto.h | 8 +
lib/vhost/vdpa_driver.h | 8 +
lib/vhost/version.map | 2 +-
lib/vhost/vhost.h | 29 +-
lib/vhost/vhost_user.c | 148 +++---
lib/vhost/virtio_net.c | 11 +-
meson.build | 4 +-
745 files changed, 6605 insertions(+), 3994 deletions(-)
Adham Masarwah (2):
net/mlx5: fix destroying empty matchers list
app/testpmd: fix show RSS RETA on Windows
Ajit Khaparde (7):
net/bnxt: fix ring teardown
net/bnxt: fix PAM4 mask setting
net/bnxt: fix crash by validating pointer
net/bnxt: check VF representor pointer before access
net/bnxt: fix VF resource allocation strategy
net/bnxt: set HW coalescing parameters
net/bnxt: fix ring calculation for representors
Alexander Kozyrev (4):
net/mlx5: fix maximum packet headers size for TSO
net/mlx5: fix MPRQ WQE size assertion
net/mlx5: fix committed bucket size
net/mlx5: fix meter capabilities reporting
Ali Alnubani (1):
doc: fix typos and punctuation in flow API guide
Anatoly Burakov (1):
net/qede: fix redundant condition in debug code
Andy Pei (1):
vdpa/ifc: fix log info mismatch
Ankur Dwivedi (1):
common/cnxk: fix NPC key extraction validation
Anoob Joseph (4):
common/cnxk: fix reset of fields
crypto/cnxk: fix inflight count calculation
crypto/cnxk: fix extend tail calculation
crypto/cnxk: fix update of number of descriptors
Arek Kusztal (1):
cryptodev: fix RSA key type name
Asaf Ravid (1):
net/cnxk: fix promiscuous mode in multicast enable flow
Ashwin Sekhar T K (1):
mempool/cnxk: fix batch allocation failure path
Bin Zheng (1):
net/ixgbe: add vector Rx parameter check
Bing Zhao (5):
common/mlx5: fix probing failure code
app/testpmd: fix raw encap of GENEVE option
net/mlx5: fix matcher priority with ICMP or ICMPv6
net/mlx5: remove unused reference counter
net/mlx5: fix configuration without Rx queue
Brian Dooley (13):
eal: add missing C++ guards
telemetry: add missing C++ guards
ethdev: add missing C++ guards
metrics: add missing C++ guards
acl: add missing C++ guards
compressdev: add missing C++ guards
eventdev: add missing C++ guards
kni: add missing C++ guards
vhost: add missing C++ guards
bpf: add missing C++ guards
cryptodev: add missing C++ guards
examples/l2fwd-crypto: fix port mask overflow
crypto/virtio: fix out-of-bounds access
Bruce Richardson (23):
doc: remove dependency on findutils on FreeBSD
dma/idxd: fix burst capacity calculation
dma/idxd: fix paths to driver sysfs directory
dma/idxd: fix wrap-around in burst capacity calculation
build: fix warnings when running external commands
build: remove deprecated Meson functions
eal: fix C++ include
eventdev: fix C++ include
graph: fix C++ include
ipsec: fix C++ include
table: fix C++ include
vhost: fix C++ include
ethdev: fix cast for C++ compatibility
test/dma: fix missing checks for device capacity
dma/idxd: configure maximum batch size to high value
doc: improve configuration examples in idxd guide
distributor: fix potential overflow
eal/freebsd: add missing C++ include guards
compressdev: fix missing space in log macro
cryptodev: fix clang C++ include
eventdev: fix clang C++ include
doc: replace characters for (R) symbol in Linux guide
doc: fix missing note on UIO module in Linux guide
Chandubabu Namburu (1):
net/axgbe: use PCI root complex device to distinguish device
Chenbo Xia (1):
vhost: fix queue number check when setting inflight FD
Chengchang Tang (1):
net/bonding: fix offloading configuration
Chengwen Feng (2):
net/hns3: delete duplicated RSS type
dma/hisilicon: use common PCI device naming
Chuanshe Zhang (1):
examples/flow_classify: fix failure message
Ciara Loftus (2):
net/af_xdp: fix build with -Wunused-function
net/af_xdp: ensure socket is deleted on Rx queue setup error
Ciara Power (4):
crypto/ipsec_mb: fix queue setup null pointer dereference
crypto/ipsec_mb: fix queue cleanup null pointer dereference
crypto/ipsec_mb: fix tainted data for session
crypto/ipsec_mb: remove useless check
Cristian Dumitrescu (2):
pipeline: fix annotation checks
pipeline: fix table state memory allocation
Dapeng Yu (2):
net/ice: track DCF state of PF
net/i40e: enable maximum frame size at port level
Dariusz Sosnowski (3):
net/mlx5: fix inline length for multi-segment TSO
net/mlx5: fix MPLS/GRE Verbs spec ordering
net/mlx5: fix VLAN push action validation
David Marchand (8):
devtools: fix comment detection in forbidden token check
stack: fix stubs header export
test/mbuf: fix mbuf data content check
ethdev: fix MAC address in telemetry device info
net/af_xdp: add missing trailing newline in logs
devtools: remove event/dlb exception in ABI check
vhost: fix FD leak with inflight messages
bpf: fix build with some libpcap version on FreeBSD
Dawid Gorecki (2):
net/ena: fix reset reason being overwritten
net/ena: check memory BAR before initializing LLQ
Devendra Singh Rawat (3):
net/qede: fix Tx completion
net/qede: fix Rx bulk
net/qede: fix maximum Rx packet length
Dmitry Kozlyuk (8):
net/mlx5: fix GCC uninitialized variable warning
net/mlx5: relax headroom assertion
app/testpmd: fix external buffer allocation
common/mlx5: fix MR lookup for non-contiguous mempool
common/mlx5: add Netlink event helpers
net/mlx5: fix link status change detection
net/mlx5: fix initial link status detection
net/mlx5: fix modify port action validation
Elena Agostini (3):
gpu/cuda: fix memory list cleanup
doc: add CUDA driver features
gpu/cuda: fix dependency loading path
Ferruh Yigit (2):
net/bonding: fix MTU set for slaves
ethdev: fix doxygen comments for device info struct
Geoffrey Le Gourriérec (1):
net/bnxt: restore dependency on kernel modules
Gerry Gribbon (1):
app/regex: fix number of matches
Gowrishankar Muthukrishnan (6):
event/cnxk: fix variables casting
event/cnxk: fix uninitialized local variables
common/cnxk: add missing checks of return values
common/cnxk fix unintended sign extension
common/cnxk: fix uninitialized pointer read
net/cnxk: fix uninitialized local variable
Gregory Etelson (11):
net/mlx5: fix RSS expansion with explicit next protocol
net/mlx5: fix GRE protocol type translation for Verbs
net/mlx5: fix GRE item translation in Verbs
net/mlx5: reduce flex item flow handle size
net/mlx5: fix flex item header length translation
net/mlx5: fix inet IPIP protocol type
net/mlx5: fix next protocol RSS expansion
net/mlx5: fix flex item availability
app/testpmd: fix GTP header parsing in checksum engine
app/testpmd: fix flow rule with flex input link
net/mlx5: fix flex item availability
Haiyue Wang (2):
net/iavf: remove git residue symbol
doc: fix KNI PMD name typo
Harman Kalra (3):
common/cnxk: reset stale values on error debug registers
common/cnxk: always use single interrupt ID with NIX
common/cnxk: fix mbuf data offset for VF
Harold Huang (2):
net/virtio-user: fix resource leak on probing failure
net/kni: fix config initialization
Heinrich Kuhn (1):
net/nfp: free HW ring memzone on queue release
Hemant Agrawal (1):
crypto/dpaax_sec: fix auth/cipher xform chain checks
Honnappa Nagarahalli (3):
examples/distributor: reduce Tx queue number to 1
examples/l3fwd: share queue size variables
examples/l3fwd: make Rx and Tx queue size configurable
Huisong Li (10):
net/hns3: fix mailbox wait time
net/hns3: fix using enum as boolean
net/hns3: fix max packet size rollback in PF
net/hns3: fix insecure way to query MAC statistics
net/hns3: fix double decrement of secondary count
net/hns3: fix operating queue when TCAM table is invalid
kni: fix freeing order in device release
net/hns3: fix RSS TC mode entry
net/hns3: fix VF RSS TC mode entry
net/hns3: increase time waiting for PF reset completion
Ivan Malov (8):
net/sfc: validate queue span when parsing flow action RSS
net/sfc: fix lock releases
net/sfc: do not push fast free offload to default TxQ config
net/sfc: demand Tx fast free offload on EF10 simple datapath
common/sfc_efx/base: fix recirculation ID set in outer rules
common/sfc_efx/base: add missing handler for 1-byte fields
net/sfc: fix flow tunnel support detection
net/sfc: reduce log level of tunnel restore info error
Jakub Poczatek (1):
doc: fix FIPS guide
Jiawei Wang (4):
net/mlx5: fix NIC egress flow mismatch in switchdev mode
net/mlx5: fix sample flow action on trusted device
net/mlx5: fix implicit tag insertion with sample action
net/mlx5: fix port matching in sample flow rule
Jiawen Wu (8):
net/ngbe: fix Rx by initializing packet buffer early
net/ngbe: fix missed link interrupt
net/ngbe: fix Tx hang on queue disable
net/ngbe: fix packet statistics
net/txgbe: fix link up and down
net/txgbe: fix KR auto-negotiation
net/ngbe: fix debug logs
net/txgbe: fix debug logs
Jie Hai (1):
net/hns3: remove duplicate macro definition
Jie Wang (1):
net: fix L2TPv2 common header
Jie Zhou (2):
eal/windows: fix error code for not supported API
test/mem: fix error check
Josh Soref (1):
fix spelling in comments and strings
Junfeng Guo (3):
net/ice: fix pattern check for flow director parser
net/ice: fix pattern check in flow director
raw/ntb: clear all valid doorbell bits on init
Junjie Wan (1):
net/bonding: fix slaves initializing on MTU setting
Junxiao Shi (1):
net/af_xdp: fix custom program loading with multiple queues
Juraj Linkeš (1):
config/arm: add values for native armv7
Kai Ji (2):
test/crypto: fix out-of-place SGL in raw datapath
crypto/qat: fix GEN4 AEAD job in raw data path
Kalesh AP (15):
net/bnxt: fix multicast address set
net/bnxt: fix multicast MAC restore during reset recovery
net/bnxt: fix queue stop operation
net/bnxt: restore RSS configuration after reset recovery
net/bnxt: fix restoring VLAN filtering after recovery
net/bnxt: cap maximum number of unicast MAC addresses
net/bnxt: set fast-path pointers only if recovery succeeds
net/bnxt: add null check for mark table
net/bnxt: fix flow create when RSS is disabled
net/bnxt: get maximum supported multicast filters count
net/bnxt: fix handling of VF configuration change
net/bnxt: fix xstats query
net/bnxt: fix check for autoneg enablement
net/bnxt: handle ring cleanup in case of error
net/bnxt: fix memzone allocation per VNIC
Karl Bonde Torp (1):
build: fix build on FreeBSD with Meson 0.61.1
Kathleen Capella (2):
net/iavf: count continuous DD bits for Arm
net/iavf: count continuous DD bits for Arm in flex Rx
Kevin Liu (2):
net/ice: fix Tx checksum offload
net/ice: fix Tx offload path choice
Kevin Traynor (6):
maintainers: update for stable branches
build: suppress rte_crypto_asym_op abi check
Revert "crypto/ipsec_mb: fix length and offset settings"
Revert "net/mlx5: fix flex item availability"
version: 21.11.1-rc1
version: 21.11.1
Kumara Parameshwaran (2):
ethdev: add internal function to device struct from name
net/tap: fix to populate FDs in secondary process
Lance Richardson (2):
buildtools: fix AVX512 check for Python 3.5
net/bnxt: fix xstats names query overrun
Leyi Rong (1):
net/iavf: fix potential out-of-bounds access
Lijun Ou (1):
net/hns3: fix RSS key with null
Lior Margalit (1):
net/mlx5: fix assertion on flags set in packet mbuf
Madhuker Mythri (1):
devargs: fix crash with uninitialized parsing
Martijn Bakker (1):
pflock: fix header file installation
Martin Spinler (2):
net/nfb: fix array indexes in deinit functions
net/nfb: fix multicast/promiscuous mode switching
Marvin Liu (1):
net/virtio: fix slots number when indirect feature on
Matan Azrad (1):
vdpa/mlx5: workaround queue stop with traffic
Maxime Coquelin (1):
vhost: fix unsafe vring addresses modifications
Maxime Gouin (3):
bus/ifpga: remove useless check while browsing devices
net/nfp: remove duplicated check when setting MAC address
net/nfp: remove useless range checks
Megha Ajmera (1):
examples/qos_sched: fix core mask overflow
Michael Baum (17):
common/mlx5: add minimum WQE size for striding RQ
net/mlx5: improve stride parameter names
net/mlx5: fix MPRQ stride devargs adjustment
common/mlx5: fix error handling in multi-class probe
net/mlx5: fix memory socket selection in ASO management
common/mlx5: fix missing validation in devargs parsing
net/mlx5: fix sibling device config check
net/mlx5: fix ineffective metadata argument adjustment
net/mlx5: fix ASO CT object release
net/mlx5: fix errno update in shared context creation
net/mlx5: fix entry in shared Rx queues list
doc: remove obsolete vector Tx explanations from mlx5 guide
doc: replace broken links in mlx guides
doc: correct name of BlueField-2 in mlx5 guide
net/mlx5: fix shared counter flag in flow validation
net/mlx5: fix check in count action validation
common/mlx5: consider local functions as internal
Michal Krawczyk (6):
net/ena: remove unused enumeration
net/ena: remove unused offload variables
net/ena: skip timer if reset is triggered
net/ena: fix meta descriptor DF flag setup
net/ena: fix checksum flag for L4
bus/pci: assign driver pointer before mapping
Michal Wilczynski (1):
net/ice: fix overwriting of LSE bit by DCF
Min Hu (Connor) (6):
net/hns3: fix Rx/Tx functions update
net/hns3: fix vector Rx/Tx when PTP enabled
net/bonding: fix promiscuous and allmulticast state
net/bonding: fix reference count on mbufs
app/testpmd: fix bonding mode set
app/testpmd: check starting port is not in bonding
Naga Harish K S V (2):
eventdev/eth_tx: fix queue add error code
eventdev/eth_rx: fix queue config query
Nicolas Chautru (1):
baseband/acc100: avoid out-of-bounds access
Nipun Gupta (1):
examples/l3fwd: fix Rx burst size for event mode
Nithin Dabilpuram (11):
examples/ipsec-secgw: fix eventdev start sequence
examples/ipsec-secgw: fix default flow rule creation
common/cnxk: fix shift offset for TL3 length disable
common/cnxk: fix byte order of frag sizes and infos
common/cnxk: fix null pointer dereferences
common/cnxk: fix uninitialized variables
examples/ipsec-secgw: fix buffer freeing in vector mode
net/cnxk: fix inline device RQ tag mask
net/cnxk: register callback early to handle initial packets
net/cnxk: fix inline IPsec security error handling
common/cnxk: fix bitmap usage for TM
Pablo de Lara (9):
crypto/ipsec_mb: fix buffer overrun
crypto/ipsec_mb: check missing operation types
crypto/ipsec_mb: fix ZUC authentication verify
crypto/ipsec_mb: fix ZUC operation overwrite
crypto/ipsec_mb: fix length and offset settings
test/efd: fix sockets mask size
efd: fix uninitialized structure
crypto/ipsec_mb: fix length and offset settings
crypto/ipsec_mb: fix GMAC parameters setting
Pavan Nikhilesh (6):
eventdev/eth_rx: fix missing internal port checks
event/cnxk: fix QoS devargs parsing
common/cnxk: add workaround for vWQE flush
config: align mempool elements to 128 bytes on CN10K
event/cnxk: fix sub-event clearing mask length
event/cnxk: fix Rx adapter config check
Peng Yu (1):
vhost: fix linker script syntax
Piotr Bronowski (2):
crypto/ipsec_mb: fix premature dereference
crypto/ipsec_mb: fix GCM requested digest length
Qi Zhang (2):
net/ice: fix Tx checksum offload capability
doc: update matching versions in ice guide
Radu Nicolau (5):
examples/ipsec-secgw: fix offload flag used for TSO IPv6
net/iavf: fix segmentation offload condition
net/iavf: fix segmentation offload buffer size
net/iavf: support NAT-T / UDP encapsulation
net/iavf: fix AES-GMAC IV size
Rahul Bhansali (2):
net/cnxk: fix mbuf data length
examples/l3fwd: fix buffer overflow in Tx
Rahul Lakkireddy (1):
net/cxgbe: fix dangling pointer by mailbox access rework
Raja Zidane (8):
net/mlx5: fix mark enabling for Rx
app/testpmd: fix GENEVE parsing in checksum mode
app/compress-perf: fix cycle count operations allocation
app/compress-perf: optimize operations pool allocation
compress/mlx5: support out-of-space status
app/compress-perf: fix socket ID type during init
app/compress-perf: fix number of queue pairs to setup
compressdev: fix socket ID type
Rakesh Kudurumalla (3):
net/cnxk: fix build with GCC 12
net/cnxk: fix RSS RETA table update
net/cnxk: fix build with optimization
Rashmi Shetty (1):
doc: fix dlb2 guide
Reshma Pattan (1):
app/pdump: abort on multi-core capture limit
Rongwei Liu (3):
net/mlx5: fix shared RSS destroy
net/mlx5: fix meter creation default state
net/mlx5: forbid multiple ASO actions in a single rule
Ruifeng Wang (1):
config: add arch define for Arm
Satheesh Paul (5):
common/cnxk: fix nibble parsing order when dumping MCAM
common/cnxk: fix flow deletion
common/cnxk: fix log level during MCAM allocation
common/cnxk: fix base rule merge
net/cnxk: fix Rx/Tx function update
Sean Morrissey (2):
app/testpmd: fix dereference before null check
doc: fix telemetry example in cryptodev guide
Shijith Thotton (1):
crypto/cnxk: enable allocated queues only
Shun Hao (3):
net/mlx5: fix meter sub-policy creation
net/mlx5: fix E-Switch manager vport ID
net/mlx5: fix meter policy creation assert
Simei Su (1):
net/ice: fix mbuf offload flag for Rx timestamp
Srikanth Yalavarthi (1):
dma/cnxk: fix installing internal headers
Stephen Douthit (1):
net/ixgbe: fix FSP check for X550EM devices
Stephen Hemminger (7):
eal/linux: log hugepage create errors with filename
net/memif: remove unnecessary Rx interrupt stub
ipc: end multiprocess thread during cleanup
vfio: cleanup the multiprocess sync handle
pcapng: handle failure of link status query
test/bpf: skip dump if conversion fails
app/dumpcap: check for failure to set promiscuous
Steve Yang (4):
app/testpmd: fix stack overflow for EEPROM display
net/i40e: fix unintentional integer overflow
eal/linux: fix illegal memory access in uevent handler
net/iavf: fix function pointer in multi-process
Suanming Mou (3):
net/mlx5: set flow error for hash list create
net/mlx5: remove unused function
net/mlx5: fix indexed pool fetch overlap
Thinh Tran (1):
net/mlx5: fix CPU socket ID for Rx queue creation
Thomas Monjalon (6):
doc: replace deprecated distutils version parsing
dmadev: add missing header include
app/testpmd: fix build without drivers
regexdev: fix section attribute of symbols
build: hide local symbols in shared libraries
devtools: fix symbols check
Tianfei Zhang (2):
raw/ifpga/base: fix SPI transaction
raw/ifpga: fix thread closing
Tianli Lai (1):
examples/kni: add missing trailing newline in log
Timothy McDaniel (3):
event/dlb2: update rolling mask used for dequeue
event/dlb2: poll HW CQ inflights before mapping queue
event/dlb2: add shift value check in sparse dequeue
Vanshika Shukla (2):
net/dpaa2: fix unregistering interrupt handler
net/dpaa2: fix timestamping for IEEE1588
Viacheslav Ovsiienko (4):
net/mlx5: fix modify field MAC address offset
app/testpmd: fix Tx scheduling interval
net/mlx5: fix metadata endianness in modify field action
doc: fix modify field action description for mlx5
Vladimir Medvedkin (1):
app/fib: fix division by zero
Wei Huang (5):
raw/ifpga/base: fix port feature ID
raw/ifpga: fix variable initialization in probing
raw/ifpga: fix interrupt handle allocation
raw/ifpga: fix monitor thread
raw/ifpga: fix build with optimization
Weiguo Li (14):
common/cnxk: fix error checking
net/enic: fix dereference before null check
net/dpaa2: fix null pointer dereference
regex/mlx5: fix memory allocation check
net/memif: remove pointer deference before null check
net/iavf: fix null pointer dereference
vdpa/sfc: fix null dereference during config
vdpa/sfc: fix null dereference during removal
compress/octeontx: fix null pointer dereference
eventdev/eth_rx: fix parameters parsing memory leak
net/sfc: fix memory allocation size for cache
net/txgbe: fix queue statistics mapping
sched: remove useless malloc in PIE data init
net/bnxt: fix null dereference in session cleanup
Wenwu Ma (1):
examples/vhost: fix launch with physical port
Wenxuan Wu (1):
eal/linux: fix device monitor stop return
Xiaoyu Min (1):
net/mlx5: reject jump to root table
Xuan Ding (2):
vhost: fix field naming in guest page struct
vhost: fix physical address mapping
Xueming Li (1):
net/virtio: fix Tx queue 0 overriden by queue 128
Yajun Wu (1):
common/mlx5: fix queue pair ack timeout configuration
Yiding Zhou (1):
net/ice: fix build with 16-byte Rx descriptor
Yu Wenjun (1):
net/bonding: fix RSS with early configure
Yuan Wang (1):
vhost: fix guest to host physical address mapping
Yunjian Wang (12):
net/bonding: fix mode type mismatch
ethdev: fix Rx queue telemetry memory leak on failure
net/ice: fix link up when starting device
net/virtio-user: check FD flags getting failure
net/virtio: fix uninitialized RSS key
ring: fix error code when creating ring
net/ixgbe: check filter init failure
mem: check allocation in dynamic hugepage init
ethdev: remove unnecessary null check
net/ixgbe: reset security context pointer on close
net/txgbe: reset security context pointer on close
net/iavf: reset security context pointer on stop
Yuying Zhang (1):
net/ice/base: add profile validation on switch filter
Zhihong Wang (1):
ring: fix overflow in memory size calculation
^ permalink raw reply [relevance 1%]
* RE: [PATCH v3 0/7] Add new cryptodev op for event metadata
2022-04-21 14:37 4% ` [PATCH v3 " Akhil Goyal
2022-04-21 14:37 2% ` [PATCH v3 1/7] cryptodev: add APIs to get/set " Akhil Goyal
@ 2022-04-27 15:37 0% ` Zhang, Roy Fan
2022-04-28 14:24 0% ` Gujjar, Abhinandan S
2022-05-01 19:24 4% ` [PATCH v4 " Akhil Goyal
3 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2022-04-27 15:37 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: anoobj, jerinj, Gujjar, Abhinandan S, Jayatheerthan, Jay,
Vangati, Narender, vfialko
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, April 21, 2022 3:37 PM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; vfialko@marvell.com; Akhil Goyal
> <gakhil@marvell.com>
> Subject: [PATCH v3 0/7] Add new cryptodev op for event metadata
>
> For using event crypto metadata, event metadata need to be set
> in session. For this session user data was used for symmetric
> crypto sessions and no support was present for asymmetric and
> security sessions.
> The use of userdata to store event metadata (which is dereferenced
> in PMD) is not correct as it is meant for the application to use it.
> Hence, a new API is created to set and get event crypto metadata which
> is scalable to all sessions supported by the crypto PMD.
> The application can use the set API to set event metadata and the
> PMD may store that inside the session private data and PMD need not
> use the get API as it would be internal to the PMD.
> For the software event crypto adapter implementation, the eventdev
> library can use the get API to get the event metadata stored inside
> the session structure.
> For Asymmetric sessions, a new field is added inside the session
> struct which is internal to library.
> For symmetric and security sessions, new field cannot be added as
> it would be ABI break. Hence, session userdata is being used to
> store that as it was used earlier. In next ABI break release this
> would be fixed similar to asymmetric crypto case.
>
> The patchset also add support for asymmetric crypto adapter
> in the test applications and the crypto/cnxk implementation of
> the new cryptodev op and corresponding changes in the eventdev lib.
>
> Changes in v3:
> - fix SW adapter case of memory allocation/free of mdata. mdata is
> allocated in set API and freed in session clear/destroy.
> - mark rte_cryptodev_session_event_mdata_get as internal API
> as it is only needed for the app or the PMD.
>
> changes in v2:
> - v1 patchset only fixed security sessions and also caused ABI breakage.
> This is fixed in v2.
> - added new API for setting event metadata.
> - added new cryptodev op which can handle all sessions
>
>
> Akhil Goyal (5):
> crypto/octeontx: use new API for event metadata
> test/event: use new API to set event crypto metadata
> eventdev: use new API to get event crypto metadata
> test/event: add asymmetric cases for crypto adapter
> test-eventdev: support asym ops for crypto adapter
>
> Volodymyr Fialko (2):
> cryptodev: add APIs to get/set event metadata
> crypto/cnxk: add event metadata set operation
>
> app/test-eventdev/evt_common.h | 2 +
> app/test-eventdev/evt_options.c | 17 +
> app/test-eventdev/evt_options.h | 4 +
> app/test-eventdev/test_perf_atq.c | 12 +-
> app/test-eventdev/test_perf_common.c | 254 ++++++++--
> app/test-eventdev/test_perf_common.h | 45 +-
> app/test-eventdev/test_perf_queue.c | 12 +-
> app/test/test_event_crypto_adapter.c | 503 +++++++++++++++++++-
> doc/guides/tools/testeventdev.rst | 5 +
> drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++++-
> drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
> drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 +++++-
> drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
> drivers/crypto/cnxk/cnxk_ae.h | 2 +
> drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 -
> drivers/crypto/cnxk/cnxk_se.h | 2 +
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +-
> lib/cryptodev/cryptodev_pmd.c | 16 +
> lib/cryptodev/cryptodev_pmd.h | 36 ++
> lib/cryptodev/rte_cryptodev.c | 41 ++
> lib/cryptodev/rte_cryptodev.h | 22 +
> lib/cryptodev/version.map | 4 +
> lib/eventdev/rte_event_crypto_adapter.c | 55 +--
> 23 files changed, 1168 insertions(+), 188 deletions(-)
>
> --
> 2.25.1
Series-acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* RE: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
2022-04-21 14:37 2% ` [PATCH v3 1/7] cryptodev: add APIs to get/set " Akhil Goyal
@ 2022-04-27 15:38 0% ` Zhang, Roy Fan
2022-04-28 14:42 0% ` Gujjar, Abhinandan S
1 sibling, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2022-04-27 15:38 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: anoobj, jerinj, Gujjar, Abhinandan S, Jayatheerthan, Jay,
Vangati, Narender, vfialko
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, April 21, 2022 3:37 PM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; vfialko@marvell.com; Akhil Goyal
> <gakhil@marvell.com>
> Subject: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
>
> From: Volodymyr Fialko <vfialko@marvell.com>
>
> Currently, crypto session userdata is used to set event crypto
> metadata from the application and the driver is dereferencing it
> in driver which is not correct. User data is meant to be opaque
> to the driver.
> To support this, new API is added to get and set event crypto
> metadata. The new API, rte_cryptodev_set_session_event_mdata,
> allows setting event metadata in session private data which is
> filled inside PMD using a new cryptodev op. This operation
> can be performed on any of the PMD supported sessions
> (sym/asym/security).
> For SW abstraction of event crypto adapter to be used by
> eventdev library, a new field is added in asymmetric crypto
> session for now and for symmetric case, current implementation
> of using userdata is used. Symmetric cases cannot be fixed now,
> as it will be ABI breakage which will be resolved in DPDK 22.11.
>
> Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* Re: librte_bpf: roadmap or any specific plans for this library
@ 2022-04-28 10:34 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-04-28 10:34 UTC (permalink / raw)
To: Björn Svensson A; +Cc: dev, Ananyev, Konstantin, Stephen Hemminger
Hello,
On Tue, Apr 26, 2022 at 10:34 AM Björn Svensson A
<bjorn.a.svensson@est.tech> wrote:
>
> Hi all,
> I hope this is the correct maillist for this topic.
Yes it is.
I copied the maintainer and people that might be interested in this topic.
>
> DPDK provides the nice library `librte_bpf` to load and execute eBPF bytecode
> and we would like to broaden our usage of this library.
>
> Today there are hints that this library might have been purpose built to enable inspection or modification of packets;
> for example the eBPF program is expected to only use a single input argument, pointing to data of some sort.
> We believe it would be beneficial to be able to use this library to run generic eBPF programs as well,
> as an alternative to run them as RX- TX-port/queue callbacks (i.e. generic programs which only uses supported features)
>
> I have seen some discussions regarding moving towards using a common library with the kernel implementation of bpf,
> but I couldn't figure out the outcome.
I don't think there was progress on this.
> My question is if there any plans to evolve this library or would improvements possibly be accepted?
>
> Here are some improvements we are interested to look into:
>
> * Add additional API for loading eBPF code.
> Today it's possible to load eBPF code from an ELF file, but having an API to load code from an ELF image from memory
> would open up for other ways to manage eBPF code.
>
> Example of the new API:
> struct rte_bpf *
> rte_bpf_elf_image_load(const struct rte_bpf_prm *prm, char *image,
> size_t size, const char *sname);
>
> * Add support of more than a single input argument.
> There are cases when additional information is needed. Being able to use more than a single input argument
> would help when running generic eBPF programs.
>
> Example of change:
> struct rte_bpf_prm {
> ...
> - struct rte_bpf_arg prog_arg; /**< eBPF program input arg description */
> + uint32_t nb_args;
> + struct rte_bpf_arg prog_args[EBPF_FUNC_MAX_ARGS]; /**< eBPF program input args */
> };
All I can tell, is that this proposal breaks ABI.
This is a blocker to get it accepted until next ABI breakage window opens.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [PATCH v3 0/7] Add new cryptodev op for event metadata
2022-04-21 14:37 4% ` [PATCH v3 " Akhil Goyal
2022-04-21 14:37 2% ` [PATCH v3 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-04-27 15:37 0% ` [PATCH v3 0/7] Add new cryptodev op for " Zhang, Roy Fan
@ 2022-04-28 14:24 0% ` Gujjar, Abhinandan S
2022-05-01 19:24 4% ` [PATCH v4 " Akhil Goyal
3 siblings, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2022-04-28 14:24 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: anoobj, jerinj, Jayatheerthan, Jay, Vangati, Narender, vfialko
Acked-by: Abhinandan Gujjar <Abhinandan.gujjar@intel.com>
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, April 21, 2022 8:07 PM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; vfialko@marvell.com; Akhil Goyal
> <gakhil@marvell.com>
> Subject: [PATCH v3 0/7] Add new cryptodev op for event metadata
>
> For using event crypto metadata, event metadata need to be set in session. For
> this session user data was used for symmetric crypto sessions and no support
> was present for asymmetric and security sessions.
> The use of userdata to store event metadata (which is dereferenced in PMD) is
> not correct as it is meant for the application to use it.
> Hence, a new API is created to set and get event crypto metadata which is
> scalable to all sessions supported by the crypto PMD.
> The application can use the set API to set event metadata and the PMD may
> store that inside the session private data and PMD need not use the get API as
> it would be internal to the PMD.
> For the software event crypto adapter implementation, the eventdev library
> can use the get API to get the event metadata stored inside the session
> structure.
> For Asymmetric sessions, a new field is added inside the session struct which is
> internal to library.
> For symmetric and security sessions, new field cannot be added as it would be
> ABI break. Hence, session userdata is being used to store that as it was used
> earlier. In next ABI break release this would be fixed similar to asymmetric
> crypto case.
>
> The patchset also add support for asymmetric crypto adapter in the test
> applications and the crypto/cnxk implementation of the new cryptodev op and
> corresponding changes in the eventdev lib.
>
> Changes in v3:
> - fix SW adapter case of memory allocation/free of mdata. mdata is allocated in
> set API and freed in session clear/destroy.
> - mark rte_cryptodev_session_event_mdata_get as internal API as it is only
> needed for the app or the PMD.
>
> changes in v2:
> - v1 patchset only fixed security sessions and also caused ABI breakage.
> This is fixed in v2.
> - added new API for setting event metadata.
> - added new cryptodev op which can handle all sessions
>
>
> Akhil Goyal (5):
> crypto/octeontx: use new API for event metadata
> test/event: use new API to set event crypto metadata
> eventdev: use new API to get event crypto metadata
> test/event: add asymmetric cases for crypto adapter
> test-eventdev: support asym ops for crypto adapter
>
> Volodymyr Fialko (2):
> cryptodev: add APIs to get/set event metadata
> crypto/cnxk: add event metadata set operation
>
> app/test-eventdev/evt_common.h | 2 +
> app/test-eventdev/evt_options.c | 17 +
> app/test-eventdev/evt_options.h | 4 +
> app/test-eventdev/test_perf_atq.c | 12 +-
> app/test-eventdev/test_perf_common.c | 254 ++++++++--
> app/test-eventdev/test_perf_common.h | 45 +-
> app/test-eventdev/test_perf_queue.c | 12 +-
> app/test/test_event_crypto_adapter.c | 503 +++++++++++++++++++-
> doc/guides/tools/testeventdev.rst | 5 +
> drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++++-
> drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
> drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 +++++-
> drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
> drivers/crypto/cnxk/cnxk_ae.h | 2 +
> drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 -
> drivers/crypto/cnxk/cnxk_se.h | 2 +
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +-
> lib/cryptodev/cryptodev_pmd.c | 16 +
> lib/cryptodev/cryptodev_pmd.h | 36 ++
> lib/cryptodev/rte_cryptodev.c | 41 ++
> lib/cryptodev/rte_cryptodev.h | 22 +
> lib/cryptodev/version.map | 4 +
> lib/eventdev/rte_event_crypto_adapter.c | 55 +--
> 23 files changed, 1168 insertions(+), 188 deletions(-)
>
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* RE: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
2022-04-21 14:37 2% ` [PATCH v3 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-04-27 15:38 0% ` Zhang, Roy Fan
@ 2022-04-28 14:42 0% ` Gujjar, Abhinandan S
1 sibling, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2022-04-28 14:42 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: anoobj, jerinj, Jayatheerthan, Jay, Vangati, Narender, vfialko
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, April 21, 2022 8:07 PM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; vfialko@marvell.com; Akhil Goyal
> <gakhil@marvell.com>
> Subject: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
>
> From: Volodymyr Fialko <vfialko@marvell.com>
>
> Currently, crypto session userdata is used to set event crypto metadata from
> the application and the driver is dereferencing it in driver which is not correct.
> User data is meant to be opaque to the driver.
> To support this, new API is added to get and set event crypto metadata. The
> new API, rte_cryptodev_set_session_event_mdata,
> allows setting event metadata in session private data which is filled inside PMD
> using a new cryptodev op. This operation can be performed on any of the PMD
> supported sessions (sym/asym/security).
> For SW abstraction of event crypto adapter to be used by eventdev library, a
> new field is added in asymmetric crypto session for now and for symmetric
> case, current implementation of using userdata is used. Symmetric cases cannot
> be fixed now, as it will be ABI breakage which will be resolved in DPDK 22.11.
>
> Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> lib/cryptodev/cryptodev_pmd.c | 16 ++++++++++++++
> lib/cryptodev/cryptodev_pmd.h | 36 ++++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.c | 41 +++++++++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.h | 22 +++++++++++++++++++
> lib/cryptodev/version.map | 4 ++++
> 5 files changed, 119 insertions(+)
>
> diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
> index 739a0b3f34..1903ade388 100644
> --- a/lib/cryptodev/cryptodev_pmd.c
> +++ b/lib/cryptodev/cryptodev_pmd.c
> @@ -227,3 +227,19 @@ cryptodev_fp_ops_set(struct rte_crypto_fp_ops
> *fp_ops,
> fp_ops->qp.enq_cb = dev->enq_cbs;
> fp_ops->qp.deq_cb = dev->deq_cbs;
> }
> +
> +void *
> +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op) {
Null check for op?
> + if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
> + op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> + return rte_cryptodev_sym_session_get_user_data(op->sym-
> >session);
> + else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
> + op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> + return op->asym->session->event_mdata;
> + else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
> + op->private_data_offset)
> + return ((uint8_t *)op + op->private_data_offset);
> + else
> + return NULL;
> +}
> diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
> index 2b1ce2da2d..7969944b66 100644
> --- a/lib/cryptodev/cryptodev_pmd.h
> +++ b/lib/cryptodev/cryptodev_pmd.h
> @@ -398,6 +398,25 @@ typedef int
> (*cryptodev_sym_configure_raw_dp_ctx_t)(
> enum rte_crypto_op_sess_type sess_type,
> union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
>
> +/**
> + * Typedef that the driver provided to set event crypto meta data.
> + *
> + * @param dev Crypto device pointer.
> + * @param sess Crypto or security session.
> + * @param op_type Operation type.
> + * @param sess_type Session type.
> + * @param ev_mdata Pointer to the event crypto meta data
> + * (aka *union rte_event_crypto_metadata*)
> + * @return
> + * - On success return 0.
> + * - On failure return negative integer.
> + */
> +typedef int (*cryptodev_session_event_mdata_set_t)(
> + struct rte_cryptodev *dev, void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *ev_mdata);
> +
> /** Crypto device operations function pointer table */ struct
> rte_cryptodev_ops {
> cryptodev_configure_t dev_configure; /**< Configure device. */
> @@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
> /**< Initialize raw data path context data. */
> };
> };
> + cryptodev_session_event_mdata_set_t session_ev_mdata_set;
> + /**< Set a Crypto or Security session even meta data. */
> };
>
>
> @@ -603,6 +624,19 @@ void
> cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
> const struct rte_cryptodev *dev);
>
> +/**
> + * Get session event meta data (aka *union rte_event_crypto_metadata*)
> + *
> + * @param op pointer to *rte_crypto_op* structure.
> + *
> + * @return
> + * - On success, pointer to event crypto metadata
> + * - On failure, a negative value.
> + */
> +__rte_internal
> +void *
> +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
> +
> static inline void *
> get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
> uint8_t driver_id) {
> @@ -636,6 +670,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
> /**< Size of private data used when creating mempool */
> uint16_t user_data_sz;
> /**< Session user data will be placed after sess_data */
> + void *event_mdata;
> + /**< Event crypto adapter metadata */
Add reference to rte_event_crypto_metadata for clarity?
> uint8_t padding[3];
> uint8_t sess_private_data[0];
> };
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c index
> 3500a2d470..a070cb2a00 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -2051,6 +2051,9 @@ rte_cryptodev_asym_session_free(uint8_t dev_id,
> void *sess)
>
> dev->dev_ops->asym_session_clear(dev, sess);
>
> + if (((struct rte_cryptodev_asym_session *)sess)->event_mdata)
> + rte_free(((struct rte_cryptodev_asym_session *)sess)-
> >event_mdata);
> +
Who allocates memory for event_mdata? If this done by application before calling
rte_cryptodev_session_event_mdata_set(), please document it.
> /* Return session to mempool */
> sess_mp = rte_mempool_from_obj(sess);
> rte_mempool_put(sess_mp, sess);
> @@ -2259,6 +2262,44 @@ rte_cryptodev_configure_raw_dp_ctx(uint8_t
> dev_id, uint16_t qp_id,
> sess_type, session_ctx, is_update);
> }
>
> +int
> +rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *ev_mdata,
> + uint16_t size)
> +{
> + struct rte_cryptodev *dev;
> +
> + if (!rte_cryptodev_is_valid_dev(dev_id))
> + goto skip_pmd_op;
> +
> + dev = rte_cryptodev_pmd_get_dev(dev_id);
> + if (dev->dev_ops->session_ev_mdata_set == NULL)
> + goto skip_pmd_op;
> +
> + return (*dev->dev_ops->session_ev_mdata_set)(dev, sess, op_type,
> + sess_type, ev_mdata);
> +
> +skip_pmd_op:
> + if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC)
> + return rte_cryptodev_sym_session_set_user_data(sess,
> ev_mdata,
> + size);
> + else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
> + struct rte_cryptodev_asym_session *s = sess;
Null check for sess?
> +
> + if (s->event_mdata == NULL) {
> + s->event_mdata = rte_malloc(NULL, size, 0);
> + if (s->event_mdata == NULL)
> + return -ENOMEM;
> + }
> + rte_memcpy(s->event_mdata, ev_mdata, size);
> +
> + return 0;
> + } else
> + return -ENOTSUP;
> +}
> +
> uint32_t
> rte_cryptodev_raw_enqueue_burst(struct rte_crypto_raw_dp_ctx *ctx,
> struct rte_crypto_sym_vec *vec, union rte_crypto_sym_ofs ofs, diff --
> git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h index
> 45d33f4a50..2c2c2edeb7 100644
> --- a/lib/cryptodev/rte_cryptodev.h
> +++ b/lib/cryptodev/rte_cryptodev.h
> @@ -1269,6 +1269,28 @@ __rte_experimental int
> rte_cryptodev_get_raw_dp_ctx_size(uint8_t dev_id);
>
> +/**
> + * Set session event meta data
> + *
> + * @param dev_id The device identifier.
> + * @param sess Crypto or security session.
> + * @param op_type Operation type.
> + * @param sess_type Session type.
> + * @param ev_mdata Pointer to the event crypto meta data
> + * (aka *union rte_event_crypto_metadata*)
> + * @param size Size of ev_mdata.
> + *
> + * @return
> + * - On success, zero.
> + * - On failure, a negative value.
> + */
> +__rte_experimental
> +int
> +rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *ev_mdata, uint16_t size);
> +
> /**
> * Union of different crypto session types, including session-less xform
> * pointer.
> diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map index
> c7c5aefceb..f0abfaa47d 100644
> --- a/lib/cryptodev/version.map
> +++ b/lib/cryptodev/version.map
> @@ -105,6 +105,9 @@ EXPERIMENTAL {
> rte_cryptodev_asym_session_pool_create;
> rte_cryptodev_asym_session_set_user_data;
> __rte_cryptodev_trace_asym_session_pool_create;
> +
> + #added in 22.07
> + rte_cryptodev_session_event_mdata_set;
> };
>
> INTERNAL {
> @@ -123,5 +126,6 @@ INTERNAL {
> rte_cryptodev_pmd_parse_input_args;
> rte_cryptodev_pmd_probing_finish;
> rte_cryptodev_pmd_release_device;
> + rte_cryptodev_session_event_mdata_get;
> rte_cryptodevs;
> };
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-04-21 18:02 5% ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2022-04-26 10:19 0% ` Ray Kinsella
@ 2022-05-01 14:46 5% ` jerinj
1 sibling, 0 replies; 200+ results
From: jerinj @ 2022-05-01 14:46 UTC (permalink / raw)
To: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and
support for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port.
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v5..v4:
- Improved the Doxgen comments as per
http://patches.dpdk.org/project/dpdk/patch/20220421180241.514767-1-jerinj@marvell.com/
- Removed input_color_proto_mask
- Renamed rte_mtr_color_in_protocol_priority_set() to rte_mtr_color_in_protocol_set()
- Introduced rte_mtr_color_in_protocol_get(), rte_mtr_color_in_protocol_priority_get()
for getting the configured input color protocol.
v4..v3:
- Aligned with community meeting call which is documented in
https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
as last message. With following exception,
- Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
Changing above symbols break existing application for no good.
- Updated 22.07 release notes
- Remove testpmd changes from series to finalize the API spec first and
then we can send testpmd changes.
v3..v2:
- Fix input color flags as a bitmask
- Add definitions for newly added API
v2..v1:
- Fix seperate typo
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
.../traffic_metering_and_policing.rst | 35 +++
doc/guides/rel_notes/release_22_07.rst | 10 +
lib/ethdev/rte_mtr.c | 50 ++++
lib/ethdev/rte_mtr.h | 216 +++++++++++++++++-
lib/ethdev/rte_mtr_driver.h | 38 +++
lib/ethdev/version.map | 6 +
6 files changed, 345 insertions(+), 10 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..d1958a023d 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Protocol based input color selection
Configuration steps
-------------------
@@ -105,3 +106,37 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Protocol based input color selection
+------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the protocol based input color selection device capabilities using
+ the following parameters with ``rte_mtr_capabilities_get()`` API.
+
+ * ``struct rte_mtr_capabilities::input_color_proto_mask;``
+ * ``struct rte_mtr_capabilities::separate_input_color_table_per_port``
+
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::vlan_table`` based on input color selected.
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method.
+
+#. Use the following APIs to configure the meter object
+
+ * Select the input protocol color with ``rte_mtr_color_in_protocol_set()`` API.
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
+
+ * Application can query the configured input color protocol and its associated
+ priority using ``rte_mtr_color_in_protocol_get()`` and
+ ``rte_mtr_color_in_protocol_priority_get()`` APIs.
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 88d6e96cc1..74ecc3f53d 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -55,6 +55,13 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added protocol based input color selection for meter.**
+
+ Added new APIs ``rte_mtr_color_in_protocol_set()``, ``rte_mtr_color_in_protocol_get()``,
+ ``rte_mtr_color_in_protocol_priority_get()``, ``rte_mtr_meter_vlan_table_update()``
+ and updated ``struct rte_mtr_params`` and ``struct rte_mtr_capabilities`` to
+ support protocol based input color selection for meter.
+
* **Updated Intel iavf driver.**
* Added Tx QoS queue rate limitation support.
@@ -112,6 +119,9 @@ ABI Changes
* No ABI change that would break compatibility with 21.11.
+* Experimental structures ``struct rte_mtr_params``
+ and ``struct rte_mtr_capabilities`` updated to support
+ protocol based input color for meter.
Known Issues
------------
diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
index e49fcf271c..441ea1dca9 100644
--- a/lib/ethdev/rte_mtr.c
+++ b/lib/ethdev/rte_mtr.c
@@ -207,6 +207,56 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
mtr_id, dscp_table, error);
}
+/** MTR object meter VLAN table update */
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
+ mtr_id, vlan_table, error);
+}
+
+/** Set the input color protocol on MTR object */
+int
+rte_mtr_color_in_protocol_set(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_set)(dev,
+ mtr_id, proto, priority, error);
+}
+
+/** Get input color protocols of MTR object */
+int
+rte_mtr_color_in_protocol_get(uint16_t port_id,
+ uint32_t mtr_id,
+ uint64_t *proto_mask,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_get)(dev,
+ mtr_id, proto_mask, error);
+}
+
+/** Get input color protocol priority of MTR object */
+int
+rte_mtr_color_in_protocol_priority_get(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t *priority,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_prio_get)(dev,
+ mtr_id, proto, priority, error);
+}
+
/** MTR object enabled stats update */
int
rte_mtr_stats_update(uint16_t port_id,
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..008bc84f0d 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,51 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color protocol method
+ *
+ * More than one of the method can be enabled for a given meter.
+ * Even if enabled, a method might not be applicable to each input packet,
+ * in case the associated protocol header is not present in the packet.
+ * The highest priority method that is both enabled for the meter and also
+ * applicable for the current input packet wins;
+ * if none is both enabled and applicable, the default input color is used.
+ * @see function rte_mtr_color_in_protocol_set()
+ *
+ */
+enum rte_mtr_color_in_protocol {
+ /**
+ * Enable the detection of the packet input color based on the outermost
+ * VLAN header fields DEI (1 bit) and PCP (3 bits).
+ * These fields are used as index into the VLAN table.
+ *
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
+ /**
+ * Enable the detection of the packet input color based on the innermost
+ * VLAN header fields DEI (1 bit) and PCP (3 bits).
+ * These fields are used as index into the VLAN table.
+ *
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
+ /**
+ * Enable the detection of the packet input color based on the outermost
+ * IP DSCP field. These fields are used as index into the DSCP table.
+ *
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_IP = RTE_BIT64(2),
+ /**
+ * Enable the detection of the packet input color based on the innermost
+ * IP DSCP field. These fields are used as index into the DSCP table.
+ *
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_IP = RTE_BIT64(3),
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,20 +278,58 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP protocol field.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_IP,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_IP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
- * Point (DSCP) input packet field. When NULL: it is equivalent to
- * setting this parameter to an all-green populated table (i.e. table
- * with all the 64 elements set to green color). The color blind mode
- * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
- * to either NULL or to an all-green populated table. When
- * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
- * at least one yellow or red color element, then the color aware mode
- * is configured.
+ * Point (DSCP) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an all-green
+ * populated table (i.e. table with all the 64 elements set to green
+ * color). The color blind mode is configured by setting
+ * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
+ * all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value or when *dscp_table*
+ * contains at least one yellow or red color element, then the color
+ * aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_IP
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_IP
+ * @see struct rte_mtr_params::input_color_proto_mask
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
+ * fields.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ * @see struct rte_mtr_params::input_color_proto_mask
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +344,12 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this when *input_color_proto_mask* set to zero.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +506,16 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Set of supported input color protocol.
+ * @see enum rte_mtr_color_in_protocol
+ */
+ uint64_t input_color_proto_mask;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int separate_input_color_table_per_port;
};
/**
@@ -832,6 +931,103 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
+/**
+ * Set the input color protocol for a given MTR object
+ *
+ * More than one of the method can be enabled for a given meter.
+ * Even if enabled, a method might not be applicable to each input packet,
+ * in case the associated protocol header is not present in the packet.
+ * The highest priority method that is both enabled for the meter and also
+ * applicable for the current input packet wins;
+ * if none is both enabled and applicable, the default input color is used.
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] proto
+ * Input color protocol.
+ * @param[in] priority
+ * Input color protocol priority. Value zero indicates
+ * the highest priority.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_set(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto, uint32_t priority,
+ struct rte_mtr_error *error);
+
+/**
+ * Get the input color protocol for a given MTR object
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[out] proto_mask
+ * Selected input color protocols as bit mask.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ *
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_get(uint16_t port_id, uint32_t mtr_id,
+ uint64_t *proto_mask,
+ struct rte_mtr_error *error);
+
+/**
+ * Get the priority associated with input color protocol for a given MTR object
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] proto
+ * Input color protocol.
+ * @param[out] priority
+ * Input color protocol priority associated with proto.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_priority_get(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto, uint32_t *priority,
+ struct rte_mtr_error *error);
+
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
index ee8c6ef7ad..f7dca9a54c 100644
--- a/lib/ethdev/rte_mtr_driver.h
+++ b/lib/ethdev/rte_mtr_driver.h
@@ -97,6 +97,32 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/** @internal mtr object meter vlan table update. */
+typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
+/** @internal Set the input color protocol on MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_set_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error);
+
+/** @internal Get the input color protocols of MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_get_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ uint64_t *proto_mask,
+ struct rte_mtr_error *error);
+
+/** @internal Get the input color protocol priority of MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_prio_get_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t *priority,
+ struct rte_mtr_error *error);
+
/** @internal MTR object enabled stats update. */
typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
@@ -139,6 +165,18 @@ struct rte_mtr_ops {
/** MTR object meter DSCP table update */
rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
+ /** MTR object meter VLAN table update */
+ rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
+
+ /** Set the input color protocol on MTR object. */
+ rte_mtr_meter_color_in_proto_set_t in_proto_set;
+
+ /** Get the input color protocol of MTR object. */
+ rte_mtr_meter_color_in_proto_get_t in_proto_get;
+
+ /** Get the input color protocol priority of MTR object. */
+ rte_mtr_meter_color_in_proto_prio_get_t in_proto_prio_get;
+
/** MTR object enabled stats update */
rte_mtr_stats_update_t stats_update;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 20391ab29e..daca7851f2 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -279,6 +279,12 @@ EXPERIMENTAL {
rte_flow_async_action_handle_create;
rte_flow_async_action_handle_destroy;
rte_flow_async_action_handle_update;
+
+ # added in 22.07
+ rte_mtr_color_in_protocol_get;
+ rte_mtr_color_in_protocol_priority_get;
+ rte_mtr_color_in_protocol_set;
+ rte_mtr_meter_vlan_table_update;
};
INTERNAL {
--
2.36.0
^ permalink raw reply [relevance 5%]
* [PATCH v4 0/7] Add new cryptodev op for event metadata
2022-04-21 14:37 4% ` [PATCH v3 " Akhil Goyal
` (2 preceding siblings ...)
2022-04-28 14:24 0% ` Gujjar, Abhinandan S
@ 2022-05-01 19:24 4% ` Akhil Goyal
2022-05-01 19:24 2% ` [PATCH v4 1/7] cryptodev: add APIs to get/set " Akhil Goyal
` (2 more replies)
3 siblings, 3 replies; 200+ results
From: Akhil Goyal @ 2022-05-01 19:24 UTC (permalink / raw)
To: dev
Cc: anoobj, jerinj, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, vfialko, Akhil Goyal
For using event crypto metadata, event metadata need to be set
in session. For this session user data was used for symmetric
crypto sessions and no support was present for asymmetric and
security sessions.
The use of userdata to store event metadata (which is dereferenced
in PMD) is not correct as it is meant for the application to use it.
Hence, a new API is created to set and get event crypto metadata which
is scalable to all sessions supported by the crypto PMD.
The application can use the set API to set event metadata and the
PMD may store that inside the session private data and PMD need not
use the get API as it would be internal to the PMD.
For the software event crypto adapter implementation, the eventdev
library can use the get API to get the event metadata stored inside
the session structure.
For Asymmetric sessions, a new field is added inside the session
struct which is internal to library.
For symmetric and security sessions, new field cannot be added as
it would be ABI break. Hence, session userdata is being used to
store that as it was used earlier. In next ABI break release this
would be fixed similar to asymmetric crypto case.
The patchset also add support for asymmetric crypto adapter
in the test applications and the crypto/cnxk implementation of
the new cryptodev op and corresponding changes in the eventdev lib.
Changes in v4:
- added null checks in set API
- updated check in session destroy
- updated API comments
- fixed test app failure reported by Abhinandan.
- moved event mdata after padding in asym session struct.
Changes in v3:
- fix SW adapter case of memory allocation/free of mdata. mdata is
allocated in set API and freed in session clear/destroy.
- mark rte_cryptodev_session_event_mdata_get as internal API
as it is only needed for the app or the PMD.
changes in v2:
- v1 patchset only fixed security sessions and also caused ABI breakage.
This is fixed in v2.
- added new API for setting event metadata.
- added new cryptodev op which can handle all sessions
Akhil Goyal (5):
crypto/octeontx: use new API for event metadata
test/event: use new API to set event crypto metadata
eventdev: use new API to get event crypto metadata
test/event: add asymmetric cases for crypto adapter
test-eventdev: support asym ops for crypto adapter
Volodymyr Fialko (2):
cryptodev: add APIs to get/set event metadata
crypto/cnxk: add event metadata set operation
app/test-eventdev/evt_common.h | 2 +
app/test-eventdev/evt_options.c | 17 +
app/test-eventdev/evt_options.h | 4 +
app/test-eventdev/test_perf_atq.c | 12 +-
app/test-eventdev/test_perf_common.c | 254 ++++++++--
app/test-eventdev/test_perf_common.h | 45 +-
app/test-eventdev/test_perf_queue.c | 12 +-
app/test/test_event_crypto_adapter.c | 511 +++++++++++++++++++-
doc/guides/tools/testeventdev.rst | 5 +
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++++-
drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 +++++-
drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
drivers/crypto/cnxk/cnxk_ae.h | 2 +
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 -
drivers/crypto/cnxk/cnxk_se.h | 2 +
drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +-
lib/cryptodev/cryptodev_pmd.c | 16 +
lib/cryptodev/cryptodev_pmd.h | 36 ++
lib/cryptodev/rte_cryptodev.c | 44 ++
lib/cryptodev/rte_cryptodev.h | 22 +
lib/cryptodev/version.map | 4 +
lib/eventdev/rte_event_crypto_adapter.c | 55 +--
23 files changed, 1179 insertions(+), 188 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 4%]
* [PATCH v4 1/7] cryptodev: add APIs to get/set event metadata
2022-05-01 19:24 4% ` [PATCH v4 " Akhil Goyal
@ 2022-05-01 19:24 2% ` Akhil Goyal
2022-05-02 9:01 0% ` Anoob Joseph
2022-05-02 11:06 0% ` Gujjar, Abhinandan S
2022-05-02 11:08 0% ` [PATCH v4 0/7] Add new cryptodev op for " Gujjar, Abhinandan S
2022-05-12 12:45 4% ` [PATCH v5 " Akhil Goyal
2 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2022-05-01 19:24 UTC (permalink / raw)
To: dev
Cc: anoobj, jerinj, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, vfialko, Akhil Goyal, Fan Zhang
From: Volodymyr Fialko <vfialko@marvell.com>
Currently, crypto session userdata is used to set event crypto
metadata from the application and the driver is dereferencing it
in driver which is not correct. User data is meant to be opaque
to the driver.
To support this, new API is added to get and set event crypto
metadata. The new API, rte_cryptodev_set_session_event_mdata,
allows setting event metadata in session private data which is
filled inside PMD using a new cryptodev op. This operation
can be performed on any of the PMD supported sessions
(sym/asym/security).
For SW abstraction of event crypto adapter to be used by
eventdev library, a new field is added in asymmetric crypto
session for now and for symmetric case, current implementation
of using userdata is used. Symmetric cases cannot be fixed now,
as it will be ABI breakage which will be resolved in DPDK 22.11.
Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
---
lib/cryptodev/cryptodev_pmd.c | 16 +++++++++++++
lib/cryptodev/cryptodev_pmd.h | 36 ++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 44 +++++++++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.h | 22 ++++++++++++++++++
lib/cryptodev/version.map | 4 ++++
5 files changed, 122 insertions(+)
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 739a0b3f34..1903ade388 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -227,3 +227,19 @@ cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
fp_ops->qp.enq_cb = dev->enq_cbs;
fp_ops->qp.deq_cb = dev->deq_cbs;
}
+
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op)
+{
+ if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return rte_cryptodev_sym_session_get_user_data(op->sym->session);
+ else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return op->asym->session->event_mdata;
+ else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
+ op->private_data_offset)
+ return ((uint8_t *)op + op->private_data_offset);
+ else
+ return NULL;
+}
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 2b1ce2da2d..7a7d3ee3f1 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -398,6 +398,25 @@ typedef int (*cryptodev_sym_configure_raw_dp_ctx_t)(
enum rte_crypto_op_sess_type sess_type,
union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
+/**
+ * Typedef that the driver provided to set event crypto meta data.
+ *
+ * @param dev Crypto device pointer.
+ * @param sess Crypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdata Pointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @return
+ * - On success return 0.
+ * - On failure return negative integer.
+ */
+typedef int (*cryptodev_session_event_mdata_set_t)(
+ struct rte_cryptodev *dev, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata);
+
/** Crypto device operations function pointer table */
struct rte_cryptodev_ops {
cryptodev_configure_t dev_configure; /**< Configure device. */
@@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
/**< Initialize raw data path context data. */
};
};
+ cryptodev_session_event_mdata_set_t session_ev_mdata_set;
+ /**< Set a Crypto or Security session even meta data. */
};
@@ -603,6 +624,19 @@ void
cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
const struct rte_cryptodev *dev);
+/**
+ * Get session event meta data (aka *union rte_event_crypto_metadata*)
+ *
+ * @param op pointer to *rte_crypto_op* structure.
+ *
+ * @return
+ * - On success, pointer to event crypto metadata
+ * - On failure, NULL.
+ */
+__rte_internal
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
+
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
@@ -637,6 +671,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
uint16_t user_data_sz;
/**< Session user data will be placed after sess_data */
uint8_t padding[3];
+ void *event_mdata;
+ /**< Event metadata (aka *union rte_event_crypto_metadata*) */
uint8_t sess_private_data[0];
};
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 3500a2d470..5ebc423afa 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2051,6 +2051,9 @@ rte_cryptodev_asym_session_free(uint8_t dev_id, void *sess)
dev->dev_ops->asym_session_clear(dev, sess);
+ if (((struct rte_cryptodev_asym_session *)sess)->event_mdata != NULL)
+ rte_free(((struct rte_cryptodev_asym_session *)sess)->event_mdata);
+
/* Return session to mempool */
sess_mp = rte_mempool_from_obj(sess);
rte_mempool_put(sess_mp, sess);
@@ -2259,6 +2262,47 @@ rte_cryptodev_configure_raw_dp_ctx(uint8_t dev_id, uint16_t qp_id,
sess_type, session_ctx, is_update);
}
+int
+rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata,
+ uint16_t size)
+{
+ struct rte_cryptodev *dev;
+
+ if (sess == NULL || ev_mdata == NULL)
+ return -EINVAL;
+
+ if (!rte_cryptodev_is_valid_dev(dev_id))
+ goto skip_pmd_op;
+
+ dev = rte_cryptodev_pmd_get_dev(dev_id);
+ if (dev->dev_ops->session_ev_mdata_set == NULL)
+ goto skip_pmd_op;
+
+ return (*dev->dev_ops->session_ev_mdata_set)(dev, sess, op_type,
+ sess_type, ev_mdata);
+
+skip_pmd_op:
+ if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+ return rte_cryptodev_sym_session_set_user_data(sess, ev_mdata,
+ size);
+ else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
+ struct rte_cryptodev_asym_session *s = sess;
+
+ if (s->event_mdata == NULL) {
+ s->event_mdata = rte_malloc(NULL, size, 0);
+ if (s->event_mdata == NULL)
+ return -ENOMEM;
+ }
+ rte_memcpy(s->event_mdata, ev_mdata, size);
+
+ return 0;
+ } else
+ return -ENOTSUP;
+}
+
uint32_t
rte_cryptodev_raw_enqueue_burst(struct rte_crypto_raw_dp_ctx *ctx,
struct rte_crypto_sym_vec *vec, union rte_crypto_sym_ofs ofs,
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 45d33f4a50..2c2c2edeb7 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -1269,6 +1269,28 @@ __rte_experimental
int
rte_cryptodev_get_raw_dp_ctx_size(uint8_t dev_id);
+/**
+ * Set session event meta data
+ *
+ * @param dev_id The device identifier.
+ * @param sess Crypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdata Pointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @param size Size of ev_mdata.
+ *
+ * @return
+ * - On success, zero.
+ * - On failure, a negative value.
+ */
+__rte_experimental
+int
+rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata, uint16_t size);
+
/**
* Union of different crypto session types, including session-less xform
* pointer.
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index c7c5aefceb..f0abfaa47d 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -105,6 +105,9 @@ EXPERIMENTAL {
rte_cryptodev_asym_session_pool_create;
rte_cryptodev_asym_session_set_user_data;
__rte_cryptodev_trace_asym_session_pool_create;
+
+ #added in 22.07
+ rte_cryptodev_session_event_mdata_set;
};
INTERNAL {
@@ -123,5 +126,6 @@ INTERNAL {
rte_cryptodev_pmd_parse_input_args;
rte_cryptodev_pmd_probing_finish;
rte_cryptodev_pmd_release_device;
+ rte_cryptodev_session_event_mdata_get;
rte_cryptodevs;
};
--
2.25.1
^ permalink raw reply [relevance 2%]
* RE: [PATCH v4 1/7] cryptodev: add APIs to get/set event metadata
2022-05-01 19:24 2% ` [PATCH v4 1/7] cryptodev: add APIs to get/set " Akhil Goyal
@ 2022-05-02 9:01 0% ` Anoob Joseph
2022-05-02 11:06 0% ` Gujjar, Abhinandan S
1 sibling, 0 replies; 200+ results
From: Anoob Joseph @ 2022-05-02 9:01 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: Jerin Jacob Kollanukkaran, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, Volodymyr Fialko, Akhil Goyal, Fan Zhang
Hi Akhil,
Minor nit inline.
With that addressed,
Series Acked-by: Anoob Joseph <anoobj@marvell.com>
Thanks,
Anoob
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, May 2, 2022 12:55 AM
> To: dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; abhinandan.gujjar@intel.com;
> jay.jayatheerthan@intel.com; narender.vangati@intel.com; Volodymyr
> Fialko <vfialko@marvell.com>; Akhil Goyal <gakhil@marvell.com>; Fan Zhang
> <roy.fan.zhang@intel.com>
> Subject: [PATCH v4 1/7] cryptodev: add APIs to get/set event metadata
>
> From: Volodymyr Fialko <vfialko@marvell.com>
>
> Currently, crypto session userdata is used to set event crypto metadata from
> the application and the driver is dereferencing it in driver which is not correct.
> User data is meant to be opaque to the driver.
> To support this, new API is added to get and set event crypto metadata. The
> new API, rte_cryptodev_set_session_event_mdata,
> allows setting event metadata in session private data which is filled inside
> PMD using a new cryptodev op. This operation can be performed on any of
> the PMD supported sessions (sym/asym/security).
> For SW abstraction of event crypto adapter to be used by eventdev library, a
> new field is added in asymmetric crypto session for now and for symmetric
> case, current implementation of using userdata is used. Symmetric cases
> cannot be fixed now, as it will be ABI breakage which will be resolved in DPDK
> 22.11.
>
> Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> ---
> lib/cryptodev/cryptodev_pmd.c | 16 +++++++++++++
> lib/cryptodev/cryptodev_pmd.h | 36 ++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.c | 44
> +++++++++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.h | 22 ++++++++++++++++++
> lib/cryptodev/version.map | 4 ++++
> 5 files changed, 122 insertions(+)
>
[snip]
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> index 3500a2d470..5ebc423afa 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -2051,6 +2051,9 @@ rte_cryptodev_asym_session_free(uint8_t dev_id,
> void *sess)
>
> dev->dev_ops->asym_session_clear(dev, sess);
>
> + if (((struct rte_cryptodev_asym_session *)sess)->event_mdata !=
> NULL)
> + rte_free(((struct rte_cryptodev_asym_session *)sess)-
> >event_mdata);
> +
[Anoob] rte_free would do a NULL check. So the other NULL check may not be required.
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4 1/7] cryptodev: add APIs to get/set event metadata
2022-05-01 19:24 2% ` [PATCH v4 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-05-02 9:01 0% ` Anoob Joseph
@ 2022-05-02 11:06 0% ` Gujjar, Abhinandan S
1 sibling, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2022-05-02 11:06 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: anoobj, jerinj, Jayatheerthan, Jay, Vangati, Narender, vfialko,
Zhang, Roy Fan
Acked-by: Abhinandan Gujjar <Abhinandan.gujjar@intel.com>
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, May 2, 2022 12:55 AM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; vfialko@marvell.com; Akhil Goyal
> <gakhil@marvell.com>; Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: [PATCH v4 1/7] cryptodev: add APIs to get/set event metadata
>
> From: Volodymyr Fialko <vfialko@marvell.com>
>
> Currently, crypto session userdata is used to set event crypto metadata from
> the application and the driver is dereferencing it in driver which is not correct.
> User data is meant to be opaque to the driver.
> To support this, new API is added to get and set event crypto metadata. The
> new API, rte_cryptodev_set_session_event_mdata,
> allows setting event metadata in session private data which is filled inside PMD
> using a new cryptodev op. This operation can be performed on any of the PMD
> supported sessions (sym/asym/security).
> For SW abstraction of event crypto adapter to be used by eventdev library, a
> new field is added in asymmetric crypto session for now and for symmetric
> case, current implementation of using userdata is used. Symmetric cases cannot
> be fixed now, as it will be ABI breakage which will be resolved in DPDK 22.11.
>
> Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> ---
> lib/cryptodev/cryptodev_pmd.c | 16 +++++++++++++
> lib/cryptodev/cryptodev_pmd.h | 36 ++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.c | 44 +++++++++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.h | 22 ++++++++++++++++++
> lib/cryptodev/version.map | 4 ++++
> 5 files changed, 122 insertions(+)
>
> diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
> index 739a0b3f34..1903ade388 100644
> --- a/lib/cryptodev/cryptodev_pmd.c
> +++ b/lib/cryptodev/cryptodev_pmd.c
> @@ -227,3 +227,19 @@ cryptodev_fp_ops_set(struct rte_crypto_fp_ops
> *fp_ops,
> fp_ops->qp.enq_cb = dev->enq_cbs;
> fp_ops->qp.deq_cb = dev->deq_cbs;
> }
> +
> +void *
> +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op) {
> + if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
> + op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> + return rte_cryptodev_sym_session_get_user_data(op->sym-
> >session);
> + else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
> + op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> + return op->asym->session->event_mdata;
> + else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
> + op->private_data_offset)
> + return ((uint8_t *)op + op->private_data_offset);
> + else
> + return NULL;
> +}
> diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
> index 2b1ce2da2d..7a7d3ee3f1 100644
> --- a/lib/cryptodev/cryptodev_pmd.h
> +++ b/lib/cryptodev/cryptodev_pmd.h
> @@ -398,6 +398,25 @@ typedef int
> (*cryptodev_sym_configure_raw_dp_ctx_t)(
> enum rte_crypto_op_sess_type sess_type,
> union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
>
> +/**
> + * Typedef that the driver provided to set event crypto meta data.
> + *
> + * @param dev Crypto device pointer.
> + * @param sess Crypto or security session.
> + * @param op_type Operation type.
> + * @param sess_type Session type.
> + * @param ev_mdata Pointer to the event crypto meta data
> + * (aka *union rte_event_crypto_metadata*)
> + * @return
> + * - On success return 0.
> + * - On failure return negative integer.
> + */
> +typedef int (*cryptodev_session_event_mdata_set_t)(
> + struct rte_cryptodev *dev, void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *ev_mdata);
> +
> /** Crypto device operations function pointer table */ struct
> rte_cryptodev_ops {
> cryptodev_configure_t dev_configure; /**< Configure device. */
> @@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
> /**< Initialize raw data path context data. */
> };
> };
> + cryptodev_session_event_mdata_set_t session_ev_mdata_set;
> + /**< Set a Crypto or Security session even meta data. */
> };
>
>
> @@ -603,6 +624,19 @@ void
> cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
> const struct rte_cryptodev *dev);
>
> +/**
> + * Get session event meta data (aka *union rte_event_crypto_metadata*)
> + *
> + * @param op pointer to *rte_crypto_op* structure.
> + *
> + * @return
> + * - On success, pointer to event crypto metadata
> + * - On failure, NULL.
> + */
> +__rte_internal
> +void *
> +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
> +
> static inline void *
> get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
> uint8_t driver_id) {
> @@ -637,6 +671,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
> uint16_t user_data_sz;
> /**< Session user data will be placed after sess_data */
> uint8_t padding[3];
> + void *event_mdata;
> + /**< Event metadata (aka *union rte_event_crypto_metadata*) */
> uint8_t sess_private_data[0];
> };
>
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c index
> 3500a2d470..5ebc423afa 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -2051,6 +2051,9 @@ rte_cryptodev_asym_session_free(uint8_t dev_id,
> void *sess)
>
> dev->dev_ops->asym_session_clear(dev, sess);
>
> + if (((struct rte_cryptodev_asym_session *)sess)->event_mdata != NULL)
> + rte_free(((struct rte_cryptodev_asym_session *)sess)-
> >event_mdata);
> +
> /* Return session to mempool */
> sess_mp = rte_mempool_from_obj(sess);
> rte_mempool_put(sess_mp, sess);
> @@ -2259,6 +2262,47 @@ rte_cryptodev_configure_raw_dp_ctx(uint8_t
> dev_id, uint16_t qp_id,
> sess_type, session_ctx, is_update);
> }
>
> +int
> +rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *ev_mdata,
> + uint16_t size)
> +{
> + struct rte_cryptodev *dev;
> +
> + if (sess == NULL || ev_mdata == NULL)
> + return -EINVAL;
> +
> + if (!rte_cryptodev_is_valid_dev(dev_id))
> + goto skip_pmd_op;
> +
> + dev = rte_cryptodev_pmd_get_dev(dev_id);
> + if (dev->dev_ops->session_ev_mdata_set == NULL)
> + goto skip_pmd_op;
> +
> + return (*dev->dev_ops->session_ev_mdata_set)(dev, sess, op_type,
> + sess_type, ev_mdata);
> +
> +skip_pmd_op:
> + if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC)
> + return rte_cryptodev_sym_session_set_user_data(sess,
> ev_mdata,
> + size);
> + else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
> + struct rte_cryptodev_asym_session *s = sess;
> +
> + if (s->event_mdata == NULL) {
> + s->event_mdata = rte_malloc(NULL, size, 0);
> + if (s->event_mdata == NULL)
> + return -ENOMEM;
> + }
> + rte_memcpy(s->event_mdata, ev_mdata, size);
> +
> + return 0;
> + } else
> + return -ENOTSUP;
> +}
> +
> uint32_t
> rte_cryptodev_raw_enqueue_burst(struct rte_crypto_raw_dp_ctx *ctx,
> struct rte_crypto_sym_vec *vec, union rte_crypto_sym_ofs ofs, diff --
> git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h index
> 45d33f4a50..2c2c2edeb7 100644
> --- a/lib/cryptodev/rte_cryptodev.h
> +++ b/lib/cryptodev/rte_cryptodev.h
> @@ -1269,6 +1269,28 @@ __rte_experimental int
> rte_cryptodev_get_raw_dp_ctx_size(uint8_t dev_id);
>
> +/**
> + * Set session event meta data
> + *
> + * @param dev_id The device identifier.
> + * @param sess Crypto or security session.
> + * @param op_type Operation type.
> + * @param sess_type Session type.
> + * @param ev_mdata Pointer to the event crypto meta data
> + * (aka *union rte_event_crypto_metadata*)
> + * @param size Size of ev_mdata.
> + *
> + * @return
> + * - On success, zero.
> + * - On failure, a negative value.
> + */
> +__rte_experimental
> +int
> +rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *ev_mdata, uint16_t size);
> +
> /**
> * Union of different crypto session types, including session-less xform
> * pointer.
> diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map index
> c7c5aefceb..f0abfaa47d 100644
> --- a/lib/cryptodev/version.map
> +++ b/lib/cryptodev/version.map
> @@ -105,6 +105,9 @@ EXPERIMENTAL {
> rte_cryptodev_asym_session_pool_create;
> rte_cryptodev_asym_session_set_user_data;
> __rte_cryptodev_trace_asym_session_pool_create;
> +
> + #added in 22.07
> + rte_cryptodev_session_event_mdata_set;
> };
>
> INTERNAL {
> @@ -123,5 +126,6 @@ INTERNAL {
> rte_cryptodev_pmd_parse_input_args;
> rte_cryptodev_pmd_probing_finish;
> rte_cryptodev_pmd_release_device;
> + rte_cryptodev_session_event_mdata_get;
> rte_cryptodevs;
> };
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4 0/7] Add new cryptodev op for event metadata
2022-05-01 19:24 4% ` [PATCH v4 " Akhil Goyal
2022-05-01 19:24 2% ` [PATCH v4 1/7] cryptodev: add APIs to get/set " Akhil Goyal
@ 2022-05-02 11:08 0% ` Gujjar, Abhinandan S
2022-05-12 12:45 4% ` [PATCH v5 " Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2022-05-02 11:08 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: anoobj, jerinj, Jayatheerthan, Jay, Vangati, Narender, vfialko
Acked-by: Abhinandan Gujjar <Abhinandan.gujjar@intel.com>
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, May 2, 2022 12:55 AM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; vfialko@marvell.com; Akhil Goyal
> <gakhil@marvell.com>
> Subject: [PATCH v4 0/7] Add new cryptodev op for event metadata
>
> For using event crypto metadata, event metadata need to be set in session. For
> this session user data was used for symmetric crypto sessions and no support
> was present for asymmetric and security sessions.
> The use of userdata to store event metadata (which is dereferenced in PMD) is
> not correct as it is meant for the application to use it.
> Hence, a new API is created to set and get event crypto metadata which is
> scalable to all sessions supported by the crypto PMD.
> The application can use the set API to set event metadata and the PMD may
> store that inside the session private data and PMD need not use the get API as
> it would be internal to the PMD.
> For the software event crypto adapter implementation, the eventdev library
> can use the get API to get the event metadata stored inside the session
> structure.
> For Asymmetric sessions, a new field is added inside the session struct which is
> internal to library.
> For symmetric and security sessions, new field cannot be added as it would be
> ABI break. Hence, session userdata is being used to store that as it was used
> earlier. In next ABI break release this would be fixed similar to asymmetric
> crypto case.
>
> The patchset also add support for asymmetric crypto adapter in the test
> applications and the crypto/cnxk implementation of the new cryptodev op and
> corresponding changes in the eventdev lib.
>
> Changes in v4:
> - added null checks in set API
> - updated check in session destroy
> - updated API comments
> - fixed test app failure reported by Abhinandan.
> - moved event mdata after padding in asym session struct.
>
> Changes in v3:
> - fix SW adapter case of memory allocation/free of mdata. mdata is allocated in
> set API and freed in session clear/destroy.
> - mark rte_cryptodev_session_event_mdata_get as internal API as it is only
> needed for the app or the PMD.
>
> changes in v2:
> - v1 patchset only fixed security sessions and also caused ABI breakage.
> This is fixed in v2.
> - added new API for setting event metadata.
> - added new cryptodev op which can handle all sessions
>
>
> Akhil Goyal (5):
> crypto/octeontx: use new API for event metadata
> test/event: use new API to set event crypto metadata
> eventdev: use new API to get event crypto metadata
> test/event: add asymmetric cases for crypto adapter
> test-eventdev: support asym ops for crypto adapter
>
> Volodymyr Fialko (2):
> cryptodev: add APIs to get/set event metadata
> crypto/cnxk: add event metadata set operation
>
> app/test-eventdev/evt_common.h | 2 +
> app/test-eventdev/evt_options.c | 17 +
> app/test-eventdev/evt_options.h | 4 +
> app/test-eventdev/test_perf_atq.c | 12 +-
> app/test-eventdev/test_perf_common.c | 254 ++++++++--
> app/test-eventdev/test_perf_common.h | 45 +-
> app/test-eventdev/test_perf_queue.c | 12 +-
> app/test/test_event_crypto_adapter.c | 511 +++++++++++++++++++-
> doc/guides/tools/testeventdev.rst | 5 +
> drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++++-
> drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
> drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 +++++-
> drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
> drivers/crypto/cnxk/cnxk_ae.h | 2 +
> drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 -
> drivers/crypto/cnxk/cnxk_se.h | 2 +
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +-
> lib/cryptodev/cryptodev_pmd.c | 16 +
> lib/cryptodev/cryptodev_pmd.h | 36 ++
> lib/cryptodev/rte_cryptodev.c | 44 ++
> lib/cryptodev/rte_cryptodev.h | 22 +
> lib/cryptodev/version.map | 4 +
> lib/eventdev/rte_event_crypto_adapter.c | 55 +--
> 23 files changed, 1179 insertions(+), 188 deletions(-)
>
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* [PATCH v2 2/2] ci: build some job with ASan
@ 2022-05-05 9:29 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-05-05 9:29 UTC (permalink / raw)
To: dev; +Cc: john.mcnamara, Aaron Conole, Michael Santana
Enable ASan, this can greatly help identify leaks and buffer overflows.
Running unit tests relying on multiprocess is unreliable with ASan
enabled, so skip them.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v1:
- reinstated table_autotest in "ASan-safe" list of ut,
---
.ci/linux-build.sh | 8 ++
.github/workflows/build.yml | 3 +-
app/test/meson.build | 208 +++++++++++++++++++-----------------
3 files changed, 118 insertions(+), 101 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 774a1441bf..93706c0131 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -95,6 +95,14 @@ if [ "$MINI" = "true" ]; then
OPTS="$OPTS -Denable_drivers=net/null"
OPTS="$OPTS -Ddisable_libs=*"
fi
+
+if [ "$ASAN" = "true" ]; then
+ OPTS="$OPTS -Db_sanitize=address"
+ if [ "${CC%%clang}" != "$CC" ]; then
+ OPTS="$OPTS -Db_lundef=false"
+ fi
+fi
+
meson build --werror $OPTS
ninja -C build
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 22daaabb91..45871e76ed 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -16,6 +16,7 @@ jobs:
env:
AARCH64: ${{ matrix.config.cross == 'aarch64' }}
ABI_CHECKS: ${{ contains(matrix.config.checks, 'abi') }}
+ ASAN: ${{ contains(matrix.config.checks, 'asan') }}
BUILD_32BIT: ${{ matrix.config.cross == 'i386' }}
BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
CC: ccache ${{ matrix.config.compiler }}
@@ -47,7 +48,7 @@ jobs:
- os: ubuntu-18.04
compiler: clang
library: shared
- checks: doc+tests
+ checks: asan+doc+tests
- os: ubuntu-18.04
compiler: gcc
library: static
diff --git a/app/test/meson.build b/app/test/meson.build
index 5fc1dd1b7b..bb4621ed2a 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -149,96 +149,97 @@ test_deps = enabled_libs
# as well as libs, the pci and vdev bus drivers are needed for a lot of tests
test_deps += ['bus_pci', 'bus_vdev']
-# Each test is marked with flag true/false
-# to indicate whether it can run in no-huge mode.
+# Each test is marked with flags:
+# - the first flag indicates whether the test can run in no-huge mode,
+# - the second flag indicates whether the test can run with ASan enabled,
fast_tests = [
- ['acl_autotest', true],
- ['atomic_autotest', false],
- ['bitmap_autotest', true],
- ['bpf_autotest', true],
- ['bpf_convert_autotest', true],
- ['bitops_autotest', true],
- ['byteorder_autotest', true],
- ['cksum_autotest', true],
- ['cmdline_autotest', true],
- ['common_autotest', true],
- ['cpuflags_autotest', true],
- ['debug_autotest', true],
- ['devargs_autotest', true],
- ['eal_flags_c_opt_autotest', false],
- ['eal_flags_main_opt_autotest', false],
- ['eal_flags_n_opt_autotest', false],
- ['eal_flags_hpet_autotest', false],
- ['eal_flags_no_huge_autotest', false],
- ['eal_flags_a_opt_autotest', false],
- ['eal_flags_b_opt_autotest', false],
- ['eal_flags_vdev_opt_autotest', false],
- ['eal_flags_r_opt_autotest', false],
- ['eal_flags_mem_autotest', false],
- ['eal_flags_file_prefix_autotest', false],
- ['eal_flags_misc_autotest', false],
- ['eal_fs_autotest', true],
- ['errno_autotest', true],
- ['ethdev_link_status', true],
- ['event_ring_autotest', true],
- ['fib_autotest', true],
- ['fib6_autotest', true],
- ['func_reentrancy_autotest', false],
- ['hash_autotest', true],
- ['interrupt_autotest', true],
- ['ipfrag_autotest', false],
- ['lcores_autotest', true],
- ['logs_autotest', true],
- ['lpm_autotest', true],
- ['lpm6_autotest', true],
- ['malloc_autotest', false],
- ['mbuf_autotest', false],
- ['mcslock_autotest', false],
- ['memcpy_autotest', true],
- ['memory_autotest', false],
- ['mempool_autotest', false],
- ['memzone_autotest', false],
- ['meter_autotest', true],
- ['multiprocess_autotest', false],
- ['per_lcore_autotest', true],
- ['pflock_autotest', true],
- ['prefetch_autotest', true],
- ['rcu_qsbr_autotest', true],
- ['pie_autotest', true],
- ['rib_autotest', true],
- ['rib6_autotest', true],
- ['ring_autotest', true],
- ['rwlock_test1_autotest', true],
- ['rwlock_rda_autotest', true],
- ['rwlock_rds_wrm_autotest', true],
- ['rwlock_rde_wro_autotest', true],
- ['sched_autotest', true],
- ['security_autotest', false],
- ['spinlock_autotest', true],
- ['stack_autotest', false],
- ['stack_lf_autotest', false],
- ['string_autotest', true],
- ['tailq_autotest', true],
- ['ticketlock_autotest', true],
- ['timer_autotest', false],
- ['user_delay_us', true],
- ['version_autotest', true],
- ['crc_autotest', true],
- ['distributor_autotest', false],
- ['eventdev_common_autotest', true],
- ['fbarray_autotest', true],
- ['hash_readwrite_func_autotest', false],
- ['ipsec_autotest', true],
- ['kni_autotest', false],
- ['kvargs_autotest', true],
- ['member_autotest', true],
- ['power_cpufreq_autotest', false],
- ['power_autotest', true],
- ['power_kvm_vm_autotest', false],
- ['reorder_autotest', true],
- ['service_autotest', true],
- ['thash_autotest', true],
- ['trace_autotest', true],
+ ['acl_autotest', true, true],
+ ['atomic_autotest', false, true],
+ ['bitmap_autotest', true, true],
+ ['bpf_autotest', true, true],
+ ['bpf_convert_autotest', true, true],
+ ['bitops_autotest', true, true],
+ ['byteorder_autotest', true, true],
+ ['cksum_autotest', true, true],
+ ['cmdline_autotest', true, true],
+ ['common_autotest', true, true],
+ ['cpuflags_autotest', true, true],
+ ['debug_autotest', true, true],
+ ['devargs_autotest', true, true],
+ ['eal_flags_c_opt_autotest', false, false],
+ ['eal_flags_main_opt_autotest', false, false],
+ ['eal_flags_n_opt_autotest', false, false],
+ ['eal_flags_hpet_autotest', false, false],
+ ['eal_flags_no_huge_autotest', false, false],
+ ['eal_flags_a_opt_autotest', false, false],
+ ['eal_flags_b_opt_autotest', false, false],
+ ['eal_flags_vdev_opt_autotest', false, false],
+ ['eal_flags_r_opt_autotest', false, false],
+ ['eal_flags_mem_autotest', false, false],
+ ['eal_flags_file_prefix_autotest', false, false],
+ ['eal_flags_misc_autotest', false, false],
+ ['eal_fs_autotest', true, true],
+ ['errno_autotest', true, true],
+ ['ethdev_link_status', true, true],
+ ['event_ring_autotest', true, true],
+ ['fib_autotest', true, true],
+ ['fib6_autotest', true, true],
+ ['func_reentrancy_autotest', false, true],
+ ['hash_autotest', true, true],
+ ['interrupt_autotest', true, true],
+ ['ipfrag_autotest', false, true],
+ ['lcores_autotest', true, true],
+ ['logs_autotest', true, true],
+ ['lpm_autotest', true, true],
+ ['lpm6_autotest', true, true],
+ ['malloc_autotest', false, true],
+ ['mbuf_autotest', false, true],
+ ['mcslock_autotest', false, true],
+ ['memcpy_autotest', true, true],
+ ['memory_autotest', false, true],
+ ['mempool_autotest', false, true],
+ ['memzone_autotest', false, true],
+ ['meter_autotest', true, true],
+ ['multiprocess_autotest', false, false],
+ ['per_lcore_autotest', true, true],
+ ['pflock_autotest', true, true],
+ ['prefetch_autotest', true, true],
+ ['rcu_qsbr_autotest', true, true],
+ ['pie_autotest', true, true],
+ ['rib_autotest', true, true],
+ ['rib6_autotest', true, true],
+ ['ring_autotest', true, true],
+ ['rwlock_test1_autotest', true, true],
+ ['rwlock_rda_autotest', true, true],
+ ['rwlock_rds_wrm_autotest', true, true],
+ ['rwlock_rde_wro_autotest', true, true],
+ ['sched_autotest', true, true],
+ ['security_autotest', false, true],
+ ['spinlock_autotest', true, true],
+ ['stack_autotest', false, true],
+ ['stack_lf_autotest', false, true],
+ ['string_autotest', true, true],
+ ['tailq_autotest', true, true],
+ ['ticketlock_autotest', true, true],
+ ['timer_autotest', false, true],
+ ['user_delay_us', true, true],
+ ['version_autotest', true, true],
+ ['crc_autotest', true, true],
+ ['distributor_autotest', false, true],
+ ['eventdev_common_autotest', true, true],
+ ['fbarray_autotest', true, true],
+ ['hash_readwrite_func_autotest', false, true],
+ ['ipsec_autotest', true, true],
+ ['kni_autotest', false, true],
+ ['kvargs_autotest', true, true],
+ ['member_autotest', true, true],
+ ['power_cpufreq_autotest', false, true],
+ ['power_autotest', true, true],
+ ['power_kvm_vm_autotest', false, true],
+ ['reorder_autotest', true, true],
+ ['service_autotest', true, true],
+ ['thash_autotest', true, true],
+ ['trace_autotest', true, true],
]
# Tests known to have issues or which don't belong in other tests lists.
@@ -345,15 +346,16 @@ endif
if dpdk_conf.has('RTE_LIB_FLOW_CLASSIFY')
test_sources += 'test_flow_classify.c'
- fast_tests += [['flow_classify_autotest', false]]
+ fast_tests += [['flow_classify_autotest', false, true]]
endif
if dpdk_conf.has('RTE_LIB_METRICS')
test_sources += ['test_metrics.c']
- fast_tests += [['metrics_autotest', true]]
+ fast_tests += [['metrics_autotest', true, true]]
endif
if not is_windows and dpdk_conf.has('RTE_LIB_TELEMETRY')
test_sources += ['test_telemetry_json.c', 'test_telemetry_data.c']
- fast_tests += [['telemetry_json_autotest', true], ['telemetry_data_autotest', true]]
+ fast_tests += [['telemetry_json_autotest', true, true]]
+ fast_tests += [['telemetry_data_autotest', true, true]]
endif
if dpdk_conf.has('RTE_LIB_PIPELINE')
# pipeline lib depends on port and table libs, so those must be present
@@ -366,7 +368,7 @@ if dpdk_conf.has('RTE_LIB_PIPELINE')
'test_table_ports.c',
'test_table_tables.c',
]
- fast_tests += [['table_autotest', true]]
+ fast_tests += [['table_autotest', true, true]]
endif
# The following linkages of drivers are required because
@@ -386,26 +388,26 @@ if dpdk_conf.has('RTE_NET_RING')
test_sources += 'test_pmd_ring.c'
test_sources += 'test_event_eth_tx_adapter.c'
test_sources += 'sample_packet_forward.c'
- fast_tests += [['ring_pmd_autotest', true]]
+ fast_tests += [['ring_pmd_autotest', true, true]]
perf_test_names += 'ring_pmd_perf_autotest'
- fast_tests += [['event_eth_tx_adapter_autotest', false]]
+ fast_tests += [['event_eth_tx_adapter_autotest', false, true]]
if dpdk_conf.has('RTE_LIB_BITRATESTATS')
test_sources += 'test_bitratestats.c'
- fast_tests += [['bitratestats_autotest', true]]
+ fast_tests += [['bitratestats_autotest', true, true]]
endif
if dpdk_conf.has('RTE_LIB_LATENCYSTATS')
test_sources += 'test_latencystats.c'
- fast_tests += [['latencystats_autotest', true]]
+ fast_tests += [['latencystats_autotest', true, true]]
endif
if dpdk_conf.has('RTE_LIB_PDUMP')
test_sources += 'test_pdump.c'
- fast_tests += [['pdump_autotest', true]]
+ fast_tests += [['pdump_autotest', true, false]]
endif
endif
if dpdk_conf.has('RTE_NET_NULL')
test_deps += 'net_null'
test_sources += 'test_vdev.c'
- fast_tests += [['vdev_autotest', true]]
+ fast_tests += [['vdev_autotest', true, true]]
endif
if dpdk_conf.has('RTE_HAS_LIBPCAP')
@@ -431,7 +433,7 @@ if dpdk_conf.has('RTE_LIB_COMPRESSDEV')
if compress_test_dep.found()
test_dep_objs += compress_test_dep
test_sources += 'test_compressdev.c'
- fast_tests += [['compressdev_autotest', false]]
+ fast_tests += [['compressdev_autotest', false, true]]
endif
endif
@@ -478,6 +480,12 @@ foreach arg : fast_tests
endif
endif
+ if get_option('b_sanitize') == 'address' or get_option('b_sanitize') == 'address,undefined'
+ if not arg[2]
+ run_test = false
+ endif
+ endif
+
if (get_option('default_library') == 'shared' and
arg[0] == 'event_eth_tx_adapter_autotest')
foreach drv:dpdk_drivers
--
2.23.0
^ permalink raw reply [relevance 3%]
* [PATCH 0/6] Vhost checksum offload improvements
@ 2022-05-05 10:27 3% Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2022-05-05 10:27 UTC (permalink / raw)
To: dev, jasowang, chenbo.xia, david.marchand, olivier.matz
Cc: stable, Maxime Coquelin
This series aims at improving Vhost checksum offloading
support.
The first patch reverts overwritting MAC address in
testpmd CSUM forward mode. This is required to be able to
test checksum offloading with real traffic. MAC forwarding
mode should be used if the MAC addresses need to be
changed.
Second patch is a Vhost library fix to be compliant with
the Virtio specification, which requires that the
pseudo-header checksum is being set by the device when
offloading the checksum to the guest.
Third patch enables the compliant offloading mode of Vhost
library in Vhost PMD by default, since the legacy mode
violates the mbuf API by setting Tx flags in the receive
path. A new devarg is introduced for application willing
to use the legacy mode.
Fourth patch is just a small cleanup to represent a boolean
value as a boolean.
The two last patches introduces compatibility layers
that performs checksum in SW when the ethdev and Virtio
features are not aligned.
Note that the two last patches are not tagged as fixes
because they rely on the new compliant offload mode of
Vhost library, and so would casue an ABI breakage if
backported.
With this series, it is now possible to perform IO
forwarding between a vhost-user port and a Vitio-user
with kernel backend port even if the guest has negotiated
VIRTIO_NET_F_CSUM.
With csum forward mode, it now works whathever the
offloading configuration set either on Virtio or Ethdev
sides.
Maxime Coquelin (6):
Revert "app/testpmd: modify mac in csum forwarding"
vhost: fix missing enqueue pseudo-header calculation
net/vhost: enable compliant offloading mode
net/vhost: make VLAN stripping flag a boolean
net/vhost: perform SW checksum in Rx path
net/vhost: perform SW checksum in Tx path
app/test-pmd/csumonly.c | 4 -
doc/guides/nics/features/vhost.ini | 1 +
doc/guides/nics/vhost.rst | 6 ++
drivers/net/vhost/rte_eth_vhost.c | 166 ++++++++++++++++++++++++++++-
lib/vhost/virtio_net.c | 10 ++
5 files changed, 179 insertions(+), 8 deletions(-)
--
2.35.1
^ permalink raw reply [relevance 3%]
* [PATCH 10/11] devtools: add RISC-V to test-meson-builds.sh
@ 2022-05-05 17:30 9% ` Stanislaw Kardach
1 sibling, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-05-05 17:30 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
---
devtools/test-meson-builds.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..12513e9d7f 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,12 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configurations
+for f in $srcdir/config/riscv/riscv* ; do
+ targetdir=build-$(basename $f | tr '_' '-' | cut -d'-' -f-2)
+ build $targetdir $f ABI $use_shared
+done
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* [PATCH v2 1/2] ci: switch to Ubuntu 20.04
2022-04-26 7:18 4% [PATCH 1/2] ci: switch to Ubuntu 20.04 David Marchand
@ 2022-05-06 11:57 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-05-06 11:57 UTC (permalink / raw)
To: dev
Cc: Aaron Conole, Michael Santana, Ruifeng Wang, Jan Viktorin,
Bruce Richardson, David Christensen
Ubuntu 18.04 is now rather old.
Besides, other entities in our CI are also testing this distribution.
Switch to a newer Ubuntu release and benefit from more recent
tool(chain)s: for example, net/cnxk now builds fine and can be
re-enabled.
Note: Ubuntu 18.04 and 20.04 seem to preserve the same paths for the ARM
and PPC cross compilation toolchains, so we can use a single
configuration file (with the hope, future releases of Ubuntu will do the
same).
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
---
Changes since v1:
- renamed ubuntu cross compilation configs for ARM and PPC,
---
.ci/linux-build.sh | 7 ++----
.github/workflows/build.yml | 22 +++++++++----------
...ntu1804 => arm64_armv8_linux_clang_ubuntu} | 0
...tu1804 => ppc64le-power8-linux-gcc-ubuntu} | 0
4 files changed, 12 insertions(+), 17 deletions(-)
rename config/arm/{arm64_armv8_linux_clang_ubuntu1804 => arm64_armv8_linux_clang_ubuntu} (100%)
rename config/ppc/{ppc64le-power8-linux-gcc-ubuntu1804 => ppc64le-power8-linux-gcc-ubuntu} (100%)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 774a1441bf..2dea0c93fa 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -57,18 +57,15 @@ catch_coredump() {
}
if [ "$AARCH64" = "true" ]; then
- # Note: common/cnxk is disabled for Ubuntu 18.04
- # https://bugs.dpdk.org/show_bug.cgi?id=697
- OPTS="$OPTS -Ddisable_drivers=common/cnxk"
if [ "${CC%%clang}" != "$CC" ]; then
- OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_clang_ubuntu1804"
+ OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_clang_ubuntu"
else
OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_gcc"
fi
fi
if [ "$PPC64LE" = "true" ]; then
- OPTS="$OPTS --cross-file config/ppc/ppc64le-power8-linux-gcc-ubuntu1804"
+ OPTS="$OPTS --cross-file config/ppc/ppc64le-power8-linux-gcc-ubuntu"
fi
if [ "$BUILD_DOCS" = "true" ]; then
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 22daaabb91..812aa7055d 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -30,43 +30,41 @@ jobs:
fail-fast: false
matrix:
config:
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
mini: mini
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
checks: abi+doc+tests
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: clang
library: static
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: clang
library: shared
checks: doc+tests
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
cross: i386
- # Note: common/cnxk is disabled for Ubuntu 18.04
- # https://bugs.dpdk.org/show_bug.cgi?id=697
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
cross: aarch64
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
cross: aarch64
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: static
cross: ppc64le
- - os: ubuntu-18.04
+ - os: ubuntu-20.04
compiler: gcc
library: shared
cross: ppc64le
diff --git a/config/arm/arm64_armv8_linux_clang_ubuntu1804 b/config/arm/arm64_armv8_linux_clang_ubuntu
similarity index 100%
rename from config/arm/arm64_armv8_linux_clang_ubuntu1804
rename to config/arm/arm64_armv8_linux_clang_ubuntu
diff --git a/config/ppc/ppc64le-power8-linux-gcc-ubuntu1804 b/config/ppc/ppc64le-power8-linux-gcc-ubuntu
similarity index 100%
rename from config/ppc/ppc64le-power8-linux-gcc-ubuntu1804
rename to config/ppc/ppc64le-power8-linux-gcc-ubuntu
--
2.23.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 2/6] eventdev: add weight and affinity to queue attributes
@ 2022-05-09 12:46 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-05-09 12:46 UTC (permalink / raw)
To: Shijith Thotton
Cc: dpdk-dev, Jerin Jacob, Pavan Nikhilesh, Van Haaren, Harry,
Mattias Rönnblom
On Tue, Apr 5, 2022 at 11:11 AM Shijith Thotton <sthotton@marvell.com> wrote:
>
> Extended eventdev queue QoS attributes to support weight and affinity.
> If queues are of same priority, events from the queue with highest
the same priority
> weight will be scheduled first. Affinity indicates the number of times,
> the subsequent schedule calls from an event port will use the same event
> queue. Schedule call selects another queue if current queue goes empty
> or schedule count reaches affinity count.
>
> To avoid ABI break, weight and affinity attributes are not yet added to
> queue config structure and relies on PMD for managing it. New eventdev
rely on
> op queue_attr_get can be used to get it from the PMD.
>
> Signed-off-by: Shijith Thotton <sthotton@marvell.com>
Please update the release notes.
With above change,
Acked-by: Jerin Jacob <jerinj@marvell.com>
> ---
> lib/eventdev/eventdev_pmd.h | 22 +++++++++++++++++++++
> lib/eventdev/rte_eventdev.c | 12 ++++++++++++
> lib/eventdev/rte_eventdev.h | 38 +++++++++++++++++++++++++++++++++++--
> 3 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
> index 3b85d9f7a5..5495aee4f6 100644
> --- a/lib/eventdev/eventdev_pmd.h
> +++ b/lib/eventdev/eventdev_pmd.h
> @@ -341,6 +341,26 @@ typedef int (*eventdev_queue_setup_t)(struct rte_eventdev *dev,
> typedef void (*eventdev_queue_release_t)(struct rte_eventdev *dev,
> uint8_t queue_id);
>
> +/**
> + * Get an event queue attribute at runtime.
> + *
> + * @param dev
> + * Event device pointer
> + * @param queue_id
> + * Event queue index
> + * @param attr_id
> + * Event queue attribute id
> + * @param[out] attr_value
> + * Event queue attribute value
> + *
> + * @return
> + * - 0: Success.
> + * - <0: Error code on failure.
> + */
> +typedef int (*eventdev_queue_attr_get_t)(struct rte_eventdev *dev,
> + uint8_t queue_id, uint32_t attr_id,
> + uint32_t *attr_value);
> +
> /**
> * Set an event queue attribute at runtime.
> *
> @@ -1231,6 +1251,8 @@ struct eventdev_ops {
> /**< Set up an event queue. */
> eventdev_queue_release_t queue_release;
> /**< Release an event queue. */
> + eventdev_queue_attr_get_t queue_attr_get;
> + /**< Get an event queue attribute. */
> eventdev_queue_attr_set_t queue_attr_set;
> /**< Set an event queue attribute. */
>
> diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
> index a31e99be02..12b261f923 100644
> --- a/lib/eventdev/rte_eventdev.c
> +++ b/lib/eventdev/rte_eventdev.c
> @@ -838,6 +838,18 @@ rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
>
> *attr_value = conf->schedule_type;
> break;
> + case RTE_EVENT_QUEUE_ATTR_WEIGHT:
> + *attr_value = RTE_EVENT_QUEUE_WEIGHT_LOWEST;
> + if (dev->dev_ops->queue_attr_get)
> + return (*dev->dev_ops->queue_attr_get)(
> + dev, queue_id, attr_id, attr_value);
> + break;
> + case RTE_EVENT_QUEUE_ATTR_AFFINITY:
> + *attr_value = RTE_EVENT_QUEUE_AFFINITY_LOWEST;
> + if (dev->dev_ops->queue_attr_get)
> + return (*dev->dev_ops->queue_attr_get)(
> + dev, queue_id, attr_id, attr_value);
> + break;
> default:
> return -EINVAL;
> };
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 16e9d5fb5b..a6fbaf1c11 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -222,8 +222,14 @@ struct rte_event;
>
> /* Event device capability bitmap flags */
> #define RTE_EVENT_DEV_CAP_QUEUE_QOS (1ULL << 0)
> -/**< Event scheduling prioritization is based on the priority associated with
> - * each event queue.
> +/**< Event scheduling prioritization is based on the priority and weight
> + * associated with each event queue. Events from a queue with highest priority
> + * is scheduled first. If the queues are of same priority, weight of the queues
> + * are considered to select a queue in a weighted round robin fashion.
> + * Subsequent dequeue calls from an event port could see events from the same
> + * event queue, if the queue is configured with an affinity count. Affinity
> + * count is the number of subsequent dequeue calls, in which an event port
> + * should use the same event queue if the queue is non-empty
> *
> * @see rte_event_queue_setup(), rte_event_queue_attr_set()
> */
> @@ -331,6 +337,26 @@ struct rte_event;
> * @see rte_event_port_link()
> */
>
> +/* Event queue scheduling weights */
> +#define RTE_EVENT_QUEUE_WEIGHT_HIGHEST 255
> +/**< Highest weight of an event queue
> + * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
> + */
> +#define RTE_EVENT_QUEUE_WEIGHT_LOWEST 0
> +/**< Lowest weight of an event queue
> + * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
> + */
> +
> +/* Event queue scheduling affinity */
> +#define RTE_EVENT_QUEUE_AFFINITY_HIGHEST 255
> +/**< Highest scheduling affinity of an event queue
> + * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
> + */
> +#define RTE_EVENT_QUEUE_AFFINITY_LOWEST 0
> +/**< Lowest scheduling affinity of an event queue
> + * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
> + */
> +
> /**
> * Get the total number of event devices that have been successfully
> * initialised.
> @@ -684,6 +710,14 @@ rte_event_queue_setup(uint8_t dev_id, uint8_t queue_id,
> * The schedule type of the queue.
> */
> #define RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE 4
> +/**
> + * The weight of the queue.
> + */
> +#define RTE_EVENT_QUEUE_ATTR_WEIGHT 5
> +/**
> + * Affinity of the queue.
> + */
> +#define RTE_EVENT_QUEUE_ATTR_AFFINITY 6
>
> /**
> * Get an attribute from a queue.
> --
> 2.25.1
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] eventdev: add function to quiesce an event port
@ 2022-05-09 17:29 3% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-05-09 17:29 UTC (permalink / raw)
To: Pavan Nikhilesh, Jayatheerthan, Jay, Erik Gabriel Carrillo,
Gujjar, Abhinandan S, McDaniel, Timothy, Hemant Agrawal,
Nipun Gupta, Van Haaren, Harry, Mattias Rönnblom, Liang Ma,
Peter Mccarthy
Cc: Jerin Jacob, Ray Kinsella, dpdk-dev, Shijith Thotton
On Wed, Apr 27, 2022 at 5:02 PM Pavan Nikhilesh
<pbhagavatula@marvell.com> wrote:
>
> Add function to quiesce any core specific resources consumed by
> the event port.
>
> When the application decides to migrate the event port to another lcore
> or teardown the current lcore it may to call `rte_event_port_quiesce`
> to make sure that all the data associated with the event port are released
> from the lcore, this might also include any prefetched events.
>
> While releasing the event port from the lcore, this function calls the
> user-provided flush callback once per event.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
+ eventdev stake holder
@jay.jayatheerthan@intel.com @erik.g.carrillo@intel.com
@abhinandan.gujjar@intel.com timothy.mcdaniel@intel.com
sthotton@marvell.com hemant.agrawal@nxp.com nipun.gupta@nxp.com
harry.van.haaren@intel.com mattias.ronnblom@ericsson.com
liangma@liangbit.com peter.mccarthy@intel.com
Since it is in a slow path and allows port teardown on migration for
the implementations where core has some state for the port. The new
API addition looks good to me.
Any objection or alternative thought from eventdev stake holders?
Some comments below.
> ---
> lib/eventdev/eventdev_pmd.h | 19 +++++++++++++++++++
> lib/eventdev/rte_eventdev.c | 19 +++++++++++++++++++
> lib/eventdev/rte_eventdev.h | 33 +++++++++++++++++++++++++++++++++
> lib/eventdev/version.map | 3 +++
> 4 files changed, 74 insertions(+)
>
> diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
> index ce469d47a6..cf9f2146a1 100644
> --- a/lib/eventdev/eventdev_pmd.h
> +++ b/lib/eventdev/eventdev_pmd.h
> @@ -381,6 +381,23 @@ typedef int (*eventdev_port_setup_t)(struct rte_eventdev *dev,
> */
> typedef void (*eventdev_port_release_t)(void *port);
>
> +/**
> + * Quiesce any core specific resources consumed by the event port
> + *
> + * @param dev
> + * Event device pointer.
> + * @param port
> + * Event port pointer.
> + * @param flush_cb
> + * User-provided event flush function.
> + * @param args
> + * Arguments to be passed to the user-provided event flush function.
> + *
> + */
> +typedef void (*eventdev_port_quiesce_t)(struct rte_eventdev *dev, void *port,
Please prefix rte_ for public symbols. i.e rte_event_port_quiesce_t.
I know we missed for existing eventdev_stop_flush_t, which we can fix
in the next ABI. I will send a patch for same.
> + eventdev_port_flush_t flush_cb,
> + void *args);
> +
> /**
> * Link multiple source event queues to destination event port.
> *
> @@ -1218,6 +1235,8 @@ struct eventdev_ops {
> /**< Set up an event port. */
> eventdev_port_release_t port_release;
> /**< Release an event port. */
> + eventdev_port_quiesce_t port_quiesce;
> + /**< Quiesce an event port. */
>
> eventdev_port_link_t port_link;
> /**< Link event queues to an event port. */
> diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
> index 532a253553..541fa5dc61 100644
> --- a/lib/eventdev/rte_eventdev.c
> +++ b/lib/eventdev/rte_eventdev.c
> @@ -730,6 +730,25 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
> return 0;
> }
>
> +void
> +rte_event_port_quiesce(uint8_t dev_id, uint8_t port_id,
> + eventdev_port_flush_t release_cb, void *args)
> +{
> + struct rte_eventdev *dev;
> +
> + RTE_EVENTDEV_VALID_DEVID_OR_RET(dev_id);
> + dev = &rte_eventdevs[dev_id];
> +
> + if (!is_valid_port(dev, port_id)) {
> + RTE_EDEV_LOG_ERR("Invalid port_id=%" PRIu8, port_id);
> + return;
> + }
> +
> + if (dev->dev_ops->port_quiesce)
> + (*dev->dev_ops->port_quiesce)(dev, dev->data->ports[port_id],
> + release_cb, args);
> +}
> +
> int
> rte_event_dev_attr_get(uint8_t dev_id, uint32_t attr_id,
> uint32_t *attr_value)
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 42a5660169..c86d8a5576 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -830,6 +830,39 @@ int
> rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
> const struct rte_event_port_conf *port_conf);
>
> +typedef void (*eventdev_port_flush_t)(uint8_t dev_id, struct rte_event event,
> + void *arg);
> +/**< Callback function prototype that can be passed during
> + * rte_event_port_release(), invoked once per a released event.
> + */
> +
> +/**
> + * Quiesce any core specific resources consumed by the event port.
> + *
> + * Event ports are generally coupled with lcores, and a given Hardware
> + * implementation might require the PMD to store port specific data in the
> + * lcore.
> + * When the application decides to migrate the event port to an other lcore
an other -> another
> + * or teardown the current lcore it may to call `rte_event_port_quiesce`
> + * to make sure that all the data associated with the event port are released
> + * from the lcore, this might also include any prefetched events.
> + * While releasing the event port from the lcore, this function calls the
> + * user-provided flush callback once per event.
> + *
> + * The event port specific config is not reset.
Make this as @note The event port-specific config shall not reset on
this API call or similar.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The index of the event port to setup. The value must be in the range
> + * [0, nb_event_ports - 1] previously supplied to rte_event_dev_configure().
> + * @param release_cb
> + * Callback function invoked once per flushed event.
> + */
> +__rte_experimental
> +void rte_event_port_quiesce(uint8_t dev_id, uint8_t port_id,
> + eventdev_port_flush_t release_cb, void *args);
>
Please update doc/guides/prog_guide/eventdev.rst and add section for teardown
and mention existing rte_event_dev_stop_flush_callback_register() and
this new API.
^ permalink raw reply [relevance 3%]
* [PATCH v2 7/8] devtools: add RISC-V to test-meson-builds.sh
@ 2022-05-10 15:07 9% ` Stanislaw Kardach
2022-05-10 15:35 0% ` Stanisław Kardach
1 sibling, 1 reply; 200+ results
From: Stanislaw Kardach @ 2022-05-10 15:07 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
devtools/test-meson-builds.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..12513e9d7f 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,12 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configurations
+for f in $srcdir/config/riscv/riscv* ; do
+ targetdir=build-$(basename $f | tr '_' '-' | cut -d'-' -f-2)
+ build $targetdir $f ABI $use_shared
+done
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* Re: [PATCH v2 7/8] devtools: add RISC-V to test-meson-builds.sh
2022-05-10 15:07 9% ` [PATCH v2 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
@ 2022-05-10 15:35 0% ` Stanisław Kardach
0 siblings, 0 replies; 200+ results
From: Stanisław Kardach @ 2022-05-10 15:35 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Frank Zhao, Sam Grove, Marcin Wojtas, upstream
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
On Tue, May 10, 2022 at 5:08 PM Stanislaw Kardach <kda@semihalf.com> wrote:
> Validate RISC-V compilation when test-meson-builds.sh is called. The
> check will be only performed if appropriate toolchain is present on the
> system (same as with other architectures).
>
> Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
> Sponsored-by: Sam Grove <sam.grove@sifive.com>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> ---
> devtools/test-meson-builds.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index a653b253cb..12513e9d7f 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -275,6 +275,12 @@ for f in $srcdir/config/ppc/ppc* ; do
> build $targetdir $f ABI $use_shared
> done
>
> +# RISC-V configurations
> +for f in $srcdir/config/riscv/riscv* ; do
> + targetdir=build-$(basename $f | tr '_' '-' | cut -d'-' -f-2)
> + build $targetdir $f ABI $use_shared
> +done
> +
>
This should not be an iteration but a single build command. I'll re-send as
v3.
> # Test installation of the x86-generic target, to be used for checking
> # the sample apps build using the pkg-config file for cflags and libs
> load_env cc
> --
> 2.30.2
>
[-- Attachment #2: Type: text/html, Size: 2017 bytes --]
^ permalink raw reply [relevance 0%]
* [PATCH v3 7/8] devtools: add RISC-V to test-meson-builds.sh
@ 2022-05-10 15:48 9% ` Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-05-10 15:48 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
devtools/test-meson-builds.sh | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..f732dccf6c 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configuration
+build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
+ $use_shared
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* [PATCH v5 0/7] Add new cryptodev op for event metadata
2022-05-01 19:24 4% ` [PATCH v4 " Akhil Goyal
2022-05-01 19:24 2% ` [PATCH v4 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-05-02 11:08 0% ` [PATCH v4 0/7] Add new cryptodev op for " Gujjar, Abhinandan S
@ 2022-05-12 12:45 4% ` Akhil Goyal
2022-05-12 12:45 2% ` [PATCH v5 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-05-16 18:30 0% ` [PATCH v5 0/7] Add new cryptodev op for " Akhil Goyal
2 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2022-05-12 12:45 UTC (permalink / raw)
To: dev
Cc: anoobj, jerinj, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, vfialko, Akhil Goyal
For using event crypto metadata, event metadata need to be set
in session. For this session user data was used for symmetric
crypto sessions and no support was present for asymmetric and
security sessions.
The use of userdata to store event metadata (which is dereferenced
in PMD) is not correct as it is meant for the application to use it.
Hence, a new API is created to set and get event crypto metadata which
is scalable to all sessions supported by the crypto PMD.
The application can use the set API to set event metadata and the
PMD may store that inside the session private data and PMD need not
use the get API as it would be internal to the PMD.
For the software event crypto adapter implementation, the eventdev
library can use the get API to get the event metadata stored inside
the session structure.
For Asymmetric sessions, a new field is added inside the session
struct which is internal to library.
For symmetric and security sessions, new field cannot be added as
it would be ABI break. Hence, session userdata is being used to
store that as it was used earlier. In next ABI break release this
would be fixed similar to asymmetric crypto case.
The patchset also add support for asymmetric crypto adapter
in the test applications and the crypto/cnxk implementation of
the new cryptodev op and corresponding changes in the eventdev lib.
changes in v5:
removed extra check for freeing mdata
Changes in v4:
- added null checks in set API
- updated check in session destroy
- updated API comments
- fixed test app failure reported by Abhinandan.
- moved event mdata after padding in asym session struct.
Changes in v3:
- fix SW adapter case of memory allocation/free of mdata. mdata is
allocated in set API and freed in session clear/destroy.
- mark rte_cryptodev_session_event_mdata_get as internal API
as it is only needed for the app or the PMD.
changes in v2:
- v1 patchset only fixed security sessions and also caused ABI breakage.
This is fixed in v2.
- added new API for setting event metadata.
- added new cryptodev op which can handle all sessions
Akhil Goyal (5):
crypto/octeontx: use new API for event metadata
test/event: use new API to set event crypto metadata
eventdev: use new API to get event crypto metadata
test/event: add asymmetric cases for crypto adapter
test-eventdev: support asym ops for crypto adapter
Volodymyr Fialko (2):
cryptodev: add APIs to get/set event metadata
crypto/cnxk: add event metadata set operation
app/test-eventdev/evt_common.h | 2 +
app/test-eventdev/evt_options.c | 17 +
app/test-eventdev/evt_options.h | 4 +
app/test-eventdev/test_perf_atq.c | 12 +-
app/test-eventdev/test_perf_common.c | 254 ++++++++--
app/test-eventdev/test_perf_common.h | 45 +-
app/test-eventdev/test_perf_queue.c | 12 +-
app/test/test_event_crypto_adapter.c | 511 +++++++++++++++++++-
doc/guides/tools/testeventdev.rst | 5 +
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++++-
drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 +++++-
drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
drivers/crypto/cnxk/cnxk_ae.h | 2 +
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 -
drivers/crypto/cnxk/cnxk_se.h | 2 +
drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +-
lib/cryptodev/cryptodev_pmd.c | 16 +
lib/cryptodev/cryptodev_pmd.h | 36 ++
lib/cryptodev/rte_cryptodev.c | 43 ++
lib/cryptodev/rte_cryptodev.h | 22 +
lib/cryptodev/version.map | 4 +
lib/eventdev/rte_event_crypto_adapter.c | 55 +--
23 files changed, 1178 insertions(+), 188 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 4%]
* [PATCH v5 1/7] cryptodev: add APIs to get/set event metadata
2022-05-12 12:45 4% ` [PATCH v5 " Akhil Goyal
@ 2022-05-12 12:45 2% ` Akhil Goyal
2022-05-16 18:30 0% ` [PATCH v5 0/7] Add new cryptodev op for " Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2022-05-12 12:45 UTC (permalink / raw)
To: dev
Cc: anoobj, jerinj, abhinandan.gujjar, jay.jayatheerthan,
narender.vangati, vfialko, Akhil Goyal, Fan Zhang,
Abhinandan Gujjar
From: Volodymyr Fialko <vfialko@marvell.com>
Currently, crypto session userdata is used to set event crypto
metadata from the application and the driver is dereferencing it
in driver which is not correct. User data is meant to be opaque
to the driver.
To support this, new API is added to get and set event crypto
metadata. The new API, rte_cryptodev_set_session_event_mdata,
allows setting event metadata in session private data which is
filled inside PMD using a new cryptodev op. This operation
can be performed on any of the PMD supported sessions
(sym/asym/security).
For SW abstraction of event crypto adapter to be used by
eventdev library, a new field is added in asymmetric crypto
session for now and for symmetric case, current implementation
of using userdata is used. Symmetric cases cannot be fixed now,
as it will be ABI breakage which will be resolved in DPDK 22.11.
Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Abhinandan Gujjar <Abhinandan.gujjar@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
---
lib/cryptodev/cryptodev_pmd.c | 16 +++++++++++++
lib/cryptodev/cryptodev_pmd.h | 36 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 43 +++++++++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.h | 22 ++++++++++++++++++
lib/cryptodev/version.map | 4 ++++
5 files changed, 121 insertions(+)
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 739a0b3f34..1903ade388 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -227,3 +227,19 @@ cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
fp_ops->qp.enq_cb = dev->enq_cbs;
fp_ops->qp.deq_cb = dev->deq_cbs;
}
+
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op)
+{
+ if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return rte_cryptodev_sym_session_get_user_data(op->sym->session);
+ else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return op->asym->session->event_mdata;
+ else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
+ op->private_data_offset)
+ return ((uint8_t *)op + op->private_data_offset);
+ else
+ return NULL;
+}
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 2b1ce2da2d..7a7d3ee3f1 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -398,6 +398,25 @@ typedef int (*cryptodev_sym_configure_raw_dp_ctx_t)(
enum rte_crypto_op_sess_type sess_type,
union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
+/**
+ * Typedef that the driver provided to set event crypto meta data.
+ *
+ * @param dev Crypto device pointer.
+ * @param sess Crypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdata Pointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @return
+ * - On success return 0.
+ * - On failure return negative integer.
+ */
+typedef int (*cryptodev_session_event_mdata_set_t)(
+ struct rte_cryptodev *dev, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata);
+
/** Crypto device operations function pointer table */
struct rte_cryptodev_ops {
cryptodev_configure_t dev_configure; /**< Configure device. */
@@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
/**< Initialize raw data path context data. */
};
};
+ cryptodev_session_event_mdata_set_t session_ev_mdata_set;
+ /**< Set a Crypto or Security session even meta data. */
};
@@ -603,6 +624,19 @@ void
cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
const struct rte_cryptodev *dev);
+/**
+ * Get session event meta data (aka *union rte_event_crypto_metadata*)
+ *
+ * @param op pointer to *rte_crypto_op* structure.
+ *
+ * @return
+ * - On success, pointer to event crypto metadata
+ * - On failure, NULL.
+ */
+__rte_internal
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
+
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
@@ -637,6 +671,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
uint16_t user_data_sz;
/**< Session user data will be placed after sess_data */
uint8_t padding[3];
+ void *event_mdata;
+ /**< Event metadata (aka *union rte_event_crypto_metadata*) */
uint8_t sess_private_data[0];
};
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 3500a2d470..e16e6802aa 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2051,6 +2051,8 @@ rte_cryptodev_asym_session_free(uint8_t dev_id, void *sess)
dev->dev_ops->asym_session_clear(dev, sess);
+ rte_free(((struct rte_cryptodev_asym_session *)sess)->event_mdata);
+
/* Return session to mempool */
sess_mp = rte_mempool_from_obj(sess);
rte_mempool_put(sess_mp, sess);
@@ -2259,6 +2261,47 @@ rte_cryptodev_configure_raw_dp_ctx(uint8_t dev_id, uint16_t qp_id,
sess_type, session_ctx, is_update);
}
+int
+rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata,
+ uint16_t size)
+{
+ struct rte_cryptodev *dev;
+
+ if (sess == NULL || ev_mdata == NULL)
+ return -EINVAL;
+
+ if (!rte_cryptodev_is_valid_dev(dev_id))
+ goto skip_pmd_op;
+
+ dev = rte_cryptodev_pmd_get_dev(dev_id);
+ if (dev->dev_ops->session_ev_mdata_set == NULL)
+ goto skip_pmd_op;
+
+ return (*dev->dev_ops->session_ev_mdata_set)(dev, sess, op_type,
+ sess_type, ev_mdata);
+
+skip_pmd_op:
+ if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+ return rte_cryptodev_sym_session_set_user_data(sess, ev_mdata,
+ size);
+ else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
+ struct rte_cryptodev_asym_session *s = sess;
+
+ if (s->event_mdata == NULL) {
+ s->event_mdata = rte_malloc(NULL, size, 0);
+ if (s->event_mdata == NULL)
+ return -ENOMEM;
+ }
+ rte_memcpy(s->event_mdata, ev_mdata, size);
+
+ return 0;
+ } else
+ return -ENOTSUP;
+}
+
uint32_t
rte_cryptodev_raw_enqueue_burst(struct rte_crypto_raw_dp_ctx *ctx,
struct rte_crypto_sym_vec *vec, union rte_crypto_sym_ofs ofs,
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 45d33f4a50..2c2c2edeb7 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -1269,6 +1269,28 @@ __rte_experimental
int
rte_cryptodev_get_raw_dp_ctx_size(uint8_t dev_id);
+/**
+ * Set session event meta data
+ *
+ * @param dev_id The device identifier.
+ * @param sess Crypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdata Pointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @param size Size of ev_mdata.
+ *
+ * @return
+ * - On success, zero.
+ * - On failure, a negative value.
+ */
+__rte_experimental
+int
+rte_cryptodev_session_event_mdata_set(uint8_t dev_id, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata, uint16_t size);
+
/**
* Union of different crypto session types, including session-less xform
* pointer.
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index c7c5aefceb..f0abfaa47d 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -105,6 +105,9 @@ EXPERIMENTAL {
rte_cryptodev_asym_session_pool_create;
rte_cryptodev_asym_session_set_user_data;
__rte_cryptodev_trace_asym_session_pool_create;
+
+ #added in 22.07
+ rte_cryptodev_session_event_mdata_set;
};
INTERNAL {
@@ -123,5 +126,6 @@ INTERNAL {
rte_cryptodev_pmd_parse_input_args;
rte_cryptodev_pmd_probing_finish;
rte_cryptodev_pmd_release_device;
+ rte_cryptodev_session_event_mdata_get;
rte_cryptodevs;
};
--
2.25.1
^ permalink raw reply [relevance 2%]
* [PATCH v2] sched: enable CMAN at runtime
@ 2022-05-12 13:10 4% ` Marcin Danilewicz
2022-05-30 11:19 3% ` Dumitrescu, Cristian
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Marcin Danilewicz @ 2022-05-12 13:10 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Log: v2 change in rte_sched.h to avoid ABI breakage.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 14 +--
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 53 ++-------
lib/sched/rte_sched.h | 2 +
12 files changed, 371 insertions(+), 140 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 8eb29c1525..1740a1d053 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-#undef RTE_SCHED_CMAN
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..efff1dbb01 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,13 +229,15 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
subport_p->cman_params->cman_mode = cman_p.cman_mode;
+ if (subport_p->cman_params->cman_mode == RTE_SCHED_CMAN_NONE)
+ return;
+
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
if (subport_p->cman_params->cman_mode ==
RTE_SCHED_CMAN_RED) {
@@ -261,7 +263,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,12 +277,14 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
+ if (cman_params.cman_mode != RTE_SCHED_CMAN_NONE) {
+ cman_params.cman_mode = RTE_SCHED_CMAN_NONE;
+ }
+
if (rte_cfgfile_has_section(cfg, "red")) {
cman_params.cman_mode = RTE_SCHED_CMAN_RED;
@@ -387,7 +390,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +467,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index ec74bee939..db14934832 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1081,7 +1077,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1161,9 +1156,11 @@ rte_sched_cman_config(struct rte_sched_port *port,
else if (params->cman_params->cman_mode == RTE_SCHED_CMAN_PIE)
return rte_sched_pie_config(port, s, params, n_subports);
+ else if (params->cman_params->cman_mode == RTE_SCHED_CMAN_NONE)
+ return 1;
+
return -EINVAL;
}
-#endif
int
rte_sched_subport_config(struct rte_sched_port *port,
@@ -1254,19 +1251,20 @@ rte_sched_subport_config(struct rte_sched_port *port,
s->n_pipe_profiles = params->n_pipe_profiles;
s->n_max_pipe_profiles = params->n_max_pipe_profiles;
-#ifdef RTE_SCHED_CMAN
+ s->cman_enabled = false;
+
if (params->cman_params != NULL) {
- s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
if (status) {
- RTE_LOG(NOTICE, SCHED,
- "%s: CMAN configuration fails\n", __func__);
- return status;
+ if (status != 1) {
+ RTE_LOG(NOTICE, SCHED,
+ "%s: CMAN configuration fails\n", __func__);
+ return status;
+ }
+ } else {
+ s->cman_enabled = true;
}
- } else {
- s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1825,14 +1823,10 @@ rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1902,29 +1896,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
diff --git a/lib/sched/rte_sched.h b/lib/sched/rte_sched.h
index 5ece64e527..82aa73ff5b 100644
--- a/lib/sched/rte_sched.h
+++ b/lib/sched/rte_sched.h
@@ -128,6 +128,8 @@ extern "C" {
enum rte_sched_cman_mode {
RTE_SCHED_CMAN_RED, /**< Random Early Detection (RED) */
RTE_SCHED_CMAN_PIE, /**< Proportional Integral Controller Enhanced (PIE) */
+ /* New enum RTE_SCHED_CMAN_NONE added at the end to avoid ABI breakage */
+ RTE_SCHED_CMAN_NONE, /**< no RED|PIE cfg available */
};
/*
--
2.25.1
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* [PATCH v3 0/5] Extend and set event queue attributes at runtime
@ 2022-05-15 9:53 3% ` Shijith Thotton
2022-05-15 9:53 3% ` [PATCH v3 2/5] eventdev: add weight and affinity to queue attributes Shijith Thotton
2022-05-16 17:35 3% ` [PATCH v4 0/5] Extend and set event queue attributes at runtime Shijith Thotton
1 sibling, 2 replies; 200+ results
From: Shijith Thotton @ 2022-05-15 9:53 UTC (permalink / raw)
To: dev, jerinj
Cc: Shijith Thotton, pbhagavatula, harry.van.haaren, mattias.ronnblom, mdr
This series adds support for setting event queue attributes at runtime
and adds two new event queue attributes weight and affinity. Eventdev
capability RTE_EVENT_DEV_CAP_RUNTIME_QUEUE_ATTR is added to expose the
capability to set attributes at runtime and rte_event_queue_attr_set()
API is used to set the attributes.
Attributes weight and affinity are not yet added to rte_event_queue_conf
structure to avoid ABI break and will be added in 22.11. Till then, PMDs
using the new attributes are expected to manage them.
Test application changes and example implementation are added as last
three patches.
v3:
* Updated release notes.
* Removed deprecation patch from series.
* Used event enq/deq to test queue priority.
v2:
* Modified attr_value type from u32 to u64 for set().
* Removed RTE_EVENT_QUEUE_ATTR_MAX macro.
* Fixed return value in implementation.
Pavan Nikhilesh (1):
common/cnxk: use lock when accessing mbox of SSO
Shijith Thotton (4):
eventdev: support to set queue attributes at runtime
eventdev: add weight and affinity to queue attributes
test/event: test cases to test runtime queue attribute
event/cnxk: support to set runtime queue attributes
app/test/test_eventdev.c | 201 ++++++++++++++++++++++
doc/guides/eventdevs/features/cnxk.ini | 1 +
doc/guides/eventdevs/features/default.ini | 1 +
doc/guides/rel_notes/release_22_07.rst | 12 ++
drivers/common/cnxk/roc_sso.c | 174 +++++++++++++------
drivers/common/cnxk/roc_sso_priv.h | 1 +
drivers/common/cnxk/roc_tim.c | 134 ++++++++++-----
drivers/event/cnxk/cn10k_eventdev.c | 4 +
drivers/event/cnxk/cn9k_eventdev.c | 4 +
drivers/event/cnxk/cnxk_eventdev.c | 91 +++++++++-
drivers/event/cnxk/cnxk_eventdev.h | 19 ++
lib/eventdev/eventdev_pmd.h | 44 +++++
lib/eventdev/rte_eventdev.c | 38 ++++
lib/eventdev/rte_eventdev.h | 71 +++++++-
lib/eventdev/version.map | 3 +
15 files changed, 695 insertions(+), 103 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 3%]
* [PATCH v3 2/5] eventdev: add weight and affinity to queue attributes
2022-05-15 9:53 3% ` [PATCH v3 0/5] Extend and set event queue attributes at runtime Shijith Thotton
@ 2022-05-15 9:53 3% ` Shijith Thotton
2022-05-16 17:35 3% ` [PATCH v4 0/5] Extend and set event queue attributes at runtime Shijith Thotton
1 sibling, 0 replies; 200+ results
From: Shijith Thotton @ 2022-05-15 9:53 UTC (permalink / raw)
To: dev, jerinj
Cc: Shijith Thotton, pbhagavatula, harry.van.haaren, mattias.ronnblom, mdr
Extended eventdev queue QoS attributes to support weight and affinity.
If queues are of the same priority, events from the queue with highest
weight will be scheduled first. Affinity indicates the number of times,
the subsequent schedule calls from an event port will use the same event
queue. Schedule call selects another queue if current queue goes empty
or schedule count reaches affinity count.
To avoid ABI break, weight and affinity attributes are not yet added to
queue config structure and rely on PMD for managing it. New eventdev op
queue_attr_get can be used to get it from the PMD.
Signed-off-by: Shijith Thotton <sthotton@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
doc/guides/rel_notes/release_22_07.rst | 7 +++++
lib/eventdev/eventdev_pmd.h | 22 +++++++++++++++
lib/eventdev/rte_eventdev.c | 12 ++++++++
lib/eventdev/rte_eventdev.h | 38 ++++++++++++++++++++++++--
4 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index a7a912d665..f35a31bbdf 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -70,6 +70,13 @@ New Features
Added new API ``rte_event_queue_attr_set()``, to set event queue attributes
at runtime.
+* **Added new queues attributes weight and affinity in eventdev.**
+
+ Defined new event queue attributes weight and affinity as below:
+
+ * ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
+ * ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
+
Removed Items
-------------
diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index 3b85d9f7a5..5495aee4f6 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -341,6 +341,26 @@ typedef int (*eventdev_queue_setup_t)(struct rte_eventdev *dev,
typedef void (*eventdev_queue_release_t)(struct rte_eventdev *dev,
uint8_t queue_id);
+/**
+ * Get an event queue attribute at runtime.
+ *
+ * @param dev
+ * Event device pointer
+ * @param queue_id
+ * Event queue index
+ * @param attr_id
+ * Event queue attribute id
+ * @param[out] attr_value
+ * Event queue attribute value
+ *
+ * @return
+ * - 0: Success.
+ * - <0: Error code on failure.
+ */
+typedef int (*eventdev_queue_attr_get_t)(struct rte_eventdev *dev,
+ uint8_t queue_id, uint32_t attr_id,
+ uint32_t *attr_value);
+
/**
* Set an event queue attribute at runtime.
*
@@ -1231,6 +1251,8 @@ struct eventdev_ops {
/**< Set up an event queue. */
eventdev_queue_release_t queue_release;
/**< Release an event queue. */
+ eventdev_queue_attr_get_t queue_attr_get;
+ /**< Get an event queue attribute. */
eventdev_queue_attr_set_t queue_attr_set;
/**< Set an event queue attribute. */
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index a31e99be02..12b261f923 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -838,6 +838,18 @@ rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
*attr_value = conf->schedule_type;
break;
+ case RTE_EVENT_QUEUE_ATTR_WEIGHT:
+ *attr_value = RTE_EVENT_QUEUE_WEIGHT_LOWEST;
+ if (dev->dev_ops->queue_attr_get)
+ return (*dev->dev_ops->queue_attr_get)(
+ dev, queue_id, attr_id, attr_value);
+ break;
+ case RTE_EVENT_QUEUE_ATTR_AFFINITY:
+ *attr_value = RTE_EVENT_QUEUE_AFFINITY_LOWEST;
+ if (dev->dev_ops->queue_attr_get)
+ return (*dev->dev_ops->queue_attr_get)(
+ dev, queue_id, attr_id, attr_value);
+ break;
default:
return -EINVAL;
};
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index c1163ee8ec..5d38996f6b 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -222,8 +222,14 @@ struct rte_event;
/* Event device capability bitmap flags */
#define RTE_EVENT_DEV_CAP_QUEUE_QOS (1ULL << 0)
-/**< Event scheduling prioritization is based on the priority associated with
- * each event queue.
+/**< Event scheduling prioritization is based on the priority and weight
+ * associated with each event queue. Events from a queue with highest priority
+ * is scheduled first. If the queues are of same priority, weight of the queues
+ * are considered to select a queue in a weighted round robin fashion.
+ * Subsequent dequeue calls from an event port could see events from the same
+ * event queue, if the queue is configured with an affinity count. Affinity
+ * count is the number of subsequent dequeue calls, in which an event port
+ * should use the same event queue if the queue is non-empty
*
* @see rte_event_queue_setup(), rte_event_queue_attr_set()
*/
@@ -331,6 +337,26 @@ struct rte_event;
* @see rte_event_port_link()
*/
+/* Event queue scheduling weights */
+#define RTE_EVENT_QUEUE_WEIGHT_HIGHEST 255
+/**< Highest weight of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+#define RTE_EVENT_QUEUE_WEIGHT_LOWEST 0
+/**< Lowest weight of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+
+/* Event queue scheduling affinity */
+#define RTE_EVENT_QUEUE_AFFINITY_HIGHEST 255
+/**< Highest scheduling affinity of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+#define RTE_EVENT_QUEUE_AFFINITY_LOWEST 0
+/**< Lowest scheduling affinity of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+
/**
* Get the total number of event devices that have been successfully
* initialised.
@@ -684,6 +710,14 @@ rte_event_queue_setup(uint8_t dev_id, uint8_t queue_id,
* The schedule type of the queue.
*/
#define RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE 4
+/**
+ * The weight of the queue.
+ */
+#define RTE_EVENT_QUEUE_ATTR_WEIGHT 5
+/**
+ * Affinity of the queue.
+ */
+#define RTE_EVENT_QUEUE_ATTR_AFFINITY 6
/**
* Get an attribute from a queue.
--
2.25.1
^ permalink raw reply [relevance 3%]
* [PATCH v4 0/5] Extend and set event queue attributes at runtime
2022-05-15 9:53 3% ` [PATCH v3 0/5] Extend and set event queue attributes at runtime Shijith Thotton
2022-05-15 9:53 3% ` [PATCH v3 2/5] eventdev: add weight and affinity to queue attributes Shijith Thotton
@ 2022-05-16 17:35 3% ` Shijith Thotton
2022-05-16 17:35 3% ` [PATCH v4 2/5] eventdev: add weight and affinity to queue attributes Shijith Thotton
1 sibling, 1 reply; 200+ results
From: Shijith Thotton @ 2022-05-16 17:35 UTC (permalink / raw)
To: dev, jerinj
Cc: Shijith Thotton, pbhagavatula, harry.van.haaren, mattias.ronnblom, mdr
This series adds support for setting event queue attributes at runtime
and adds two new event queue attributes weight and affinity. Eventdev
capability RTE_EVENT_DEV_CAP_RUNTIME_QUEUE_ATTR is added to expose the
capability to set attributes at runtime and rte_event_queue_attr_set()
API is used to set the attributes.
Attributes weight and affinity are not yet added to rte_event_queue_conf
structure to avoid ABI break and will be added in 22.11. Till then, PMDs
using the new attributes are expected to manage them.
Test application changes and example implementation are added as last
three patches.
v4:
* Removed EBUSY from rte_event_queue_attr_set() return vals.
v3:
* Updated release notes.
* Removed deprecation patch from series.
* Used event enq/deq to test queue priority.
v2:
* Modified attr_value type from u32 to u64 for set().
* Removed RTE_EVENT_QUEUE_ATTR_MAX macro.
* Fixed return value in implementation.
Pavan Nikhilesh (1):
common/cnxk: use lock when accessing mbox of SSO
Shijith Thotton (4):
eventdev: support to set queue attributes at runtime
eventdev: add weight and affinity to queue attributes
test/event: test cases to test runtime queue attribute
event/cnxk: support to set runtime queue attributes
app/test/test_eventdev.c | 201 ++++++++++++++++++++++
doc/guides/eventdevs/features/cnxk.ini | 1 +
doc/guides/eventdevs/features/default.ini | 1 +
doc/guides/rel_notes/release_22_07.rst | 12 ++
drivers/common/cnxk/roc_sso.c | 174 +++++++++++++------
drivers/common/cnxk/roc_sso_priv.h | 1 +
drivers/common/cnxk/roc_tim.c | 134 ++++++++++-----
drivers/event/cnxk/cn10k_eventdev.c | 4 +
drivers/event/cnxk/cn9k_eventdev.c | 4 +
drivers/event/cnxk/cnxk_eventdev.c | 91 +++++++++-
drivers/event/cnxk/cnxk_eventdev.h | 19 ++
lib/eventdev/eventdev_pmd.h | 44 +++++
lib/eventdev/rte_eventdev.c | 38 ++++
lib/eventdev/rte_eventdev.h | 70 +++++++-
lib/eventdev/version.map | 3 +
15 files changed, 694 insertions(+), 103 deletions(-)
--
2.25.1
^ permalink raw reply [relevance 3%]
* [PATCH v4 2/5] eventdev: add weight and affinity to queue attributes
2022-05-16 17:35 3% ` [PATCH v4 0/5] Extend and set event queue attributes at runtime Shijith Thotton
@ 2022-05-16 17:35 3% ` Shijith Thotton
0 siblings, 0 replies; 200+ results
From: Shijith Thotton @ 2022-05-16 17:35 UTC (permalink / raw)
To: dev, jerinj
Cc: Shijith Thotton, pbhagavatula, harry.van.haaren, mattias.ronnblom, mdr
Extended eventdev queue QoS attributes to support weight and affinity.
If queues are of the same priority, events from the queue with highest
weight will be scheduled first. Affinity indicates the number of times,
the subsequent schedule calls from an event port will use the same event
queue. Schedule call selects another queue if current queue goes empty
or schedule count reaches affinity count.
To avoid ABI break, weight and affinity attributes are not yet added to
queue config structure and rely on PMD for managing it. New eventdev op
queue_attr_get can be used to get it from the PMD.
Signed-off-by: Shijith Thotton <sthotton@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
doc/guides/rel_notes/release_22_07.rst | 7 +++++
lib/eventdev/eventdev_pmd.h | 22 +++++++++++++++
lib/eventdev/rte_eventdev.c | 12 ++++++++
lib/eventdev/rte_eventdev.h | 38 ++++++++++++++++++++++++--
4 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index a7a912d665..f35a31bbdf 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -70,6 +70,13 @@ New Features
Added new API ``rte_event_queue_attr_set()``, to set event queue attributes
at runtime.
+* **Added new queues attributes weight and affinity in eventdev.**
+
+ Defined new event queue attributes weight and affinity as below:
+
+ * ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
+ * ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
+
Removed Items
-------------
diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index 3b85d9f7a5..5495aee4f6 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -341,6 +341,26 @@ typedef int (*eventdev_queue_setup_t)(struct rte_eventdev *dev,
typedef void (*eventdev_queue_release_t)(struct rte_eventdev *dev,
uint8_t queue_id);
+/**
+ * Get an event queue attribute at runtime.
+ *
+ * @param dev
+ * Event device pointer
+ * @param queue_id
+ * Event queue index
+ * @param attr_id
+ * Event queue attribute id
+ * @param[out] attr_value
+ * Event queue attribute value
+ *
+ * @return
+ * - 0: Success.
+ * - <0: Error code on failure.
+ */
+typedef int (*eventdev_queue_attr_get_t)(struct rte_eventdev *dev,
+ uint8_t queue_id, uint32_t attr_id,
+ uint32_t *attr_value);
+
/**
* Set an event queue attribute at runtime.
*
@@ -1231,6 +1251,8 @@ struct eventdev_ops {
/**< Set up an event queue. */
eventdev_queue_release_t queue_release;
/**< Release an event queue. */
+ eventdev_queue_attr_get_t queue_attr_get;
+ /**< Get an event queue attribute. */
eventdev_queue_attr_set_t queue_attr_set;
/**< Set an event queue attribute. */
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index a31e99be02..12b261f923 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -838,6 +838,18 @@ rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
*attr_value = conf->schedule_type;
break;
+ case RTE_EVENT_QUEUE_ATTR_WEIGHT:
+ *attr_value = RTE_EVENT_QUEUE_WEIGHT_LOWEST;
+ if (dev->dev_ops->queue_attr_get)
+ return (*dev->dev_ops->queue_attr_get)(
+ dev, queue_id, attr_id, attr_value);
+ break;
+ case RTE_EVENT_QUEUE_ATTR_AFFINITY:
+ *attr_value = RTE_EVENT_QUEUE_AFFINITY_LOWEST;
+ if (dev->dev_ops->queue_attr_get)
+ return (*dev->dev_ops->queue_attr_get)(
+ dev, queue_id, attr_id, attr_value);
+ break;
default:
return -EINVAL;
};
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index a79b1397eb..9a7c0bcf25 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -222,8 +222,14 @@ struct rte_event;
/* Event device capability bitmap flags */
#define RTE_EVENT_DEV_CAP_QUEUE_QOS (1ULL << 0)
-/**< Event scheduling prioritization is based on the priority associated with
- * each event queue.
+/**< Event scheduling prioritization is based on the priority and weight
+ * associated with each event queue. Events from a queue with highest priority
+ * is scheduled first. If the queues are of same priority, weight of the queues
+ * are considered to select a queue in a weighted round robin fashion.
+ * Subsequent dequeue calls from an event port could see events from the same
+ * event queue, if the queue is configured with an affinity count. Affinity
+ * count is the number of subsequent dequeue calls, in which an event port
+ * should use the same event queue if the queue is non-empty
*
* @see rte_event_queue_setup(), rte_event_queue_attr_set()
*/
@@ -331,6 +337,26 @@ struct rte_event;
* @see rte_event_port_link()
*/
+/* Event queue scheduling weights */
+#define RTE_EVENT_QUEUE_WEIGHT_HIGHEST 255
+/**< Highest weight of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+#define RTE_EVENT_QUEUE_WEIGHT_LOWEST 0
+/**< Lowest weight of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+
+/* Event queue scheduling affinity */
+#define RTE_EVENT_QUEUE_AFFINITY_HIGHEST 255
+/**< Highest scheduling affinity of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+#define RTE_EVENT_QUEUE_AFFINITY_LOWEST 0
+/**< Lowest scheduling affinity of an event queue
+ * @see rte_event_queue_attr_get(), rte_event_queue_attr_set()
+ */
+
/**
* Get the total number of event devices that have been successfully
* initialised.
@@ -684,6 +710,14 @@ rte_event_queue_setup(uint8_t dev_id, uint8_t queue_id,
* The schedule type of the queue.
*/
#define RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE 4
+/**
+ * The weight of the queue.
+ */
+#define RTE_EVENT_QUEUE_ATTR_WEIGHT 5
+/**
+ * Affinity of the queue.
+ */
+#define RTE_EVENT_QUEUE_ATTR_AFFINITY 6
/**
* Get an attribute from a queue.
--
2.25.1
^ permalink raw reply [relevance 3%]
* RE: [PATCH v5 0/7] Add new cryptodev op for event metadata
2022-05-12 12:45 4% ` [PATCH v5 " Akhil Goyal
2022-05-12 12:45 2% ` [PATCH v5 1/7] cryptodev: add APIs to get/set " Akhil Goyal
@ 2022-05-16 18:30 0% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2022-05-16 18:30 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: Anoob Joseph, Jerin Jacob Kollanukkaran, abhinandan.gujjar,
jay.jayatheerthan, narender.vangati, Volodymyr Fialko
> Subject: [PATCH v5 0/7] Add new cryptodev op for event metadata
>
> For using event crypto metadata, event metadata need to be set
> in session. For this session user data was used for symmetric
> crypto sessions and no support was present for asymmetric and
> security sessions.
> The use of userdata to store event metadata (which is dereferenced
> in PMD) is not correct as it is meant for the application to use it.
> Hence, a new API is created to set and get event crypto metadata which
> is scalable to all sessions supported by the crypto PMD.
> The application can use the set API to set event metadata and the
> PMD may store that inside the session private data and PMD need not
> use the get API as it would be internal to the PMD.
> For the software event crypto adapter implementation, the eventdev
> library can use the get API to get the event metadata stored inside
> the session structure.
> For Asymmetric sessions, a new field is added inside the session
> struct which is internal to library.
> For symmetric and security sessions, new field cannot be added as
> it would be ABI break. Hence, session userdata is being used to
> store that as it was used earlier. In next ABI break release this
> would be fixed similar to asymmetric crypto case.
>
> The patchset also add support for asymmetric crypto adapter
> in the test applications and the crypto/cnxk implementation of
> the new cryptodev op and corresponding changes in the eventdev lib.
>
> changes in v5:
> removed extra check for freeing mdata
Series Applied to dpdk-next-crypto
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split
@ 2022-05-17 21:12 3% ` Thomas Monjalon
2022-05-19 14:40 0% ` Ding, Xuan
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-17 21:12 UTC (permalink / raw)
To: xuan.ding, yuanx.wang, wenxuanx.wu
Cc: andrew.rybchenko, xiaoyun.li, ferruh.yigit, aman.deep.singh, dev,
yuying.zhang, qi.z.zhang, jerinjacobk, stephen, mb, viacheslavo,
ping.yu
Hello,
It seems you didn't try to address my main comment on v4:
"
Before doing anything, the first patch of this series should make
the current status clearer.
Example, this line does not explain what it does:
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
And header_split has been removed in ab3ce1e0c193 ("ethdev: remove old offload API")
If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed,
let's add a comment to start a deprecation.
"
Also the comment from Andrew about removing limitation to 2 packets
is not addressed.
All the part about the protocols capability is missing here.
It is not encouraging.
26/04/2022 13:13, wenxuanx.wu@intel.com:
> From: Wenxuan Wu <wenxuanx.wu@intel.com>
>
> Protocol based buffer split consists of splitting a received packet into two
> separate regions based on its content. The split happens after the packet
> protocol header and before the packet payload. Splitting is usually between
> the packet protocol header that can be posted to a dedicated buffer and the
> packet payload that can be posted to a different buffer.
>
> Currently, Rx buffer split supports length and offset based packet split.
> protocol split is based on buffer split, configuring length of buffer split
> is not suitable for NICs that do split based on protocol types.
Why? Is it impossible to support length split on Intel NIC?
> Because tunneling makes the conversion from length
> to protocol type impossible.
This is not a HW issue.
I agree on the need but that a different usage than length split.
> This patch extends the current buffer split to support protocol and offset
> based buffer split. A new proto field is introduced in the rte_eth_rxseg_split
> structure reserved field to specify header protocol type. With Rx queue
> offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and corresponding protocol
> type configured. PMD will split the ingress packets into two separate regions.
> Currently, both inner and outer L2/L3/L4 level protocol based buffer split
> can be supported.
>
> For example, let's suppose we configured the Rx queue with the
> following segments:
> seg0 - pool0, off0=2B
> seg1 - pool1, off1=128B
>
> With protocol split type configured with RTE_PTYPE_L4_UDP. The packet
> consists of MAC_IP_UDP_PAYLOAD will be splitted like following:
> seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0
> seg1 - payload @ 128 in mbuf from pool1
Not clear what is the calculation.
> The memory attributes for the split parts may differ either - for example
> the mempool0 and mempool1 belong to dpdk memory and external memory,
> respectively.
>
> Signed-off-by: Xuan Ding <xuan.ding@intel.com>
> Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> Signed-off-by: Wenxuan Wu <wenxuanx.wu@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> ---
> lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++-------
> lib/ethdev/rte_ethdev.h | 15 ++++++++++++++-
> 2 files changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 29a3d80466..1a2bc172ab 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -1661,6 +1661,7 @@ rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg,
> struct rte_mempool *mpl = rx_seg[seg_idx].mp;
> uint32_t length = rx_seg[seg_idx].length;
> uint32_t offset = rx_seg[seg_idx].offset;
> + uint32_t proto = rx_seg[seg_idx].proto;
>
> if (mpl == NULL) {
> RTE_ETHDEV_LOG(ERR, "null mempool pointer\n");
> @@ -1694,13 +1695,34 @@ rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg,
> }
> offset += seg_idx != 0 ? 0 : RTE_PKTMBUF_HEADROOM;
> *mbp_buf_size = rte_pktmbuf_data_room_size(mpl);
> - length = length != 0 ? length : *mbp_buf_size;
> - if (*mbp_buf_size < length + offset) {
> - RTE_ETHDEV_LOG(ERR,
> - "%s mbuf_data_room_size %u < %u (segment length=%u + segment offset=%u)\n",
> - mpl->name, *mbp_buf_size,
> - length + offset, length, offset);
> - return -EINVAL;
> + if (proto == 0) {
Add a comment here, /* split at fixed length */
> + length = length != 0 ? length : *mbp_buf_size;
> + if (*mbp_buf_size < length + offset) {
> + RTE_ETHDEV_LOG(ERR,
> + "%s mbuf_data_room_size %u < %u (segment length=%u + segment offset=%u)\n",
> + mpl->name, *mbp_buf_size,
> + length + offset, length, offset);
> + return -EINVAL;
> + }
> + } else {
Add a comment here, /* split after specified protocol header */
> + /* Ensure n_seg is 2 in protocol based buffer split. */
> + if (n_seg != 2) {
(should be a space, not a tab before brace)
Why do you limit the feature to 2 segments only?
> + RTE_ETHDEV_LOG(ERR, "number of buffer split protocol segments should be 2.\n");
> + return -EINVAL;
> + }
> + /* Length and protocol are exclusive here, so make sure length is 0 in protocol
> + based buffer split. */
> + if (length != 0) {
> + RTE_ETHDEV_LOG(ERR, "segment length should be set to zero in buffer split\n");
> + return -EINVAL;
> + }
> + if (*mbp_buf_size < offset) {
> + RTE_ETHDEV_LOG(ERR,
> + "%s mbuf_data_room_size %u < %u segment offset)\n",
> + mpl->name, *mbp_buf_size,
> + offset);
> + return -EINVAL;
[...]
> + * - The proto in the elements defines the split position of received packets.
> + *
> * - If the length in the segment description element is zero
> * the actual buffer size will be deduced from the appropriate
> * memory pool properties.
> @@ -1197,12 +1200,21 @@ struct rte_eth_txmode {
> * - pool from the last valid element
> * - the buffer size from this pool
> * - zero offset
> + *
> + * - Length based buffer split:
> + * - mp, length, offset should be configured.
> + * - The proto should not be configured in length split. Zero default.
> + *
> + * - Protocol based buffer split:
> + * - mp, offset, proto should be configured.
> + * - The length should not be configured in protocol split. Zero default.
What means "Zero default"?
You should just ignore the non relevant field.
> struct rte_eth_rxseg_split {
> struct rte_mempool *mp; /**< Memory pool to allocate segment from. */
> uint16_t length; /**< Segment data length, configures split point. */
> uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
> - uint32_t reserved; /**< Reserved field. */
How do you manage ABI compatibility?
Was the reserved field initialized to 0 in previous versions?
> + uint32_t proto; /**< Protocol of buffer split, determines protocol split point. */
What are the values for "proto"?
> @@ -1664,6 +1676,7 @@ struct rte_eth_conf {
> RTE_ETH_RX_OFFLOAD_QINQ_STRIP)
> #define DEV_RX_OFFLOAD_VLAN RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN) RTE_ETH_RX_OFFLOAD_VLAN
>
> +
It looks to be an useless change.
> /*
> * If new Rx offload capabilities are defined, they also must be
> * mentioned in rte_rx_offload_names in rte_ethdev.c file.
>
^ permalink raw reply [relevance 3%]
* Re: [RFC v1 3/7] ethdev: introduce Rx queue based limit watermark
@ 2022-05-19 9:37 4% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2022-05-19 9:37 UTC (permalink / raw)
To: Spike Du, matan, viacheslavo, orika, thomas; +Cc: dev, rasland
On 5/6/22 06:56, Spike Du wrote:
> LWM(limit watermark) is a per Rx queue attribute that notifies dpdk
dpdk is not necessary about.
I'm not sure that "attribute" can notify application. Please,
reword the description.
> application event of RTE_ETH_EVENT_RXQ_LIMIT_REACHED when the Rx
> queue's usable descriptor is under the watermark.
> To simplify its configuration, LWM is a percentage of Rx queue
> descriptor size with valid value of [0,99].
> Setting LWM to 0 means disable it.
... which is the default.
Can I request notification when no descriptors left?
1 seems to be close to the answer, but not in the case of big
Rx rings.
> Add LWM's configuration handle in eth_dev_ops.
handle sounds bad here. May be "driver callback" or "driver
method".
>
> Signed-off-by: Spike Du <spiked@nvidia.com>
> ---
> lib/ethdev/ethdev_driver.h | 7 +++++++
> lib/ethdev/rte_ethdev.c | 28 ++++++++++++++++++++++++++++
> lib/ethdev/rte_ethdev.h | 30 +++++++++++++++++++++++++++++-
> lib/ethdev/version.map | 3 +++
> 4 files changed, 67 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> index 69d9dc2..1e9cdbf 100644
> --- a/lib/ethdev/ethdev_driver.h
> +++ b/lib/ethdev/ethdev_driver.h
> @@ -470,6 +470,10 @@ typedef int (*eth_rx_queue_setup_t)(struct rte_eth_dev *dev,
> const struct rte_eth_rxconf *rx_conf,
> struct rte_mempool *mb_pool);
>
> +typedef int (*eth_rx_queue_set_lwm_t)(struct rte_eth_dev *dev,
> + uint16_t rx_queue_id,
> + uint8_t lwm);
> +
Please, add full description including parameters and return
values.
> /** @internal Setup a transmit queue of an Ethernet device. */
> typedef int (*eth_tx_queue_setup_t)(struct rte_eth_dev *dev,
> uint16_t tx_queue_id,
> @@ -1283,6 +1287,9 @@ struct eth_dev_ops {
>
> /** Dump private info from device */
> eth_dev_priv_dump_t eth_dev_priv_dump;
> +
> + /** Set Rx queue limit watermark */
> + eth_rx_queue_set_lwm_t rx_queue_set_lwm;
> };
>
> /**
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 29a3d80..1e4fc6a 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -4414,6 +4414,34 @@ int rte_eth_set_queue_rate_limit(uint16_t port_id, uint16_t queue_idx,
> queue_idx, tx_rate));
> }
>
> +int rte_eth_rx_queue_set_lwm(uint16_t port_id, uint16_t queue_idx,
> + uint8_t lwm)
> +{
> + struct rte_eth_dev *dev;
> + struct rte_eth_dev_info dev_info;
> + int ret;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> +
> + ret = rte_eth_dev_info_get(port_id, &dev_info);
> + if (ret != 0)
> + return ret;
> +
> + if (queue_idx > dev_info.max_rx_queues) {
It should be >=
> + RTE_ETHDEV_LOG(ERR,
> + "Set queue rate limit:port %u: invalid queue ID=%u\n",
> + port_id, queue_idx);
> + return -EINVAL;
> + }
> +
> + if (lwm > 99)
> + return -EINVAL;
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_set_lwm, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->rx_queue_set_lwm)(dev,
> + queue_idx, lwm));
> +}
> +
> RTE_INIT(eth_dev_init_fp_ops)
> {
> uint32_t i;
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8e..f29e53b 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1249,8 +1249,12 @@ struct rte_eth_rxconf {
> */
> union rte_eth_rxseg *rx_seg;
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + uint64_t reserved_64s;
> + uint32_t reserved_32s;
> + uint32_t lwm:8;
> + uint32_t reserved_bits:24;
I strong dislike bit fields for such purpose. It should
be uint8_t field.
Since we break ABI below anyway, we can break it here as well.
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> +
No unrelated changes, please.
> };
>
> /**
> @@ -3668,6 +3672,29 @@ int rte_eth_dev_set_vlan_ether_type(uint16_t port_id,
> */
> int rte_eth_dev_set_vlan_pvid(uint16_t port_id, uint16_t pvid, int on);
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Set Rx queue based limit watermark.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param queue_idx
> + * The index of the receive queue
> + * @param lwm
> + * The limit watermark percentage of Rx queue descriptor size.
> + * The valid range is [0,99].
> + * Setting 0 means disable limit watermark.
> + *
> + * @return
> + * - (0) if successful.
> + * - negative if failed.
Please, be precise with negative return values specification
and its meaning.
> + */
> +__rte_experimental
> +int rte_eth_rx_queue_set_lwm(uint16_t port_id, uint16_t queue_idx,
> + uint8_t lwm);
> +
> typedef void (*buffer_tx_error_fn)(struct rte_mbuf **unsent, uint16_t count,
> void *userdata);
>
> @@ -3873,6 +3900,7 @@ enum rte_eth_event_type {
> RTE_ETH_EVENT_DESTROY, /**< port is released */
> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */
> RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
> + RTE_ETH_EVENT_RXQ_LIMIT_REACHED,/**< RX queue limit reached */
RX -> Rx
as I understand it is an ABI breakage.
> RTE_ETH_EVENT_MAX /**< max value of this enum */
> };
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 20391ab..8b85ad8 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -279,6 +279,9 @@ EXPERIMENTAL {
> rte_flow_async_action_handle_create;
> rte_flow_async_action_handle_destroy;
> rte_flow_async_action_handle_update;
> +
> + # added in 22.07
> + rte_eth_rx_queue_set_lwm;
> };
>
> INTERNAL {
^ permalink raw reply [relevance 4%]
* RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split
2022-05-17 21:12 3% ` Thomas Monjalon
@ 2022-05-19 14:40 0% ` Ding, Xuan
2022-05-26 14:58 0% ` Ding, Xuan
0 siblings, 1 reply; 200+ results
From: Ding, Xuan @ 2022-05-19 14:40 UTC (permalink / raw)
To: Thomas Monjalon, Wang, YuanX, Wu, WenxuanX
Cc: andrew.rybchenko, Li, Xiaoyun, ferruh.yigit, Singh, Aman Deep,
dev, Zhang, Yuying, Zhang, Qi Z, jerinjacobk, stephen, mb,
viacheslavo, Yu, Ping
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, May 18, 2022 5:12 AM
> To: Ding, Xuan <xuan.ding@intel.com>; Wang, YuanX
> <yuanx.wang@intel.com>; Wu, WenxuanX <wenxuanx.wu@intel.com>
> Cc: andrew.rybchenko@oktetlabs.ru; Li, Xiaoyun <xiaoyun.li@intel.com>;
> ferruh.yigit@xilinx.com; Singh, Aman Deep <aman.deep.singh@intel.com>;
> dev@dpdk.org; Zhang, Yuying <yuying.zhang@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>; jerinjacobk@gmail.com;
> stephen@networkplumber.org; mb@smartsharesystems.com;
> viacheslavo@nvidia.com; Yu, Ping <ping.yu@intel.com>
> Subject: Re: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer
> split
>
> Hello,
>
> It seems you didn't try to address my main comment on v4:
> "
> Before doing anything, the first patch of this series should make the current
> status clearer.
> Example, this line does not explain what it does:
> uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/ And
> header_split has been removed in ab3ce1e0c193 ("ethdev: remove old
> offload API")
>
> If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a comment
> to start a deprecation.
> "
Thank you for the detailed review.
First of all, I agree that header split should be deprecated.
Since it is unrelated with buffer split, I was planning to send the deprecation notice
in 22.07 sometime later and start the deprecation in 22.11.
If you think it should be the first step, I will send the deprecation notice first.
>
> Also the comment from Andrew about removing limitation to 2 packets is not
> addressed.
Secondly, it is said that the protocol based buffer split will divide the packet into two segments.
Because I thought it will only be used in the split between header and payload.
In fact, protocol based buffer split can support multi-segment split.
That is to say, like length-based buffer split, we define a series of protos,
as the split point of protocol based buffer split. And this series of protos,
like lengths, indicate the split location.
For example, a packet consists of MAC/IPV4/UDP/payload.
If we define the buffer split proto with IPV4, and UDP, the packet will be
split into three segments:
seg0: MAC and IPV4 header, 34 bytes
seg1: UDP header, 8 bytes
seg2: Payload, the actual payload size
What do you think of this design?
>
> All the part about the protocols capability is missing here.
Yes, I missed the protocols capability with RTE_PTYPE* now.
I will update the doc with supported protocol capability in v6.
>
> It is not encouraging.
>
> 26/04/2022 13:13, wenxuanx.wu@intel.com:
> > From: Wenxuan Wu <wenxuanx.wu@intel.com>
> >
> > Protocol based buffer split consists of splitting a received packet
> > into two separate regions based on its content. The split happens
> > after the packet protocol header and before the packet payload.
> > Splitting is usually between the packet protocol header that can be
> > posted to a dedicated buffer and the packet payload that can be posted to
> a different buffer.
> >
> > Currently, Rx buffer split supports length and offset based packet split.
> > protocol split is based on buffer split, configuring length of buffer
> > split is not suitable for NICs that do split based on protocol types.
>
> Why? Is it impossible to support length split on Intel NIC?
Yes, our NIC supports split based on protocol types. And I think there are other vendors too.
The existence of tunneling results in the composition of a packet is various.
Given a changeable length, it is impossible to tell the driver a fixed protocol type.
>
> > Because tunneling makes the conversion from length to protocol type
> > impossible.
>
> This is not a HW issue.
> I agree on the need but that a different usage than length split.
I think the new usage can solve this problem, so that length split
and proto split can have the same result.
>
> > This patch extends the current buffer split to support protocol and
> > offset based buffer split. A new proto field is introduced in the
> > rte_eth_rxseg_split structure reserved field to specify header
> > protocol type. With Rx queue offload
> RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
> > enabled and corresponding protocol type configured. PMD will split the
> ingress packets into two separate regions.
> > Currently, both inner and outer L2/L3/L4 level protocol based buffer
> > split can be supported.
> >
> > For example, let's suppose we configured the Rx queue with the
> > following segments:
> > seg0 - pool0, off0=2B
> > seg1 - pool1, off1=128B
> >
> > With protocol split type configured with RTE_PTYPE_L4_UDP. The packet
> > consists of MAC_IP_UDP_PAYLOAD will be splitted like following:
> > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0
> > seg1 - payload @ 128 in mbuf from pool1
>
> Not clear what is the calculation.
The previous usage of protocol based split is the split between header and payload.
Here for a packet composed of MAC_IP_UDP_PAYLOAD, with protocol split type RTE_PTYPE_L4_UDP
configured, it means split between the UDP header and payload.
In length configuration, the proto = RTE_PTYPE_L4_UDP means length = 42B.
>
> > The memory attributes for the split parts may differ either - for
> > example the mempool0 and mempool1 belong to dpdk memory and
> external
> > memory, respectively.
> >
> > Signed-off-by: Xuan Ding <xuan.ding@intel.com>
> > Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> > Signed-off-by: Wenxuan Wu <wenxuanx.wu@intel.com>
> > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > ---
> > lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++-------
> > lib/ethdev/rte_ethdev.h | 15 ++++++++++++++-
> > 2 files changed, 43 insertions(+), 8 deletions(-)
> >
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index
> > 29a3d80466..1a2bc172ab 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -1661,6 +1661,7 @@ rte_eth_rx_queue_check_split(const struct
> rte_eth_rxseg_split *rx_seg,
> > struct rte_mempool *mpl = rx_seg[seg_idx].mp;
> > uint32_t length = rx_seg[seg_idx].length;
> > uint32_t offset = rx_seg[seg_idx].offset;
> > + uint32_t proto = rx_seg[seg_idx].proto;
> >
> > if (mpl == NULL) {
> > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n");
> @@ -1694,13
> > +1695,34 @@ rte_eth_rx_queue_check_split(const struct
> rte_eth_rxseg_split *rx_seg,
> > }
> > offset += seg_idx != 0 ? 0 : RTE_PKTMBUF_HEADROOM;
> > *mbp_buf_size = rte_pktmbuf_data_room_size(mpl);
> > - length = length != 0 ? length : *mbp_buf_size;
> > - if (*mbp_buf_size < length + offset) {
> > - RTE_ETHDEV_LOG(ERR,
> > - "%s mbuf_data_room_size %u < %u
> (segment length=%u + segment offset=%u)\n",
> > - mpl->name, *mbp_buf_size,
> > - length + offset, length, offset);
> > - return -EINVAL;
> > + if (proto == 0) {
>
> Add a comment here, /* split at fixed length */
Thanks for the suggestion, will add it in next version.
>
> > + length = length != 0 ? length : *mbp_buf_size;
> > + if (*mbp_buf_size < length + offset) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "%s mbuf_data_room_size %u < %u
> (segment length=%u + segment offset=%u)\n",
> > + mpl->name, *mbp_buf_size,
> > + length + offset, length, offset);
> > + return -EINVAL;
> > + }
> > + } else {
>
> Add a comment here, /* split after specified protocol header */
Thanks for the suggestion, will add it in next version.
>
> > + /* Ensure n_seg is 2 in protocol based buffer split. */
> > + if (n_seg != 2) {
>
> (should be a space, not a tab before brace)
Get it.
>
> Why do you limit the feature to 2 segments only?
Please see the new usage explained above.
>
> > + RTE_ETHDEV_LOG(ERR, "number of buffer
> split protocol segments should be 2.\n");
> > + return -EINVAL;
> > + }
> > + /* Length and protocol are exclusive here, so make
> sure length is 0 in protocol
> > + based buffer split. */
> > + if (length != 0) {
> > + RTE_ETHDEV_LOG(ERR, "segment length
> should be set to zero in buffer split\n");
> > + return -EINVAL;
> > + }
> > + if (*mbp_buf_size < offset) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "%s
> mbuf_data_room_size %u < %u segment offset)\n",
> > + mpl->name, *mbp_buf_size,
> > + offset);
> > + return -EINVAL;
> [...]
> > + * - The proto in the elements defines the split position of received packets.
> > + *
> > * - If the length in the segment description element is zero
> > * the actual buffer size will be deduced from the appropriate
> > * memory pool properties.
> > @@ -1197,12 +1200,21 @@ struct rte_eth_txmode {
> > * - pool from the last valid element
> > * - the buffer size from this pool
> > * - zero offset
> > + *
> > + * - Length based buffer split:
> > + * - mp, length, offset should be configured.
> > + * - The proto should not be configured in length split. Zero default.
> > + *
> > + * - Protocol based buffer split:
> > + * - mp, offset, proto should be configured.
> > + * - The length should not be configured in protocol split. Zero default.
>
> What means "Zero default"?
> You should just ignore the non relevant field.
Yes, you are right, the none relevant field should be just ignored.
I will update the doc in v6.
>
> > struct rte_eth_rxseg_split {
> > struct rte_mempool *mp; /**< Memory pool to allocate segment
> from. */
> > uint16_t length; /**< Segment data length, configures split point. */
> > uint16_t offset; /**< Data offset from beginning of mbuf data buffer.
> */
> > - uint32_t reserved; /**< Reserved field. */
>
> How do you manage ABI compatibility?
> Was the reserved field initialized to 0 in previous versions?
I think we reached an agreement in RFC v1. There is no document for the reserved
field in the previous release. And it is always initialized to zero in real cases.
And now splitting based on fixed length and protocol header parsing is exclusive,
we can ignore the none relevant field.
>
> > + uint32_t proto; /**< Protocol of buffer split, determines protocol
> > +split point. */
>
> What are the values for "proto"?
Yes, I missed the protocol capability here, will fix it in v6.
>
> > @@ -1664,6 +1676,7 @@ struct rte_eth_conf {
> > RTE_ETH_RX_OFFLOAD_QINQ_STRIP) #define
> DEV_RX_OFFLOAD_VLAN
> > RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN) RTE_ETH_RX_OFFLOAD_VLAN
> >
> > +
>
> It looks to be an useless change.
Thanks for the catch, will fix it in next version.
Thanks again for your time.
Regards,
Xuan
>
> > /*
> > * If new Rx offload capabilities are defined, they also must be
> > * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> >
>
>
>
>
^ permalink raw reply [relevance 0%]
* [PATCH 00/40] cryptodev: rsa, dh, ecdh changes
@ 2022-05-20 5:54 3% Arek Kusztal
2022-05-20 5:54 8% ` [PATCH 02/40] cryptodev: remove list end enumerators Arek Kusztal
2022-05-20 7:30 0% ` [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Akhil Goyal
0 siblings, 2 replies; 200+ results
From: Arek Kusztal @ 2022-05-20 5:54 UTC (permalink / raw)
To: dev; +Cc: gakhil, anoobj, roy.fan.zhang, Arek Kusztal
This patchset introduces some of changes discussed on mailing list
for 22.07 release in cryptodev asym.
Key changes:
- It fixes API for RSA (expescially signature paddings)
- Adds Elliptic-Curve Diffie-Hellman
- Removes LIST_END enumerators (ABI issue - supressed asym_xform)
- Adds Eliiptic-Curve point verification (DH verification - but will be used only for EC)
- Adds RSA missing padding fields.
- Adds asym op flags
- Fixes many API comments (like EC curves)
Commits are grouped by functionality, and mostly independent.
Arek Kusztal (40):
cryptodev: redefine ec group enum
cryptodev: remove list end enumerators
test/crypto: remove list end enumerators
cryptodev: reduce number of comments in asym xform
test/crypto: removed asym xform none
cryptodev: separate key exchange operation enum
crypto/openssl: separate key exchange operation enum
test/crypto: separate key exchange operation enum
cryptodev: remove unnecessary zero assignement
cryptodev: remove comment about using ephemeral key in dsa
cryptodev: remove asym crypto next xform
crypto/openssl: remove asym crypto next xform
test/crypto: remove asym crypto next xform
app/test-crypto-perf: remove asym crypto next xform
app/test-eventdev: remove asym crypto next xform
cryptodev: move dh type from xform to dh op
crypto/openssl: move dh type from xform to dh op
test/crypto: move dh type from xform to dh op
cryptodev: changed order of dh fields
cryptodev: add elliptic curve diffie hellman
cryptodev: add public key verify option
cryptodev: move RSA padding into separate struct
crypto/qat: move RSA padding into separate struct
crypto/openssl: move RSA padding into separate struct
crypto/octeontx: move RSA padding into separate struct
crypto/cnxk: move RSA padding into separate struct
common/cpt: move RSA padding into separate struct
test/crypto: move RSA padding into separate struct
cryptodev: add salt length and optional label
cryptodev: reduce rsa struct to only necessary fields
crypto/qat: reduce rsa struct to only necessary fields
crypto/openssl: reduce rsa struct to only necessary fields
crypto/octeontx: reduce rsa struct to only necessary fields
crypto/cnxk: reduce rsa struct to only necessary fields
common/cpt: reduce rsa struct to only necessary fields
test/crypto: reduce rsa struct to only necessary fields
cryptodev: add asym op flags
cryptodev: clarify usage of private key in dh
crypto/openssl: generate dh private key
test/crypto: added test for dh priv key generation
app/test-crypto-perf/cperf_ops.c | 1 -
app/test-eventdev/test_perf_common.c | 1 -
app/test/test_cryptodev_asym.c | 117 +++++----
app/test/test_cryptodev_dh_test_vectors.h | 1 -
app/test/test_cryptodev_dsa_test_vectors.h | 1 -
app/test/test_cryptodev_mod_test_vectors.h | 2 -
app/test/test_cryptodev_rsa_test_vectors.h | 2 -
app/test/test_event_crypto_adapter.c | 4 -
devtools/libabigail.abignore | 2 +
drivers/common/cpt/cpt_ucode_asym.h | 12 +-
drivers/crypto/cnxk/cnxk_ae.h | 44 ++--
drivers/crypto/octeontx/otx_cryptodev_ops.c | 26 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 47 ++--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +--
drivers/crypto/qat/qat_asym.c | 28 +--
lib/cryptodev/rte_crypto_asym.h | 342 ++++++++++++++++-----------
lib/cryptodev/rte_cryptodev.c | 15 +-
17 files changed, 358 insertions(+), 320 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* [PATCH 02/40] cryptodev: remove list end enumerators
2022-05-20 5:54 3% [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Arek Kusztal
@ 2022-05-20 5:54 8% ` Arek Kusztal
2022-05-20 7:19 0% ` [EXT] " Akhil Goyal
2022-05-20 7:30 0% ` [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Arek Kusztal @ 2022-05-20 5:54 UTC (permalink / raw)
To: dev; +Cc: gakhil, anoobj, roy.fan.zhang, Arek Kusztal, mdr
- Removed LIST_END enumerators from asymmetric crypto API.
Adding new enum entries would require moving
LIST_END down, therefore changing its assigned number.
This would cause problems to ABI stability, so these
enums were removed.
Cc: mdr@ashroe.eu
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
devtools/libabigail.abignore | 2 ++
lib/cryptodev/rte_crypto_asym.h | 10 +++-------
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..f1945ce3b7 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,8 @@
; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
[suppress_type]
name = rte_crypto_asym_op
+[suppress_type]
+ name = rte_crypto_asym_xform_type
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 7206652458..a474b6acd1 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -95,10 +95,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm
* Perform Signature Generation and Verification.
*/
- RTE_CRYPTO_ASYM_XFORM_ECPM,
+ RTE_CRYPTO_ASYM_XFORM_ECPM
/**< Elliptic Curve Point Multiplication */
- RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
- /**< End of list */
};
/**
@@ -117,9 +115,8 @@ enum rte_crypto_asym_op_type {
/**< DH Private Key generation operation */
RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
/**< DH Public Key generation operation */
- RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
+ RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE
/**< DH Shared Secret compute operation */
- RTE_CRYPTO_ASYM_OP_LIST_END
};
/**
@@ -134,9 +131,8 @@ enum rte_crypto_rsa_padding_type {
*/
RTE_CRYPTO_RSA_PADDING_OAEP,
/**< RSA PKCS#1 OAEP padding scheme */
- RTE_CRYPTO_RSA_PADDING_PSS,
+ RTE_CRYPTO_RSA_PADDING_PSS
/**< RSA PKCS#1 PSS padding scheme */
- RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
};
/**
--
2.13.6
^ permalink raw reply [relevance 8%]
* RE: [EXT] [PATCH 02/40] cryptodev: remove list end enumerators
2022-05-20 5:54 8% ` [PATCH 02/40] cryptodev: remove list end enumerators Arek Kusztal
@ 2022-05-20 7:19 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-05-20 7:19 UTC (permalink / raw)
To: Arek Kusztal, dev; +Cc: Anoob Joseph, roy.fan.zhang, mdr
> - Removed LIST_END enumerators from asymmetric crypto API.
> Adding new enum entries would require moving
> LIST_END down, therefore changing its assigned number.
> This would cause problems to ABI stability, so these
> enums were removed.
>
> Cc: mdr@ashroe.eu
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
There was already a patch in patchworks but it need rework.
Can you look at this and address the comments
http://patches.dpdk.org/project/dpdk/patch/20211008204516.3497060-1-gakhil@marvell.com/
> devtools/libabigail.abignore | 2 ++
> lib/cryptodev/rte_crypto_asym.h | 10 +++-------
> 2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 79ff15dc4e..f1945ce3b7 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -27,6 +27,8 @@
> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> experimental
> [suppress_type]
> name = rte_crypto_asym_op
> +[suppress_type]
> + name = rte_crypto_asym_xform_type
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ; Temporary exceptions till next major ABI version ;
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 7206652458..a474b6acd1 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -95,10 +95,8 @@ enum rte_crypto_asym_xform_type {
> /**< Elliptic Curve Digital Signature Algorithm
> * Perform Signature Generation and Verification.
> */
> - RTE_CRYPTO_ASYM_XFORM_ECPM,
> + RTE_CRYPTO_ASYM_XFORM_ECPM
> /**< Elliptic Curve Point Multiplication */
> - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> - /**< End of list */
> };
>
> /**
> @@ -117,9 +115,8 @@ enum rte_crypto_asym_op_type {
> /**< DH Private Key generation operation */
> RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> /**< DH Public Key generation operation */
> - RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE
> /**< DH Shared Secret compute operation */
> - RTE_CRYPTO_ASYM_OP_LIST_END
> };
>
> /**
> @@ -134,9 +131,8 @@ enum rte_crypto_rsa_padding_type {
> */
> RTE_CRYPTO_RSA_PADDING_OAEP,
> /**< RSA PKCS#1 OAEP padding scheme */
> - RTE_CRYPTO_RSA_PADDING_PSS,
> + RTE_CRYPTO_RSA_PADDING_PSS
> /**< RSA PKCS#1 PSS padding scheme */
> - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> };
>
> /**
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes
2022-05-20 5:54 3% [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-20 5:54 8% ` [PATCH 02/40] cryptodev: remove list end enumerators Arek Kusztal
@ 2022-05-20 7:30 0% ` Akhil Goyal
2022-05-20 7:37 0% ` Kusztal, ArkadiuszX
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2022-05-20 7:30 UTC (permalink / raw)
To: Arek Kusztal, dev; +Cc: Anoob Joseph, roy.fan.zhang
> This patchset introduces some of changes discussed on mailing list
> for 22.07 release in cryptodev asym.
>
> Key changes:
>
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Removes LIST_END enumerators (ABI issue - supressed asym_xform)
> - Adds Eliiptic-Curve point verification (DH verification - but will be used only for
> EC)
> - Adds RSA missing padding fields.
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
>
> Commits are grouped by functionality, and mostly independent.
Please ensure all commits compile individually.
Also mark previous versions in patchworks as superseded.
>
> Arek Kusztal (40):
> cryptodev: redefine ec group enum
> cryptodev: remove list end enumerators
> test/crypto: remove list end enumerators
> cryptodev: reduce number of comments in asym xform
> test/crypto: removed asym xform none
> cryptodev: separate key exchange operation enum
> crypto/openssl: separate key exchange operation enum
> test/crypto: separate key exchange operation enum
> cryptodev: remove unnecessary zero assignement
> cryptodev: remove comment about using ephemeral key in dsa
> cryptodev: remove asym crypto next xform
> crypto/openssl: remove asym crypto next xform
> test/crypto: remove asym crypto next xform
> app/test-crypto-perf: remove asym crypto next xform
> app/test-eventdev: remove asym crypto next xform
> cryptodev: move dh type from xform to dh op
> crypto/openssl: move dh type from xform to dh op
> test/crypto: move dh type from xform to dh op
> cryptodev: changed order of dh fields
> cryptodev: add elliptic curve diffie hellman
> cryptodev: add public key verify option
> cryptodev: move RSA padding into separate struct
> crypto/qat: move RSA padding into separate struct
> crypto/openssl: move RSA padding into separate struct
> crypto/octeontx: move RSA padding into separate struct
> crypto/cnxk: move RSA padding into separate struct
> common/cpt: move RSA padding into separate struct
> test/crypto: move RSA padding into separate struct
> cryptodev: add salt length and optional label
> cryptodev: reduce rsa struct to only necessary fields
> crypto/qat: reduce rsa struct to only necessary fields
> crypto/openssl: reduce rsa struct to only necessary fields
> crypto/octeontx: reduce rsa struct to only necessary fields
> crypto/cnxk: reduce rsa struct to only necessary fields
> common/cpt: reduce rsa struct to only necessary fields
> test/crypto: reduce rsa struct to only necessary fields
> cryptodev: add asym op flags
> cryptodev: clarify usage of private key in dh
> crypto/openssl: generate dh private key
> test/crypto: added test for dh priv key generation
>
> app/test-crypto-perf/cperf_ops.c | 1 -
> app/test-eventdev/test_perf_common.c | 1 -
> app/test/test_cryptodev_asym.c | 117 +++++----
> app/test/test_cryptodev_dh_test_vectors.h | 1 -
> app/test/test_cryptodev_dsa_test_vectors.h | 1 -
> app/test/test_cryptodev_mod_test_vectors.h | 2 -
> app/test/test_cryptodev_rsa_test_vectors.h | 2 -
> app/test/test_event_crypto_adapter.c | 4 -
> devtools/libabigail.abignore | 2 +
> drivers/common/cpt/cpt_ucode_asym.h | 12 +-
> drivers/crypto/cnxk/cnxk_ae.h | 44 ++--
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 26 +-
> drivers/crypto/openssl/rte_openssl_pmd.c | 47 ++--
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +--
> drivers/crypto/qat/qat_asym.c | 28 +--
> lib/cryptodev/rte_crypto_asym.h | 342 ++++++++++++++++-----------
> lib/cryptodev/rte_cryptodev.c | 15 +-
> 17 files changed, 358 insertions(+), 320 deletions(-)
>
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes
2022-05-20 7:30 0% ` [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Akhil Goyal
@ 2022-05-20 7:37 0% ` Kusztal, ArkadiuszX
0 siblings, 0 replies; 200+ results
From: Kusztal, ArkadiuszX @ 2022-05-20 7:37 UTC (permalink / raw)
To: Akhil Goyal, dev; +Cc: Anoob Joseph, Zhang, Roy Fan
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Friday, May 20, 2022 9:30 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes
>
> > This patchset introduces some of changes discussed on mailing list for
> > 22.07 release in cryptodev asym.
> >
> > Key changes:
> >
> > - It fixes API for RSA (expescially signature paddings)
> > - Adds Elliptic-Curve Diffie-Hellman
> > - Removes LIST_END enumerators (ABI issue - supressed asym_xform)
> > - Adds Eliiptic-Curve point verification (DH verification - but will
> > be used only for
> > EC)
> > - Adds RSA missing padding fields.
> > - Adds asym op flags
> > - Fixes many API comments (like EC curves)
> >
> > Commits are grouped by functionality, and mostly independent.
>
> Please ensure all commits compile individually.
> Also mark previous versions in patchworks as superseded.
[Arek] - I will send v2 then, and I will fix all technical issues. Please verify if you are fine with changes proposed,. Most of these changes were already proposed in previous patches and in RFCs with no or minor problems found. Second patchset I would like to send contains capability changes and montgormery/Edwards curvers (would be good to have this in this release).
>
> >
> > Arek Kusztal (40):
> > cryptodev: redefine ec group enum
> > cryptodev: remove list end enumerators
> > test/crypto: remove list end enumerators
> > cryptodev: reduce number of comments in asym xform
> > test/crypto: removed asym xform none
> > cryptodev: separate key exchange operation enum
> > crypto/openssl: separate key exchange operation enum
> > test/crypto: separate key exchange operation enum
> > cryptodev: remove unnecessary zero assignement
> > cryptodev: remove comment about using ephemeral key in dsa
> > cryptodev: remove asym crypto next xform
> > crypto/openssl: remove asym crypto next xform
> > test/crypto: remove asym crypto next xform
> > app/test-crypto-perf: remove asym crypto next xform
> > app/test-eventdev: remove asym crypto next xform
> > cryptodev: move dh type from xform to dh op
> > crypto/openssl: move dh type from xform to dh op
> > test/crypto: move dh type from xform to dh op
> > cryptodev: changed order of dh fields
> > cryptodev: add elliptic curve diffie hellman
> > cryptodev: add public key verify option
> > cryptodev: move RSA padding into separate struct
> > crypto/qat: move RSA padding into separate struct
> > crypto/openssl: move RSA padding into separate struct
> > crypto/octeontx: move RSA padding into separate struct
> > crypto/cnxk: move RSA padding into separate struct
> > common/cpt: move RSA padding into separate struct
> > test/crypto: move RSA padding into separate struct
> > cryptodev: add salt length and optional label
> > cryptodev: reduce rsa struct to only necessary fields
> > crypto/qat: reduce rsa struct to only necessary fields
> > crypto/openssl: reduce rsa struct to only necessary fields
> > crypto/octeontx: reduce rsa struct to only necessary fields
> > crypto/cnxk: reduce rsa struct to only necessary fields
> > common/cpt: reduce rsa struct to only necessary fields
> > test/crypto: reduce rsa struct to only necessary fields
> > cryptodev: add asym op flags
> > cryptodev: clarify usage of private key in dh
> > crypto/openssl: generate dh private key
> > test/crypto: added test for dh priv key generation
> >
> > app/test-crypto-perf/cperf_ops.c | 1 -
> > app/test-eventdev/test_perf_common.c | 1 -
> > app/test/test_cryptodev_asym.c | 117 +++++----
> > app/test/test_cryptodev_dh_test_vectors.h | 1 -
> > app/test/test_cryptodev_dsa_test_vectors.h | 1 -
> > app/test/test_cryptodev_mod_test_vectors.h | 2 -
> > app/test/test_cryptodev_rsa_test_vectors.h | 2 -
> > app/test/test_event_crypto_adapter.c | 4 -
> > devtools/libabigail.abignore | 2 +
> > drivers/common/cpt/cpt_ucode_asym.h | 12 +-
> > drivers/crypto/cnxk/cnxk_ae.h | 44 ++--
> > drivers/crypto/octeontx/otx_cryptodev_ops.c | 26 +-
> > drivers/crypto/openssl/rte_openssl_pmd.c | 47 ++--
> > drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +--
> > drivers/crypto/qat/qat_asym.c | 28 +--
> > lib/cryptodev/rte_crypto_asym.h | 342 ++++++++++++++++-----------
> > lib/cryptodev/rte_cryptodev.c | 15 +-
> > 17 files changed, 358 insertions(+), 320 deletions(-)
> >
> > --
> > 2.13.6
^ permalink raw reply [relevance 0%]
* RE: [PATCH 04/12] net/ena: fix build with GCC 12
@ 2022-05-21 9:49 3% ` Morten Brørup
2022-05-21 16:23 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-05-21 9:49 UTC (permalink / raw)
To: Stephen Hemminger, David Marchand
Cc: dev, thomas, ferruh.yigit, stable, Marcin Wojtas,
Michal Krawczyk, Shai Brandes, Evgeny Schemeilin, Igor Chauskin
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, 20 May 2022 22.28
>
> On Wed, 18 May 2022 12:16:49 +0200
> David Marchand <david.marchand@redhat.com> wrote:
>
> > + for (i = 0; i < RTE_DIM(default_key); ++i)
> > default_key[i] = rte_rand() & 0xff;
>
> We should have rte_random_bytes() functionality if this gets
> used often.
Since the other pseudorandom functions are called rand, such a function should be named rte_rand_bytes().
>
> Also, worth considering dropping DPDK random number generator
> in userspace for security reasons and just using more secure kernel
> code.
Absolutely not! We need a fast pseudorandom number generator in DPDK.
If anything, we could consider renaming the functions and header file to reflect that they are pseudorandom number generators, and not (cryptographically) random generators. That would cause an API/ABI breakage, so it's probably not going to happen. ;-)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events
@ 2022-05-21 10:33 0% ` fengchengwen
2022-05-24 15:11 0% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: fengchengwen @ 2022-05-21 10:33 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: Ferruh Yigit, Kalesh A P, dev, ajit.khaparde, asafp,
David Marchand, Andrew Rybchenko, lizhenyi1, shuliubin 00419723
Hi all,
This patch lasts for a long time. Are we waiting for 22.11 to deal with it?
We have the same requirements for the reset or recovery mechanism, but there are differences:
APP PMD
| |
| detect error
| <---report error event--- |
| |
do error stats |
and report |
| ---start recover--> |
| do recover
| <---report recover result |
| |
if succ just log
else may migrate
service
Can we generalize these processes(means that the implementation is at the framework layer)? or only at PMD API?
On 2022/2/15 0:06, Ray Kinsella wrote:
>
> Thomas Monjalon <thomas@monjalon.net> writes:
>
>> 14/02/2022 11:16, Ray Kinsella:
>>> Ray Kinsella <mdr@ashroe.eu> writes:
>>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>>> 02/02/2022 12:44, Ray Kinsella:
>>>>>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>>>>>> On 1/28/2022 12:48 PM, Kalesh A P wrote:
>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>> @@ -3818,6 +3818,24 @@ enum rte_eth_event_type {
>>>>>>>> RTE_ETH_EVENT_DESTROY, /**< port is released */
>>>>>>>> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */
>>>>>>>> RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
>>>>>>>> + RTE_ETH_EVENT_ERR_RECOVERING,
>>>>>>>> + /**< port recovering from an error
>>>>>>>> + *
>>>>>>>> + * PMD detected a FW reset or error condition.
>>>>>>>> + * PMD will try to recover from the error.
>>>>>>>> + * Data path may be quiesced and Control path operations
>>>>>>>> + * may fail at this time.
>>>>>>>> + */
>>>>>>>> + RTE_ETH_EVENT_RECOVERED,
>>>>>>>> + /**< port recovered from an error
>>>>>>>> + *
>>>>>>>> + * PMD has recovered from the error condition.
>>>>>>>> + * Control path and Data path are up now.
>>>>>>>> + * PMD re-configures the port to the state prior to the error.
>>>>>>>> + * Since the device has undergone a reset, flow rules
>>>>>>>> + * offloaded prior to reset may be lost and
>>>>>>>> + * the application should recreate the rules again.
>>>>>>>> + */
>>>>>>>> RTE_ETH_EVENT_MAX /**< max value of this enum */
>>>>>>>
>>>>>>>
>>>>>>> Also ABI check complains about 'RTE_ETH_EVENT_MAX' value check, cc'ed more people
>>>>>>> to evaluate if it is a false positive:
>>>>>>>
>>>>>>>
>>>>>>> 1 function with some indirect sub-type change:
>>>>>>> [C] 'function int rte_eth_dev_callback_register(uint16_t, rte_eth_event_type, rte_eth_dev_cb_fn, void*)' at rte_ethdev.c:4637:1 has some indirect sub-type changes:
>>>>>>> parameter 3 of type 'typedef rte_eth_dev_cb_fn' has sub-type changes:
>>>>>>> underlying type 'int (typedef uint16_t, enum rte_eth_event_type, void*, void*)*' changed:
>>>>>>> in pointed to type 'function type int (typedef uint16_t, enum rte_eth_event_type, void*, void*)':
>>>>>>> parameter 2 of type 'enum rte_eth_event_type' has sub-type changes:
>>>>>>> type size hasn't changed
>>>>>>> 2 enumerator insertions:
>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_ERR_RECOVERING' value '11'
>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_RECOVERED' value '12'
>>>>>>> 1 enumerator change:
>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_MAX' from value '11' to '13' at rte_ethdev.h:3807:1
>>>>>>
>>>>>> I don't immediately see the problem that this would cause.
>>>>>> There are no array sizes etc dependent on the value of MAX for instance.
>>>>>>
>>>>>> Looks safe?
>>>>>
>>>>> We never know how this enum will be used by the application.
>>>>> The max value may be used for the size of an event array.
>>>>> It looks a real ABI issue unfortunately.
>>>>
>>>> Right - but we only really care about it when an array size based on MAX
>>>> is likely to be passed to DPDK, which doesn't apply in this case.
>>
>> I don't completely agree.
>> A developer may assume an event will never exceed MAX value.
>> However, after an upgrade of DPDK without app rebuild,
>> a higher event value may be received in the app,
>> breaking the assumption.
>> Should we consider this case as an ABI breakage?
>
> Nope - I think we should explicitly exclude MAX values from any
> ABI guarantee, as being able to change them is key to our be able to
> evolve DPDK while maintaining ABI stability.
>
> Consider what it means applying the ABI policy to a MAX value, you are
> in effect saying that that no value can be added to this enumeration
> until the next ABI version, for me this is very restrictive without a
> solid reason.
>
>>
>>>> I noted that some Linux folks explicitly mark similar MAX values as not
>>>> part of the ABI.
>>>>
>>>> /usr/include/linux/perf_event.h
>>>> 37: PERF_TYPE_MAX, /* non-ABI */
>>>> 60: PERF_COUNT_HW_MAX, /* non-ABI */
>>>> 79: PERF_COUNT_HW_CACHE_MAX, /* non-ABI */
>>>> 87: PERF_COUNT_HW_CACHE_OP_MAX, /* non-ABI */
>>>> 94: PERF_COUNT_HW_CACHE_RESULT_MAX, /* non-ABI */
>>>> 116: PERF_COUNT_SW_MAX, /* non-ABI */
>>>> 149: PERF_SAMPLE_MAX = 1U << 24, /* non-ABI */
>>>> 151: __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /*
>>>> non-ABI; internal use */
>>>> 189: PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */
>>>> 267: PERF_TXN_MAX = (1 << 8), /* non-ABI */
>>>> 301: PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
>>>> 1067: PERF_RECORD_MAX, /* non-ABI */
>>>> 1078: PERF_RECORD_KSYMBOL_TYPE_MAX /* non-ABI */
>>>> 1087: PERF_BPF_EVENT_MAX, /* non-ABI */
>>>
>>> Any thoughts on similarly annotating all our _MAX enums in the same way?
>>> We could also add a section in the ABI Policy to make it explicit _MAX
>>> enum values are not part of the ABI - what do folks think?
>>
>> Interesting. I am not sure it is always ABI-safe though.
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH 04/12] net/ena: fix build with GCC 12
2022-05-21 9:49 3% ` Morten Brørup
@ 2022-05-21 16:23 0% ` Stephen Hemminger
2022-05-22 20:30 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-05-21 16:23 UTC (permalink / raw)
To: Morten Brørup
Cc: David Marchand, dev, thomas, ferruh.yigit, stable, Marcin Wojtas,
Michal Krawczyk, Shai Brandes, Evgeny Schemeilin, Igor Chauskin
On Sat, 21 May 2022 11:49:47 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > Also, worth considering dropping DPDK random number generator
> > in userspace for security reasons and just using more secure kernel
> > code.
>
> Absolutely not! We need a fast pseudorandom number generator in DPDK.
>
> If anything, we could consider renaming the functions and header file to reflect that they are pseudorandom number generators, and not (cryptographically) random generators. That would cause an API/ABI breakage, so it's probably not going to happen. ;-)
The Linux kernel has received an way more attention on random numbers than
DPDK. If you follow the history, what happens is that a simple dumb LCG
or similar random number generator gets invented, and then gets used for
lots of things that people don't think need a strong generator.
Followed by DoS and other attacks where the weak random number generator
is broken when used for doing things like creating sequence numbers of
TCP port assignment. This is then followed by even more work on the
kernel random number generator to make the default random number generator
stronger.
I bring up this history, so that DPDK won't have to repeat it.
Right now the DPDK random number generator is insecure because it uses
long but weak PRNG and never reseeds itself.
See:
https://lwn.net/Articles/884875/
There is also FIPS to consider.
https://lwn.net/Articles/877607/
Since random number generators are hard, prefer that someone else do it :-)
^ permalink raw reply [relevance 0%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
@ 2022-05-22 15:23 3% ` Stephen Hemminger
2022-05-23 3:01 0% ` Spike Du
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-05-22 15:23 UTC (permalink / raw)
To: Spike Du; +Cc: matan, viacheslavo, orika, thomas, dev, rasland
On Sun, 22 May 2022 08:58:56 +0300
Spike Du <spiked@nvidia.com> wrote:
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8ee10..687ae5ff29 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> */
> union rte_eth_rxseg *rx_seg;
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + /**
> + * Per-queue Rx limit watermark defined as percentage of Rx queue
> + * size. If Rx queue receives traffic higher than this percentage,
> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> + */
> + uint8_t lwm;
> +
> + uint8_t reserved_bits[3];
> + uint32_t reserved_32s;
> + uint64_t reserved_64s;
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> };
>
Ok but, this is an ABI risk about this because reserved stuff was never required before.
Whenever is a reserved field is introduced the code (in this case rte_ethdev_configure).
Best practice would have been to have the code require all reserved fields be 0
in earlier releases. In this case an application is like to define a watermark
of zero; how will your code handle it.
Also, using 8 bits as percentage is different than how other API's handle this.
Since Rx queue size is in packets, why is this not in packets?
Also document what behavior of 0 is.
Why introduce new query/set operations? This should just be part of the overall
device configuration.
^ permalink raw reply [relevance 3%]
* RE: [PATCH 04/12] net/ena: fix build with GCC 12
2022-05-21 16:23 0% ` Stephen Hemminger
@ 2022-05-22 20:30 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-05-22 20:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Marchand, dev, thomas, ferruh.yigit, stable, Marcin Wojtas,
Michal Krawczyk, Shai Brandes, Evgeny Schemeilin, Igor Chauskin
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, 21 May 2022 18.24
>
> On Sat, 21 May 2022 11:49:47 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > >
> > > Also, worth considering dropping DPDK random number generator
> > > in userspace for security reasons and just using more secure kernel
> > > code.
> >
> > Absolutely not! We need a fast pseudorandom number generator in DPDK.
> >
> > If anything, we could consider renaming the functions and header file
> to reflect that they are pseudorandom number generators, and not
> (cryptographically) random generators. That would cause an API/ABI
> breakage, so it's probably not going to happen. ;-)
>
>
> The Linux kernel has received an way more attention on random numbers
> than
> DPDK. If you follow the history, what happens is that a simple dumb LCG
> or similar random number generator gets invented, and then gets used
> for
> lots of things that people don't think need a strong generator.
>
> Followed by DoS and other attacks where the weak random number
> generator
> is broken when used for doing things like creating sequence numbers of
> TCP port assignment. This is then followed by even more work on the
> kernel random number generator to make the default random number
> generator
> stronger.
>
> I bring up this history, so that DPDK won't have to repeat it.
>
> Right now the DPDK random number generator is insecure because it uses
> long but weak PRNG and never reseeds itself.
>
> See:
> https://lwn.net/Articles/884875/
>
> There is also FIPS to consider.
> https://lwn.net/Articles/877607/
>
> Since random number generators are hard, prefer that someone else do it
> :-)
First of all, I would like to thank you for the history lesson and references, Stephen, it made my Saturday evening much more nerdy and interesting than expected! Not being a native English speaker, please understand that I mean this sincerely. I really enjoyed reading about this corner of the Linux kernel history.
Overall, I think that RNGs generally fall into two categories: Unsafe (regardless how advanced) and safe for crypto use.
It should be OK for DPDK to provide something blazing fast, but unsafe. The DPDK documentation clearly states that the provided random functions are not safe for crypto, so I would expect the developers to use them accordingly.
Having thought about it, I came to this conclusion: Regardless if we provide unsafe RNG functions in DPDK or not, it is ultimately up to the application developers to choose which RNG category to use for different purposes. If we don't provide something fast, developers will just use the standard rand48() functions or similar. And a blazing fast (but unsafe) RNG is useful for simple things like pseudo-random packet sampling in the data plane.
Who would have thought that using a simple RNG for TCP port assignment could end up being a security problem... The developers will always have a choice between secure and fast, and the risk of a developer making the wrong decision is not affected by DPDK providing some unsafe RNG or not.
At a higher level, I come to think of the RFCs, which all have a Security Considerations chapter. Ideally, all patches had such a chapter, and all reviews considered the security aspects, so someone would catch the use of an unsafe RNG where a safe RNG should be used. Removing the rand() functions from DPDK will not have the desired effect, only raising security awareness will.
And just to leave off where you left off: I 100 % agree that we should not try to invent our own crypto safe RNG!
PS: I assume that safe RNGs cannot generate numbers at the same rate as unsafe RNGs. If this was not generally true, there should be no need to use unsafe RNGs (except for test purposes, where reproducibility is a requirement).
In cases where the safe RNG can generate numbers at a sufficiently high rate, why not use it? This, however, requires that the application developer knows both the required rate and the rate of the safe RNG, which I guess very few developers do.
^ permalink raw reply [relevance 0%]
* RE: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-22 15:23 3% ` Stephen Hemminger
@ 2022-05-23 3:01 0% ` Spike Du
2022-05-23 21:45 4% ` Thomas Monjalon
2022-05-23 22:54 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Spike Du @ 2022-05-23 3:01 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
dev, Raslan Darawsheh
Hi, pls see below.
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, May 22, 2022 11:23 PM
> To: Spike Du <spiked@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dev@dpdk.org;
> Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
>
> External email: Use caution opening links or attachments
>
>
> On Sun, 22 May 2022 08:58:56 +0300
> Spike Du <spiked@nvidia.com> wrote:
>
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > 04cff8ee10..687ae5ff29 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > */
> > union rte_eth_rxseg *rx_seg;
> >
> > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > + /**
> > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > + * size. If Rx queue receives traffic higher than this percentage,
> > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > + */
> > + uint8_t lwm;
> > +
> > + uint8_t reserved_bits[3];
> > + uint32_t reserved_32s;
> > + uint64_t reserved_64s;
> > void *reserved_ptrs[2]; /**< Reserved for future fields */
> > };
> >
>
> Ok but, this is an ABI risk about this because reserved stuff was never
> required before.
> Whenever is a reserved field is introduced the code (in this case
> rte_ethdev_configure).
>
> Best practice would have been to have the code require all reserved fields be
> 0 in earlier releases. In this case an application is like to define a watermark of
> zero; how will your code handle it.
Having watermark of 0 is desired, which is the default. LWM of 0 means the Rx
Queue's watermark is not monitored, hence no LWM event is generated.
>
> Also, using 8 bits as percentage is different than how other API's handle this.
> Since Rx queue size is in packets, why is this not in packets?
The short answer is to simply the LWM configuration.
Rx queue descriptor is complex nowadays.
For normal queue, user may configure LWM according to queue descriptor number easily.
But for below queues, it's not easy:
Take mprq as example, the testpmd cmd options can be " -a 0000:03:00.0,rxqs_min_mprq=1,mprq_en=1,mprq_max_memcpy_len=465,mprq_log_stride_size=8,mprq_log_stride_num=3
-- --mbcache=512 -i --nb-cores=7 --txd=1024 --rxd=1024 ",
For MLX5 implementation, the minimum "unit" in queue has 64 descriptors, the "unit" number is 16, if you configure according to descriptor number(1024)
Here, you may easily set LWM as something like 512, but HW doesn't allow it, because 512 > 16. If you want the watermark to be half, the correct value is 8.
The same issue happens to feature like "Rx queue buffer split" where a packet can be split to multiple descriptors.
Using percentage doesn't have such issues, PMD will cover all the details.
> Also document what behavior of 0 is.
Sure. The behavior is like the old days without this feature, pls see above.
> Why introduce new query/set operations? This should just be part of the
> overall device configuration.
Due to different implementation. LWM can be a dynamic configuration which can help user design a flexible flow control.
User may feel ok with LWM of 80% to get high throughput, or later on with 50% to throttle the traffic responsively by handling LWM event in order to reduce drop.
Some driver like mlx5 may implement LWM event as one-time shot. When you receive LWM event, you need to reconfigure LWM in order to receive the event again, thus you will
not likely to be overwhelmed by the events.
These all require set operation.
For the query operation. The rte_event API rte_eth_dev_callback_process() is per-port API, it doesn't carry much information when an event happens.
When a LWM event happens, we need to know in which Rx queue it happens or optionally what's the current LWM percentage of this queue.
The query operation serves this purpose.
Regards,
Spike.
^ permalink raw reply [relevance 0%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-23 3:01 0% ` Spike Du
@ 2022-05-23 21:45 4% ` Thomas Monjalon
2022-05-24 2:50 3% ` Spike Du
2022-05-23 22:54 0% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-23 21:45 UTC (permalink / raw)
To: Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit, andrew.rybchenko
23/05/2022 05:01, Spike Du:
> From: Stephen Hemminger <stephen@networkplumber.org>
> > Spike Du <spiked@nvidia.com> wrote:
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > */
> > > union rte_eth_rxseg *rx_seg;
> > >
> > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > + /**
> > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > + * size. If Rx queue receives traffic higher than this percentage,
> > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > + */
> > > + uint8_t lwm;
> > > +
> > > + uint8_t reserved_bits[3];
> > > + uint32_t reserved_32s;
> > > + uint64_t reserved_64s;
> >
> > Ok but, this is an ABI risk about this because reserved stuff was never
> > required before.
An ABI compatibility issue would be for an application compiled
with an old DPDK, and loading a new DPDK at runtime.
Let's think what would happen in such a case.
> > Whenever is a reserved field is introduced the code (in this case
> > rte_ethdev_configure).
rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
Then the library and drivers may interpret a wrong value.
> > Best practice would have been to have the code require all reserved fields be
> > 0 in earlier releases. In this case an application is like to define a watermark of
> > zero; how will your code handle it.
>
> Having watermark of 0 is desired, which is the default. LWM of 0 means the Rx
> Queue's watermark is not monitored, hence no LWM event is generated.
The problem is to have a value not initialized.
I think the best approach is to not expose the LWM value
through this configuration structure.
If the need is to get the current value,
we should better add a field in the struct rte_eth_rxq_info.
[...]
>
> > Why introduce new query/set operations? This should just be part of the
> > overall device configuration.
Thanks to the "set" function, we can avoid the ABI compat issue.
> Due to different implementation. LWM can be a dynamic configuration which can help user design a flexible flow control.
> User may feel ok with LWM of 80% to get high throughput, or later on with 50% to throttle the traffic responsively by handling LWM event in order to reduce drop.
> Some driver like mlx5 may implement LWM event as one-time shot. When you receive LWM event, you need to reconfigure LWM in order to receive the event again, thus you will
> not likely to be overwhelmed by the events.
> These all require set operation.
Yes it is better to allow dynamic watermark configuration,
not using the function rte_eth_rx_queue_setup().
> For the query operation. The rte_event API rte_eth_dev_callback_process() is per-port API, it doesn't carry much information when an event happens.
> When a LWM event happens, we need to know in which Rx queue it happens or optionally what's the current LWM percentage of this queue.
> The query operation serves this purpose.
Yes "query" has to be called in the event handler
because event structure is not specific to any event type.
^ permalink raw reply [relevance 4%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-23 3:01 0% ` Spike Du
2022-05-23 21:45 4% ` Thomas Monjalon
@ 2022-05-23 22:54 0% ` Stephen Hemminger
2022-05-24 3:46 0% ` Spike Du
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-05-23 22:54 UTC (permalink / raw)
To: Spike Du
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
dev, Raslan Darawsheh
On Mon, 23 May 2022 03:01:20 +0000
Spike Du <spiked@nvidia.com> wrote:
> Hi, pls see below.
>
> > -----Original Message-----
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Sunday, May 22, 2022 11:23 PM
> > To: Spike Du <spiked@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dev@dpdk.org;
> > Raslan Darawsheh <rasland@nvidia.com>
> > Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Sun, 22 May 2022 08:58:56 +0300
> > Spike Du <spiked@nvidia.com> wrote:
> >
> > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > > 04cff8ee10..687ae5ff29 100644
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > */
> > > union rte_eth_rxseg *rx_seg;
> > >
> > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > + /**
> > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > + * size. If Rx queue receives traffic higher than this percentage,
> > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > + */
> > > + uint8_t lwm;
> > > +
> > > + uint8_t reserved_bits[3];
> > > + uint32_t reserved_32s;
> > > + uint64_t reserved_64s;
> > > void *reserved_ptrs[2]; /**< Reserved for future fields */
> > > };
> > >
> >
> > Ok but, this is an ABI risk about this because reserved stuff was never
> > required before.
> > Whenever is a reserved field is introduced the code (in this case
> > rte_ethdev_configure).
> >
> > Best practice would have been to have the code require all reserved fields be
> > 0 in earlier releases. In this case an application is like to define a watermark of
> > zero; how will your code handle it.
> Having watermark of 0 is desired, which is the default. LWM of 0 means the Rx
> Queue's watermark is not monitored, hence no LWM event is generated.
> >
> > Also, using 8 bits as percentage is different than how other API's handle this.
> > Since Rx queue size is in packets, why is this not in packets?
> The short answer is to simply the LWM configuration.
> Rx queue descriptor is complex nowadays.
> For normal queue, user may configure LWM according to queue descriptor number easily.
> But for below queues, it's not easy:
> Take mprq as example, the testpmd cmd options can be " -a 0000:03:00.0,rxqs_min_mprq=1,mprq_en=1,mprq_max_memcpy_len=465,mprq_log_stride_size=8,mprq_log_stride_num=3
> -- --mbcache=512 -i --nb-cores=7 --txd=1024 --rxd=1024 ",
> For MLX5 implementation, the minimum "unit" in queue has 64 descriptors, the "unit" number is 16, if you configure according to descriptor number(1024)
> Here, you may easily set LWM as something like 512, but HW doesn't allow it, because 512 > 16. If you want the watermark to be half, the correct value is 8.
> The same issue happens to feature like "Rx queue buffer split" where a packet can be split to multiple descriptors.
> Using percentage doesn't have such issues, PMD will cover all the details.
>
> > Also document what behavior of 0 is.
> Sure. The behavior is like the old days without this feature, pls see above.
>
> > Why introduce new query/set operations? This should just be part of the
> > overall device configuration.
> Due to different implementation. LWM can be a dynamic configuration which can help user design a flexible flow control.
> User may feel ok with LWM of 80% to get high throughput, or later on with 50% to throttle the traffic responsively by handling LWM event in order to reduce drop.
> Some driver like mlx5 may implement LWM event as one-time shot. When you receive LWM event, you need to reconfigure LWM in order to receive the event again, thus you will
> not likely to be overwhelmed by the events.
> These all require set operation.
>
> For the query operation. The rte_event API rte_eth_dev_callback_process() is per-port API, it doesn't carry much information when an event happens.
> When a LWM event happens, we need to know in which Rx queue it happens or optionally what's the current LWM percentage of this queue.
> The query operation serves this purpose.
>
>
> Regards,
> Spike.
>
>
The bigger question is why does this have to be just MLX5 and why
can't it fit into the existing DPDK RX interrupt framework?
Linux and BSD have had this for years in their packet coalescing logic.
Ethtool provides ability to set lot of irq coalescing parameters like:
ethtool -C|--coalesce devname [adaptive-rx on|off] [adaptive-tx on|off]
[rx-usecs N] [rx-frames N] [rx-usecs-irq N] [rx-frames-irq N]
[tx-usecs N] [tx-frames N] [tx-usecs-irq N] [tx-frames-irq N]
[stats-block-usecs N] [pkt-rate-low N] [rx-usecs-low N]
[rx-frames-low N] [tx-usecs-low N] [tx-frames-low N]
[pkt-rate-high N] [rx-usecs-high N] [rx-frames-high N]
[tx-usecs-high N] [tx-frames-high N] [sample-interval N]
[cqe-mode-rx on|off] [cqe-mode-tx on|off]
It feels like this is just the DPDK version of a small subset of that.
Since many device already support IRQ coalescing, it would be best to build
one new API that has most of these. Rather than a MLX/Nvidia only API for
a single parameter.
^ permalink raw reply [relevance 0%]
* RE: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-23 21:45 4% ` Thomas Monjalon
@ 2022-05-24 2:50 3% ` Spike Du
2022-05-24 8:18 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Spike Du @ 2022-05-24 2:50 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL), Stephen Hemminger
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit, andrew.rybchenko
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, May 24, 2022 5:46 AM
> To: Stephen Hemminger <stephen@networkplumber.org>; Spike Du
> <spiked@nvidia.com>
> Cc: dev@dpdk.org; Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; ferruh.yigit@amd.com;
> andrew.rybchenko@oktetlabs.ru
> Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
>
> External email: Use caution opening links or attachments
>
>
> 23/05/2022 05:01, Spike Du:
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > > Spike Du <spiked@nvidia.com> wrote:
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > > */
> > > > union rte_eth_rxseg *rx_seg;
> > > >
> > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > > + /**
> > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > > + * size. If Rx queue receives traffic higher than this percentage,
> > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > > + */
> > > > + uint8_t lwm;
> > > > +
> > > > + uint8_t reserved_bits[3];
> > > > + uint32_t reserved_32s;
> > > > + uint64_t reserved_64s;
> > >
> > > Ok but, this is an ABI risk about this because reserved stuff was
> > > never required before.
>
> An ABI compatibility issue would be for an application compiled with an old
> DPDK, and loading a new DPDK at runtime.
> Let's think what would happen in such a case.
>
> > > Whenever is a reserved field is introduced the code (in this case
> > > rte_ethdev_configure).
>
> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> Then the library and drivers may interpret a wrong value.
>
> > > Best practice would have been to have the code require all reserved
> > > fields be
> > > 0 in earlier releases. In this case an application is like to define
> > > a watermark of zero; how will your code handle it.
> >
> > Having watermark of 0 is desired, which is the default. LWM of 0 means
> > the Rx Queue's watermark is not monitored, hence no LWM event is
> generated.
>
> The problem is to have a value not initialized.
> I think the best approach is to not expose the LWM value through this
> configuration structure.
> If the need is to get the current value, we should better add a field in the
> struct rte_eth_rxq_info.
At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
The Rx queue, if user follows these examples we should not have ABI issue.
Since many people are concerned about rxconf change, it's ok to remove the LWM
Field there.
Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
We should have a way to get it.
>
> [...]
> >
> > > Why introduce new query/set operations? This should just be part of
> > > the overall device configuration.
>
> Thanks to the "set" function, we can avoid the ABI compat issue.
>
> > Due to different implementation. LWM can be a dynamic configuration
> which can help user design a flexible flow control.
> > User may feel ok with LWM of 80% to get high throughput, or later on with
> 50% to throttle the traffic responsively by handling LWM event in order to
> reduce drop.
> > Some driver like mlx5 may implement LWM event as one-time shot. When
> > you receive LWM event, you need to reconfigure LWM in order to receive
> the event again, thus you will not likely to be overwhelmed by the events.
> > These all require set operation.
>
> Yes it is better to allow dynamic watermark configuration, not using the
> function rte_eth_rx_queue_setup().
>
> > For the query operation. The rte_event API
> rte_eth_dev_callback_process() is per-port API, it doesn't carry much
> information when an event happens.
> > When a LWM event happens, we need to know in which Rx queue it
> happens or optionally what's the current LWM percentage of this queue.
> > The query operation serves this purpose.
>
> Yes "query" has to be called in the event handler because event structure is
> not specific to any event type.
>
>
^ permalink raw reply [relevance 3%]
* RE: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-23 22:54 0% ` Stephen Hemminger
@ 2022-05-24 3:46 0% ` Spike Du
0 siblings, 0 replies; 200+ results
From: Spike Du @ 2022-05-24 3:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
dev, Raslan Darawsheh
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, May 24, 2022 6:55 AM
> To: Spike Du <spiked@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dev@dpdk.org;
> Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
>
> External email: Use caution opening links or attachments
>
>
> On Mon, 23 May 2022 03:01:20 +0000
> Spike Du <spiked@nvidia.com> wrote:
>
> > Hi, pls see below.
> >
> > > -----Original Message-----
> > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > Sent: Sunday, May 22, 2022 11:23 PM
> > > To: Spike Du <spiked@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dev@dpdk.org;
> > > Raslan Darawsheh <rasland@nvidia.com>
> > > Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit
> > > watermark
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Sun, 22 May 2022 08:58:56 +0300
> > > Spike Du <spiked@nvidia.com> wrote:
> > >
> > > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> > > > index
> > > > 04cff8ee10..687ae5ff29 100644
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > > */
> > > > union rte_eth_rxseg *rx_seg;
> > > >
> > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > > + /**
> > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > > + * size. If Rx queue receives traffic higher than this percentage,
> > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > > + */
> > > > + uint8_t lwm;
> > > > +
> > > > + uint8_t reserved_bits[3];
> > > > + uint32_t reserved_32s;
> > > > + uint64_t reserved_64s;
> > > > void *reserved_ptrs[2]; /**< Reserved for future fields */
> > > > };
> > > >
> > >
> > > Ok but, this is an ABI risk about this because reserved stuff was
> > > never required before.
> > > Whenever is a reserved field is introduced the code (in this case
> > > rte_ethdev_configure).
> > >
> > > Best practice would have been to have the code require all reserved
> > > fields be
> > > 0 in earlier releases. In this case an application is like to define
> > > a watermark of zero; how will your code handle it.
> > Having watermark of 0 is desired, which is the default. LWM of 0 means
> > the Rx Queue's watermark is not monitored, hence no LWM event is
> generated.
> > >
> > > Also, using 8 bits as percentage is different than how other API's handle
> this.
> > > Since Rx queue size is in packets, why is this not in packets?
> > The short answer is to simply the LWM configuration.
> > Rx queue descriptor is complex nowadays.
> > For normal queue, user may configure LWM according to queue descriptor
> number easily.
> > But for below queues, it's not easy:
> > Take mprq as example, the testpmd cmd options can be " -a
> >
> 0000:03:00.0,rxqs_min_mprq=1,mprq_en=1,mprq_max_memcpy_len=465,
> mprq_lo
> > g_stride_size=8,mprq_log_stride_num=3
> > -- --mbcache=512 -i --nb-cores=7 --txd=1024 --rxd=1024 ", For MLX5
> > implementation, the minimum "unit" in queue has 64 descriptors, the
> > "unit" number is 16, if you configure according to descriptor number(1024)
> Here, you may easily set LWM as something like 512, but HW doesn't allow it,
> because 512 > 16. If you want the watermark to be half, the correct value is 8.
> > The same issue happens to feature like "Rx queue buffer split" where a
> packet can be split to multiple descriptors.
> > Using percentage doesn't have such issues, PMD will cover all the details.
> >
> > > Also document what behavior of 0 is.
> > Sure. The behavior is like the old days without this feature, pls see above.
> >
> > > Why introduce new query/set operations? This should just be part of
> > > the overall device configuration.
> > Due to different implementation. LWM can be a dynamic configuration
> which can help user design a flexible flow control.
> > User may feel ok with LWM of 80% to get high throughput, or later on with
> 50% to throttle the traffic responsively by handling LWM event in order to
> reduce drop.
> > Some driver like mlx5 may implement LWM event as one-time shot. When
> > you receive LWM event, you need to reconfigure LWM in order to receive
> the event again, thus you will not likely to be overwhelmed by the events.
> > These all require set operation.
> >
> > For the query operation. The rte_event API
> rte_eth_dev_callback_process() is per-port API, it doesn't carry much
> information when an event happens.
> > When a LWM event happens, we need to know in which Rx queue it
> happens or optionally what's the current LWM percentage of this queue.
> > The query operation serves this purpose.
> >
> >
> > Regards,
> > Spike.
> >
> >
>
> The bigger question is why does this have to be just MLX5 and why can't it fit
> into the existing DPDK RX interrupt framework?
>
> Linux and BSD have had this for years in their packet coalescing logic.
> Ethtool provides ability to set lot of irq coalescing parameters like:
>
> ethtool -C|--coalesce devname [adaptive-rx on|off] [adaptive-tx on|off]
> [rx-usecs N] [rx-frames N] [rx-usecs-irq N] [rx-frames-irq N]
> [tx-usecs N] [tx-frames N] [tx-usecs-irq N] [tx-frames-irq N]
> [stats-block-usecs N] [pkt-rate-low N] [rx-usecs-low N]
> [rx-frames-low N] [tx-usecs-low N] [tx-frames-low N]
> [pkt-rate-high N] [rx-usecs-high N] [rx-frames-high N]
> [tx-usecs-high N] [tx-frames-high N] [sample-interval N]
> [cqe-mode-rx on|off] [cqe-mode-tx on|off]
>
> It feels like this is just the DPDK version of a small subset of that.
> Since many device already support IRQ coalescing, it would be best to build
> one new API that has most of these. Rather than a MLX/Nvidia only API for a
> single parameter.
I take MLX5 as example here because I only know how mlx5 works, I don't understand
How other NICs work. It doesn't mean I try to change common code only to satisfy
Mlx5 needs.
I think interrupt coalesce is different from LWM:
Interrupt coalesce is delay interrupt until a batch of packets(or an interval) is received.
LWM intends to notify when a Rx queue is out of buffer. Delaying interrupt can't detect
A specific fullness value of the Rx queue, but LWM can if driver supports it.
Regards,
Spike.
^ permalink raw reply [relevance 0%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-24 2:50 3% ` Spike Du
@ 2022-05-24 8:18 3% ` Thomas Monjalon
2022-05-25 12:59 4% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-24 8:18 UTC (permalink / raw)
To: Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit, andrew.rybchenko
24/05/2022 04:50, Spike Du:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 23/05/2022 05:01, Spike Du:
> > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > > Spike Du <spiked@nvidia.com> wrote:
> > > > > --- a/lib/ethdev/rte_ethdev.h
> > > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > > > */
> > > > > union rte_eth_rxseg *rx_seg;
> > > > >
> > > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > > > + /**
> > > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > > > + * size. If Rx queue receives traffic higher than this percentage,
> > > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > > > + */
> > > > > + uint8_t lwm;
> > > > > +
> > > > > + uint8_t reserved_bits[3];
> > > > > + uint32_t reserved_32s;
> > > > > + uint64_t reserved_64s;
> > > >
> > > > Ok but, this is an ABI risk about this because reserved stuff was
> > > > never required before.
> >
> > An ABI compatibility issue would be for an application compiled with an old
> > DPDK, and loading a new DPDK at runtime.
> > Let's think what would happen in such a case.
> >
> > > > Whenever is a reserved field is introduced the code (in this case
> > > > rte_ethdev_configure).
> >
> > rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> > Then the library and drivers may interpret a wrong value.
> >
> > > > Best practice would have been to have the code require all reserved
> > > > fields be
> > > > 0 in earlier releases. In this case an application is like to define
> > > > a watermark of zero; how will your code handle it.
> > >
> > > Having watermark of 0 is desired, which is the default. LWM of 0 means
> > > the Rx Queue's watermark is not monitored, hence no LWM event is
> > generated.
> >
> > The problem is to have a value not initialized.
> > I think the best approach is to not expose the LWM value through this
> > configuration structure.
> > If the need is to get the current value, we should better add a field in the
> > struct rte_eth_rxq_info.
>
> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
> The Rx queue, if user follows these examples we should not have ABI issue.
> Since many people are concerned about rxconf change, it's ok to remove the LWM
> Field there.
> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
> We should have a way to get it.
Unfortunately we cannot rely on examples for ABI compatibility.
My suggestion of moving the field in rte_eth_rxq_info
is not obvious because it could change the size of the struct.
But thanks to __rte_cache_min_aligned, it is OK.
Running pahole on this struct shows we have 50 bytes free:
/* size: 128, cachelines: 2, members: 6 */
/* padding: 50 */
The other option would be to get the LWM value with a "get" function.
What others prefer?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events
2022-05-21 10:33 0% ` fengchengwen
@ 2022-05-24 15:11 0% ` Ray Kinsella
2022-06-10 0:16 0% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-05-24 15:11 UTC (permalink / raw)
To: fengchengwen
Cc: Thomas Monjalon, Ferruh Yigit, Kalesh A P, dev, ajit.khaparde,
asafp, David Marchand, Andrew Rybchenko, lizhenyi1,
shuliubin 00419723
fengchengwen <fengchengwen@huawei.com> writes:
> Hi all,
>
> This patch lasts for a long time. Are we waiting for 22.11 to deal with it?
That was my read, as can't reliably change the value of _MAX at this
stage without it having impact elsewhere.
> We have the same requirements for the reset or recovery mechanism, but there are differences:
>
> APP PMD
> | |
> | detect error
> | <---report error event--- |
> | |
> do error stats |
> and report |
> | ---start recover--> |
> | do recover
> | <---report recover result |
> | |
> if succ just log
> else may migrate
> service
>
> Can we generalize these processes(means that the implementation is at the framework layer)? or only at PMD API?
>
>
> On 2022/2/15 0:06, Ray Kinsella wrote:
>>
>> Thomas Monjalon <thomas@monjalon.net> writes:
>>
>>> 14/02/2022 11:16, Ray Kinsella:
>>>> Ray Kinsella <mdr@ashroe.eu> writes:
>>>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>>>> 02/02/2022 12:44, Ray Kinsella:
>>>>>>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>>>>>>> On 1/28/2022 12:48 PM, Kalesh A P wrote:
>>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>>> @@ -3818,6 +3818,24 @@ enum rte_eth_event_type {
>>>>>>>>> RTE_ETH_EVENT_DESTROY, /**< port is released */
>>>>>>>>> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */
>>>>>>>>> RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
>>>>>>>>> + RTE_ETH_EVENT_ERR_RECOVERING,
>>>>>>>>> + /**< port recovering from an error
>>>>>>>>> + *
>>>>>>>>> + * PMD detected a FW reset or error condition.
>>>>>>>>> + * PMD will try to recover from the error.
>>>>>>>>> + * Data path may be quiesced and Control path operations
>>>>>>>>> + * may fail at this time.
>>>>>>>>> + */
>>>>>>>>> + RTE_ETH_EVENT_RECOVERED,
>>>>>>>>> + /**< port recovered from an error
>>>>>>>>> + *
>>>>>>>>> + * PMD has recovered from the error condition.
>>>>>>>>> + * Control path and Data path are up now.
>>>>>>>>> + * PMD re-configures the port to the state prior to the error.
>>>>>>>>> + * Since the device has undergone a reset, flow rules
>>>>>>>>> + * offloaded prior to reset may be lost and
>>>>>>>>> + * the application should recreate the rules again.
>>>>>>>>> + */
>>>>>>>>> RTE_ETH_EVENT_MAX /**< max value of this enum */
>>>>>>>>
>>>>>>>>
>>>>>>>> Also ABI check complains about 'RTE_ETH_EVENT_MAX' value check, cc'ed more people
>>>>>>>> to evaluate if it is a false positive:
>>>>>>>>
>>>>>>>>
>>>>>>>> 1 function with some indirect sub-type change:
>>>>>>>> [C] 'function int rte_eth_dev_callback_register(uint16_t, rte_eth_event_type, rte_eth_dev_cb_fn, void*)' at rte_ethdev.c:4637:1 has some indirect sub-type changes:
>>>>>>>> parameter 3 of type 'typedef rte_eth_dev_cb_fn' has sub-type changes:
>>>>>>>> underlying type 'int (typedef uint16_t, enum rte_eth_event_type, void*, void*)*' changed:
>>>>>>>> in pointed to type 'function type int (typedef uint16_t, enum rte_eth_event_type, void*, void*)':
>>>>>>>> parameter 2 of type 'enum rte_eth_event_type' has sub-type changes:
>>>>>>>> type size hasn't changed
>>>>>>>> 2 enumerator insertions:
>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_ERR_RECOVERING' value '11'
>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_RECOVERED' value '12'
>>>>>>>> 1 enumerator change:
>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_MAX' from value '11' to '13' at rte_ethdev.h:3807:1
>>>>>>>
>>>>>>> I don't immediately see the problem that this would cause.
>>>>>>> There are no array sizes etc dependent on the value of MAX for instance.
>>>>>>>
>>>>>>> Looks safe?
>>>>>>
>>>>>> We never know how this enum will be used by the application.
>>>>>> The max value may be used for the size of an event array.
>>>>>> It looks a real ABI issue unfortunately.
>>>>>
>>>>> Right - but we only really care about it when an array size based on MAX
>>>>> is likely to be passed to DPDK, which doesn't apply in this case.
>>>
>>> I don't completely agree.
>>> A developer may assume an event will never exceed MAX value.
>>> However, after an upgrade of DPDK without app rebuild,
>>> a higher event value may be received in the app,
>>> breaking the assumption.
>>> Should we consider this case as an ABI breakage?
>>
>> Nope - I think we should explicitly exclude MAX values from any
>> ABI guarantee, as being able to change them is key to our be able to
>> evolve DPDK while maintaining ABI stability.
>>
>> Consider what it means applying the ABI policy to a MAX value, you are
>> in effect saying that that no value can be added to this enumeration
>> until the next ABI version, for me this is very restrictive without a
>> solid reason.
>>
>>>
>>>>> I noted that some Linux folks explicitly mark similar MAX values as not
>>>>> part of the ABI.
>>>>>
>>>>> /usr/include/linux/perf_event.h
>>>>> 37: PERF_TYPE_MAX, /* non-ABI */
>>>>> 60: PERF_COUNT_HW_MAX, /* non-ABI */
>>>>> 79: PERF_COUNT_HW_CACHE_MAX, /* non-ABI */
>>>>> 87: PERF_COUNT_HW_CACHE_OP_MAX, /* non-ABI */
>>>>> 94: PERF_COUNT_HW_CACHE_RESULT_MAX, /* non-ABI */
>>>>> 116: PERF_COUNT_SW_MAX, /* non-ABI */
>>>>> 149: PERF_SAMPLE_MAX = 1U << 24, /* non-ABI */
>>>>> 151: __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /*
>>>>> non-ABI; internal use */
>>>>> 189: PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */
>>>>> 267: PERF_TXN_MAX = (1 << 8), /* non-ABI */
>>>>> 301: PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
>>>>> 1067: PERF_RECORD_MAX, /* non-ABI */
>>>>> 1078: PERF_RECORD_KSYMBOL_TYPE_MAX /* non-ABI */
>>>>> 1087: PERF_BPF_EVENT_MAX, /* non-ABI */
>>>>
>>>> Any thoughts on similarly annotating all our _MAX enums in the same way?
>>>> We could also add a section in the ABI Policy to make it explicit _MAX
>>>> enum values are not part of the ABI - what do folks think?
>>>
>>> Interesting. I am not sure it is always ABI-safe though.
>>
>>
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* [RFT 0/2] pie: floating point fixes
@ 2022-05-24 18:46 3% Stephen Hemminger
2022-05-24 19:31 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-05-24 18:46 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
A couple of small untested changes to address some
issues found while reviewing usage of random in DPDK.
The PIE code should get rexamined in later release.
It should not be exposing internal algorithm, that makes
it brittle for ABI.
Also, no code in DPDK should ever be doing floating point
math in the data path!
Stephen Hemminger (2):
rte_pie: remove unnecessary floating point
rte_pie: fix incorrect floating point math
lib/sched/rte_pie.h | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--
2.35.1
^ permalink raw reply [relevance 3%]
* RE: [RFT 0/2] pie: floating point fixes
2022-05-24 18:46 3% [RFT 0/2] pie: floating point fixes Stephen Hemminger
@ 2022-05-24 19:31 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-05-24 19:31 UTC (permalink / raw)
To: Stephen Hemminger, dev
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 24 May 2022 20.46
>
> A couple of small untested changes to address some
> issues found while reviewing usage of random in DPDK.
>
> The PIE code should get rexamined in later release.
Untested fixes to seemingly untested code. What's not to like? ;-)
> It should not be exposing internal algorithm, that makes
> it brittle for ABI.
Agree. Just look at the mempool... an increasing amount of its internals are getting elevated to public API, so other code can understand and use its internals instead of going through its API. (My current pet peeve.)
>
> Also, no code in DPDK should ever be doing floating point
> math in the data path!
+1
>
> Stephen Hemminger (2):
> rte_pie: remove unnecessary floating point
> rte_pie: fix incorrect floating point math
This looks much better than what it replaces, so...
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 0%]
* [PATCH] eal/ppc: undefine AltiVec keyword vector
@ 2022-05-25 9:53 4% Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-25 9:53 UTC (permalink / raw)
To: dev; +Cc: mdr, david.marchand, techboard, David Christensen
The AltiVec header file is defining "vector", except in C++ build.
The keyword "vector" may conflict easily.
As a rule, it is better to use the alternative keyword "__vector".
The DPDK header file rte_altivec.h takes care of undefining "vector",
so the applications and dependencies are free to define the name "vector".
This is a compatibility breakage for applications which were using
the keyword "vector" for its AltiVec meaning.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/release_22_07.rst | 5 +++++
lib/eal/ppc/include/rte_altivec.h | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index e49cacecef..ee60b17821 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -133,6 +133,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* The DPDK header file ``rte_altivec.h``,
+ which is a wrapper for the PPC header file ``altivec.h``,
+ undefines the AltiVec keyword ``vector``.
+ The alternative keyword ``__vector`` should be used instead.
+
ABI Changes
-----------
diff --git a/lib/eal/ppc/include/rte_altivec.h b/lib/eal/ppc/include/rte_altivec.h
index 1551a94544..7c088d2d16 100644
--- a/lib/eal/ppc/include/rte_altivec.h
+++ b/lib/eal/ppc/include/rte_altivec.h
@@ -9,6 +9,13 @@
/* To include altivec.h, GCC version must be >= 4.8 */
#include <altivec.h>
+/*
+ * The keyword "vector" is defined in altivec.h,
+ * and often conflicts with code in applications or dependencies.
+ * It is preferred to use the alternative keyword "__vector".
+ */
+#undef vector
+
/*
* Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. std=c11.
* Otherwise there would be a type conflict between stdbool and altivec.
--
2.36.0
^ permalink raw reply [relevance 4%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-24 8:18 3% ` Thomas Monjalon
@ 2022-05-25 12:59 4% ` Andrew Rybchenko
2022-05-25 13:58 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2022-05-25 12:59 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit
On 5/24/22 11:18, Thomas Monjalon wrote:
> 24/05/2022 04:50, Spike Du:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 23/05/2022 05:01, Spike Du:
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>> Spike Du <spiked@nvidia.com> wrote:
>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
>>>>>> */
>>>>>> union rte_eth_rxseg *rx_seg;
>>>>>>
>>>>>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
>>>>>> + /**
>>>>>> + * Per-queue Rx limit watermark defined as percentage of Rx queue
>>>>>> + * size. If Rx queue receives traffic higher than this percentage,
>>>>>> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
>>>>>> + */
>>>>>> + uint8_t lwm;
>>>>>> +
>>>>>> + uint8_t reserved_bits[3];
>>>>>> + uint32_t reserved_32s;
>>>>>> + uint64_t reserved_64s;
>>>>>
>>>>> Ok but, this is an ABI risk about this because reserved stuff was
>>>>> never required before.
>>>
>>> An ABI compatibility issue would be for an application compiled with an old
>>> DPDK, and loading a new DPDK at runtime.
>>> Let's think what would happen in such a case.
>>>
>>>>> Whenever is a reserved field is introduced the code (in this case
>>>>> rte_ethdev_configure).
>>>
>>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
>>> Then the library and drivers may interpret a wrong value.
>>>
>>>>> Best practice would have been to have the code require all reserved
>>>>> fields be
>>>>> 0 in earlier releases. In this case an application is like to define
>>>>> a watermark of zero; how will your code handle it.
>>>>
>>>> Having watermark of 0 is desired, which is the default. LWM of 0 means
>>>> the Rx Queue's watermark is not monitored, hence no LWM event is
>>> generated.
>>>
>>> The problem is to have a value not initialized.
>>> I think the best approach is to not expose the LWM value through this
>>> configuration structure.
>>> If the need is to get the current value, we should better add a field in the
>>> struct rte_eth_rxq_info.
>>
>> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
>> The Rx queue, if user follows these examples we should not have ABI issue.
>> Since many people are concerned about rxconf change, it's ok to remove the LWM
>> Field there.
>> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
>> We should have a way to get it.
>
> Unfortunately we cannot rely on examples for ABI compatibility.
> My suggestion of moving the field in rte_eth_rxq_info
> is not obvious because it could change the size of the struct.
> But thanks to __rte_cache_min_aligned, it is OK.
> Running pahole on this struct shows we have 50 bytes free:
> /* size: 128, cachelines: 2, members: 6 */
> /* padding: 50 */
>
> The other option would be to get the LWM value with a "get" function.
>
> What others prefer?
If I'm not mistaken the changeset breaks ABI in any case since
it adds a new event and changes MAX. If so, I'd wait for the
next ABI breaking release and do not touch reserved fields.
^ permalink raw reply [relevance 4%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-25 12:59 4% ` Andrew Rybchenko
@ 2022-05-25 13:58 3% ` Thomas Monjalon
2022-05-25 14:23 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-25 13:58 UTC (permalink / raw)
To: Stephen Hemminger, Spike Du, Andrew Rybchenko
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit
25/05/2022 14:59, Andrew Rybchenko:
> On 5/24/22 11:18, Thomas Monjalon wrote:
> > 24/05/2022 04:50, Spike Du:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 23/05/2022 05:01, Spike Du:
> >>>> From: Stephen Hemminger <stephen@networkplumber.org>
> >>>>> Spike Du <spiked@nvidia.com> wrote:
> >>>>>> --- a/lib/ethdev/rte_ethdev.h
> >>>>>> +++ b/lib/ethdev/rte_ethdev.h
> >>>>>> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> >>>>>> */
> >>>>>> union rte_eth_rxseg *rx_seg;
> >>>>>>
> >>>>>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> >>>>>> + /**
> >>>>>> + * Per-queue Rx limit watermark defined as percentage of Rx queue
> >>>>>> + * size. If Rx queue receives traffic higher than this percentage,
> >>>>>> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> >>>>>> + */
> >>>>>> + uint8_t lwm;
> >>>>>> +
> >>>>>> + uint8_t reserved_bits[3];
> >>>>>> + uint32_t reserved_32s;
> >>>>>> + uint64_t reserved_64s;
> >>>>>
> >>>>> Ok but, this is an ABI risk about this because reserved stuff was
> >>>>> never required before.
> >>>
> >>> An ABI compatibility issue would be for an application compiled with an old
> >>> DPDK, and loading a new DPDK at runtime.
> >>> Let's think what would happen in such a case.
> >>>
> >>>>> Whenever is a reserved field is introduced the code (in this case
> >>>>> rte_ethdev_configure).
> >>>
> >>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> >>> Then the library and drivers may interpret a wrong value.
> >>>
> >>>>> Best practice would have been to have the code require all reserved
> >>>>> fields be
> >>>>> 0 in earlier releases. In this case an application is like to define
> >>>>> a watermark of zero; how will your code handle it.
> >>>>
> >>>> Having watermark of 0 is desired, which is the default. LWM of 0 means
> >>>> the Rx Queue's watermark is not monitored, hence no LWM event is
> >>> generated.
> >>>
> >>> The problem is to have a value not initialized.
> >>> I think the best approach is to not expose the LWM value through this
> >>> configuration structure.
> >>> If the need is to get the current value, we should better add a field in the
> >>> struct rte_eth_rxq_info.
> >>
> >> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
> >> The Rx queue, if user follows these examples we should not have ABI issue.
> >> Since many people are concerned about rxconf change, it's ok to remove the LWM
> >> Field there.
> >> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
> >> We should have a way to get it.
> >
> > Unfortunately we cannot rely on examples for ABI compatibility.
> > My suggestion of moving the field in rte_eth_rxq_info
> > is not obvious because it could change the size of the struct.
> > But thanks to __rte_cache_min_aligned, it is OK.
> > Running pahole on this struct shows we have 50 bytes free:
> > /* size: 128, cachelines: 2, members: 6 */
> > /* padding: 50 */
> >
> > The other option would be to get the LWM value with a "get" function.
> >
> > What others prefer?
>
> If I'm not mistaken the changeset breaks ABI in any case since
> it adds a new event and changes MAX.
I think we can consider it as not a breakage (a rule should be added).
Last time we had to update this enum, this was the conclusion:
from https://git.dpdk.org/dpdk/commit/?id=44bf3c796be3f
"
The new event type addition in the enum is flagged as an ABI breakage,
so an ignore rule is added for these reasons:
- It is not changing value of existing types (except MAX)
- The new value is not used by existing API if the event is not
registered
In general, it is safe adding new ethdev event types at the end of the
enum, because of event callback registration mechanism.
"
> If so, I'd wait for the
> next ABI breaking release and do not touch reserved fields.
In any case, rte_eth_rxconf is not a good fit
because we have a separate function for configuration.
It should be either in rte_eth_rxq_info or a specific "get" function.
^ permalink raw reply [relevance 3%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-25 13:58 3% ` Thomas Monjalon
@ 2022-05-25 14:23 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2022-05-25 14:23 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit
On 5/25/22 16:58, Thomas Monjalon wrote:
> 25/05/2022 14:59, Andrew Rybchenko:
>> On 5/24/22 11:18, Thomas Monjalon wrote:
>>> 24/05/2022 04:50, Spike Du:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 23/05/2022 05:01, Spike Du:
>>>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>>>> Spike Du <spiked@nvidia.com> wrote:
>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
>>>>>>>> */
>>>>>>>> union rte_eth_rxseg *rx_seg;
>>>>>>>>
>>>>>>>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
>>>>>>>> + /**
>>>>>>>> + * Per-queue Rx limit watermark defined as percentage of Rx queue
>>>>>>>> + * size. If Rx queue receives traffic higher than this percentage,
>>>>>>>> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
>>>>>>>> + */
>>>>>>>> + uint8_t lwm;
>>>>>>>> +
>>>>>>>> + uint8_t reserved_bits[3];
>>>>>>>> + uint32_t reserved_32s;
>>>>>>>> + uint64_t reserved_64s;
>>>>>>>
>>>>>>> Ok but, this is an ABI risk about this because reserved stuff was
>>>>>>> never required before.
>>>>>
>>>>> An ABI compatibility issue would be for an application compiled with an old
>>>>> DPDK, and loading a new DPDK at runtime.
>>>>> Let's think what would happen in such a case.
>>>>>
>>>>>>> Whenever is a reserved field is introduced the code (in this case
>>>>>>> rte_ethdev_configure).
>>>>>
>>>>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
>>>>> Then the library and drivers may interpret a wrong value.
>>>>>
>>>>>>> Best practice would have been to have the code require all reserved
>>>>>>> fields be
>>>>>>> 0 in earlier releases. In this case an application is like to define
>>>>>>> a watermark of zero; how will your code handle it.
>>>>>>
>>>>>> Having watermark of 0 is desired, which is the default. LWM of 0 means
>>>>>> the Rx Queue's watermark is not monitored, hence no LWM event is
>>>>> generated.
>>>>>
>>>>> The problem is to have a value not initialized.
>>>>> I think the best approach is to not expose the LWM value through this
>>>>> configuration structure.
>>>>> If the need is to get the current value, we should better add a field in the
>>>>> struct rte_eth_rxq_info.
>>>>
>>>> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
>>>> The Rx queue, if user follows these examples we should not have ABI issue.
>>>> Since many people are concerned about rxconf change, it's ok to remove the LWM
>>>> Field there.
>>>> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
>>>> We should have a way to get it.
>>>
>>> Unfortunately we cannot rely on examples for ABI compatibility.
>>> My suggestion of moving the field in rte_eth_rxq_info
>>> is not obvious because it could change the size of the struct.
>>> But thanks to __rte_cache_min_aligned, it is OK.
>>> Running pahole on this struct shows we have 50 bytes free:
>>> /* size: 128, cachelines: 2, members: 6 */
>>> /* padding: 50 */
>>>
>>> The other option would be to get the LWM value with a "get" function.
>>>
>>> What others prefer?
>>
>> If I'm not mistaken the changeset breaks ABI in any case since
>> it adds a new event and changes MAX.
>
> I think we can consider it as not a breakage (a rule should be added).
> Last time we had to update this enum, this was the conclusion:
> from https://git.dpdk.org/dpdk/commit/?id=44bf3c796be3f
> "
> The new event type addition in the enum is flagged as an ABI breakage,
> so an ignore rule is added for these reasons:
> - It is not changing value of existing types (except MAX)
> - The new value is not used by existing API if the event is not
> registered
> In general, it is safe adding new ethdev event types at the end of the
> enum, because of event callback registration mechanism.
> "
I see. Makes sense. Thanks for the information.
>> If so, I'd wait for the
>> next ABI breaking release and do not touch reserved fields.
>
> In any case, rte_eth_rxconf is not a good fit
> because we have a separate function for configuration.
Yes, it is better to avoid two ways to configure the same
thing.
> It should be either in rte_eth_rxq_info or a specific "get" function.
I see no point to introduce specific get function for a single
value. I think that rte_eth_rxq_info is the right way to get
current value.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
@ 2022-05-25 18:02 3% ` Ray Kinsella
2022-05-25 18:34 3% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-05-25 18:02 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, david.marchand, techboard, David Christensen
Thomas Monjalon <thomas@monjalon.net> writes:
> 25/05/2022 13:48, Ray Kinsella:
>>
>> Thomas Monjalon <thomas@monjalon.net> writes:
>>
>> > The AltiVec header file is defining "vector", except in C++ build.
>> > The keyword "vector" may conflict easily.
>> > As a rule, it is better to use the alternative keyword "__vector".
>> >
>> > The DPDK header file rte_altivec.h takes care of undefining "vector",
>> > so the applications and dependencies are free to define the name "vector".
>> >
>> > This is a compatibility breakage for applications which were using
>> > the keyword "vector" for its AltiVec meaning.
>> >
>> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> > ---
>> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
>> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
>> > 2 files changed, 12 insertions(+)
>> >
>>
>> Acked-by: Ray Kinsella <mdr@ashroe.eu>
>
> Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> It means the keyword vector is not available anymore with this #include.
> Please confirm it is OK to merge in DPDK 22.07.
I did think about it yes ;-).
I can't see how it would break the ABI in the short term.
And it makes sense to preclude this keyword in the long term.
So I ack'ed - did I miss something?
--
Regards, Ray K
^ permalink raw reply [relevance 3%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-25 18:02 3% ` Ray Kinsella
@ 2022-05-25 18:34 3% ` Tyler Retzlaff
2022-05-26 10:18 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-05-25 18:34 UTC (permalink / raw)
To: Ray Kinsella
Cc: Thomas Monjalon, dev, david.marchand, techboard, David Christensen
On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
>
> Thomas Monjalon <thomas@monjalon.net> writes:
>
> > 25/05/2022 13:48, Ray Kinsella:
> >>
> >> Thomas Monjalon <thomas@monjalon.net> writes:
> >>
> >> > The AltiVec header file is defining "vector", except in C++ build.
> >> > The keyword "vector" may conflict easily.
> >> > As a rule, it is better to use the alternative keyword "__vector".
> >> >
> >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
> >> > so the applications and dependencies are free to define the name "vector".
> >> >
> >> > This is a compatibility breakage for applications which were using
> >> > the keyword "vector" for its AltiVec meaning.
> >> >
> >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >> > ---
> >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
> >> > 2 files changed, 12 insertions(+)
> >> >
> >>
> >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> >
> > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> > It means the keyword vector is not available anymore with this #include.
> > Please confirm it is OK to merge in DPDK 22.07.
>
> I did think about it yes ;-).
> I can't see how it would break the ABI in the short term.
> And it makes sense to preclude this keyword in the long term.
>
> So I ack'ed - did I miss something?
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
double ack, impact of break is understood as follows.
* this is not an issue with abi it is an issue with api.
* the break will cause a compile failure, the action to resolve is to
replace vector with __vector.
>
>
> --
> Regards, Ray K
^ permalink raw reply [relevance 3%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-25 18:34 3% ` Tyler Retzlaff
@ 2022-05-26 10:18 0% ` Thomas Monjalon
2022-05-26 11:02 0% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-26 10:18 UTC (permalink / raw)
To: Ray Kinsella, Tyler Retzlaff
Cc: dev, david.marchand, techboard, David Christensen
25/05/2022 20:34, Tyler Retzlaff:
> On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
> > Thomas Monjalon <thomas@monjalon.net> writes:
> > > 25/05/2022 13:48, Ray Kinsella:
> > >> Thomas Monjalon <thomas@monjalon.net> writes:
> > >>
> > >> > The AltiVec header file is defining "vector", except in C++ build.
> > >> > The keyword "vector" may conflict easily.
> > >> > As a rule, it is better to use the alternative keyword "__vector".
> > >> >
> > >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
> > >> > so the applications and dependencies are free to define the name "vector".
> > >> >
> > >> > This is a compatibility breakage for applications which were using
> > >> > the keyword "vector" for its AltiVec meaning.
> > >> >
> > >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > >> > ---
> > >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> > >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
> > >> > 2 files changed, 12 insertions(+)
> > >> >
> > >>
> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> > >
> > > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> > > It means the keyword vector is not available anymore with this #include.
> > > Please confirm it is OK to merge in DPDK 22.07.
> >
> > I did think about it yes ;-).
> > I can't see how it would break the ABI in the short term.
> > And it makes sense to preclude this keyword in the long term.
> >
> > So I ack'ed - did I miss something?
>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>
> double ack, impact of break is understood as follows.
>
> * this is not an issue with abi it is an issue with api.
> * the break will cause a compile failure, the action to resolve is to
> replace vector with __vector.
Exactly
I'll wait few days or acks from the techboard, and will apply.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-26 10:18 0% ` Thomas Monjalon
@ 2022-05-26 11:02 0% ` Ray Kinsella
2022-06-01 15:04 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-05-26 11:02 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Tyler Retzlaff, dev, david.marchand, techboard, David Christensen
Thomas Monjalon <thomas@monjalon.net> writes:
> 25/05/2022 20:34, Tyler Retzlaff:
>> On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
>> > Thomas Monjalon <thomas@monjalon.net> writes:
>> > > 25/05/2022 13:48, Ray Kinsella:
>> > >> Thomas Monjalon <thomas@monjalon.net> writes:
>> > >>
>> > >> > The AltiVec header file is defining "vector", except in C++ build.
>> > >> > The keyword "vector" may conflict easily.
>> > >> > As a rule, it is better to use the alternative keyword "__vector".
>> > >> >
>> > >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
>> > >> > so the applications and dependencies are free to define the name "vector".
>> > >> >
>> > >> > This is a compatibility breakage for applications which were using
>> > >> > the keyword "vector" for its AltiVec meaning.
>> > >> >
>> > >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> > >> > ---
>> > >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
>> > >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
>> > >> > 2 files changed, 12 insertions(+)
>> > >> >
>> > >>
>> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
>> > >
>> > > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
>> > > It means the keyword vector is not available anymore with this #include.
>> > > Please confirm it is OK to merge in DPDK 22.07.
>> >
>> > I did think about it yes ;-).
>> > I can't see how it would break the ABI in the short term.
>> > And it makes sense to preclude this keyword in the long term.
>> >
>> > So I ack'ed - did I miss something?
>>
>> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>
>> double ack, impact of break is understood as follows.
>>
>> * this is not an issue with abi it is an issue with api.
>> * the break will cause a compile failure, the action to resolve is to
>> replace vector with __vector.
>
> Exactly
>
> I'll wait few days or acks from the techboard, and will apply.
+1
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split
2022-05-19 14:40 0% ` Ding, Xuan
@ 2022-05-26 14:58 0% ` Ding, Xuan
0 siblings, 0 replies; 200+ results
From: Ding, Xuan @ 2022-05-26 14:58 UTC (permalink / raw)
To: Ding, Xuan, Thomas Monjalon, Wang, YuanX, Wu, WenxuanX
Cc: andrew.rybchenko, Li, Xiaoyun, ferruh.yigit, Singh, Aman Deep,
dev, Zhang, Yuying, Zhang, Qi Z, jerinjacobk, stephen, mb,
viacheslavo, Yu, Ping
Hi,
> -----Original Message-----
> From: Ding, Xuan <xuan.ding@intel.com>
> Sent: Thursday, May 19, 2022 10:40 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Wang, YuanX
> <yuanx.wang@intel.com>; Wu, WenxuanX <wenxuanx.wu@intel.com>
> Cc: andrew.rybchenko@oktetlabs.ru; Li, Xiaoyun <xiaoyun.li@intel.com>;
> ferruh.yigit@xilinx.com; Singh, Aman Deep <aman.deep.singh@intel.com>;
> dev@dpdk.org; Zhang, Yuying <yuying.zhang@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>; jerinjacobk@gmail.com;
> stephen@networkplumber.org; mb@smartsharesystems.com;
> viacheslavo@nvidia.com; Yu, Ping <ping.yu@intel.com>
> Subject: RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer
> split
>
> Hi Thomas,
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Wednesday, May 18, 2022 5:12 AM
> > To: Ding, Xuan <xuan.ding@intel.com>; Wang, YuanX
> > <yuanx.wang@intel.com>; Wu, WenxuanX <wenxuanx.wu@intel.com>
> > Cc: andrew.rybchenko@oktetlabs.ru; Li, Xiaoyun <xiaoyun.li@intel.com>;
> > ferruh.yigit@xilinx.com; Singh, Aman Deep <aman.deep.singh@intel.com>;
> > dev@dpdk.org; Zhang, Yuying <yuying.zhang@intel.com>; Zhang, Qi Z
> > <qi.z.zhang@intel.com>; jerinjacobk@gmail.com;
> > stephen@networkplumber.org; mb@smartsharesystems.com;
> > viacheslavo@nvidia.com; Yu, Ping <ping.yu@intel.com>
> > Subject: Re: [PATCH v5 1/4] lib/ethdev: introduce protocol type based
> > buffer split
> >
> > Hello,
> >
> > It seems you didn't try to address my main comment on v4:
> > "
> > Before doing anything, the first patch of this series should make the
> > current status clearer.
> > Example, this line does not explain what it does:
> > uint16_t split_hdr_size; /**< hdr buf size (header_split
> > enabled).*/ And header_split has been removed in ab3ce1e0c193
> > ("ethdev: remove old offload API")
> >
> > If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a
> comment
> > to start a deprecation.
> > "
>
> Thank you for the detailed review.
>
> First of all, I agree that header split should be deprecated.
> Since it is unrelated with buffer split, I was planning to send the deprecation
> notice in 22.07 sometime later and start the deprecation in 22.11.
>
> If you think it should be the first step, I will send the deprecation notice first.
>
> >
> > Also the comment from Andrew about removing limitation to 2 packets is
> > not addressed.
>
> Secondly, it is said that the protocol based buffer split will divide the packet
> into two segments.
> Because I thought it will only be used in the split between header and
> payload.
>
> In fact, protocol based buffer split can support multi-segment split.
> That is to say, like length-based buffer split, we define a series of protos, as
> the split point of protocol based buffer split. And this series of protos, like
> lengths, indicate the split location.
>
> For example, a packet consists of MAC/IPV4/UDP/payload.
> If we define the buffer split proto with IPV4, and UDP, the packet will be split
> into three segments:
> seg0: MAC and IPV4 header, 34 bytes
> seg1: UDP header, 8 bytes
> seg2: Payload, the actual payload size
>
> What do you think of this design?
>
> >
> > All the part about the protocols capability is missing here.
>
> Yes, I missed the protocols capability with RTE_PTYPE* now.
> I will update the doc with supported protocol capability in v6.
>
> >
> > It is not encouraging.
> >
> > 26/04/2022 13:13, wenxuanx.wu@intel.com:
> > > From: Wenxuan Wu <wenxuanx.wu@intel.com>
> > >
> > > Protocol based buffer split consists of splitting a received packet
> > > into two separate regions based on its content. The split happens
> > > after the packet protocol header and before the packet payload.
> > > Splitting is usually between the packet protocol header that can be
> > > posted to a dedicated buffer and the packet payload that can be
> > > posted to
> > a different buffer.
> > >
> > > Currently, Rx buffer split supports length and offset based packet split.
> > > protocol split is based on buffer split, configuring length of
> > > buffer split is not suitable for NICs that do split based on protocol types.
> >
> > Why? Is it impossible to support length split on Intel NIC?
>
> Yes, our NIC supports split based on protocol types. And I think there are
> other vendors too.
> The existence of tunneling results in the composition of a packet is various.
> Given a changeable length, it is impossible to tell the driver a fixed protocol
> type.
>
> >
> > > Because tunneling makes the conversion from length to protocol type
> > > impossible.
> >
> > This is not a HW issue.
> > I agree on the need but that a different usage than length split.
>
> I think the new usage can solve this problem, so that length split and proto
> split can have the same result.
>
> >
> > > This patch extends the current buffer split to support protocol and
> > > offset based buffer split. A new proto field is introduced in the
> > > rte_eth_rxseg_split structure reserved field to specify header
> > > protocol type. With Rx queue offload
> > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
> > > enabled and corresponding protocol type configured. PMD will split
> > > the
> > ingress packets into two separate regions.
> > > Currently, both inner and outer L2/L3/L4 level protocol based buffer
> > > split can be supported.
> > >
> > > For example, let's suppose we configured the Rx queue with the
> > > following segments:
> > > seg0 - pool0, off0=2B
> > > seg1 - pool1, off1=128B
> > >
> > > With protocol split type configured with RTE_PTYPE_L4_UDP. The
> > > packet consists of MAC_IP_UDP_PAYLOAD will be splitted like following:
> > > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from
> pool0
> > > seg1 - payload @ 128 in mbuf from pool1
> >
> > Not clear what is the calculation.
>
> The previous usage of protocol based split is the split between header and
> payload.
> Here for a packet composed of MAC_IP_UDP_PAYLOAD, with protocol split
> type RTE_PTYPE_L4_UDP configured, it means split between the UDP header
> and payload.
> In length configuration, the proto = RTE_PTYPE_L4_UDP means length = 42B.
>
> >
> > > The memory attributes for the split parts may differ either - for
> > > example the mempool0 and mempool1 belong to dpdk memory and
> > external
> > > memory, respectively.
> > >
> > > Signed-off-by: Xuan Ding <xuan.ding@intel.com>
> > > Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> > > Signed-off-by: Wenxuan Wu <wenxuanx.wu@intel.com>
> > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > ---
> > > lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++-------
> > > lib/ethdev/rte_ethdev.h | 15 ++++++++++++++-
> > > 2 files changed, 43 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index
> > > 29a3d80466..1a2bc172ab 100644
> > > --- a/lib/ethdev/rte_ethdev.c
> > > +++ b/lib/ethdev/rte_ethdev.c
> > > @@ -1661,6 +1661,7 @@ rte_eth_rx_queue_check_split(const struct
> > rte_eth_rxseg_split *rx_seg,
> > > struct rte_mempool *mpl = rx_seg[seg_idx].mp;
> > > uint32_t length = rx_seg[seg_idx].length;
> > > uint32_t offset = rx_seg[seg_idx].offset;
> > > + uint32_t proto = rx_seg[seg_idx].proto;
> > >
> > > if (mpl == NULL) {
> > > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n");
> > @@ -1694,13
> > > +1695,34 @@ rte_eth_rx_queue_check_split(const struct
> > rte_eth_rxseg_split *rx_seg,
> > > }
> > > offset += seg_idx != 0 ? 0 : RTE_PKTMBUF_HEADROOM;
> > > *mbp_buf_size = rte_pktmbuf_data_room_size(mpl);
> > > - length = length != 0 ? length : *mbp_buf_size;
> > > - if (*mbp_buf_size < length + offset) {
> > > - RTE_ETHDEV_LOG(ERR,
> > > - "%s mbuf_data_room_size %u < %u
> > (segment length=%u + segment offset=%u)\n",
> > > - mpl->name, *mbp_buf_size,
> > > - length + offset, length, offset);
> > > - return -EINVAL;
> > > + if (proto == 0) {
> >
> > Add a comment here, /* split at fixed length */
>
> Thanks for the suggestion, will add it in next version.
>
> >
> > > + length = length != 0 ? length : *mbp_buf_size;
> > > + if (*mbp_buf_size < length + offset) {
> > > + RTE_ETHDEV_LOG(ERR,
> > > + "%s mbuf_data_room_size %u < %u
> > (segment length=%u + segment offset=%u)\n",
> > > + mpl->name, *mbp_buf_size,
> > > + length + offset, length, offset);
> > > + return -EINVAL;
> > > + }
> > > + } else {
> >
> > Add a comment here, /* split after specified protocol header */
>
> Thanks for the suggestion, will add it in next version.
>
> >
> > > + /* Ensure n_seg is 2 in protocol based buffer split. */
> > > + if (n_seg != 2) {
> >
> > (should be a space, not a tab before brace)
>
> Get it.
>
> >
> > Why do you limit the feature to 2 segments only?
>
> Please see the new usage explained above.
>
> >
> > > + RTE_ETHDEV_LOG(ERR, "number of buffer
> > split protocol segments should be 2.\n");
> > > + return -EINVAL;
> > > + }
> > > + /* Length and protocol are exclusive here, so make
> > sure length is 0 in protocol
> > > + based buffer split. */
> > > + if (length != 0) {
> > > + RTE_ETHDEV_LOG(ERR, "segment length
> > should be set to zero in buffer split\n");
> > > + return -EINVAL;
> > > + }
> > > + if (*mbp_buf_size < offset) {
> > > + RTE_ETHDEV_LOG(ERR,
> > > + "%s
> > mbuf_data_room_size %u < %u segment offset)\n",
> > > + mpl->name, *mbp_buf_size,
> > > + offset);
> > > + return -EINVAL;
> > [...]
> > > + * - The proto in the elements defines the split position of received
> packets.
> > > + *
> > > * - If the length in the segment description element is zero
> > > * the actual buffer size will be deduced from the appropriate
> > > * memory pool properties.
> > > @@ -1197,12 +1200,21 @@ struct rte_eth_txmode {
> > > * - pool from the last valid element
> > > * - the buffer size from this pool
> > > * - zero offset
> > > + *
> > > + * - Length based buffer split:
> > > + * - mp, length, offset should be configured.
> > > + * - The proto should not be configured in length split. Zero default.
> > > + *
> > > + * - Protocol based buffer split:
> > > + * - mp, offset, proto should be configured.
> > > + * - The length should not be configured in protocol split. Zero default.
> >
> > What means "Zero default"?
> > You should just ignore the non relevant field.
>
> Yes, you are right, the none relevant field should be just ignored.
> I will update the doc in v6.
Sorry for replying myself.
After consideration, I found it is hard to just ignore the non-relevant field.
Because when length and proto both exist, it is hard to decide whether it is
length based buffer split or protocol based buffer split, which affects the
check in rte_eth_rx_queue_check_split().
So I would like to keep the current design in v6. When choosing one mode of
buffer split, the non-relevant field should not be configured.
Hope to get your feedbacks. :)
Regards,
Xuan
>
> >
> > > struct rte_eth_rxseg_split {
> > > struct rte_mempool *mp; /**< Memory pool to allocate segment
> > from. */
> > > uint16_t length; /**< Segment data length, configures split point. */
> > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer.
> > */
> > > - uint32_t reserved; /**< Reserved field. */
> >
> > How do you manage ABI compatibility?
> > Was the reserved field initialized to 0 in previous versions?
>
> I think we reached an agreement in RFC v1. There is no document for the
> reserved field in the previous release. And it is always initialized to zero in
> real cases.
> And now splitting based on fixed length and protocol header parsing is
> exclusive, we can ignore the none relevant field.
>
> >
> > > + uint32_t proto; /**< Protocol of buffer split, determines protocol
> > > +split point. */
> >
> > What are the values for "proto"?
>
> Yes, I missed the protocol capability here, will fix it in v6.
>
> >
> > > @@ -1664,6 +1676,7 @@ struct rte_eth_conf {
> > > RTE_ETH_RX_OFFLOAD_QINQ_STRIP) #define
> > DEV_RX_OFFLOAD_VLAN
> > > RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN)
> RTE_ETH_RX_OFFLOAD_VLAN
> > >
> > > +
> >
> > It looks to be an useless change.
>
> Thanks for the catch, will fix it in next version.
>
> Thanks again for your time.
>
> Regards,
> Xuan
>
> >
> > > /*
> > > * If new Rx offload capabilities are defined, they also must be
> > > * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> > >
> >
> >
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/1] lpm: add a scalar version of lookupx4 function
@ 2022-05-27 13:16 3% ` Medvedkin, Vladimir
0 siblings, 0 replies; 200+ results
From: Medvedkin, Vladimir @ 2022-05-27 13:16 UTC (permalink / raw)
To: Stanisław Kardach
Cc: Michal Mazurek, dev, Frank Zhao, Sam Grove, Marcin Wojtas,
upstream, Bruce Richardson
Hi Stanislaw,
On 27/05/2022 12:16, Stanisław Kardach wrote:
> On Tue, May 24, 2022 at 6:28 PM Stanisław Kardach <kda@semihalf.com> wrote:
> <snip>
>> That said I wonder why do we have different const requirements for
>> rte_lpm_lookup() and rte_lpm_lookupx4():
>> static inline int rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip,
>> uint32_t *next_hop)
>> static inline void rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t
>> ip, uint32_t hop[4], uint32_t defv);
>> I think both should be const.
>>
> To re-iterate the question, should I also post a patch for changing
> rte_lpm_lookup() to add "const" to "struct rte_lpm *lpm" argument?
> rte_lpm_lookup_bulk_func() and rte_lpm_lookupx4() already take lpm as
> const.
> I'm pushing because otherwise I get a const discard warning in the
> scalar version of rte_lpm_lookupx4() utilizing rte_lpm_lookup().
Since these are inline functions, there will be no problems with the
ABI/API, so please add const to the *lpm argument.
Thanks!
>
> Best Regards,
> Stanislaw Kardach
--
Regards,
Vladimir
^ permalink raw reply [relevance 3%]
* [PATCH v2 1/2] lpm: add const to lpm arg of rte_lpm_lookup
@ 2022-05-27 18:18 3% ` Stanislaw Kardach
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
1 sibling, 1 reply; 200+ results
From: Stanislaw Kardach @ 2022-05-27 18:18 UTC (permalink / raw)
To: Vladimir Medvedkin
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
All other rte_lpm_lookup* functions take lpm argument as a const. As the
basic rte_lpm_lookup() performs the same function, it should also do
that.
As this function is inline, no API/ABI change happens.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
lib/lpm/rte_lpm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index eb91960e81..1cf863a146 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
* -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
*/
static inline int
-rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
+rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
{
unsigned tbl24_index = (ip >> 8);
uint32_t tbl_entry;
--
2.30.2
^ permalink raw reply [relevance 3%]
* [PATCH v3] pcap: support MTU set
@ 2022-05-30 10:36 3% ` Ido Goshen
2022-05-30 18:05 0% ` Ferruh Yigit
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
` (3 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Ido Goshen @ 2022-05-30 10:36 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
drivers/net/pcap/pcap_ethdev.c | 44 +++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..2e7fff9579 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -93,6 +93,7 @@ struct pmd_internals {
int single_iface;
int phy_mac;
unsigned int infinite_rx;
+ int is_mtu_set;
};
struct pmd_process_private {
@@ -278,11 +279,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
const u_char *packet;
struct rte_mbuf *mbuf;
struct pcap_rx_queue *pcap_q = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[pcap_q->port_id];
+ struct pmd_internals *internals = dev->data->dev_private;
uint16_t num_rx = 0;
uint32_t rx_bytes = 0;
pcap_t *pcap;
- pp = rte_eth_devices[pcap_q->port_id].process_private;
+ pp = dev->process_private;
pcap = pp->rx_pcap[pcap_q->queue_id];
if (unlikely(pcap == NULL || nb_pkts == 0))
@@ -303,6 +306,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
break;
}
+ if (unlikely(header.caplen > dev->data->mtu) &&
+ internals->is_mtu_set) {
+ pcap_q->rx_stat.err_pkts++;
+ rte_pktmbuf_free(mbuf);
+ break;
+ }
+
if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
/* pcap packet will fit in the mbuf, can copy it */
rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
@@ -378,6 +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *dumper_q = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[dumper_q->port_id];
+ struct pmd_internals *internals = dev->data->dev_private;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
struct pcap_pkthdr header;
@@ -385,7 +397,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
size_t len, caplen;
- pp = rte_eth_devices[dumper_q->port_id].process_private;
+ pp = dev->process_private;
dumper = pp->tx_dumper[dumper_q->queue_id];
if (dumper == NULL || nb_pkts == 0)
@@ -396,6 +408,13 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = caplen = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > dev->data->mtu) &&
+ internals->is_mtu_set) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
caplen = sizeof(temp_data);
@@ -464,13 +483,15 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *tx_queue = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[tx_queue->port_id];
+ struct pmd_internals *internals = dev->data->dev_private;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
pcap_t *pcap;
unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
size_t len;
- pp = rte_eth_devices[tx_queue->port_id].process_private;
+ pp = dev->process_private;
pcap = pp->tx_pcap[tx_queue->queue_id];
if (unlikely(nb_pkts == 0 || pcap == NULL))
@@ -479,6 +500,13 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > dev->data->mtu) &&
+ internals->is_mtu_set) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
PMD_LOG(ERR,
@@ -807,6 +835,14 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ PMD_LOG(INFO, "mtu set %s %u\n", dev->device->name, mtu);
+ struct pmd_internals *internals = dev->data->dev_private;
+ internals->is_mtu_set = 1;
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
@@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
.addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
};
(*internals)->phy_mac = 0;
+ (*internals)->is_mtu_set = 0;
data = (*eth_dev)->data;
data->nb_rx_queues = (uint16_t)nb_rx_queues;
data->nb_tx_queues = (uint16_t)nb_tx_queues;
--
2.17.1
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-12 13:10 4% ` [PATCH v2] " Marcin Danilewicz
@ 2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 14:03 4% ` Danilewicz, MarcinX
2022-06-02 9:57 3% ` Danilewicz, MarcinX
2022-05-30 11:35 0% ` Dumitrescu, Cristian
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2 siblings, 2 replies; 200+ results
From: Dumitrescu, Cristian @ 2022-05-30 11:19 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Thursday, May 12, 2022 2:11 PM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v2] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Log: v2 change in rte_sched.h to avoid ABI breakage.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 14 +--
> examples/qos_sched/cfg_file.h | 2 -
> examples/qos_sched/init.c | 4 -
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 130 ++++++++++-----------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 53 ++-------
> lib/sched/rte_sched.h | 2 +
> 12 files changed, 371 insertions(+), 140 deletions(-)
> create mode 100644 examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
> diff --git a/lib/sched/rte_sched.h b/lib/sched/rte_sched.h
> index 5ece64e527..82aa73ff5b 100644
> --- a/lib/sched/rte_sched.h
> +++ b/lib/sched/rte_sched.h
> @@ -128,6 +128,8 @@ extern "C" {
> enum rte_sched_cman_mode {
> RTE_SCHED_CMAN_RED, /**< Random Early Detection (RED) */
> RTE_SCHED_CMAN_PIE, /**< Proportional Integral Controller
> Enhanced (PIE) */
> + /* New enum RTE_SCHED_CMAN_NONE added at the end to avoid
> ABI breakage */
> + RTE_SCHED_CMAN_NONE, /**< no RED|PIE cfg available */
> };
Can you please explain why you need to add the new RTE_SCHED_CMAN_NONE value to this enumeration and what is the ABI breakage that you are trying to avoid?
The library expects the struct rte_sched_subport_params:: cman_params to be NULL when the CMAN is disabled, why is this not enough to detect that CMAN is disabled? I suggest to keep the current approach.
>
> /*
> --
> 2.25.1
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-12 13:10 4% ` [PATCH v2] " Marcin Danilewicz
2022-05-30 11:19 3% ` Dumitrescu, Cristian
@ 2022-05-30 11:35 0% ` Dumitrescu, Cristian
2022-06-07 10:40 0% ` Danilewicz, MarcinX
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2 siblings, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2022-05-30 11:35 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
Hi Marcin,
Comments inline below.
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Thursday, May 12, 2022 2:11 PM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v2] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Log: v2 change in rte_sched.h to avoid ABI breakage.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 14 +--
> examples/qos_sched/cfg_file.h | 2 -
> examples/qos_sched/init.c | 4 -
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 130 ++++++++++-----------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 53 ++-------
> lib/sched/rte_sched.h | 2 +
> 12 files changed, 371 insertions(+), 140 deletions(-)
> create mode 100644 examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
<snip>
> diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
> index ec74bee939..db14934832 100644
> --- a/lib/sched/rte_sched.c
> +++ b/lib/sched/rte_sched.c
<snip>
> -#ifdef RTE_SCHED_CMAN
> static int
> rte_sched_red_config(struct rte_sched_port *port,
> struct rte_sched_subport *s,
> @@ -1161,9 +1156,11 @@ rte_sched_cman_config(struct rte_sched_port
> *port,
> else if (params->cman_params->cman_mode ==
> RTE_SCHED_CMAN_PIE)
> return rte_sched_pie_config(port, s, params, n_subports);
>
> + else if (params->cman_params->cman_mode ==
> RTE_SCHED_CMAN_NONE)
> + return 1;
> +
> return -EINVAL;
> }
> -#endif
Yes, you do need to remove the #ifdef ... #endif around this function, but no, you don't need to change this function, as it is only called when params->cman_params != NULL, i.e. CMAN is enabled. As mentioned before, there is no need to add the CMAN_NONE to the enumeration, as the CMAN_NONE value is equivalent to params->cman_params being set to NULL.
>
> int
> rte_sched_subport_config(struct rte_sched_port *port,
> @@ -1254,19 +1251,20 @@ rte_sched_subport_config(struct
> rte_sched_port *port,
> s->n_pipe_profiles = params->n_pipe_profiles;
> s->n_max_pipe_profiles = params->n_max_pipe_profiles;
>
> -#ifdef RTE_SCHED_CMAN
> + s->cman_enabled = false;
> +
> if (params->cman_params != NULL) {
> - s->cman_enabled = true;
> status = rte_sched_cman_config(port, s, params,
> n_subports);
> if (status) {
> - RTE_LOG(NOTICE, SCHED,
> - "%s: CMAN configuration fails\n",
> __func__);
> - return status;
> + if (status != 1) {
> + RTE_LOG(NOTICE, SCHED,
> + "%s: CMAN configuration
> fails\n", __func__);
> + return status;
> + }
> + } else {
> + s->cman_enabled = true;
> }
> - } else {
> - s->cman_enabled = false;
> }
> -#endif
>
Same comment here: yes, remove the #ifdef ... #endif, but no need to change this code fragment, as it sets correctly the s->cman_enabled flag, which is then the only flag used by the rest of the code. Again, no need to have a CMAN_NONE in the enumeration, as the same is achieved by setting params->cman_params to NULL.
> /* Scheduling loop detection */
> s->pipe_loop = RTE_SCHED_PIPE_INVALID;
> @@ -1825,14 +1823,10 @@
> rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport
> *subport,
>
> qe->stats.n_pkts_dropped += 1;
> qe->stats.n_bytes_dropped += pkt_len;
> -#ifdef RTE_SCHED_CMAN
> if (subport->cman_enabled)
> qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
> -#endif
> }
Please don't forget to remove the __rte_unused attribute for the n_pkts_cman_dropped in the function parameters, right?
<snip>
Regards,
Cristian
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [RFC PATCH] ethdev: support congestion management
@ 2022-05-30 13:15 2% jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: jerinj @ 2022-05-30 13:15 UTC (permalink / raw)
To: dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, cristian.dumitrescu, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
NIC HW controllers often come with congestion management support on
various HW objects such as Rx queue depth or mempool queue depth.
Also, it can support various modes of operation such as RED
(Random early discard), WRED etc on those HW objects.
This patch adds a framework to express such modes(enum rte_cman_mode)
and introduce (enum rte_eth_cman_obj) to enumerate the different
objects where the modes can operate on.
This patch adds RTE_CMAN_RED mode of operation and
RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
Introduced reserved fields in configuration structure
backed by rte_eth_cman_config_init() to add new configuration
parameters without ABI breakage.
Added rte_eth_cman_info_get() API to get the information such as
supported modes and objects.
Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
to configure congestion management on those object with associated mode.
Finally, Added rte_eth_cman_config_get() API to retrieve the
applied configuration.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
doc/guides/nics/features.rst | 12 +++
doc/guides/nics/features/default.ini | 1 +
lib/eal/include/meson.build | 1 +
lib/eal/include/rte_cman.h | 51 ++++++++++
lib/ethdev/rte_ethdev.h | 145 +++++++++++++++++++++++++++
5 files changed, 210 insertions(+)
create mode 100644 lib/eal/include/rte_cman.h
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 21bedb743f..ffcc2bcc92 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -727,6 +727,18 @@ Supports configuring per-queue stat counter mapping.
``rte_eth_dev_set_tx_queue_stats_mapping()``.
+.. _nic_features_congestion_management
+
+Congestion management
+---------------------
+
+Supports congestion management.
+
+* **[implements] eth_dev_ops**: ``cman_info_get``, ``cman_config_set``, ``cman_config_get``.
+* **[related] API**: ``rte_eth_cman_info_get()``, ``rte_eth_cman_config_init()``,
+ ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
+
+
.. _nic_features_fw_version:
FW version
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index b1d18ac62c..060497e41f 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -60,6 +60,7 @@ Tx descriptor status =
Basic stats =
Extended stats =
Stats per queue =
+Congestion management =
FW version =
EEPROM dump =
Module EEPROM dump =
diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
index 9700494816..40e31e0e6d 100644
--- a/lib/eal/include/meson.build
+++ b/lib/eal/include/meson.build
@@ -10,6 +10,7 @@ headers += files(
'rte_branch_prediction.h',
'rte_bus.h',
'rte_class.h',
+ 'rte_cman.h',
'rte_common.h',
'rte_compat.h',
'rte_debug.h',
diff --git a/lib/eal/include/rte_cman.h b/lib/eal/include/rte_cman.h
new file mode 100644
index 0000000000..e6dad2ebf7
--- /dev/null
+++ b/lib/eal/include/rte_cman.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2022 Marvell International Ltd.
+ */
+
+#ifndef RTE_CMAN_H
+#define RTE_CMAN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_bitops.h>
+
+/**
+ * @file
+ * Congestion management related parameters for DPDK.
+ */
+
+/** Congestion management modes */
+enum rte_cman_mode {
+ /** Congestion based on Random Early Detection.
+ *
+ * https://en.wikipedia.org/wiki/Random_early_detection
+ * @see struct rte_cman_red_params
+ */
+ RTE_CMAN_RED = RTE_BIT64(0),
+};
+
+/**
+ * RED based congestion management configuration parameters.
+ */
+struct rte_cman_red_params {
+ /**< Minimum threshold (min_th) value
+ *
+ * Value expressed as percentage. Value must be in 0 to 100(inclusive).
+ */
+ uint8_t min_th;
+ /**< Maximum threshold (max_th) value
+ *
+ * Value expressed as percentage. Value must be in 0 to 100(inclusive).
+ */
+ uint8_t max_th;
+ /** Inverse of packet marking probability maximum value (maxp = 1 / maxp_inv) */
+ uint16_t maxp_inv;
+};
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_CMAN_H */
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 04cff8ee10..7c8718bb2e 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -160,6 +160,7 @@ extern "C" {
#define RTE_ETHDEV_DEBUG_TX
#endif
+#include <rte_cman.h>
#include <rte_compat.h>
#include <rte_log.h>
#include <rte_interrupts.h>
@@ -5452,6 +5453,150 @@ typedef struct {
__rte_experimental
int rte_eth_dev_priv_dump(uint16_t port_id, FILE *file);
+/* Congestion management */
+
+/** Enumerate list of ethdev congestion management objects */
+enum rte_eth_cman_obj {
+ /** Congestion management based on Rx queue depth */
+ RTE_ETH_CMAN_OBJ_RX_QUEUE = RTE_BIT64(0),
+ /** Congestion management based on mempool depth associated with Rx queue
+ * @see rte_eth_rx_queue_setup()
+ */
+ RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL = RTE_BIT64(1),
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * A structure used to retrieve information of ethdev congestion management.
+ */
+struct rte_eth_cman_info {
+ /** Set of supported congestion management modes
+ * @see enum rte_cman_mode
+ */
+ uint64_t modes_supported;
+ /** Set of supported congestion management objects
+ * @see enum rte_eth_cman_obj
+ */
+ uint64_t objs_supported;
+ /** Reserved for future fields */
+ uint8_t rsvd[64];
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * A structure used to configure the ethdev congestion management.
+ */
+struct rte_eth_cman_config {
+ /** Congestion management object */
+ enum rte_eth_cman_obj obj;
+ /** Congestion management mode */
+ enum rte_cman_mode mode;
+ union {
+ /** Rx queue to configure congestion management.
+ *
+ * Valid when object is RTE_ETH_CMAN_OBJ_RX_QUEUE or
+ * RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL.
+ */
+ uint16_t rx_queue;
+ /** Reserved for future fields */
+ uint8_t rsvd_obj_params[16];
+ } obj_param;
+ union {
+ /** RED configuration parameters.
+ *
+ * Valid when mode is RTE_CMAN_RED.
+ */
+ struct rte_cman_red_params red;
+ /** Reserved for future fields */
+ uint8_t rsvd_mode_params[64];
+ } mode_param;
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Retrieve the information for ethdev congestion management
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param info
+ * A pointer to a structure of type *rte_eth_cman_info* to be filled with
+ * the information about congestion management.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if support for cman_info_get does not exist.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_info_get(uint16_t port_id, struct rte_eth_cman_info *info);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Initialize the ethdev congestion management configuration structure with default values.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param config
+ * A pointer to a structure of type *rte_eth_cman_config* to be initialized
+ * with default value.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_config_init(uint16_t port_id, struct rte_eth_cman_config *config);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Configure ethdev congestion management
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param config
+ * A pointer to a structure of type *rte_eth_cman_config* to be configured.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if support for cman_config_set does not exist.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_config_set(uint16_t port_id, struct rte_eth_cman_config *config);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Retrieve the applied ethdev congestion management parameters for the given port.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param config
+ * A pointer to a structure of type *rte_eth_cman_config* to retrieve
+ * congestion management parameters for the given object.
+ * Application must fill all parameters except mode_param parameter in
+ * struct rte_eth_cman_config.
+ *
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if support for cman_config_get does not exist.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_config_get(uint16_t port_id, struct rte_eth_cman_config *config);
+
#include <rte_ethdev_core.h>
/**
--
2.36.1
^ permalink raw reply [relevance 2%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:19 3% ` Dumitrescu, Cristian
@ 2022-05-30 14:03 4% ` Danilewicz, MarcinX
2022-06-02 9:57 3% ` Danilewicz, MarcinX
1 sibling, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-05-30 14:03 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
Hi Cristian,
> Can you please explain why you need to add the new
> RTE_SCHED_CMAN_NONE value to this enumeration and what is the ABI
> breakage that you are trying to avoid?
>
> The library expects the struct rte_sched_subport_params:: cman_params to
> be NULL when the CMAN is disabled, why is this not enough to detect that
> CMAN is disabled? I suggest to keep the current approach.
Well, that above was just another approach. I'll have look to follow your advice, because there should be a third case when no RED or PIR config was found in files.
So I used third enum to detect this case, like here:
> + else if (params->cman_params->cman_mode ==
> RTE_SCHED_CMAN_NONE)
> + return 1;
Also I got this advice to move RTE_SCHED_CMAN_NONE to the bottom to remove ABI warnings, because structure in header file has changed without change in map files (?) for that?
Here is some more detailed log with errors:
1 data member change:
type of 'rte_sched_cman_params* rte_sched_subport_params::cman_params' changed:
in pointed to type 'struct rte_sched_cman_params' at rte_sched.h:166:1:
type size hasn't changed
1 data member change:
type of 'rte_sched_cman_mode rte_sched_cman_params::cman_mode' changed:
type size hasn't changed
1 enumerator insertion:
'rte_sched_cman_mode::RTE_SCHED_CMAN_NONE' value '0'
2 enumerator changes:
'rte_sched_cman_mode::RTE_SCHED_CMAN_RED' from value '0' to '1' at rte_sched.h:128:1
'rte_sched_cman_mode::RTE_SCHED_CMAN_PIE' from value '1' to '2' at rte_sched.h:128:1
Error: ABI issue reported for 'abidiff --suppr devtools/libabigail.abignore --no-added-syms --headers-dir1 reference/usr/local/include --headers-dir2 install/usr/local/include reference/dump/librte_sched.dump install/dump/librte_sched.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Kind Regards,
/Marcin
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3] pcap: support MTU set
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
@ 2022-05-30 18:05 0% ` Ferruh Yigit
2022-05-31 13:12 0% ` Ido Goshen
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-05-30 18:05 UTC (permalink / raw)
To: Ido Goshen, ferruh.yigit, stephen; +Cc: dev, Tianli Lai
On 5/30/2022 11:36 AM, Ido Goshen wrote:
> Support rte_eth_dev_set_mtu by pcap vdevs
> Enforce mtu on rx/tx
>
Still not sure about enforcing MTU on pcap, but please find comments on
mechanical issues
> Bugzilla ID: 961
> Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
>
> ---
> v3:
> Preserve pcap behavior to support max size packets by default
> alternative to v2 in order to limit the code change to pcap only and
> avoid abi change.
> Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
>
> v2:
> Preserve pcap behavior to support max size packets by default.
> ---
> drivers/net/pcap/pcap_ethdev.c | 44 +++++++++++++++++++++++++++++++---
> 1 file changed, 41 insertions(+), 3 deletions(-)
>
Is documentation needs to be updated as well?
And what do you think to update release notes for this update?
> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index ec29fd6bc5..2e7fff9579 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -93,6 +93,7 @@ struct pmd_internals {
> int single_iface;
> int phy_mac;
> unsigned int infinite_rx;
> + int is_mtu_set;
> };
>
> struct pmd_process_private {
> @@ -278,11 +279,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> const u_char *packet;
> struct rte_mbuf *mbuf;
> struct pcap_rx_queue *pcap_q = queue;
> + struct rte_eth_dev *dev = &rte_eth_devices[pcap_q->port_id];
> + struct pmd_internals *internals = dev->data->dev_private;
'rte_eth_devices[]' needs to be used for 'process_private' but lets not
tie it to access 'dev_private'.
You can add "struct pmd_internals *" to the "struct pcap_rx_queue" &
"struct pcap_tx_queue" structs for the access. Please check null PMD for
sample.
> uint16_t num_rx = 0;
> uint32_t rx_bytes = 0;
> pcap_t *pcap;
>
> - pp = rte_eth_devices[pcap_q->port_id].process_private;
> + pp = dev->process_private;
> pcap = pp->rx_pcap[pcap_q->queue_id];
>
> if (unlikely(pcap == NULL || nb_pkts == 0))
> @@ -303,6 +306,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> break;
> }
>
> + if (unlikely(header.caplen > dev->data->mtu) &&
> + internals->is_mtu_set) {
> + pcap_q->rx_stat.err_pkts++;
> + rte_pktmbuf_free(mbuf);
> + break;
> + }
> +
> if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
> /* pcap packet will fit in the mbuf, can copy it */
> rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> @@ -378,6 +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *dumper_q = queue;
> + struct rte_eth_dev *dev = &rte_eth_devices[dumper_q->port_id];
> + struct pmd_internals *internals = dev->data->dev_private;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> struct pcap_pkthdr header;
> @@ -385,7 +397,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
> size_t len, caplen;
>
> - pp = rte_eth_devices[dumper_q->port_id].process_private;
> + pp = dev->process_private;
> dumper = pp->tx_dumper[dumper_q->queue_id];
>
> if (dumper == NULL || nb_pkts == 0)
> @@ -396,6 +408,13 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = caplen = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > dev->data->mtu) &&
> + internals->is_mtu_set) {
It is possible to save only some part of the packet to the pcap file,
please check snaplen patch [1], how MTU config should work with this
feature?
[1]
https://patchwork.dpdk.org/project/dpdk/patch/20220313112638.3945-1-laitianli@tom.com/
> + rte_pktmbuf_free(mbuf);
> + continue;
Normally a PMD should not silently free a packet itself, it should
return error and application will decide to free the packet or not.
> + }
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> caplen = sizeof(temp_data);
> @@ -464,13 +483,15 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *tx_queue = queue;
> + struct rte_eth_dev *dev = &rte_eth_devices[tx_queue->port_id];
> + struct pmd_internals *internals = dev->data->dev_private;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> pcap_t *pcap;
> unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
> size_t len;
>
> - pp = rte_eth_devices[tx_queue->port_id].process_private;
> + pp = dev->process_private;
> pcap = pp->tx_pcap[tx_queue->queue_id];
>
> if (unlikely(nb_pkts == 0 || pcap == NULL))
> @@ -479,6 +500,13 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > dev->data->mtu) &&
> + internals->is_mtu_set) {
> + rte_pktmbuf_free(mbuf);
> + continue;
ditto
> + }
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> PMD_LOG(ERR,
> @@ -807,6 +835,14 @@ eth_stats_reset(struct rte_eth_dev *dev)
> return 0;
> }
>
> +static int eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
Please follow coding convention to have return type in a separate line:
static int
eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
> +{
> + PMD_LOG(INFO, "mtu set %s %u\n", dev->device->name, mtu);
Can you please move the log after variable declerations. And can be good
to capitilise MTU in the log.
> + struct pmd_internals *internals = dev->data->dev_private;
> + internals->is_mtu_set = 1;
> + return 0;
> +}
> +
> static inline void
> infinite_rx_ring_free(struct rte_ring *pkts)
> {
> @@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
> .link_update = eth_link_update,
> .stats_get = eth_stats_get,
> .stats_reset = eth_stats_reset,
> + .mtu_set = eth_mtu_set,
> };
>
> static int
> @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> .addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
> };
> (*internals)->phy_mac = 0;
> + (*internals)->is_mtu_set = 0;
> data = (*eth_dev)->data;
> data->nb_rx_queues = (uint16_t)nb_rx_queues;
> data->nb_tx_queues = (uint16_t)nb_tx_queues;
^ permalink raw reply [relevance 0%]
* [PATCH v3 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-05-27 18:18 3% ` [PATCH v2 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
@ 2022-05-30 18:24 3% ` Stanislaw Kardach
2022-05-30 20:38 0% ` Stephen Hemminger
2022-06-01 9:35 0% ` Medvedkin, Vladimir
0 siblings, 2 replies; 200+ results
From: Stanislaw Kardach @ 2022-05-30 18:24 UTC (permalink / raw)
To: Vladimir Medvedkin
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
All other rte_lpm_lookup* functions take lpm argument as a const. As the
basic rte_lpm_lookup() performs the same function, it should also do
that.
As this function is inline, no API/ABI change happens.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
lib/lpm/rte_lpm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index eb91960e81..1cf863a146 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
* -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
*/
static inline int
-rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
+rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
{
unsigned tbl24_index = (ip >> 8);
uint32_t tbl_entry;
--
2.30.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
@ 2022-05-30 19:43 0% ` Ajit Khaparde
2022-05-31 1:09 0% ` Min Hu (Connor)
2022-05-31 16:09 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Ajit Khaparde @ 2022-05-30 19:43 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: dpdk-dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko,
Andrew Boyer, Beilei Xing, Bruce Richardson, Chas Williams, Xia,
Chenbo, Ciara Loftus, Devendra Singh Rawat, Ed Czeck,
Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh, Guoyang Zhou,
Haiyue Wang, Harman Kalra, Heinrich Kuhn, Hemant Agrawal,
Hyong Youb Kim, Igor Chauskin, Igor Russkikh, Jakub Grajciar,
Singh, Jasvinder, Jian Wang, Jiawen Wu, Jingjing Wu, John Daley,
John Miller, John W. Linville, Wiles, Keith, Kiran Kumar K,
oulijun, Liron Himi, Long Li, Marcin Wojtas, Martin Spinler,
Matan Azrad, Matt Peters, Maxime Coquelin, Michal Krawczyk,
Min Hu (Connor),
Nalla Pradeep, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
Rosen Xu, Sachin Saxena (OSS),
Satha Rao, Shahed Shaikh, Shai Brandes, Shepard Siegel,
Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
Veerasenareddy Burru, Slava Ovsiienko, Xiao Wang, Xiaoyun Wang,
Yisen Zhuang, Yong Wang, Ziyang Xuan, Dumitrescu, Cristian
[-- Attachment #1: Type: text/plain, Size: 10369 bytes --]
On Mon, May 30, 2022 at 6:16 AM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
Can you also add How all this helps an application? Thanks
>
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> doc/guides/nics/features.rst | 12 +++
> doc/guides/nics/features/default.ini | 1 +
> lib/eal/include/meson.build | 1 +
> lib/eal/include/rte_cman.h | 51 ++++++++++
> lib/ethdev/rte_ethdev.h | 145 +++++++++++++++++++++++++++
> 5 files changed, 210 insertions(+)
> create mode 100644 lib/eal/include/rte_cman.h
>
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 21bedb743f..ffcc2bcc92 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -727,6 +727,18 @@ Supports configuring per-queue stat counter mapping.
> ``rte_eth_dev_set_tx_queue_stats_mapping()``.
>
>
> +.. _nic_features_congestion_management
> +
> +Congestion management
> +---------------------
> +
> +Supports congestion management.
> +
> +* **[implements] eth_dev_ops**: ``cman_info_get``, ``cman_config_set``, ``cman_config_get``.
> +* **[related] API**: ``rte_eth_cman_info_get()``, ``rte_eth_cman_config_init()``,
> + ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
> +
> +
> .. _nic_features_fw_version:
>
> FW version
> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
> index b1d18ac62c..060497e41f 100644
> --- a/doc/guides/nics/features/default.ini
> +++ b/doc/guides/nics/features/default.ini
> @@ -60,6 +60,7 @@ Tx descriptor status =
> Basic stats =
> Extended stats =
> Stats per queue =
> +Congestion management =
> FW version =
> EEPROM dump =
> Module EEPROM dump =
> diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
> index 9700494816..40e31e0e6d 100644
> --- a/lib/eal/include/meson.build
> +++ b/lib/eal/include/meson.build
> @@ -10,6 +10,7 @@ headers += files(
> 'rte_branch_prediction.h',
> 'rte_bus.h',
> 'rte_class.h',
> + 'rte_cman.h',
> 'rte_common.h',
> 'rte_compat.h',
> 'rte_debug.h',
> diff --git a/lib/eal/include/rte_cman.h b/lib/eal/include/rte_cman.h
> new file mode 100644
> index 0000000000..e6dad2ebf7
> --- /dev/null
> +++ b/lib/eal/include/rte_cman.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2022 Marvell International Ltd.
> + */
> +
> +#ifndef RTE_CMAN_H
> +#define RTE_CMAN_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_bitops.h>
> +
> +/**
> + * @file
> + * Congestion management related parameters for DPDK.
> + */
> +
> +/** Congestion management modes */
> +enum rte_cman_mode {
> + /** Congestion based on Random Early Detection.
> + *
> + * https://en.wikipedia.org/wiki/Random_early_detection
> + * @see struct rte_cman_red_params
> + */
> + RTE_CMAN_RED = RTE_BIT64(0),
> +};
> +
> +/**
> + * RED based congestion management configuration parameters.
> + */
> +struct rte_cman_red_params {
> + /**< Minimum threshold (min_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t min_th;
> + /**< Maximum threshold (max_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t max_th;
> + /** Inverse of packet marking probability maximum value (maxp = 1 / maxp_inv) */
> + uint16_t maxp_inv;
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* RTE_CMAN_H */
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8ee10..7c8718bb2e 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -160,6 +160,7 @@ extern "C" {
> #define RTE_ETHDEV_DEBUG_TX
> #endif
>
> +#include <rte_cman.h>
> #include <rte_compat.h>
> #include <rte_log.h>
> #include <rte_interrupts.h>
> @@ -5452,6 +5453,150 @@ typedef struct {
> __rte_experimental
> int rte_eth_dev_priv_dump(uint16_t port_id, FILE *file);
>
> +/* Congestion management */
> +
> +/** Enumerate list of ethdev congestion management objects */
> +enum rte_eth_cman_obj {
> + /** Congestion management based on Rx queue depth */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE = RTE_BIT64(0),
> + /** Congestion management based on mempool depth associated with Rx queue
> + * @see rte_eth_rx_queue_setup()
> + */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL = RTE_BIT64(1),
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * A structure used to retrieve information of ethdev congestion management.
> + */
> +struct rte_eth_cman_info {
> + /** Set of supported congestion management modes
> + * @see enum rte_cman_mode
> + */
> + uint64_t modes_supported;
> + /** Set of supported congestion management objects
> + * @see enum rte_eth_cman_obj
> + */
> + uint64_t objs_supported;
> + /** Reserved for future fields */
> + uint8_t rsvd[64];
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * A structure used to configure the ethdev congestion management.
> + */
> +struct rte_eth_cman_config {
> + /** Congestion management object */
> + enum rte_eth_cman_obj obj;
> + /** Congestion management mode */
> + enum rte_cman_mode mode;
> + union {
> + /** Rx queue to configure congestion management.
> + *
> + * Valid when object is RTE_ETH_CMAN_OBJ_RX_QUEUE or
> + * RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL.
> + */
> + uint16_t rx_queue;
> + /** Reserved for future fields */
> + uint8_t rsvd_obj_params[16];
> + } obj_param;
> + union {
> + /** RED configuration parameters.
> + *
> + * Valid when mode is RTE_CMAN_RED.
> + */
> + struct rte_cman_red_params red;
> + /** Reserved for future fields */
> + uint8_t rsvd_mode_params[64];
> + } mode_param;
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the information for ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param info
> + * A pointer to a structure of type *rte_eth_cman_info* to be filled with
> + * the information about congestion management.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_info_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_info_get(uint16_t port_id, struct rte_eth_cman_info *info);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Initialize the ethdev congestion management configuration structure with default values.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be initialized
> + * with default value.
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_init(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Configure ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be configured.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_set does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_set(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the applied ethdev congestion management parameters for the given port.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to retrieve
> + * congestion management parameters for the given object.
> + * Application must fill all parameters except mode_param parameter in
> + * struct rte_eth_cman_config.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_get(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> #include <rte_ethdev_core.h>
>
> /**
> --
> 2.36.1
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4218 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
@ 2022-05-30 20:38 0% ` Stephen Hemminger
2022-06-01 9:35 0% ` Medvedkin, Vladimir
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-05-30 20:38 UTC (permalink / raw)
To: Stanislaw Kardach
Cc: Vladimir Medvedkin, dev, Frank Zhao, Sam Grove, mw, upstream
On Mon, 30 May 2022 20:24:36 +0200
Stanislaw Kardach <kda@semihalf.com> wrote:
> All other rte_lpm_lookup* functions take lpm argument as a const. As the
> basic rte_lpm_lookup() performs the same function, it should also do
> that.
>
> As this function is inline, no API/ABI change happens.
>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
@ 2022-05-31 1:09 0% ` Min Hu (Connor)
2022-05-31 16:09 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Min Hu (Connor) @ 2022-05-31 1:09 UTC (permalink / raw)
To: jerinj, dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, cristian.dumitrescu
Hi, jerinj,
在 2022/5/30 21:15, jerinj@marvell.com 写道:
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> doc/guides/nics/features.rst | 12 +++
> doc/guides/nics/features/default.ini | 1 +
> lib/eal/include/meson.build | 1 +
> lib/eal/include/rte_cman.h | 51 ++++++++++
> lib/ethdev/rte_ethdev.h | 145 +++++++++++++++++++++++++++
> 5 files changed, 210 insertions(+)
> create mode 100644 lib/eal/include/rte_cman.h
>
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 21bedb743f..ffcc2bcc92 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -727,6 +727,18 @@ Supports configuring per-queue stat counter mapping.
> ``rte_eth_dev_set_tx_queue_stats_mapping()``.
>
>
> +.. _nic_features_congestion_management
> +
> +Congestion management
> +---------------------
> +
> +Supports congestion management.
> +
> +* **[implements] eth_dev_ops**: ``cman_info_get``, ``cman_config_set``, ``cman_config_get``.
> +* **[related] API**: ``rte_eth_cman_info_get()``, ``rte_eth_cman_config_init()``,
> + ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
> +
> +
> .. _nic_features_fw_version:
>
> FW version
> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
> index b1d18ac62c..060497e41f 100644
> --- a/doc/guides/nics/features/default.ini
> +++ b/doc/guides/nics/features/default.ini
> @@ -60,6 +60,7 @@ Tx descriptor status =
> Basic stats =
> Extended stats =
> Stats per queue =
> +Congestion management =
> FW version =
> EEPROM dump =
> Module EEPROM dump =
> diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
> index 9700494816..40e31e0e6d 100644
> --- a/lib/eal/include/meson.build
> +++ b/lib/eal/include/meson.build
> @@ -10,6 +10,7 @@ headers += files(
> 'rte_branch_prediction.h',
> 'rte_bus.h',
> 'rte_class.h',
> + 'rte_cman.h',
> 'rte_common.h',
> 'rte_compat.h',
> 'rte_debug.h',
> diff --git a/lib/eal/include/rte_cman.h b/lib/eal/include/rte_cman.h
> new file mode 100644
> index 0000000000..e6dad2ebf7
> --- /dev/null
> +++ b/lib/eal/include/rte_cman.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2022 Marvell International Ltd.
> + */
> +
> +#ifndef RTE_CMAN_H
> +#define RTE_CMAN_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_bitops.h>
> +
> +/**
> + * @file
> + * Congestion management related parameters for DPDK.
> + */
> +
> +/** Congestion management modes */
> +enum rte_cman_mode {
> + /** Congestion based on Random Early Detection.
> + *
> + * https://en.wikipedia.org/wiki/Random_early_detection
> + * @see struct rte_cman_red_params
> + */
> + RTE_CMAN_RED = RTE_BIT64(0),
> +};
> +
> +/**
> + * RED based congestion management configuration parameters.
> + */
> +struct rte_cman_red_params {
> + /**< Minimum threshold (min_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t min_th;
> + /**< Maximum threshold (max_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t max_th;
> + /** Inverse of packet marking probability maximum value (maxp = 1 / maxp_inv) */
> + uint16_t maxp_inv;
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* RTE_CMAN_H */
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8ee10..7c8718bb2e 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -160,6 +160,7 @@ extern "C" {
> #define RTE_ETHDEV_DEBUG_TX
> #endif
>
> +#include <rte_cman.h>
> #include <rte_compat.h>
> #include <rte_log.h>
> #include <rte_interrupts.h>
> @@ -5452,6 +5453,150 @@ typedef struct {
> __rte_experimental
> int rte_eth_dev_priv_dump(uint16_t port_id, FILE *file);
>
> +/* Congestion management */
> +
> +/** Enumerate list of ethdev congestion management objects */
> +enum rte_eth_cman_obj {
> + /** Congestion management based on Rx queue depth */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE = RTE_BIT64(0),
> + /** Congestion management based on mempool depth associated with Rx queue
> + * @see rte_eth_rx_queue_setup()
> + */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL = RTE_BIT64(1),
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
'API' --> 'structure'
> + *
> + * A structure used to retrieve information of ethdev congestion management.
> + */
> +struct rte_eth_cman_info {
> + /** Set of supported congestion management modes
> + * @see enum rte_cman_mode
> + */
> + uint64_t modes_supported;
> + /** Set of supported congestion management objects
> + * @see enum rte_eth_cman_obj
> + */
> + uint64_t objs_supported;
> + /** Reserved for future fields */
> + uint8_t rsvd[64];
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
'API' --> 'structure'
> + *
> + * A structure used to configure the ethdev congestion management.
> + */
> +struct rte_eth_cman_config {
> + /** Congestion management object */
> + enum rte_eth_cman_obj obj;
> + /** Congestion management mode */
> + enum rte_cman_mode mode;
> + union {
> + /** Rx queue to configure congestion management.
> + *
> + * Valid when object is RTE_ETH_CMAN_OBJ_RX_QUEUE or
> + * RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL.
> + */
> + uint16_t rx_queue;
> + /** Reserved for future fields */
> + uint8_t rsvd_obj_params[16];
> + } obj_param;
> + union {
> + /** RED configuration parameters.
> + *
> + * Valid when mode is RTE_CMAN_RED.
> + */
> + struct rte_cman_red_params red;
> + /** Reserved for future fields */
> + uint8_t rsvd_mode_params[64];
> + } mode_param;
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the information for ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param info
> + * A pointer to a structure of type *rte_eth_cman_info* to be filled with
> + * the information about congestion management.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_info_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_info_get(uint16_t port_id, struct rte_eth_cman_info *info);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Initialize the ethdev congestion management configuration structure with default values.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be initialized
> + * with default value.
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_init(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Configure ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be configured.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_set does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_set(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the applied ethdev congestion management parameters for the given port.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to retrieve
> + * congestion management parameters for the given object.
> + * Application must fill all parameters except mode_param parameter in
> + * struct rte_eth_cman_config.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_get(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> #include <rte_ethdev_core.h>
>
> /**
>
^ permalink raw reply [relevance 0%]
* [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
@ 2022-05-31 4:04 3% Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Arek Kusztal @ 2022-05-31 4:04 UTC (permalink / raw)
To: dev; +Cc: gakhil, roy.fan.zhang, Arek Kusztal
This patchset introduces some of changes discussed on mailing list for 22.07 release in cryptodev asym.
Key changes:
- It fixes API for RSA (expescially signature paddings)
- Adds Elliptic-Curve Diffie-Hellman
- Adds Eliiptic-Curve point verification
- Adds RSA missing padding fields
- Adds asym op flags
- Fixes many API comments (like EC curves)
v4:
- fixed shared build problem
- added ABI ignore entry for xform
Arek Kusztal (12):
cryptodev: redefine ec group enum
cryptodev: separate key exchange operation enum
cryptodev: remove comment about using ephemeral key in dsa
cryptodev: clarify usage of private key in dh
cryptodev: move dh type from xform to dh op
cryptodev: add elliptic curve diffie hellman
cryptodev: add public key verify option
cryptodev: add asym op flags
cryptodev: clarify usage of rsa padding hash
cryptodev: move RSA padding into separate struct
cryptodev: clarify rsa verify with none padding
cryptodev: add salt length and optional label
app/test/test_cryptodev_asym.c | 63 ++++----
devtools/libabigail.abignore | 3 +
drivers/common/cpt/cpt_ucode_asym.h | 4 +-
drivers/crypto/cnxk/cnxk_ae.h | 8 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 17 +--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +---
drivers/crypto/qat/qat_asym.c | 12 +-
lib/cryptodev/rte_crypto_asym.h | 217 ++++++++++++++++++++-------
lib/cryptodev/rte_cryptodev.c | 15 +-
lib/cryptodev/rte_cryptodev.h | 4 +-
lib/cryptodev/version.map | 1 +
12 files changed, 237 insertions(+), 144 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
@ 2022-05-31 4:04 4% ` Arek Kusztal
2022-05-31 7:49 0% ` [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Zhang, Roy Fan
2022-05-31 11:52 0% ` [EXT] " Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Arek Kusztal @ 2022-05-31 4:04 UTC (permalink / raw)
To: dev; +Cc: gakhil, roy.fan.zhang, Arek Kusztal, mdr
- Added elliptic curve Diffie-Hellman parameters.
Point multiplication allows the user to process every phase of
ECDH, but for phase 1, user should not really care about the generator.
The user does not even need to know what the generator looks like,
therefore setting ec xform would make this work.
Cc: mdr@ashroe.eu
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
devtools/libabigail.abignore | 3 +++
lib/cryptodev/rte_crypto_asym.h | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..6d174b291f 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,9 @@
; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
[suppress_type]
name = rte_crypto_asym_op
+; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is experimental
+[suppress_type]
+ name = rte_crypto_asym_xform_type
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 88bc34dc8c..f61a2ddce8 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm
* Perform Signature Generation and Verification.
*/
+ RTE_CRYPTO_ASYM_XFORM_ECDH,
+ /**< Elliptic Curve Diffie Hellman */
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
@@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param {
};
/**
+ * Elliptic Curve Diffie-Hellman Operations params.
+ */
+struct rte_crypto_ecdh_op_param {
+ enum rte_crypto_asym_ke_type ke_type;
+ /**< Key exchange operation type */
+ rte_crypto_uint priv_key;
+ /**<
+ * Output - generated private key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
+ *
+ * Input - private key when ke_type is one of:
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ *
+ * In case priv_key.length is 0 and ke_type is set with
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+ * device will generate private key and use it for public
+ * key generation.
+ */
+ struct rte_crypto_ec_point pub_key;
+ /**<
+ * Output - generated public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
+ *
+ * Input - peer's public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+ struct rte_crypto_ec_point shared_secret;
+ /**<
+ * Output - calculated shared secret when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+};
+
+/**
* DSA Operations params
*
*/
@@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_mod_op_param modex;
struct rte_crypto_mod_op_param modinv;
struct rte_crypto_dh_op_param dh;
+ struct rte_crypto_ecdh_op_param ecdh;
struct rte_crypto_dsa_op_param dsa;
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
--
2.13.6
^ permalink raw reply [relevance 4%]
* RE: [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
@ 2022-05-31 7:49 0% ` Zhang, Roy Fan
2022-05-31 11:52 0% ` [EXT] " Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2022-05-31 7:49 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, dev; +Cc: gakhil
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:04 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
>
> This patchset introduces some of changes discussed on mailing list for 22.07
> release in cryptodev asym.
>
> Key changes:
>
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Adds Eliiptic-Curve point verification
> - Adds RSA missing padding fields
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
>
> v4:
> - fixed shared build problem
> - added ABI ignore entry for xform
>
> Arek Kusztal (12):
> cryptodev: redefine ec group enum
> cryptodev: separate key exchange operation enum
> cryptodev: remove comment about using ephemeral key in dsa
> cryptodev: clarify usage of private key in dh
> cryptodev: move dh type from xform to dh op
> cryptodev: add elliptic curve diffie hellman
> cryptodev: add public key verify option
> cryptodev: add asym op flags
> cryptodev: clarify usage of rsa padding hash
> cryptodev: move RSA padding into separate struct
> cryptodev: clarify rsa verify with none padding
> cryptodev: add salt length and optional label
>
> app/test/test_cryptodev_asym.c | 63 ++++----
> devtools/libabigail.abignore | 3 +
> drivers/common/cpt/cpt_ucode_asym.h | 4 +-
> drivers/crypto/cnxk/cnxk_ae.h | 8 +-
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
> drivers/crypto/openssl/rte_openssl_pmd.c | 17 +--
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +---
> drivers/crypto/qat/qat_asym.c | 12 +-
> lib/cryptodev/rte_crypto_asym.h | 217 ++++++++++++++++++++-----
> --
> lib/cryptodev/rte_cryptodev.c | 15 +-
> lib/cryptodev/rte_cryptodev.h | 4 +-
> lib/cryptodev/version.map | 1 +
> 12 files changed, 237 insertions(+), 144 deletions(-)
>
> --
> 2.13.6
Series-acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-05-31 7:49 0% ` [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Zhang, Roy Fan
@ 2022-05-31 11:52 0% ` Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-05-31 11:52 UTC (permalink / raw)
To: Arek Kusztal, dev; +Cc: roy.fan.zhang
> This patchset introduces some of changes discussed on mailing list for 22.07
> release in cryptodev asym.
>
> Key changes:
>
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Adds Eliiptic-Curve point verification
> - Adds RSA missing padding fields
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
>
> v4:
> - fixed shared build problem
> - added ABI ignore entry for xform
The Documentation is still not updated for these changes.
Please update doc/guides/prog_guide/cryptodev_lib.rst
And doc/guides/cryptodevs/features/default.ini (for ECDH)
Also update release notes (ECDH).
>
> Arek Kusztal (12):
> cryptodev: redefine ec group enum
> cryptodev: separate key exchange operation enum
> cryptodev: remove comment about using ephemeral key in dsa
> cryptodev: clarify usage of private key in dh
> cryptodev: move dh type from xform to dh op
> cryptodev: add elliptic curve diffie hellman
> cryptodev: add public key verify option
> cryptodev: add asym op flags
> cryptodev: clarify usage of rsa padding hash
> cryptodev: move RSA padding into separate struct
> cryptodev: clarify rsa verify with none padding
> cryptodev: add salt length and optional label
>
> app/test/test_cryptodev_asym.c | 63 ++++----
> devtools/libabigail.abignore | 3 +
> drivers/common/cpt/cpt_ucode_asym.h | 4 +-
> drivers/crypto/cnxk/cnxk_ae.h | 8 +-
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
> drivers/crypto/openssl/rte_openssl_pmd.c | 17 +--
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +---
> drivers/crypto/qat/qat_asym.c | 12 +-
> lib/cryptodev/rte_crypto_asym.h | 217 ++++++++++++++++++++-------
> lib/cryptodev/rte_cryptodev.c | 15 +-
> lib/cryptodev/rte_cryptodev.h | 4 +-
> lib/cryptodev/version.map | 1 +
> 12 files changed, 237 insertions(+), 144 deletions(-)
>
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* RE: [PATCH v3] pcap: support MTU set
2022-05-30 18:05 0% ` Ferruh Yigit
@ 2022-05-31 13:12 0% ` Ido Goshen
0 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-05-31 13:12 UTC (permalink / raw)
To: Ferruh Yigit, stephen; +Cc: dev, Tianli Lai
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> Sent: Monday, 30 May 2022 21:06
> To: Ido Goshen <Ido@cgstowernetworks.com>; ferruh.yigit@xilinx.com;
> stephen@networkplumber.org
> Cc: dev@dpdk.org; Tianli Lai <laitianli@tom.com>
> Subject: Re: [PATCH v3] pcap: support MTU set
>
> On 5/30/2022 11:36 AM, Ido Goshen wrote:
> > Support rte_eth_dev_set_mtu by pcap vdevs Enforce mtu on rx/tx
> >
>
> Still not sure about enforcing MTU on pcap, but please find comments on
> mechanical issues
[idog] Trying to detail more about use cases:
1. CI tests which are HW independent and works with --vdevs=net_pcap
For testing that mtu feature(s) work correctly in our app a pcap that contains
mix sized packets should be used. Using pcap that has only small size packets
will miss the all point.
2. Customer support - it's much simpler to debug on a workstation and not
real HW setup. We often get the customer's configuration and a pcap in order
to reproduce an issue. It will be a pain and error-prone to manipulate the pcap
before using it.
I will address the mechanical issues and post v4 patch
> > Bugzilla ID: 961
> > Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
> >
> > ---
> > v3:
> > Preserve pcap behavior to support max size packets by default
> > alternative to v2 in order to limit the code change to pcap only and
> > avoid abi change.
> > Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
> >
> > v2:
> > Preserve pcap behavior to support max size packets by default.
> > ---
> > drivers/net/pcap/pcap_ethdev.c | 44
> +++++++++++++++++++++++++++++++---
> > 1 file changed, 41 insertions(+), 3 deletions(-)
> >
>
> Is documentation needs to be updated as well?
[idog] I don't think so
It's using the standard rte_eth_dev_set_mtu() which is already documented in
features.rst https://doc.dpdk.org/guides/nics/features.html#mtu-update
I don't see other PMDs mention explicitly they support it (it's the normal behaviour)
> And what do you think to update release notes for this update?
[idog] ok
> > +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
> > + if (unlikely(len > dev->data->mtu) &&
> > + internals->is_mtu_set) {
>
> It is possible to save only some part of the packet to the pcap file, please
> check snaplen patch [1], how MTU config should work with this feature?
>
> [1]
> https://patchwork.dpdk.org/project/dpdk/patch/20220313112638.3945-1-
> laitianli@tom.com/
>
[idog] interesting to know this is being work on.
(To your method, why is it needed? there are tools like editpcap that can be
applied on the dpdk output file and snap the packets ;-)
I think integration of the 2 features is trivial, mtu controls if the packet is
written to file or not, and snaplan controls what part of it needs to be written.
i.e. mtu is checked before snaplen.
Using snaplen > mtu will become meaningless (maybe block/warn on such configuration)
Alternative is to apply mtu only on pcap iface (assuming snaplen is applied only
on tx_pcap file)
If supporting mtu only for pcap live ifaces and not for pcap files then
the all thing can be implemented differently by setting the OS netdevice
mtu (e.g. in linux SIOCSIFMTU) instead of enforcing it by the pcap pmd
but this will require osdep use and I admit I have no idea how to do it for windows
Would this be a better approach?
^ permalink raw reply [relevance 0%]
* [PATCH v4 7/8] devtools: add RISC-V to test-meson-builds.sh
@ 2022-05-31 14:13 9% ` Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-05-31 14:13 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
devtools/test-meson-builds.sh | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..f732dccf6c 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configuration
+build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
+ $use_shared
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* Re: [PATCH v3 0/6] move DPAA2 QDMA driver freom raw to dma
@ 2022-05-31 15:29 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-05-31 15:29 UTC (permalink / raw)
To: nipun.gupta, hemant.agrawal; +Cc: dev, G.Singh, gakhil
26/05/2022 08:00, Hemant Agrawal:
> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>
> On 5/5/2022 2:35 PM, nipun.gupta@nxp.com wrote:
> > From: Nipun Gupta <nipun.gupta@nxp.com>
> >
> > This change removes the DPAA2 QDMA raw driver and adds the
> > QDMA driver in dma set of drivers. The underlying I/O
> > framework remains intact, whereas the configuration part
> > is done as per the DMA API support.
> >
> > Changes in v2:
> > - Fix checkpath errors
> > - Fix documentation compilation
> >
> > Changes in v3:
> > - Add the missing doc/dmadevs/dpaa2.rst file
> >
> > Nipun Gupta (6):
> > raw/dpaa2_qdma: remove dpaa2 QDMA driver from raw
> > dma/dpaa2: introduce DPAA2 DMA driver skeleton
> > dma/dpaa2: support basic operations
> > dma/dpaa2: add PMD apis for additional configuration
> > dma/dpaa2: support DMA operations
> > dma/dpaa2: support statistics
Fixed some mistakes in the file MAINTAINERS,
and added an exception in devtools/check-abi.sh to skip old driver.
Applied, thanks.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
2022-05-31 1:09 0% ` Min Hu (Connor)
@ 2022-05-31 16:09 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-05-31 16:09 UTC (permalink / raw)
To: jerinj
Cc: dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko,
ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, cristian.dumitrescu
On Mon, 30 May 2022 18:45:26 +0530
<jerinj@marvell.com> wrote:
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
The concept of supporting hardware queue management is good, but would like
to make some suggestions:
The hardware support of QOS should ideally be part of the existing DPDK
traffic management. For example, in Linux there are devices that can offload
traffic control (TC) to hardware and this is done via flags to existing
software infrastructure.
Your implementation makes HW and SW QoS diverge. This will require each application
to get even more dependent on a particular hardware device.
Which brings up the bigger picture problem. Don't want to repeat the problems
with rte_flow here. Any hardware support needs to have a matching set of software
implementation, and test cases. The problem with rte_flow is the semantics are
poorly defined and each vendor does it differently; and the SW flow classifier
is incomplete and does not match what the HW does.
In an ideal world, there would be:
- an abstract API for defining ingress and egress queue management
- a software implementation of that API
- multiple hardware implementations
- ability to transparently use both SW and HW queue management from application
- complete test suite for that API.
Yes, that is asking a lot. But as trailblazer in this area, you have to do the
hard work.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
2022-05-30 20:38 0% ` Stephen Hemminger
@ 2022-06-01 9:35 0% ` Medvedkin, Vladimir
1 sibling, 0 replies; 200+ results
From: Medvedkin, Vladimir @ 2022-06-01 9:35 UTC (permalink / raw)
To: Stanislaw Kardach; +Cc: dev, Frank Zhao, Sam Grove, mw, upstream
On 30/05/2022 19:24, Stanislaw Kardach wrote:
> All other rte_lpm_lookup* functions take lpm argument as a const. As the
> basic rte_lpm_lookup() performs the same function, it should also do
> that.
>
> As this function is inline, no API/ABI change happens.
>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> ---
> lib/lpm/rte_lpm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
> index eb91960e81..1cf863a146 100644
> --- a/lib/lpm/rte_lpm.h
> +++ b/lib/lpm/rte_lpm.h
> @@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
> * -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
> */
> static inline int
> -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> {
> unsigned tbl24_index = (ip >> 8);
> uint32_t tbl_entry;
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
--
Regards,
Vladimir
^ permalink raw reply [relevance 0%]
* [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
@ 2022-06-01 9:02 4% ` Arek Kusztal
2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
0 siblings, 2 replies; 200+ results
From: Arek Kusztal @ 2022-06-01 9:02 UTC (permalink / raw)
To: dev; +Cc: gakhil, roy.fan.zhang, Arek Kusztal
- Added elliptic curve Diffie-Hellman parameters.
Point multiplication allows the user to process every phase of
ECDH, but for phase 1, user should not really care about the generator.
The user does not even need to know what the generator looks like,
therefore setting ec xform would make this work.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
devtools/libabigail.abignore | 3 +++
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
doc/guides/rel_notes/release_22_07.rst | 2 ++
lib/cryptodev/rte_crypto_asym.h | 38 ++++++++++++++++++++++++++++++
5 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..6d174b291f 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,9 @@
; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
[suppress_type]
name = rte_crypto_asym_op
+; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is experimental
+[suppress_type]
+ name = rte_crypto_asym_xform_type
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 018fe0221e..7371ca6644 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -118,6 +118,7 @@ Modular Inversion =
Diffie-hellman =
ECDSA =
ECPM =
+ECDH =
;
; Supported Operating systems of a default crypto driver.
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index edd11059bc..9e54683aa1 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -1018,9 +1018,9 @@ Asymmetric Cryptography
-----------------------
The cryptodev library currently provides support for the following asymmetric
-Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman
-public and/or private key generation and shared secret compute, DSA Signature
-generation and verification.
+Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman and
+Elliptic Curve Diffie-Hellman public and/or private key generation and shared
+secret compute, DSA Signature generation and verification.
Session and Session Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1088,6 +1088,7 @@ Each xform defines specific asymmetric crypto algo. Currently supported are:
* Modular operations (Exponentiation and Inverse)
* Diffie-Hellman
* DSA
+* Elliptic Curve Diffie-Hellman
* None - special case where PMD may support a passthrough mode. More for diagnostic purpose
See *DPDK API Reference* for details on each rte_crypto_xxx_xform struct
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 73a2434f86..ef6eaf0ad2 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -130,6 +130,8 @@ Removed Items
API Changes
-----------
+* cryptodev: Added Elliptic Curve Diffie-Hellman (ECDH) algorithm.
+
.. This section should contain API changes. Sample format:
* sample: Add a short 1-2 sentence description of the API change
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 88bc34dc8c..f61a2ddce8 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm
* Perform Signature Generation and Verification.
*/
+ RTE_CRYPTO_ASYM_XFORM_ECDH,
+ /**< Elliptic Curve Diffie Hellman */
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
@@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param {
};
/**
+ * Elliptic Curve Diffie-Hellman Operations params.
+ */
+struct rte_crypto_ecdh_op_param {
+ enum rte_crypto_asym_ke_type ke_type;
+ /**< Key exchange operation type */
+ rte_crypto_uint priv_key;
+ /**<
+ * Output - generated private key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
+ *
+ * Input - private key when ke_type is one of:
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ *
+ * In case priv_key.length is 0 and ke_type is set with
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+ * device will generate private key and use it for public
+ * key generation.
+ */
+ struct rte_crypto_ec_point pub_key;
+ /**<
+ * Output - generated public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
+ *
+ * Input - peer's public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+ struct rte_crypto_ec_point shared_secret;
+ /**<
+ * Output - calculated shared secret when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+};
+
+/**
* DSA Operations params
*
*/
@@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_mod_op_param modex;
struct rte_crypto_mod_op_param modinv;
struct rte_crypto_dh_op_param dh;
+ struct rte_crypto_ecdh_op_param ecdh;
struct rte_crypto_dsa_op_param dsa;
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
--
2.13.6
^ permalink raw reply [relevance 4%]
* RE: [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-01 9:02 4% ` [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
@ 2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Kusztal, ArkadiuszX @ 2022-06-01 10:14 UTC (permalink / raw)
To: dev; +Cc: gakhil, Zhang, Roy Fan
Hi Akhil,
I did not put much effort into documentation part. I believe it needs bit more attention in asym area (one bigger patch) + backported fixes about ECDSA and ECPM.
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Wednesday, June 1, 2022 11:03 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
>
> - Added elliptic curve Diffie-Hellman parameters.
> Point multiplication allows the user to process every phase of ECDH, but for
> phase 1, user should not really care about the generator.
> The user does not even need to know what the generator looks like, therefore
> setting ec xform would make this work.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> devtools/libabigail.abignore | 3 +++
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> doc/guides/rel_notes/release_22_07.rst | 2 ++
> lib/cryptodev/rte_crypto_asym.h | 38
> ++++++++++++++++++++++++++++++
> 5 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore index
> 79ff15dc4e..6d174b291f 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -27,6 +27,9 @@
> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> experimental [suppress_type]
> name = rte_crypto_asym_op
> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API
> +is experimental [suppress_type]
> + name = rte_crypto_asym_xform_type
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ; Temporary exceptions till next major ABI version ; diff --git
> a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 018fe0221e..7371ca6644 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -118,6 +118,7 @@ Modular Inversion =
> Diffie-hellman =
> ECDSA =
> ECPM =
> +ECDH =
>
> ;
> ; Supported Operating systems of a default crypto driver.
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index edd11059bc..9e54683aa1 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -1018,9 +1018,9 @@ Asymmetric Cryptography
> -----------------------
>
> The cryptodev library currently provides support for the following asymmetric -
> Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman -
> public and/or private key generation and shared secret compute, DSA Signature -
> generation and verification.
> +Crypto operations; RSA, Modular exponentiation and inversion,
> +Diffie-Hellman and Elliptic Curve Diffie-Hellman public and/or private
> +key generation and shared secret compute, DSA Signature generation and
> verification.
>
> Session and Session Management
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> @@ -1088,6 +1088,7 @@ Each xform defines specific asymmetric crypto algo.
> Currently supported are:
> * Modular operations (Exponentiation and Inverse)
> * Diffie-Hellman
> * DSA
> +* Elliptic Curve Diffie-Hellman
> * None - special case where PMD may support a passthrough mode. More for
> diagnostic purpose
>
> See *DPDK API Reference* for details on each rte_crypto_xxx_xform struct diff
> --git a/doc/guides/rel_notes/release_22_07.rst
> b/doc/guides/rel_notes/release_22_07.rst
> index 73a2434f86..ef6eaf0ad2 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -130,6 +130,8 @@ Removed Items
> API Changes
> -----------
>
> +* cryptodev: Added Elliptic Curve Diffie-Hellman (ECDH) algorithm.
> +
> .. This section should contain API changes. Sample format:
>
> * sample: Add a short 1-2 sentence description of the API change diff --git
> a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h index
> 88bc34dc8c..f61a2ddce8 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
> /**< Elliptic Curve Digital Signature Algorithm
> * Perform Signature Generation and Verification.
> */
> + RTE_CRYPTO_ASYM_XFORM_ECDH,
> + /**< Elliptic Curve Diffie Hellman */
> RTE_CRYPTO_ASYM_XFORM_ECPM,
> /**< Elliptic Curve Point Multiplication */
> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> @@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param { };
>
> /**
> + * Elliptic Curve Diffie-Hellman Operations params.
> + */
> +struct rte_crypto_ecdh_op_param {
> + enum rte_crypto_asym_ke_type ke_type;
> + /**< Key exchange operation type */
> + rte_crypto_uint priv_key;
> + /**<
> + * Output - generated private key when ke_type is
> + * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
> + *
> + * Input - private key when ke_type is one of:
> + * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
> + * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
> + *
> + * In case priv_key.length is 0 and ke_type is set with
> + * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
> + * device will generate private key and use it for public
> + * key generation.
> + */
> + struct rte_crypto_ec_point pub_key;
> + /**<
> + * Output - generated public key when ke_type is
> + * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
> + *
> + * Input - peer's public key when ke_type is
> + * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
> + */
> + struct rte_crypto_ec_point shared_secret;
> + /**<
> + * Output - calculated shared secret when ke_type is
> + * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
> + */
> +};
> +
> +/**
> * DSA Operations params
> *
> */
> @@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
> struct rte_crypto_mod_op_param modex;
> struct rte_crypto_mod_op_param modinv;
> struct rte_crypto_dh_op_param dh;
> + struct rte_crypto_ecdh_op_param ecdh;
> struct rte_crypto_dsa_op_param dsa;
> struct rte_crypto_ecdsa_op_param ecdsa;
> struct rte_crypto_ecpm_op_param ecpm;
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
@ 2022-06-01 11:15 3% Stanislaw Kardach
2022-06-02 20:52 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Stanislaw Kardach @ 2022-06-01 11:15 UTC (permalink / raw)
To: Vladimir Medvedkin
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, upstream,
Stephen Hemminger
All other rte_lpm_lookup* functions take lpm argument as a const. As the
basic rte_lpm_lookup() performs the same function, it should also do
that.
As this function is inline, no API/ABI change happens.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/lpm/rte_lpm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index eb91960e81..1cf863a146 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
* -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
*/
static inline int
-rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
+rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
{
unsigned tbl24_index = (ip >> 8);
uint32_t tbl_entry;
--
2.30.2
^ permalink raw reply [relevance 3%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-26 11:02 0% ` Ray Kinsella
@ 2022-06-01 15:04 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-01 15:04 UTC (permalink / raw)
To: dev
Cc: Tyler Retzlaff, david.marchand, techboard, David Christensen,
Ray Kinsella
26/05/2022 13:02, Ray Kinsella:
> Thomas Monjalon <thomas@monjalon.net> writes:
> > 25/05/2022 20:34, Tyler Retzlaff:
> >> On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
> >> > Thomas Monjalon <thomas@monjalon.net> writes:
> >> > > 25/05/2022 13:48, Ray Kinsella:
> >> > >> Thomas Monjalon <thomas@monjalon.net> writes:
> >> > >>
> >> > >> > The AltiVec header file is defining "vector", except in C++ build.
> >> > >> > The keyword "vector" may conflict easily.
> >> > >> > As a rule, it is better to use the alternative keyword "__vector".
> >> > >> >
> >> > >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
> >> > >> > so the applications and dependencies are free to define the name "vector".
> >> > >> >
> >> > >> > This is a compatibility breakage for applications which were using
> >> > >> > the keyword "vector" for its AltiVec meaning.
> >> > >> >
> >> > >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >> > >> > ---
> >> > >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> >> > >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
> >> > >> > 2 files changed, 12 insertions(+)
> >> > >> >
> >> > >>
> >> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> >> > >
> >> > > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> >> > > It means the keyword vector is not available anymore with this #include.
> >> > > Please confirm it is OK to merge in DPDK 22.07.
> >> >
> >> > I did think about it yes ;-).
> >> > I can't see how it would break the ABI in the short term.
> >> > And it makes sense to preclude this keyword in the long term.
> >> >
> >> > So I ack'ed - did I miss something?
> >>
> >> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >>
> >> double ack, impact of break is understood as follows.
> >>
> >> * this is not an issue with abi it is an issue with api.
> >> * the break will cause a compile failure, the action to resolve is to
> >> replace vector with __vector.
> >
> > Exactly
> >
> > I'll wait few days or acks from the techboard, and will apply.
>
> +1
Applied
^ permalink raw reply [relevance 0%]
* [PATCH 07/14] net/nfp: support NFDK firmware
@ 2022-06-02 1:52 6% ` Jin Liu
2022-06-02 22:53 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Jin Liu @ 2022-06-02 1:52 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
drivers/net/nfp/nfp_ctrl.h | 2 ++
drivers/net/nfp/nfp_ethdev.c | 51 ++++++++++++++++++++++++++-------
drivers/net/nfp/nfp_ethdev_vf.c | 37 +++++++++++++++++-------
3 files changed, 69 insertions(+), 21 deletions(-)
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 4d2cd9b0b3..c09a035323 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -384,7 +410,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
RTE_LOG(ERR, PMD, "device %s can not be used: restricted dma "
"mask to 40 bits!\n", pci_dev->device.name);
return -ENODEV;
- };
+ }
port = ((struct nfp_net_hw *)eth_dev->data->dev_private)->idx;
if (port < 0 || port > 7) {
@@ -401,11 +427,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -440,6 +461,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -472,7 +498,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -938,6 +963,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -987,11 +1013,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index f5a0406e7d..e83c9dbcaf 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -287,7 +287,7 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
RTE_LOG(ERR, PMD, "device %s can not be used: restricted dma "
"mask to 40 bits!\n", pci_dev->device.name);
return -ENODEV;
- };
+ }
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
@@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -312,15 +338,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
--
2.27.0
^ permalink raw reply [relevance 6%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 14:03 4% ` Danilewicz, MarcinX
@ 2022-06-02 9:57 3% ` Danilewicz, MarcinX
1 sibling, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-06-02 9:57 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
+this time to dpdk.org , to test removal of automatic footer
Hi Cristian,
< snip >
> > +++ b/lib/sched/rte_sched.h
> > @@ -128,6 +128,8 @@ extern "C" {
> > enum rte_sched_cman_mode {
> > RTE_SCHED_CMAN_RED, /**< Random Early Detection (RED) */
> > RTE_SCHED_CMAN_PIE, /**< Proportional Integral Controller
< snip >
> Can you please explain why you need to add the new
> RTE_SCHED_CMAN_NONE value to this enumeration and what is the ABI
> breakage that you are trying to avoid?
>
well, it was third value for cases when no RED or PIE is configured from config file
Initially I have found this error:
1 data member change:
type of 'rte_sched_cman_params* rte_sched_subport_params::cman_params' changed:
in pointed to type 'struct rte_sched_cman_params' at rte_sched.h:166:1:
type size hasn't changed
1 data member change:
type of 'rte_sched_cman_mode rte_sched_cman_params::cman_mode' changed:
type size hasn't changed
1 enumerator insertion:
'rte_sched_cman_mode::RTE_SCHED_CMAN_NONE' value '0'
2 enumerator changes:
'rte_sched_cman_mode::RTE_SCHED_CMAN_RED' from value '0' to '1' at rte_sched.h:128:1
'rte_sched_cman_mode::RTE_SCHED_CMAN_PIE' from value '1' to '2' at rte_sched.h:128:1
Error: ABI issue reported for 'abidiff --suppr devtools/libabigail.abignore --no-added-syms
--headers-dir1 reference/usr/local/include --headers-dir2 install/usr/local/include reference
/dump/librte_sched.dump install/dump/librte_sched.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Then I moved RTE_SCHED_CMAN_NONE to the end of existing enum, as advices. That removed error above.
In that moment, I needed quick fix for discussion about change for showing approach. Not final fix.
< snip >
> The library expects the struct rte_sched_subport_params:: cman_params to
> be NULL when the CMAN is disabled, why is this not enough to detect that
> CMAN is disabled? I suggest to keep the current approach.
Ok, I'll try to use NULL instead.
Kind Regards,
/Marcin
^ permalink raw reply [relevance 3%]
* RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-01 9:02 4% ` [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
@ 2022-06-02 13:33 3% ` Akhil Goyal
2022-06-02 14:21 0% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2022-06-02 13:33 UTC (permalink / raw)
To: Arek Kusztal, dev, Ray Kinsella; +Cc: roy.fan.zhang
> - Added elliptic curve Diffie-Hellman parameters.
> Point multiplication allows the user to process every phase of
> ECDH, but for phase 1, user should not really care about the generator.
> The user does not even need to know what the generator looks like,
> therefore setting ec xform would make this work.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> devtools/libabigail.abignore | 3 +++
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> doc/guides/rel_notes/release_22_07.rst | 2 ++
> lib/cryptodev/rte_crypto_asym.h | 38
> ++++++++++++++++++++++++++++++
> 5 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 79ff15dc4e..6d174b291f 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -27,6 +27,9 @@
> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> experimental
> [suppress_type]
> name = rte_crypto_asym_op
> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is
> experimental
> +[suppress_type]
> + name = rte_crypto_asym_xform_type
>
This exception does not seem to work.
Thomas and I are getting ABI issues even with this suppress rule.
[C] 'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
type size hasn't changed
1 data member change:
type of 'const rte_cryptodev_capabilities* capabilities' changed:
in pointed to type 'const rte_cryptodev_capabilities':
in unqualified underlying type 'struct rte_cryptodev_capabilities' at rte_cryptodev.h:198:1:
type size hasn't changed
1 data member change:
type of 'anonymous data member union {rte_cryptodev_symmetric_capability sym; rte_cryptodev_asymmetric_capability asym;}' changed:
type size hasn't changed
1 data member change:
type of 'rte_cryptodev_asymmetric_capability asym' changed:
type size hasn't changed
1 data member change:
type of 'rte_cryptodev_asymmetric_xform_capability xform_capa' changed:
type size hasn't changed
1 data member change:
type of 'rte_crypto_asym_xform_type xform_type' changed:
type size hasn't changed
1 enumerator insertion:
'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
2 enumerator changes:
'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from value '8' to '9' at rte_crypto_asym.h:80:1
'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END' from value '9' to '10' at rte_crypto_asym.h:80:1
^ permalink raw reply [relevance 3%]
* Re: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
@ 2022-06-02 14:21 0% ` Ray Kinsella
2022-06-02 14:25 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-06-02 14:21 UTC (permalink / raw)
To: Akhil Goyal; +Cc: Arek Kusztal, dev, roy.fan.zhang
Akhil Goyal <gakhil@marvell.com> writes:
>> - Added elliptic curve Diffie-Hellman parameters.
>> Point multiplication allows the user to process every phase of
>> ECDH, but for phase 1, user should not really care about the generator.
>> The user does not even need to know what the generator looks like,
>> therefore setting ec xform would make this work.
>>
>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> ---
>> devtools/libabigail.abignore | 3 +++
>> doc/guides/cryptodevs/features/default.ini | 1 +
>> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
>> doc/guides/rel_notes/release_22_07.rst | 2 ++
>> lib/cryptodev/rte_crypto_asym.h | 38
>> ++++++++++++++++++++++++++++++
>> 5 files changed, 48 insertions(+), 3 deletions(-)
>>
>> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
>> index 79ff15dc4e..6d174b291f 100644
>> --- a/devtools/libabigail.abignore
>> +++ b/devtools/libabigail.abignore
>> @@ -27,6 +27,9 @@
>> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
>> experimental
>> [suppress_type]
>> name = rte_crypto_asym_op
>> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is
>> experimental
>> +[suppress_type]
>> + name = rte_crypto_asym_xform_type
>>
> This exception does not seem to work.
> Thomas and I are getting ABI issues even with this suppress rule.
>
> [C] 'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
> in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
> type size hasn't changed
> 1 data member change:
> type of 'const rte_cryptodev_capabilities* capabilities' changed:
> in pointed to type 'const rte_cryptodev_capabilities':
> in unqualified underlying type 'struct rte_cryptodev_capabilities' at rte_cryptodev.h:198:1:
> type size hasn't changed
> 1 data member change:
> type of 'anonymous data member union {rte_cryptodev_symmetric_capability sym; rte_cryptodev_asymmetric_capability asym;}' changed:
> type size hasn't changed
> 1 data member change:
> type of 'rte_cryptodev_asymmetric_capability asym' changed:
> type size hasn't changed
> 1 data member change:
> type of 'rte_cryptodev_asymmetric_xform_capability xform_capa' changed:
> type size hasn't changed
> 1 data member change:
> type of 'rte_crypto_asym_xform_type xform_type' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
> 2 enumerator changes:
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from value '8' to '9' at rte_crypto_asym.h:80:1
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END' from value '9' to '10' at rte_crypto_asym.h:80:1
Ok - will take a look see.
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 14:21 0% ` Ray Kinsella
@ 2022-06-02 14:25 0% ` Akhil Goyal
2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-06-02 14:25 UTC (permalink / raw)
To: Ray Kinsella; +Cc: Arek Kusztal, dev, roy.fan.zhang
>
> Akhil Goyal <gakhil@marvell.com> writes:
>
> >> - Added elliptic curve Diffie-Hellman parameters.
> >> Point multiplication allows the user to process every phase of
> >> ECDH, but for phase 1, user should not really care about the generator.
> >> The user does not even need to know what the generator looks like,
> >> therefore setting ec xform would make this work.
> >>
> >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >> ---
> >> devtools/libabigail.abignore | 3 +++
> >> doc/guides/cryptodevs/features/default.ini | 1 +
> >> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> >> doc/guides/rel_notes/release_22_07.rst | 2 ++
> >> lib/cryptodev/rte_crypto_asym.h | 38
> >> ++++++++++++++++++++++++++++++
> >> 5 files changed, 48 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> >> index 79ff15dc4e..6d174b291f 100644
> >> --- a/devtools/libabigail.abignore
> >> +++ b/devtools/libabigail.abignore
> >> @@ -27,6 +27,9 @@
> >> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> >> experimental
> >> [suppress_type]
> >> name = rte_crypto_asym_op
> >> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is
> >> experimental
> >> +[suppress_type]
> >> + name = rte_crypto_asym_xform_type
> >>
> > This exception does not seem to work.
> > Thomas and I are getting ABI issues even with this suppress rule.
> >
> > [C] 'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at
> rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> > parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
> > in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
> > type size hasn't changed
> > 1 data member change:
> > type of 'const rte_cryptodev_capabilities* capabilities' changed:
> > in pointed to type 'const rte_cryptodev_capabilities':
> > in unqualified underlying type 'struct rte_cryptodev_capabilities' at
> rte_cryptodev.h:198:1:
> > type size hasn't changed
> > 1 data member change:
> > type of 'anonymous data member union
> {rte_cryptodev_symmetric_capability sym;
> rte_cryptodev_asymmetric_capability asym;}' changed:
> > type size hasn't changed
> > 1 data member change:
> > type of 'rte_cryptodev_asymmetric_capability asym' changed:
> > type size hasn't changed
> > 1 data member change:
> > type of 'rte_cryptodev_asymmetric_xform_capability
> xform_capa' changed:
> > type size hasn't changed
> > 1 data member change:
> > type of 'rte_crypto_asym_xform_type xform_type' changed:
> > type size hasn't changed
> > 1 enumerator insertion:
> >
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
> > 2 enumerator changes:
> >
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from value
> '8' to '9' at rte_crypto_asym.h:80:1
> >
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END'
> from value '9' to '10' at rte_crypto_asym.h:80:1
>
> Ok - will take a look see.
Thomas has fixed the suppress rule while pulling on main.
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 14:25 0% ` Akhil Goyal
@ 2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
2022-06-03 13:26 4% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Kusztal, ArkadiuszX @ 2022-06-02 14:46 UTC (permalink / raw)
To: Akhil Goyal, Ray Kinsella; +Cc: dev, Zhang, Roy Fan
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, June 2, 2022 4:25 PM
> To: Ray Kinsella <mdr@ashroe.eu>
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Zhang,
> Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
>
> >
> > Akhil Goyal <gakhil@marvell.com> writes:
> >
> > >> - Added elliptic curve Diffie-Hellman parameters.
> > >> Point multiplication allows the user to process every phase of
> > >> ECDH, but for phase 1, user should not really care about the generator.
> > >> The user does not even need to know what the generator looks like,
> > >> therefore setting ec xform would make this work.
> > >>
> > >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > >> ---
> > >> devtools/libabigail.abignore | 3 +++
> > >> doc/guides/cryptodevs/features/default.ini | 1 +
> > >> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> > >> doc/guides/rel_notes/release_22_07.rst | 2 ++
> > >> lib/cryptodev/rte_crypto_asym.h | 38
> > >> ++++++++++++++++++++++++++++++
> > >> 5 files changed, 48 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/devtools/libabigail.abignore
> > >> b/devtools/libabigail.abignore index 79ff15dc4e..6d174b291f 100644
> > >> --- a/devtools/libabigail.abignore
> > >> +++ b/devtools/libabigail.abignore
> > >> @@ -27,6 +27,9 @@
> > >> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> > >> experimental [suppress_type]
> > >> name = rte_crypto_asym_op
> > >> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto
> > >> +API is
> > >> experimental
> > >> +[suppress_type]
> > >> + name = rte_crypto_asym_xform_type
> > >>
> > > This exception does not seem to work.
> > > Thomas and I are getting ABI issues even with this suppress rule.
> > >
> > > [C] 'function void rte_cryptodev_info_get(uint8_t,
> > > rte_cryptodev_info*)' at
> > rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> > > parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
> > > in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'const rte_cryptodev_capabilities* capabilities' changed:
> > > in pointed to type 'const rte_cryptodev_capabilities':
> > > in unqualified underlying type 'struct
> > > rte_cryptodev_capabilities' at
> > rte_cryptodev.h:198:1:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'anonymous data member union
> > {rte_cryptodev_symmetric_capability sym;
> > rte_cryptodev_asymmetric_capability asym;}' changed:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'rte_cryptodev_asymmetric_capability asym' changed:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of
> > > 'rte_cryptodev_asymmetric_xform_capability
> > xform_capa' changed:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'rte_crypto_asym_xform_type xform_type' changed:
> > > type size hasn't changed
> > > 1 enumerator insertion:
> > >
> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
> > > 2 enumerator changes:
> > >
> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from
> value
> > '8' to '9' at rte_crypto_asym.h:80:1
> > >
> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END'
> > from value '9' to '10' at rte_crypto_asym.h:80:1
> >
> > Ok - will take a look see.
> Thomas has fixed the suppress rule while pulling on main.
For some unknown reason both:
[suppress_type]
type_kind = enum
changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
and
[suppress_type]
name = rte_crypto_asym_xform_type
works fine for me with check-abi tool:
{DPDK_NEW}/devtools/check-abi.sh ${DPDK_REF}/build/ref ${DPDK_NEW}/build/new
Otherwise I get:
1 function with some indirect sub-type change:
[C]'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
abidiff: 1.2.0 version
@Akhil - additionally RTE_CRYPTO_ASYM_XFORM_ECDH was supposed to be placed at the end of the enum. My mistake, I have placed it incorrectly.
Would a fix that swaps these enums be accepted? This could potentially remove changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-06-01 11:15 3% [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
@ 2022-06-02 20:52 0% ` Thomas Monjalon
2022-06-03 7:29 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-02 20:52 UTC (permalink / raw)
To: Stanislaw Kardach, Stephen Hemminger
Cc: Vladimir Medvedkin, dev, dev, Frank Zhao, Sam Grove, upstream
01/06/2022 13:15, Stanislaw Kardach:
> All other rte_lpm_lookup* functions take lpm argument as a const. As the
> basic rte_lpm_lookup() performs the same function, it should also do
> that.
>
> As this function is inline, no API/ABI change happens.
It is an API change and should be noted in the release notes.
> static inline int
> -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
^ permalink raw reply [relevance 0%]
* Re: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-02 1:52 6% ` [PATCH 07/14] net/nfp: support NFDK firmware Jin Liu
@ 2022-06-02 22:53 0% ` Ferruh Yigit
2022-06-14 8:49 3% ` Kevin Liu
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-06-02 22:53 UTC (permalink / raw)
To: Jin Liu, dev; +Cc: niklas.soderlund, Diana Wang, Peng Zhang, Chaoyong He
On 6/2/2022 2:52 AM, Jin Liu wrote:
> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
> according to the firmware version, mount different driver functions.
>
Creating a new set of dev_ops for new FW is a way and it works, but it
looks like it creates some duplication of the code, and maintaining
multiple dev_ops can be difficult (driver already has different ones for
PF & VF).
Another option can be keeping ethdev interface same, but manage
different FWs closer to FW, where directly interacted with FW.
Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing
different FW within this function, instead of having two dev_ops,
'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
If difference is small, this can be better to reduce duplication.
What is the difference between two FWs, as far as I can see Tx
descriptor is different and queue setup is affected, is it only diff?
> Signed-off-by: Jin Liu <jin.liu@corigine.com>
> Signed-off-by: Diana Wang <na.wang@corigine.com>
> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
<...>
> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>
> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
> + if (hw->ctrl_bar == NULL) {
> + PMD_DRV_LOG(ERR,
> + "hw->ctrl_bar is NULL. BAR0 not configured");
> + return -ENODEV;
> + }
> +
> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
> +
> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
> +
> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> + case NFP_NET_CFG_VERSION_DP_NFD3:
> + break;
> + case NFP_NET_CFG_VERSION_DP_NFDK:
> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> + return -EINVAL;
> + }
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> + return -EINVAL;
> + }
> +
This part seems extracted to its own function for PF
('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same
logic between them.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-06-02 20:52 0% ` Thomas Monjalon
@ 2022-06-03 7:29 0% ` Bruce Richardson
2022-06-03 7:43 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-06-03 7:29 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Stanislaw Kardach, Stephen Hemminger, Vladimir Medvedkin, dev,
Frank Zhao, Sam Grove, upstream
On Thu, Jun 02, 2022 at 10:52:25PM +0200, Thomas Monjalon wrote:
> 01/06/2022 13:15, Stanislaw Kardach:
> > All other rte_lpm_lookup* functions take lpm argument as a const. As the
> > basic rte_lpm_lookup() performs the same function, it should also do
> > that.
> >
> > As this function is inline, no API/ABI change happens.
>
> It is an API change and should be noted in the release notes.
>
> > static inline int
> > -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> > +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
>
While I've no particular objection to it appearing in the RN doc, I wonder
whether it really counts as an API change. I can't see any practical
difference that this change would make to the end user - no source code
needs updating for example.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-06-03 7:29 0% ` Bruce Richardson
@ 2022-06-03 7:43 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-03 7:43 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, Stephen Hemminger, Vladimir Medvedkin, dev,
Frank Zhao, Sam Grove, upstream
03/06/2022 09:29, Bruce Richardson:
> On Thu, Jun 02, 2022 at 10:52:25PM +0200, Thomas Monjalon wrote:
> > 01/06/2022 13:15, Stanislaw Kardach:
> > > All other rte_lpm_lookup* functions take lpm argument as a const. As the
> > > basic rte_lpm_lookup() performs the same function, it should also do
> > > that.
> > >
> > > As this function is inline, no API/ABI change happens.
> >
> > It is an API change and should be noted in the release notes.
> >
> > > static inline int
> > > -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> > > +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> >
> While I've no particular objection to it appearing in the RN doc, I wonder
> whether it really counts as an API change. I can't see any practical
> difference that this change would make to the end user - no source code
> needs updating for example.
Yes you're right, we can skip the release notes here.
^ permalink raw reply [relevance 0%]
* Re: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
@ 2022-06-03 13:26 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2022-06-03 13:26 UTC (permalink / raw)
To: Kusztal, ArkadiuszX; +Cc: Akhil Goyal, dev, Zhang, Roy Fan
"Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com> writes:
>> -----Original Message-----
>> From: Akhil Goyal <gakhil@marvell.com>
>> Sent: Thursday, June 2, 2022 4:25 PM
>> To: Ray Kinsella <mdr@ashroe.eu>
>> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Zhang,
>> Roy Fan <roy.fan.zhang@intel.com>
>> Subject: RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
>>
>> >
>> > Akhil Goyal <gakhil@marvell.com> writes:
>> >
>> > >> - Added elliptic curve Diffie-Hellman parameters.
>> > >> Point multiplication allows the user to process every phase of
>> > >> ECDH, but for phase 1, user should not really care about the generator.
>> > >> The user does not even need to know what the generator looks like,
>> > >> therefore setting ec xform would make this work.
>> > >>
>> > >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> > >> ---
>> > >> devtools/libabigail.abignore | 3 +++
>> > >> doc/guides/cryptodevs/features/default.ini | 1 +
>> > >> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
>> > >> doc/guides/rel_notes/release_22_07.rst | 2 ++
>> > >> lib/cryptodev/rte_crypto_asym.h | 38
>> > >> ++++++++++++++++++++++++++++++
>> > >> 5 files changed, 48 insertions(+), 3 deletions(-)
>> > >>
>> > >> diff --git a/devtools/libabigail.abignore
>> > >> b/devtools/libabigail.abignore index 79ff15dc4e..6d174b291f 100644
>> > >> --- a/devtools/libabigail.abignore
>> > >> +++ b/devtools/libabigail.abignore
>> > >> @@ -27,6 +27,9 @@
>> > >> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
>> > >> experimental [suppress_type]
>> > >> name = rte_crypto_asym_op
>> > >> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto
>> > >> +API is
>> > >> experimental
>> > >> +[suppress_type]
>> > >> + name = rte_crypto_asym_xform_type
>> > >>
>> > > This exception does not seem to work.
>> > > Thomas and I are getting ABI issues even with this suppress rule.
>> > >
>> > > [C] 'function void rte_cryptodev_info_get(uint8_t,
>> > > rte_cryptodev_info*)' at
>> > rte_cryptodev.c:1582:1 has some indirect sub-type changes:
>> > > parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
>> > > in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'const rte_cryptodev_capabilities* capabilities' changed:
>> > > in pointed to type 'const rte_cryptodev_capabilities':
>> > > in unqualified underlying type 'struct
>> > > rte_cryptodev_capabilities' at
>> > rte_cryptodev.h:198:1:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'anonymous data member union
>> > {rte_cryptodev_symmetric_capability sym;
>> > rte_cryptodev_asymmetric_capability asym;}' changed:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'rte_cryptodev_asymmetric_capability asym' changed:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of
>> > > 'rte_cryptodev_asymmetric_xform_capability
>> > xform_capa' changed:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'rte_crypto_asym_xform_type xform_type' changed:
>> > > type size hasn't changed
>> > > 1 enumerator insertion:
>> > >
>> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
>> > > 2 enumerator changes:
>> > >
>> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from
>> value
>> > '8' to '9' at rte_crypto_asym.h:80:1
>> > >
>> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END'
>> > from value '9' to '10' at rte_crypto_asym.h:80:1
>> >
>> > Ok - will take a look see.
>> Thomas has fixed the suppress rule while pulling on main.
>
> For some unknown reason both:
> [suppress_type]
> type_kind = enum
> changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> and
> [suppress_type]
> name = rte_crypto_asym_xform_type
>
> works fine for me with check-abi tool:
> {DPDK_NEW}/devtools/check-abi.sh ${DPDK_REF}/build/ref ${DPDK_NEW}/build/new
>
> Otherwise I get:
>
> 1 function with some indirect sub-type change:
>
> [C]'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
>
> abidiff: 1.2.0 version
So like you with 1.2.0 I didn't see the error, with 2.0.0 I see the
following, so I recommend that you update to 2.0.0 or later. I had
inadvertently reverted versions after a system rebuild.
ninja: Entering directory `./build-gcc-static'
ninja: no work to do.
ninja: Entering directory `./build-gcc-shared'
ninja: no work to do.
Error: ABI issue reported for 'abidiff --suppr /root/src/dpdk/devtools/../devtools/libabigail.abignore --no-added-syms --headers-dir1 /root/src/dpdk/build_ref/v21.11/build-gcc-shared/usr/local/include --headers-dir2 /root/src/dpdk/build-gcc-shared/install/usr/local/include /root/src/dpdk/build_ref/v21.11/build-gcc-shared/dump/librte_cryptodev.dump /root/src/dpdk/build-gcc-shared/install/dump/librte_cryptodev.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Error: ABI issue reported for 'abidiff --suppr /root/src/dpdk/devtools/../devtools/libabigail.abignore --no-added-syms --headers-dir1 /root/src/dpdk/build_ref/v21.11/build-gcc-shared/usr/local/include --headers-dir2 /root/src/dpdk/build-gcc-shared/install/usr/local/include /root/src/dpdk/build_ref/v21.11/build-gcc-shared/dump/librte_security.dump /root/src/dpdk/build-gcc-shared/install/dump/librte_security.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Me thinks, we need to add a check for libabigail version to the build
scripts.
That all said, Thomas's supression rule has better percision than the
original proposed.
> @Akhil - additionally RTE_CRYPTO_ASYM_XFORM_ECDH was supposed to be placed at the end of the enum. My mistake, I have placed it incorrectly.
> Would a fix that swaps these enums be accepted? This could potentially remove changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM.
--
Regards, Ray K
^ permalink raw reply [relevance 4%]
* Optimizations are not features
@ 2022-06-04 9:09 3% Morten Brørup
2022-06-04 9:33 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-06-04 9:09 UTC (permalink / raw)
To: dev; +Cc: techboard
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
I would like the DPDK community to change its view on compile time options. Here is why:
Application specific performance micro-optimizations like "fast mbuf free" and "mbuf direct re-arm" are being added to DPDK and presented as features.
They are not features, but optimizations, and I don't understand the need for them to be available at run-time!
Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as "no fragmented packets", "no attached mbufs" and "single mbuf pool". And even more exotic optimizations, such as the "indexed mempool cache", which was rejected due to ABI violations - they could be marked as "risky and untested" or similar, but still be part of the DPDK main repository.
Med venlig hilsen / Kind regards,
-Morten Brørup
[-- Attachment #2: Type: text/html, Size: 3730 bytes --]
^ permalink raw reply [relevance 3%]
* Re: Optimizations are not features
2022-06-04 9:09 3% Optimizations are not features Morten Brørup
@ 2022-06-04 9:33 0% ` Jerin Jacob
2022-06-04 10:00 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-06-04 9:33 UTC (permalink / raw)
To: Morten Brørup; +Cc: dpdk-dev, techboard
On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> I would like the DPDK community to change its view on compile time options. Here is why:
>
>
>
> Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features.
>
>
>
> They are not features, but optimizations, and I don’t understand the need for them to be available at run-time!
>
>
>
> Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
Agree. I think, keeping the best of both worlds would be
-Enable the feature/optimization as runtime
-Have a compile-time option to disable the feature/optimization as an override.
>
>
>
> Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
>
>
>
> Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository.
>
>
>
>
>
> Med venlig hilsen / Kind regards,
>
> -Morten Brørup
>
>
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 9:33 0% ` Jerin Jacob
@ 2022-06-04 10:00 0% ` Andrew Rybchenko
2022-06-04 11:10 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2022-06-04 10:00 UTC (permalink / raw)
To: Jerin Jacob, Morten Brørup; +Cc: dpdk-dev, techboard
On 6/4/22 12:33, Jerin Jacob wrote:
> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>>
>> I would like the DPDK community to change its view on compile time options. Here is why:
>>
>>
>>
>> Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features.
>>
>>
>>
>> They are not features, but optimizations, and I don’t understand the need for them to be available at run-time!
>>
>>
>>
>> Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
>
> Agree. I think, keeping the best of both worlds would be
>
> -Enable the feature/optimization as runtime
> -Have a compile-time option to disable the feature/optimization as an override.
It is hard to find the right balance, but in general compile
time options are a nightmare for maintenance. Number of
required builds will grow as an exponent. Of course, we can
limit number of checked combinations, but it will result in
flow of patches to fix build in other cases.
Also compile time options tend to make code less readable
which makes all aspects of the development harder.
Yes, compile time is nice for micro optimizations, but
I have great concerns that it is a right way to go.
>> Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
>>
>>
>>
>> Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository.
>>
>>
>>
>>
>>
>> Med venlig hilsen / Kind regards,
>>
>> -Morten Brørup
>>
>>
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 10:00 0% ` Andrew Rybchenko
@ 2022-06-04 11:10 0% ` Jerin Jacob
2022-06-04 12:19 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-06-04 11:10 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: Morten Brørup, dpdk-dev, techboard
On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
<andrew.rybchenko@oktetlabs.ru> wrote:
>
> On 6/4/22 12:33, Jerin Jacob wrote:
> > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> >>
> >> I would like the DPDK community to change its view on compile time options. Here is why:
> >>
> >>
> >>
> >> Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features.
> >>
> >>
> >>
> >> They are not features, but optimizations, and I don’t understand the need for them to be available at run-time!
> >>
> >>
> >>
> >> Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
> >
> > Agree. I think, keeping the best of both worlds would be
> >
> > -Enable the feature/optimization as runtime
> > -Have a compile-time option to disable the feature/optimization as an override.
>
> It is hard to find the right balance, but in general compile
> time options are a nightmare for maintenance. Number of
> required builds will grow as an exponent. Of course, we can
> limit number of checked combinations, but it will result in
> flow of patches to fix build in other cases.
The build breakage can be fixed if we use (2) vs (1)
1)
#ifdef ...
My feature
#endif
2)
static __rte_always_inline int
rte_has_xyz_feature(void)
{
#ifdef RTE_LIBRTE_XYZ_FEATURE
return RTE_LIBRTE_XYZ_FEATURE;
#else
return 0;
#endif
}
if(rte_has_xyz_feature())) {
My feature code
}
> Also compile time options tend to make code less readable
> which makes all aspects of the development harder.
>
> Yes, compile time is nice for micro optimizations, but
> I have great concerns that it is a right way to go.
>
> >> Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
> >>
> >>
> >>
> >> Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository.
> >>
> >>
> >>
> >>
> >>
> >> Med venlig hilsen / Kind regards,
> >>
> >> -Morten Brørup
> >>
> >>
>
^ permalink raw reply [relevance 0%]
* RE: Optimizations are not features
2022-06-04 11:10 0% ` Jerin Jacob
@ 2022-06-04 12:19 3% ` Morten Brørup
2022-06-04 12:51 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-06-04 12:19 UTC (permalink / raw)
To: Jerin Jacob, Andrew Rybchenko; +Cc: dpdk-dev, techboard
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Saturday, 4 June 2022 13.10
>
> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru> wrote:
> >
> > On 6/4/22 12:33, Jerin Jacob wrote:
> > > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> <mb@smartsharesystems.com> wrote:
> > >>
> > >> I would like the DPDK community to change its view on compile time
> options. Here is why:
> > >>
> > >>
> > >>
> > >> Application specific performance micro-optimizations like “fast
> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> presented as features.
> > >>
> > >>
> > >>
> > >> They are not features, but optimizations, and I don’t understand
> the need for them to be available at run-time!
> > >>
> > >>
> > >>
> > >> Instead of adding a bunch of exotic exceptions to the fast path of
> the PMDs, they should be compile time options. This will improve
> performance by avoiding branches in the fast path, both for the
> applications using them, and for generic applications (where the exotic
> code is omitted).
> > >
> > > Agree. I think, keeping the best of both worlds would be
> > >
> > > -Enable the feature/optimization as runtime
> > > -Have a compile-time option to disable the feature/optimization as
> an override.
> >
> > It is hard to find the right balance, but in general compile
> > time options are a nightmare for maintenance. Number of
> > required builds will grow as an exponent.
Test combinations are exponential for N features, regardless if N are runtime or compile time options.
> > Of course, we can
> > limit number of checked combinations, but it will result in
> > flow of patches to fix build in other cases.
>
> The build breakage can be fixed if we use (2) vs (1)
>
> 1)
> #ifdef ...
> My feature
> #endif
>
> 2)
> static __rte_always_inline int
> rte_has_xyz_feature(void)
> {
> #ifdef RTE_LIBRTE_XYZ_FEATURE
> return RTE_LIBRTE_XYZ_FEATURE;
> #else
> return 0;
> #endif
> }
>
> if(rte_has_xyz_feature())) {
> My feature code
>
> }
>
I'm not sure all the features can be covered by that, e.g. added fields in structures.
Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API.
>
>
> > Also compile time options tend to make code less readable
> > which makes all aspects of the development harder.
> >
> > Yes, compile time is nice for micro optimizations, but
> > I have great concerns that it is a right way to go.
> >
> > >> Please note that I am only talking about the performance
> optimizations that are limited to application specific use cases. I
> think it makes sense to require that performance optimizing an
> application also requires recompiling the performance critical
> libraries used by it.
> > >>
> > >>
> > >>
> > >> Allowing compile time options for application specific performance
> optimizations in DPDK would also open a path for other optimizations,
> which can only be achieved at compile time, such as “no fragmented
> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> exotic optimizations, such as the “indexed mempool cache”, which was
> rejected due to ABI violations – they could be marked as “risky and
> untested” or similar, but still be part of the DPDK main repository.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Med venlig hilsen / Kind regards,
> > >>
> > >> -Morten Brørup
> > >>
> > >>
> >
^ permalink raw reply [relevance 3%]
* Re: Optimizations are not features
2022-06-04 12:19 3% ` Morten Brørup
@ 2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Andrew Rybchenko @ 2022-06-04 12:51 UTC (permalink / raw)
To: Morten Brørup, Jerin Jacob; +Cc: dpdk-dev, techboard
On 6/4/22 15:19, Morten Brørup wrote:
>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
>> Sent: Saturday, 4 June 2022 13.10
>>
>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>
>>> On 6/4/22 12:33, Jerin Jacob wrote:
>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
>> <mb@smartsharesystems.com> wrote:
>>>>>
>>>>> I would like the DPDK community to change its view on compile time
>> options. Here is why:
>>>>>
>>>>>
>>>>>
>>>>> Application specific performance micro-optimizations like “fast
>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
>> presented as features.
>>>>>
>>>>>
>>>>>
>>>>> They are not features, but optimizations, and I don’t understand
>> the need for them to be available at run-time!
>>>>>
>>>>>
>>>>>
>>>>> Instead of adding a bunch of exotic exceptions to the fast path of
>> the PMDs, they should be compile time options. This will improve
>> performance by avoiding branches in the fast path, both for the
>> applications using them, and for generic applications (where the exotic
>> code is omitted).
>>>>
>>>> Agree. I think, keeping the best of both worlds would be
>>>>
>>>> -Enable the feature/optimization as runtime
>>>> -Have a compile-time option to disable the feature/optimization as
>> an override.
>>>
>>> It is hard to find the right balance, but in general compile
>>> time options are a nightmare for maintenance. Number of
>>> required builds will grow as an exponent.
>
> Test combinations are exponential for N features, regardless if N are runtime or compile time options.
But since I'm talking about build checks I don't care about exponential
grows in run time. Yes, testing should care, but it is a separate story.
>
>>> Of course, we can
>>> limit number of checked combinations, but it will result in
>>> flow of patches to fix build in other cases.
>>
>> The build breakage can be fixed if we use (2) vs (1)
>>
>> 1)
>> #ifdef ...
>> My feature
>> #endif
>>
>> 2)
>> static __rte_always_inline int
>> rte_has_xyz_feature(void)
>> {
>> #ifdef RTE_LIBRTE_XYZ_FEATURE
>> return RTE_LIBRTE_XYZ_FEATURE;
>> #else
>> return 0;
>> #endif
>> }
>>
>> if(rte_has_xyz_feature())) {
>> My feature code
>>
>> }
>>
Jerin, thanks, very good example.
> I'm not sure all the features can be covered by that, e.g. added fields in structures.
+1
>
> Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API.
>
>>
>>
>>> Also compile time options tend to make code less readable
>>> which makes all aspects of the development harder.
>>>
>>> Yes, compile time is nice for micro optimizations, but
>>> I have great concerns that it is a right way to go.
>>>
>>>>> Please note that I am only talking about the performance
>> optimizations that are limited to application specific use cases. I
>> think it makes sense to require that performance optimizing an
>> application also requires recompiling the performance critical
>> libraries used by it.
>>>>>
>>>>>
>>>>>
>>>>> Allowing compile time options for application specific performance
>> optimizations in DPDK would also open a path for other optimizations,
>> which can only be achieved at compile time, such as “no fragmented
>> packets”, “no attached mbufs” and “single mbuf pool”. And even more
>> exotic optimizations, such as the “indexed mempool cache”, which was
>> rejected due to ABI violations – they could be marked as “risky and
>> untested” or similar, but still be part of the DPDK main repository.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Med venlig hilsen / Kind regards,
>>>>>
>>>>> -Morten Brørup
>>>>>
>>>>>
>>>
>
^ permalink raw reply [relevance 0%]
* RE: Optimizations are not features
2022-06-04 12:51 0% ` Andrew Rybchenko
@ 2022-06-05 8:15 0% ` Morten Brørup
2022-06-05 16:05 0% ` Stephen Hemminger
2022-06-06 9:35 0% ` Konstantin Ananyev
2 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-05 8:15 UTC (permalink / raw)
To: Andrew Rybchenko, Jerin Jacob; +Cc: dpdk-dev, techboard
> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Saturday, 4 June 2022 14.52
>
> On 6/4/22 15:19, Morten Brørup wrote:
> >> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> >> Sent: Saturday, 4 June 2022 13.10
> >>
> >> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> >> <andrew.rybchenko@oktetlabs.ru> wrote:
> >>>
> >>> On 6/4/22 12:33, Jerin Jacob wrote:
> >>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> >> <mb@smartsharesystems.com> wrote:
> >>>>>
> >>>>> I would like the DPDK community to change its view on compile
> time
> >> options. Here is why:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Application specific performance micro-optimizations like “fast
> >> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> >> presented as features.
> >>>>>
> >>>>>
> >>>>>
> >>>>> They are not features, but optimizations, and I don’t understand
> >> the need for them to be available at run-time!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Instead of adding a bunch of exotic exceptions to the fast path
> of
> >> the PMDs, they should be compile time options. This will improve
> >> performance by avoiding branches in the fast path, both for the
> >> applications using them, and for generic applications (where the
> exotic
> >> code is omitted).
> >>>>
> >>>> Agree. I think, keeping the best of both worlds would be
> >>>>
> >>>> -Enable the feature/optimization as runtime
> >>>> -Have a compile-time option to disable the feature/optimization as
> >> an override.
> >>>
> >>> It is hard to find the right balance, but in general compile
> >>> time options are a nightmare for maintenance. Number of
> >>> required builds will grow as an exponent.
> >
> > Test combinations are exponential for N features, regardless if N are
> runtime or compile time options.
>
> But since I'm talking about build checks I don't care about exponential
> grows in run time. Yes, testing should care, but it is a separate
> story.
Build checks is just one of many test methods. A very low cost and efficient test method, though.
I acknowledge that build checks will be more complicated with additional compile time options. And build checks are important for code quality, so we should find a solution for that challenge.
The primary scope of my suggestion is application specific performance optimization features only, so let's call them "exotic features". Also, they should be "opt in". Keep in mind: They are not really features, since they don't add anything new, they are only performance optimizations beneficial for specific application use cases.
With this in mind, we could continue ordinary testing with these options disabled. I.e. no additional testing.
Regardless how exotic the features may be, we certainly want some testing of them, so we could do some things to avoid exponential testing:
1. With each ordinary build check (with all options disabled), another build check could be run with a random set of options enabled. Or additional tests could be run on a weekly basis with random combinations of options.
2. Any patch related to one or more of these exotic features could include some magic keywords to indicate which combinations of options must be enabled during build checking and testing.
>
> >
> >>> Of course, we can
> >>> limit number of checked combinations, but it will result in
> >>> flow of patches to fix build in other cases.
> >>
> >> The build breakage can be fixed if we use (2) vs (1)
> >>
> >> 1)
> >> #ifdef ...
> >> My feature
> >> #endif
> >>
> >> 2)
> >> static __rte_always_inline int
> >> rte_has_xyz_feature(void)
> >> {
> >> #ifdef RTE_LIBRTE_XYZ_FEATURE
> >> return RTE_LIBRTE_XYZ_FEATURE;
> >> #else
> >> return 0;
> >> #endif
> >> }
> >>
> >> if(rte_has_xyz_feature())) {
> >> My feature code
> >>
> >> }
> >>
>
> Jerin, thanks, very good example.
>
> > I'm not sure all the features can be covered by that, e.g. added
> fields in structures.
>
> +1
>
> >
> > Also, I would consider such features "opt in" at compile time only.
> As such, they could be allowed to break the ABI/API.
> >
> >>
> >>
> >>> Also compile time options tend to make code less readable
> >>> which makes all aspects of the development harder.
> >>>
> >>> Yes, compile time is nice for micro optimizations, but
> >>> I have great concerns that it is a right way to go.
> >>>
> >>>>> Please note that I am only talking about the performance
> >> optimizations that are limited to application specific use cases. I
> >> think it makes sense to require that performance optimizing an
> >> application also requires recompiling the performance critical
> >> libraries used by it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Allowing compile time options for application specific
> performance
> >> optimizations in DPDK would also open a path for other
> optimizations,
> >> which can only be achieved at compile time, such as “no fragmented
> >> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> >> exotic optimizations, such as the “indexed mempool cache”, which was
> >> rejected due to ABI violations – they could be marked as “risky and
> >> untested” or similar, but still be part of the DPDK main repository.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Med venlig hilsen / Kind regards,
> >>>>>
> >>>>> -Morten Brørup
> >>>>>
> >>>>>
> >>>
> >
>
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
@ 2022-06-05 16:05 0% ` Stephen Hemminger
2022-06-06 9:35 0% ` Konstantin Ananyev
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-06-05 16:05 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: Morten Brørup, Jerin Jacob, dpdk-dev, techboard
On Sat, 4 Jun 2022 15:51:58 +0300
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> wrote:
> On 6/4/22 15:19, Morten Brørup wrote:
> >> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> >> Sent: Saturday, 4 June 2022 13.10
> >>
> >> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> >> <andrew.rybchenko@oktetlabs.ru> wrote:
> >>>
> >>> On 6/4/22 12:33, Jerin Jacob wrote:
> >>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> >> <mb@smartsharesystems.com> wrote:
> >>>>>
> >>>>> I would like the DPDK community to change its view on compile time
> >> options. Here is why:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Application specific performance micro-optimizations like “fast
> >> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> >> presented as features.
> >>>>>
> >>>>>
> >>>>>
> >>>>> They are not features, but optimizations, and I don’t understand
> >> the need for them to be available at run-time!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Instead of adding a bunch of exotic exceptions to the fast path of
> >> the PMDs, they should be compile time options. This will improve
> >> performance by avoiding branches in the fast path, both for the
> >> applications using them, and for generic applications (where the exotic
> >> code is omitted).
> >>>>
> >>>> Agree. I think, keeping the best of both worlds would be
> >>>>
> >>>> -Enable the feature/optimization as runtime
> >>>> -Have a compile-time option to disable the feature/optimization as
> >> an override.
> >>>
> >>> It is hard to find the right balance, but in general compile
> >>> time options are a nightmare for maintenance. Number of
> >>> required builds will grow as an exponent.
> >
> > Test combinations are exponential for N features, regardless if N are runtime or compile time options.
>
> But since I'm talking about build checks I don't care about exponential
> grows in run time. Yes, testing should care, but it is a separate story.
>
> >
> >>> Of course, we can
> >>> limit number of checked combinations, but it will result in
> >>> flow of patches to fix build in other cases.
> >>
> >> The build breakage can be fixed if we use (2) vs (1)
> >>
> >> 1)
> >> #ifdef ...
> >> My feature
> >> #endif
> >>
> >> 2)
> >> static __rte_always_inline int
> >> rte_has_xyz_feature(void)
> >> {
> >> #ifdef RTE_LIBRTE_XYZ_FEATURE
> >> return RTE_LIBRTE_XYZ_FEATURE;
> >> #else
> >> return 0;
> >> #endif
> >> }
> >>
> >> if(rte_has_xyz_feature())) {
> >> My feature code
> >>
> >> }
> >>
>
> Jerin, thanks, very good example.
>
> > I'm not sure all the features can be covered by that, e.g. added fields in structures.
>
> +1
>
> >
> > Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API.
> >
> >>
> >>
> >>> Also compile time options tend to make code less readable
> >>> which makes all aspects of the development harder.
> >>>
> >>> Yes, compile time is nice for micro optimizations, but
> >>> I have great concerns that it is a right way to go.
> >>>
> >>>>> Please note that I am only talking about the performance
> >> optimizations that are limited to application specific use cases. I
> >> think it makes sense to require that performance optimizing an
> >> application also requires recompiling the performance critical
> >> libraries used by it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Allowing compile time options for application specific performance
> >> optimizations in DPDK would also open a path for other optimizations,
> >> which can only be achieved at compile time, such as “no fragmented
> >> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> >> exotic optimizations, such as the “indexed mempool cache”, which was
> >> rejected due to ABI violations – they could be marked as “risky and
> >> untested” or similar, but still be part of the DPDK main repository.
There is a tradeoff that DPDK has had for several years.
1. For ease of use the DPDK should be available in Linux distributions in
pre-built binary format. In that case any changes in behavior need to be
done at runtime.
2. For performance and size, the DPDK should limit conditional branches
and not include dead code. This is what embedded appliance developers want.
3. For flexibilty, the DPDK should allow every option at the smallest granularity
(often per-packet or per-queue). This allows application to use feature if
available but not be limited to only hardware that supports it.
All of these do conflict. The big problem that I see is that when a feature
that changes the semantic of mbuf is used (no-attach, single pool etc).
It is opening other code to bugs. Therefore I am reluctant to use them;
in real life production 1% performance gain is totally offset by the cost
of .1% more bugs in code run by customers.
It would make my life easier if DPDK supported one set of semantics and
they worked everywhere. This is what every OS does (Linux, FreeBSD, Windows).
That would mean either all drivers support the feature in all cases or
the feature is never introduced. What would help this would be a set
of functions that help code do the right thing. Examples in Linux
are skb_linearize(), skb_maypull(), etc.
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
2022-06-05 16:05 0% ` Stephen Hemminger
@ 2022-06-06 9:35 0% ` Konstantin Ananyev
2 siblings, 0 replies; 200+ results
From: Konstantin Ananyev @ 2022-06-06 9:35 UTC (permalink / raw)
To: Andrew Rybchenko, Morten Brørup, Jerin Jacob; +Cc: dpdk-dev, techboard
04/06/2022 13:51, Andrew Rybchenko пишет:
> On 6/4/22 15:19, Morten Brørup wrote:
>>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
>>> Sent: Saturday, 4 June 2022 13.10
>>>
>>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
>>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>>
>>>> On 6/4/22 12:33, Jerin Jacob wrote:
>>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
>>> <mb@smartsharesystems.com> wrote:
>>>>>>
>>>>>> I would like the DPDK community to change its view on compile time
>>> options. Here is why:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Application specific performance micro-optimizations like “fast
>>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
>>> presented as features.
>>>>>>
>>>>>>
>>>>>>
>>>>>> They are not features, but optimizations, and I don’t understand
>>> the need for them to be available at run-time!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Instead of adding a bunch of exotic exceptions to the fast path of
>>> the PMDs, they should be compile time options. This will improve
>>> performance by avoiding branches in the fast path, both for the
>>> applications using them, and for generic applications (where the exotic
>>> code is omitted).
>>>>>
>>>>> Agree. I think, keeping the best of both worlds would be
>>>>>
>>>>> -Enable the feature/optimization as runtime
>>>>> -Have a compile-time option to disable the feature/optimization as
>>> an override.
>>>>
>>>> It is hard to find the right balance, but in general compile
>>>> time options are a nightmare for maintenance. Number of
>>>> required builds will grow as an exponent.
>>
>> Test combinations are exponential for N features, regardless if N are
>> runtime or compile time options.
>
> But since I'm talking about build checks I don't care about exponential
> grows in run time. Yes, testing should care, but it is a separate story.
>
>>
>>>> Of course, we can
>>>> limit number of checked combinations, but it will result in
>>>> flow of patches to fix build in other cases.
>>>
>>> The build breakage can be fixed if we use (2) vs (1)
>>>
>>> 1)
>>> #ifdef ...
>>> My feature
>>> #endif
>>>
>>> 2)
>>> static __rte_always_inline int
>>> rte_has_xyz_feature(void)
>>> {
>>> #ifdef RTE_LIBRTE_XYZ_FEATURE
>>> return RTE_LIBRTE_XYZ_FEATURE;
>>> #else
>>> return 0;
>>> #endif
>>> }
>>>
>>> if(rte_has_xyz_feature())) {
>>> My feature code
>>>
>>> }
>>>
>
> Jerin, thanks, very good example.
>
>> I'm not sure all the features can be covered by that, e.g. added
>> fields in structures.
>
> +1
>
>>
>> Also, I would consider such features "opt in" at compile time only. As
>> such, they could be allowed to break the ABI/API.
>>
>>>
>>>
>>>> Also compile time options tend to make code less readable
>>>> which makes all aspects of the development harder.
>>>>
>>>> Yes, compile time is nice for micro optimizations, but
>>>> I have great concerns that it is a right way to go.
>>>>
>>>>>> Please note that I am only talking about the performance
>>> optimizations that are limited to application specific use cases. I
>>> think it makes sense to require that performance optimizing an
>>> application also requires recompiling the performance critical
>>> libraries used by it.
>>>>>>abandon some of existing functionality to create a 'short-cut'
>>>>>>
>>>>>>
>>>>>> Allowing compile time options for application specific performance
>>> optimizations in DPDK would also open a path for other optimizations,
>>> which can only be achieved at compile time, such as “no fragmented
>>> packets”, “no attached mbufs” and “single mbuf pool”. And even more
>>> exotic optimizations, such as the “indexed mempool cache”, which was
>>> rejected due to ABI violations – they could be marked as “risky and
>>> untested” or similar, but still be part of the DPDK main repository.
>>>>>>
Thanks Morten for bringing it up, it is an interesting topic.
Though I look at it from different angle.
All optimizations you mentioned above introduce new limitations:
MBUF_FAST_FREE - no indirect mbufs and multiple mempools,
mempool object indexes - mempool size is limited to 4GB,
direct rearm - drop ability to stop/reconfigure TX queue,
while RX queue is still running,
etc.
Note that all these limitations are not forced by HW.
All of them are pure SW limitations that developers forced in
(or tried to) to get few extra performance.
That's concerning tendency.
As more and more such 'optimization via limitation' will come in:
- DPDK feature list will become more and more fragmented.
- Would cause more and more confusion for the users.
- Unmet expectations - difference in performance between 'default'
and 'optimized' version of DPDK will become bigger and bigger.
- As Andrew already mentioned, maintaining all these 'sub-flavours'
of DPDK will become more and more difficult.
So, probably instead of making such changes easier,
we need somehow to persuade developers to think more about
optimizations that would be generic and transparent to the user.
I do realize that it is not always possible due to various reasons
(HW limitations, external dependencies, etc.)
but that's another story.
Let's take for example MBUF_FAST_FREE.
In fact, I am not sure that we need it as tx offload flag at all.
PMD TX-path has all necessary information to decide at run-time
can it do fast_free() for not:
At tx_burst() PMD can check are all mbufs satisfy these conditions
(same mempool, refcnt==1) and update some fields and/or counters
inside TXQ to reflect it.
Then, at tx_free() we can use this info to decide
between fast_free() and normal_free().
As at tx_burst() we read mbuf fields anyway, impact for this
extra step I guess would be minimal.
Yes, most likely, it wouldn't be as fast as with current
TX offload flag, or conditional compilation approach.
But it might be still significantly faster then normal_free(),
plus such approach will be generic and transparent to the user.
Konstantin
^ permalink raw reply [relevance 0%]
* [PATCH v4] pcap: support MTU set
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
@ 2022-06-06 16:21 3% ` Ido Goshen
2022-06-06 17:10 0% ` Stephen Hemminger
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Ido Goshen @ 2022-06-06 16:21 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 38 ++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 0ed4f92820..717191d498 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -95,6 +95,9 @@ New Features
* Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
* Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
+* **Updated pcap driver.**
+
+ * Added support for MTU via ``rte_eth_dev_set_mtu``
Removed Items
-------------
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..db1958f20f 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -74,6 +74,7 @@ struct pcap_rx_queue {
/* Contains pre-generated packets to be looped through */
struct rte_ring *pkts;
+ struct pmd_internals *internals;
};
struct pcap_tx_queue {
@@ -82,6 +83,7 @@ struct pcap_tx_queue {
struct queue_stat tx_stat;
char name[PATH_MAX];
char type[ETH_PCAP_ARG_MAXLEN];
+ struct pmd_internals *internals;
};
struct pmd_internals {
@@ -93,6 +95,7 @@ struct pmd_internals {
int single_iface;
int phy_mac;
unsigned int infinite_rx;
+ uint16_t mtu;
};
struct pmd_process_private {
@@ -278,6 +281,7 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
const u_char *packet;
struct rte_mbuf *mbuf;
struct pcap_rx_queue *pcap_q = queue;
+ struct pmd_internals *internals = pcap_q->internals;
uint16_t num_rx = 0;
uint32_t rx_bytes = 0;
pcap_t *pcap;
@@ -303,6 +307,12 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
break;
}
+ if (unlikely(header.caplen > internals->mtu)) {
+ pcap_q->rx_stat.err_pkts++;
+ rte_pktmbuf_free(mbuf);
+ break;
+ }
+
if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
/* pcap packet will fit in the mbuf, can copy it */
rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
@@ -378,6 +388,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *dumper_q = queue;
+ struct pmd_internals *internals = dumper_q->internals;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
struct pcap_pkthdr header;
@@ -396,6 +407,12 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = caplen = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > internals->mtu)) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
caplen = sizeof(temp_data);
@@ -464,6 +481,7 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *tx_queue = queue;
+ struct pmd_internals *internals = tx_queue->internals;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
pcap_t *pcap;
@@ -479,6 +497,12 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > internals->mtu)) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
PMD_LOG(ERR,
@@ -807,6 +831,16 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+
+ PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
+ internals->mtu = mtu;
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -878,6 +912,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
pcap_q->mb_pool = mb_pool;
pcap_q->port_id = dev->data->port_id;
pcap_q->queue_id = rx_queue_id;
+ pcap_q->internals = internals;
dev->data->rx_queues[rx_queue_id] = pcap_q;
if (internals->infinite_rx) {
@@ -952,6 +987,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev,
pcap_q->port_id = dev->data->port_id;
pcap_q->queue_id = tx_queue_id;
+ pcap_q->internals = internals;
dev->data->tx_queues[tx_queue_id] = pcap_q;
return 0;
@@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
@@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
.addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
};
(*internals)->phy_mac = 0;
+ (*internals)->mtu = RTE_ETH_PCAP_SNAPLEN;
data = (*eth_dev)->data;
data->nb_rx_queues = (uint16_t)nb_rx_queues;
data->nb_tx_queues = (uint16_t)nb_tx_queues;
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4] pcap: support MTU set
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
@ 2022-06-06 17:10 0% ` Stephen Hemminger
2022-06-06 19:07 3% ` Ido Goshen
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-06 17:10 UTC (permalink / raw)
To: Ido Goshen; +Cc: ferruh.yigit, dev
On Mon, 6 Jun 2022 19:21:47 +0300
Ido Goshen <ido@cgstowernetworks.com> wrote:
> Support rte_eth_dev_set_mtu by pcap vdevs
> Enforce mtu on rx/tx
>
> Bugzilla ID: 961
This is not really a bug, it is an enhancement specific to your
test setup. It should not be backported to stable.
Since it is change in behavior it might be better to add a vdev argument
for this rather than overloading meaning of MTU. Also, this does not behave
the same as virtio or hardware drivers.
> Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
>
> ---
> v4:
> 1. Add release notes comment
> 2. Access pmd internals via queue struct
> 3. eth_mtu_set code convention fixes
>
> v3:
> Preserve pcap behavior to support max size packets by default
> alternative to v2 in order to limit the code change to pcap only and
> avoid abi change.
> Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
>
> v2:
> Preserve pcap behavior to support max size packets by default.
> ---
> doc/guides/rel_notes/release_22_07.rst | 3 ++
> drivers/net/pcap/pcap_ethdev.c | 38 ++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
> index 0ed4f92820..717191d498 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -95,6 +95,9 @@ New Features
> * Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
> * Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
>
> +* **Updated pcap driver.**
> +
> + * Added support for MTU via ``rte_eth_dev_set_mtu``
>
> Removed Items
> -------------
> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index ec29fd6bc5..db1958f20f 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -74,6 +74,7 @@ struct pcap_rx_queue {
>
> /* Contains pre-generated packets to be looped through */
> struct rte_ring *pkts;
> + struct pmd_internals *internals;
> };
>
> struct pcap_tx_queue {
> @@ -82,6 +83,7 @@ struct pcap_tx_queue {
> struct queue_stat tx_stat;
> char name[PATH_MAX];
> char type[ETH_PCAP_ARG_MAXLEN];
> + struct pmd_internals *internals;
> };
>
> struct pmd_internals {
> @@ -93,6 +95,7 @@ struct pmd_internals {
> int single_iface;
> int phy_mac;
> unsigned int infinite_rx;
> + uint16_t mtu;
> };
The mtu is already in dev->data->mtu, why copy it?
> struct pmd_process_private {
> @@ -278,6 +281,7 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> const u_char *packet;
> struct rte_mbuf *mbuf;
> struct pcap_rx_queue *pcap_q = queue;
> + struct pmd_internals *internals = pcap_q->internals;
> uint16_t num_rx = 0;
> uint32_t rx_bytes = 0;
> pcap_t *pcap;
> @@ -303,6 +307,12 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> break;
> }
>
> + if (unlikely(header.caplen > internals->mtu)) {
> + pcap_q->rx_stat.err_pkts++;
> + rte_pktmbuf_free(mbuf);
> + break;
> + }
This doesn't account for VLAN header.
> if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
> /* pcap packet will fit in the mbuf, can copy it */
> rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> @@ -378,6 +388,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *dumper_q = queue;
> + struct pmd_internals *internals = dumper_q->internals;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> struct pcap_pkthdr header;
> @@ -396,6 +407,12 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = caplen = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > internals->mtu)) {
> + rte_pktmbuf_free(mbuf);
> + continue;
> + }
There needs to be a per queue counter any and all drops.
<
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> caplen = sizeof(temp_data);
> @@ -464,6 +481,7 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *tx_queue = queue;
> + struct pmd_internals *internals = tx_queue->internals;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> pcap_t *pcap;
> @@ -479,6 +497,12 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > internals->mtu)) {
> + rte_pktmbuf_free(mbuf);
> + continue;
> + }
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> PMD_LOG(ERR,
> @@ -807,6 +831,16 @@ eth_stats_reset(struct rte_eth_dev *dev)
> return 0;
> }
>
> +static int
> +eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> +
> + PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
> + internals->mtu = mtu;
> + return 0;
> +}
If you drop internals->mtu (redundant) then this just becomes stub (ie return 0)
> +
> static inline void
> infinite_rx_ring_free(struct rte_ring *pkts)
> {
> @@ -878,6 +912,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
> pcap_q->mb_pool = mb_pool;
> pcap_q->port_id = dev->data->port_id;
> pcap_q->queue_id = rx_queue_id;
> + pcap_q->internals = internals;
> dev->data->rx_queues[rx_queue_id] = pcap_q;
>
> if (internals->infinite_rx) {
> @@ -952,6 +987,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev,
>
> pcap_q->port_id = dev->data->port_id;
> pcap_q->queue_id = tx_queue_id;
> + pcap_q->internals = internals;
> dev->data->tx_queues[tx_queue_id] = pcap_q;
>
> return 0;
> @@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
> .link_update = eth_link_update,
> .stats_get = eth_stats_get,
> .stats_reset = eth_stats_reset,
> + .mtu_set = eth_mtu_set,
> };
>
> static int
> @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> .addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
> };
> (*internals)->phy_mac = 0;
> + (*internals)->mtu = RTE_ETH_PCAP_SNAPLEN;
Use dev->data->mtu not internal value.
> data = (*eth_dev)->data;
> data->nb_rx_queues = (uint16_t)nb_rx_queues;
> data->nb_tx_queues = (uint16_t)nb_tx_queues;
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] pcap: support MTU set
2022-06-06 17:10 0% ` Stephen Hemminger
@ 2022-06-06 19:07 3% ` Ido Goshen
0 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-06 19:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: ferruh.yigit, dev
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Monday, 6 June 2022 20:10
> To: Ido Goshen <Ido@cgstowernetworks.com>
> Cc: ferruh.yigit@xilinx.com; dev@dpdk.org
> Subject: Re: [PATCH v4] pcap: support MTU set
>
> On Mon, 6 Jun 2022 19:21:47 +0300
> Ido Goshen <ido@cgstowernetworks.com> wrote:
>
> > Support rte_eth_dev_set_mtu by pcap vdevs Enforce mtu on rx/tx
> >
> > Bugzilla ID: 961
>
> This is not really a bug, it is an enhancement specific to your test setup. It should
> not be backported to stable.
>
> Since it is change in behavior it might be better to add a vdev argument for this
> rather than overloading meaning of MTU.
[idog] The default behavior stays the same and long packets will continue to pass as used to,
Only if 'rte_eth_dev_set_mtu' is explicitly used it will take effect.
I doubt it'll break anything cause no one could use it so far as it returns -ENOTSUP,
and I assume that would be the expected behavior for anyone who will set it.
Adding it as an argument to vdev (e.g. vdev='net_pcap0,iface=eth0,mtu=9400') seems to me
like a duplication to an existing API.
> Also, this does not behave the same[idog] as virtio or hardware drivers.
[idog] The idea of this patch is to make pcap behave more like HW NICs.
Couple of HW NICs (ixgbe, i40e) I've checked do respect MTU
Please see test outputs in https://bugs.dpdk.org/show_bug.cgi?id=961
Though probably it's done by the HW and not by the driver
Alternative might be to set the network interfaces MTU and not do it in pmd, so
It'll be like the "HW" is doing it, but this will work only for ifaces and not for pcap files.
>
> The mtu is already in dev->data->mtu, why copy it?
>
[idog] That's what I was using so far, but I got a request from ferruh.yigit@xilinx.com
not to use 'dev' but access 'internals' via the 'pcap_rx/tx_queue' struct.
> > + if (unlikely(header.caplen > internals->mtu)) {
> > + pcap_q->rx_stat.err_pkts++;
> > + rte_pktmbuf_free(mbuf);
> > + break;
> > + }
>
> This doesn't account for VLAN header.
[idog] Good point, I'm never sure what overhead should be considered?
Please advice what should I add
e.g. '(RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN + RTE_VLAN_HLEN * 2)'
however caller can always set it a bit higher if needed
> > +
> > + if (unlikely(len > internals->mtu)) {
> > + rte_pktmbuf_free(mbuf);
> > + continue;
> > + }
>
> There needs to be a per queue counter any and all drops.
[idog] It will be counted few lines below by
'dumper_q->tx_stat.err_pkts += nb_pkts - num_tx;'
as this case doesn't increment the 'num_tx'
> >
> > +static int
> > +eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> > + struct pmd_internals *internals = dev->data->dev_private;
> > +
> > + PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
> > + internals->mtu = mtu;
> > + return 0;
> > +}
>
> If you drop internals->mtu (redundant) then this just becomes stub (ie return 0)
>
[idog] Again I'm not sure if it's right to use 'dev->data->mtu' directly where later needed.
ferruh.yigit@xilinx.com ?
Anyway this function is needed even if it does nothing (or just logs) in order for the
eth_dev_ops.mtu_set to be supported
> >
> > static int
> > @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> > .addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
> > };
> > (*internals)->phy_mac = 0;
> > + (*internals)->mtu = RTE_ETH_PCAP_SNAPLEN;
>
>
> Use dev->data->mtu not internal value.
>
[idog] This runs early when the probe creates the device
Later 'dev->data->mtu' will be overwritten later in 'rte_eth_dev_configure'
To hard-coded 1500
if (dev_conf->rxmode.mtu == 0)
dev->data->dev_conf.rxmode.mtu = RTE_ETHER_MTU;
ret = eth_dev_validate_mtu(port_id, &dev_info,
dev->data->dev_conf.rxmode.mtu);
if (ret != 0)
goto rollback;
dev->data->mtu = dev->data->dev_conf.rxmode.mtu;
I tried to overcome it by [PATCH v2] http://mails.dpdk.org/archives/dev/2022-May/241974.html
But this code change spills out of the pcap pmd and changes rte_ethdev abi which I rather avoid
^ permalink raw reply [relevance 3%]
* Re: [PATCH v1] bbdev: add device status info
@ 2022-06-07 0:09 3% ` Stephen Hemminger
2022-06-07 12:42 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-07 0:09 UTC (permalink / raw)
To: Nicolas Chautru
Cc: dev, gakhil, trix, maxime.coquelin, hemant.agrawal, hernan.vargas
On Mon, 6 Jun 2022 15:50:08 -0700
Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> const struct rte_bbdev_op_cap *capabilities;
> /** Device cpu_flag requirements */
> const enum rte_cpu_flag_t *cpu_flag_reqs;
> + /** Device Status */
> + enum rte_bbdev_device_status device_status;
> };
>
This ends up being an ABI breakage, can't change a struct like that
until 22.11 release.
^ permalink raw reply [relevance 3%]
* [PATCH v5] pcap: support MTU set for linux interafces
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
@ 2022-06-07 6:27 3% ` Ido Goshen
2022-06-08 16:04 3% ` [PATCH v6] " Ido Goshen
2022-06-19 9:30 3% ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-20 8:39 3% ` [PATCH v8 " Ido Goshen
4 siblings, 1 reply; 200+ results
From: Ido Goshen @ 2022-06-07 6:27 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 43 ++++++++++++++++++++++++++
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 +++++
drivers/net/pcap/pcap_osdep_linux.c | 21 +++++++++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 +++++
6 files changed, 82 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 0ed4f92820..b90cfefc55 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -95,6 +95,9 @@ New Features
* Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
* Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
+* **Updated pcap driver.**
+
+ * Added support for MTU on Linux network interfaces
Removed Items
-------------
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..3d76d50ef1 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -807,6 +807,48 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ unsigned int i;
+ struct pmd_internals *internals = dev->data->dev_private;
+ int is_supported = 0;
+ int is_err = 0;
+
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ struct pcap_rx_queue* queue = &internals->rx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_IN_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ struct pcap_tx_queue* queue = &internals->tx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_TX_IFACE_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ if (!is_supported)
+ return -ENOTSUP;
+
+ if (is_err)
+ return -1;
+
+ PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1046,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
diff --git a/drivers/net/pcap/pcap_osdep.h b/drivers/net/pcap/pcap_osdep.h
index bf41cba982..ef8be7543c 100644
--- a/drivers/net/pcap/pcap_osdep.h
+++ b/drivers/net/pcap/pcap_osdep.h
@@ -14,5 +14,6 @@ extern int eth_pcap_logtype;
int osdep_iface_index_get(const char *name);
int osdep_iface_mac_get(const char *name, struct rte_ether_addr *mac);
+int osdep_iface_mtu_set(const char *if_name, uint16_t mtu);
#endif
diff --git a/drivers/net/pcap/pcap_osdep_freebsd.c b/drivers/net/pcap/pcap_osdep_freebsd.c
index 20556b3e92..52d4a0e6db 100644
--- a/drivers/net/pcap/pcap_osdep_freebsd.c
+++ b/drivers/net/pcap/pcap_osdep_freebsd.c
@@ -57,3 +57,10 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
rte_free(buf);
return 0;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ PMD_LOG(WARN, "mtu set not supported on freebsd\n");
+ return -ENOTSUP;
+}
diff --git a/drivers/net/pcap/pcap_osdep_linux.c b/drivers/net/pcap/pcap_osdep_linux.c
index 97033f57c5..b0b4a716fe 100644
--- a/drivers/net/pcap/pcap_osdep_linux.c
+++ b/drivers/net/pcap/pcap_osdep_linux.c
@@ -40,3 +40,24 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
close(if_fd);
return 0;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ struct ifreq ifr;
+ int if_fd = socket(AF_INET, SOCK_DGRAM, 0);
+
+ if (if_fd == -1)
+ return -1;
+
+ rte_strscpy(ifr.ifr_name, if_name, sizeof(ifr.ifr_name));
+ ifr.ifr_mtu = mtu;
+ if (ioctl(if_fd, SIOCSIFMTU, &ifr)) {
+ PMD_LOG(ERR, "%s mtu set to %d failed\n", if_name, mtu);
+ close(if_fd);
+ return -1;
+ }
+
+ close(if_fd);
+ return 0;
+}
diff --git a/drivers/net/pcap/pcap_osdep_windows.c b/drivers/net/pcap/pcap_osdep_windows.c
index 1d398dc7ed..15205a521e 100644
--- a/drivers/net/pcap/pcap_osdep_windows.c
+++ b/drivers/net/pcap/pcap_osdep_windows.c
@@ -116,3 +116,10 @@ osdep_iface_mac_get(const char *device_name, struct rte_ether_addr *mac)
free(info);
return ret;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ PMD_LOG(WARN, "mtu set not supported on Windows\n", sys_ret);
+ return -ENOTSUP;
+}
--
2.17.1
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:35 0% ` Dumitrescu, Cristian
@ 2022-06-07 10:40 0% ` Danilewicz, MarcinX
0 siblings, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-06-07 10:40 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
Hi Cristian,
Please find answers inline.
<snip>
> > Log: v2 change in rte_sched.h to avoid ABI breakage.
<snip>
Lessons learned, so I have fixed also positioning of this above.
<snip>
> > diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c index
> > ec74bee939..db14934832 100644
> > --- a/lib/sched/rte_sched.c
> > +++ b/lib/sched/rte_sched.c
>
<snip>
> Same comment here: yes, remove the #ifdef ... #endif, but no need to
> change this code fragment, as it sets correctly the s->cman_enabled flag,
> which is then the only flag used by the rest of the code. Again, no need to
> have a CMAN_NONE in the enumeration, as the same is achieved by setting
> params->cman_params to NULL.
Yes, with that approach this is better.
<snip>
> > qe->stats.n_pkts_dropped += 1;
> > qe->stats.n_bytes_dropped += pkt_len; -#ifdef RTE_SCHED_CMAN
> > if (subport->cman_enabled)
> > qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
> -#endif }
>
> Please don't forget to remove the __rte_unused attribute for the
> n_pkts_cman_dropped in the function parameters, right?
Nice spot. Looks like this was there for some time.
Regards,
Marcin
^ permalink raw reply [relevance 0%]
* [PATCH RESEND v4 7/8] devtools: add RISC-V to test-meson-builds.sh
@ 2022-06-07 10:46 9% ` Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-06-07 10:46 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
devtools/test-meson-builds.sh | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..f732dccf6c 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configuration
+build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
+ $use_shared
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* Re: [PATCH v1] bbdev: add new operation for FFT processing
@ 2022-06-07 11:29 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-06-07 11:29 UTC (permalink / raw)
To: Hemant Agrawal, Chautru, Nicolas
Cc: thomas, Zhang, Mingshan, dev, gakhil, Vargas, Hernan,
Maxime Coquelin, trix
Hi guys,
On Thu, May 26, 2022 at 8:05 AM Hemant Agrawal
<hemant.agrawal@oss.nxp.com> wrote:
> On 5/26/2022 3:37 AM, Chautru, Nicolas wrote:
> > Hi Hernant,
> > Gentle reminder in case you can find the time. Could please have a look this patch for bbdev api extension. This is targeting 22.11.
> > New operation type for FFT processing (On top of 4 existing operations types). There is no impact to the la12xx PMD but would be good to get review/feedback.
> > This can be used for vanilla FFT and/or chained FFT/iFFT + point-wise multiplication making it applicable for SRS processing.
> > Thanks,
> > Nic
>
> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>
> HI Nicolas,
>
> Yes, I had a look into it. I see no issue in it. This is fairly
> independent feature addition to BBDEV.
>
Hemant,
For this v22.11 change, we will need some acks on the ABI breakage
announce in v22.07:
https://patchwork.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
Could you review it?
Thanks.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [PATCH v1] bbdev: add device status info
2022-06-07 0:09 3% ` Stephen Hemminger
@ 2022-06-07 12:42 0% ` Maxime Coquelin
2022-06-07 15:44 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-07 12:42 UTC (permalink / raw)
To: Stephen Hemminger, Nicolas Chautru
Cc: dev, gakhil, trix, hemant.agrawal, hernan.vargas
Hi Stephen,
On 6/7/22 02:09, Stephen Hemminger wrote:
> On Mon, 6 Jun 2022 15:50:08 -0700
> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>
>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
>> const struct rte_bbdev_op_cap *capabilities;
>> /** Device cpu_flag requirements */
>> const enum rte_cpu_flag_t *cpu_flag_reqs;
>> + /** Device Status */
>> + enum rte_bbdev_device_status device_status;
>> };
>>
>
> This ends up being an ABI breakage, can't change a struct like that
> until 22.11 release.
>
Indeed, but Nicolas mentioned in the cover-letter that the patch targets
v22.11; not this release.
However, a deprecation notice should be sent for v22.07 if it hasn't
been done yet.
Maxime
^ permalink raw reply [relevance 0%]
* Minutes of Technical Board Meeting, 2022-06-01
@ 2022-06-07 13:48 4% Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2022-06-07 13:48 UTC (permalink / raw)
To: dev
Members Attending
=================
9/11
- Aaron
- Bruce
- Hemant
- Jerin
- Kevin
- Maxime
- Olivier (chair)
- Stephen
- Thomas
NOTE: The technical board meetings are on every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC. Meetings are public, and DPDK
community members are welcome to attend.
NOTE: Next meeting will be on Wednesday 2021-June-15 @3pm UTC, and will
be chaired by Stephen.
Agenda items
============
1) Update on the tech writer hire
---------------------------------
We are in the process of recruiting a tech writer to enhance DPDK
documentation.
The work group is composed of Nathan, Bruce, Stephen, Thomas.
- 5 reasonnable candidates among 17 applicants
- the list of tasks is defined, it has been estimated to ~250h
- the work should be spread over ~6 months to give enough time
to the community for feedback
- after some time, if the community is satisfied, the writer can
suggest new enhancements, reworks, or estimation updates
- in case the community is not satisfied, the contract could end
before the end of the tasks
2) Discussions about alternatives to bug bounty to find bugs
------------------------------------------------------------
These three ideas were mentionned:
- static analysis tools
- fuzz testing
- adding more tests to CI
Projects from Google Project Zero were also mentionned:
https://github.com/orgs/googleprojectzero/repositories
3) Reminder about API/ABI stability
-----------------------------------
Recently, the vector keyword was removed from rte_altivec.h:
http://git.dpdk.org/dpdk/commit/?id=64fcadeac0f
Since it is a minor (accepted) API breakage, it is the opportunity
to do a reminder about the ABI/API process:
- API breakages are announced and can happen in minor versions
- ABI breakages are announced and can only happen in LTS releases
4) Removal of KNI
-----------------
There is no more maintainer for KNI.
A progressive removal proposal was made:
- add a message at runtime and/or compilation to announce deprecation
- remove KNI example after 22.11
- remove lib + kmod from main repo for 23.11
Bruce recently submitted a doc patchset to explain how to replace
it by virtio-user:
https://patchwork.dpdk.org/project/dpdk/list/?series=23218
The status of pending patches is not obvious. Until now, it was not
announced that new patches won't be integrated. Thomas will open the
discussion.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v7] eal: add bus cleanup to eal cleanup
@ 2022-06-07 15:12 3% ` David Marchand
2022-06-13 15:58 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-06-07 15:12 UTC (permalink / raw)
To: Thomas Monjalon, Kevin Laatz
Cc: dev, Morten Brørup, Bruce Richardson, Li Zhang, Matan Azrad,
Stephen Hemminger, lihuisong
On Tue, Jun 7, 2022 at 1:09 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 03/06/2022 16:36, Kevin Laatz:
> > During EAL init, all buses are probed and the devices found are
> > initialized. On eal_cleanup(), the inverse does not happen, meaning any
> > allocated memory and other configuration will not be cleaned up
> > appropriately on exit.
> [...]
> > --- a/devtools/libabigail.abignore
> > +++ b/devtools/libabigail.abignore
> > @@ -56,3 +56,12 @@
> > ; Ignore libabigail false-positive in clang builds, after moving code.
> > [suppress_function]
> > name = rte_eal_remote_launch
> > +
> > +; Ignore field inserted to rte_bus, adding cleanup function
> > +[suppress_type]
> > + name = rte_bus
> > + has_data_member_inserted_at = end
> > +
> > +; Ignore changes to internally used structs containing rte_bus
> > +[suppress_type]
> > + name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus
(This change is strange as there is no rte_vdev_bus type, but I won't
investigate the relevance of this rule for now).
>
> I'm not sure we can safely consider these structs as internal.
> The right process is to send a deprecation notice,
> and then remove them from the public API.
Same for me, I don't think we can safely ignore.
A rte_bus struct is embedded in rte_pci_bus (resp. rte_vmbus_bus).
If we make it grow, any inlined access (like walk in device_list or
driver_list) after the rte_bus object is broken for code accessing it
out of DPDK.
Such code might exist out there, since we expose
FOREACH_DEVICE_ON_PCIBUS, for example.
>
> For info, Li has sent a patch for the bus cleanup
> which is not updating the bus code:
> https://patches.dpdk.org/project/dpdk/patch/20220606114650.209612-3-lizh@nvidia.com/
> It may be a temporary solution before the deprecation.
On the principle, that's probably the best, there is no question about
unclear frontier of the ABI.
(In practice though, the mentionned patch is triggering segfaults in
two CI, for pdump).
Hiding rte_bus object should be straightforward in v22.11, I had some
patches, but never finished the work.
It would be great too, to look into rte_driver and rte_device which
are exposed important types, but that's another story.
--
David Marchand
^ permalink raw reply [relevance 3%]
* RE: [PATCH v1] bbdev: add device status info
2022-06-07 12:42 0% ` Maxime Coquelin
@ 2022-06-07 15:44 0% ` Chautru, Nicolas
2022-06-07 16:20 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2022-06-07 15:44 UTC (permalink / raw)
To: Maxime Coquelin, Stephen Hemminger
Cc: dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
Hi Maxime,
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, June 7, 2022 5:43 AM
> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
> <nicolas.chautru@intel.com>
> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v1] bbdev: add device status info
>
> Hi Stephen,
>
> On 6/7/22 02:09, Stephen Hemminger wrote:
> > On Mon, 6 Jun 2022 15:50:08 -0700
> > Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> >
> >> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> >> const struct rte_bbdev_op_cap *capabilities;
> >> /** Device cpu_flag requirements */
> >> const enum rte_cpu_flag_t *cpu_flag_reqs;
> >> + /** Device Status */
> >> + enum rte_bbdev_device_status device_status;
> >> };
> >>
> >
> > This ends up being an ABI breakage, can't change a struct like that
> > until 22.11 release.
> >
>
> Indeed, but Nicolas mentioned in the cover-letter that the patch targets
> v22.11; not this release.
>
> However, a deprecation notice should be sent for v22.07 if it hasn't been
> done yet.
I have sent this deprecation Maxime:
https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
Do you believe this needs to be extended to cover more details the change and including this device status info explicitly? I can update the verbiage in more details if required
>
> Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH v1] bbdev: add device status info
2022-06-07 15:44 0% ` Chautru, Nicolas
@ 2022-06-07 16:20 0% ` Maxime Coquelin
2022-06-07 16:42 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-07 16:20 UTC (permalink / raw)
To: Chautru, Nicolas, Stephen Hemminger
Cc: dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
Hi Nicolas,
On 6/7/22 17:44, Chautru, Nicolas wrote:
> Hi Maxime,
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Tuesday, June 7, 2022 5:43 AM
>> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
>> <nicolas.chautru@intel.com>
>> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
>> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
>> Subject: Re: [PATCH v1] bbdev: add device status info
>>
>> Hi Stephen,
>>
>> On 6/7/22 02:09, Stephen Hemminger wrote:
>>> On Mon, 6 Jun 2022 15:50:08 -0700
>>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>>>
>>>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
>>>> const struct rte_bbdev_op_cap *capabilities;
>>>> /** Device cpu_flag requirements */
>>>> const enum rte_cpu_flag_t *cpu_flag_reqs;
>>>> + /** Device Status */
>>>> + enum rte_bbdev_device_status device_status;
>>>> };
>>>>
>>>
>>> This ends up being an ABI breakage, can't change a struct like that
>>> until 22.11 release.
>>>
>>
>> Indeed, but Nicolas mentioned in the cover-letter that the patch targets
>> v22.11; not this release.
>>
>> However, a deprecation notice should be sent for v22.07 if it hasn't been
>> done yet.
>
> I have sent this deprecation Maxime:
> https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
> Do you believe this needs to be extended to cover more details the change and including this device status info explicitly? I can update the verbiage in more details if required
Thanks for the pointer, I missed it.
Reading the deprecation notice, it is not clear to me it is about the
device status info enum.
Maybe rewording it a bit to be more specific would help.
Thanks,
Maxime
>
>>
>> Maxime
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v1] bbdev: add device status info
2022-06-07 16:20 0% ` Maxime Coquelin
@ 2022-06-07 16:42 0% ` Stephen Hemminger
2022-06-08 22:44 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-07 16:42 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Chautru, Nicolas, dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
On Tue, 7 Jun 2022 18:20:38 +0200
Maxime Coquelin <maxime.coquelin@redhat.com> wrote:
> Hi Nicolas,
>
> On 6/7/22 17:44, Chautru, Nicolas wrote:
> > Hi Maxime,
> >
> >> -----Original Message-----
> >> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> >> Sent: Tuesday, June 7, 2022 5:43 AM
> >> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
> >> <nicolas.chautru@intel.com>
> >> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
> >> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> >> Subject: Re: [PATCH v1] bbdev: add device status info
> >>
> >> Hi Stephen,
> >>
> >> On 6/7/22 02:09, Stephen Hemminger wrote:
> >>> On Mon, 6 Jun 2022 15:50:08 -0700
> >>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> >>>
> >>>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> >>>> const struct rte_bbdev_op_cap *capabilities;
> >>>> /** Device cpu_flag requirements */
> >>>> const enum rte_cpu_flag_t *cpu_flag_reqs;
> >>>> + /** Device Status */
> >>>> + enum rte_bbdev_device_status device_status;
> >>>> };
> >>>>
> >>>
> >>> This ends up being an ABI breakage, can't change a struct like that
> >>> until 22.11 release.
> >>>
> >>
> >> Indeed, but Nicolas mentioned in the cover-letter that the patch targets
> >> v22.11; not this release.
> >>
> >> However, a deprecation notice should be sent for v22.07 if it hasn't been
> >> done yet.
> >
> > I have sent this deprecation Maxime:
> > https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
> > Do you believe this needs to be extended to cover more details the change and including this device status info explicitly? I can update the verbiage in more details if required
>
> Thanks for the pointer, I missed it.
> Reading the deprecation notice, it is not clear to me it is about the
> device status info enum.
>
> Maybe rewording it a bit to be more specific would help.
You might want to use one the existing empty padding slots (holes) in
that structure. It appears to have been laid out haphazardly.
^ permalink raw reply [relevance 0%]
* [PATCH v3] sched: enable CMAN at runtime
2022-05-12 13:10 4% ` [PATCH v2] " Marcin Danilewicz
2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 11:35 0% ` Dumitrescu, Cristian
@ 2022-06-08 9:42 1% ` Marcin Danilewicz
2022-06-08 11:59 0% ` Dumitrescu, Cristian
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
2 siblings, 2 replies; 200+ results
From: Marcin Danilewicz @ 2022-06-08 9:42 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 8eb29c1525..1740a1d053 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-#undef RTE_SCHED_CMAN
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index ec74bee939..84c5e315c3 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1081,7 +1077,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1163,7 +1158,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_config(struct rte_sched_port *port,
@@ -1254,7 +1248,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
s->n_pipe_profiles = params->n_pipe_profiles;
s->n_max_pipe_profiles = params->n_max_pipe_profiles;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1266,7 +1259,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1792,7 +1784,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1818,21 +1810,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1877,13 +1865,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1902,29 +1888,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* RE: [PATCH v3] sched: enable CMAN at runtime
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
@ 2022-06-08 11:59 0% ` Dumitrescu, Cristian
2022-06-08 15:29 0% ` Danilewicz, MarcinX
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
1 sibling, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2022-06-08 11:59 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Wednesday, June 8, 2022 10:42 AM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v3] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> Log: v2 change in rte_sched.h to avoid ABI breakage.
> v3 changes from comments
> ---
Marcin,
Your patch does not apply cleanly on top of DPDK main latest, can you please fix.
Regards,
Cristian
^ permalink raw reply [relevance 0%]
* [PATCH v2 0/6] Vhost checksum offload improvements
@ 2022-06-08 12:49 3% Maxime Coquelin
2022-06-17 14:06 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-08 12:49 UTC (permalink / raw)
To: dev, jasowang, chenbo.xia, david.marchand, olivier.matz,
wenwux.ma, yuying.zhang, aman.deep.singh
Cc: Maxime Coquelin
This series aims at improving Vhost checksum offloading
support.
The first patch reverts overwritting MAC address in
testpmd CSUM forward mode. This is required to be able to
test checksum offloading with real traffic. MAC forwarding
mode should be used if the MAC addresses need to be
changed.
Second patch is a Vhost library fix to be compliant with
the Virtio specification, which requires that the
pseudo-header checksum is being set by the device when
offloading the checksum to the guest.
Third patch enables the compliant offloading mode of Vhost
library in Vhost PMD by default, since the legacy mode
violates the mbuf API by setting Tx flags in the receive
path. A new devarg is introduced for application willing
to use the legacy mode.
Fourth patch is just a small cleanup to represent a boolean
value as a boolean.
The two last patches introduces compatibility layers
that performs checksum in SW when the ethdev and Virtio
features are not aligned.
Note that the two last patches are not tagged as fixes
because they rely on the new compliant offload mode of
Vhost library, and so would casue an ABI breakage if
backported.
With this series, it is now possible to perform IO
forwarding between a vhost-user port and a Vitio-user
with kernel backend port even if the guest has negotiated
VIRTIO_NET_F_CSUM.
With csum forward mode, it now works whathever the
offloading configuration set either on Virtio or Ethdev
sides.
Changes in v2:
==============
- Add the new devarg to validation array (Wenwu)
- Fix typos in commit messages (Chenbo, checkpatch, Yuying)
Maxime Coquelin (6):
Revert "app/testpmd: modify mac in csum forwarding"
vhost: fix missing enqueue pseudo-header calculation
net/vhost: enable compliant offloading mode
net/vhost: make VLAN stripping flag a boolean
net/vhost: perform SW checksum in Rx path
net/vhost: perform SW checksum in Tx path
app/test-pmd/csumonly.c | 4 -
doc/guides/nics/features/vhost.ini | 1 +
doc/guides/nics/vhost.rst | 6 ++
drivers/net/vhost/rte_eth_vhost.c | 167 ++++++++++++++++++++++++++++-
lib/vhost/virtio_net.c | 10 ++
5 files changed, 180 insertions(+), 8 deletions(-)
--
2.35.3
^ permalink raw reply [relevance 3%]
* RE: [PATCH v3] sched: enable CMAN at runtime
2022-06-08 11:59 0% ` Dumitrescu, Cristian
@ 2022-06-08 15:29 0% ` Danilewicz, MarcinX
0 siblings, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-06-08 15:29 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
Hi Cristian,
Ok, let me check.
BR,
/Marcin
> -----Original Message-----
> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Sent: Wednesday, June 8, 2022 1:59 PM
> To: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>; dev@dpdk.org;
> Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>; Liu, Yu Y
> <yu.y.liu@intel.com>
> Subject: RE: [PATCH v3] sched: enable CMAN at runtime
>
>
>
> > -----Original Message-----
> > From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> > Sent: Wednesday, June 8, 2022 10:42 AM
> > To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > Cc: Ajmera, Megha <megha.ajmera@intel.com>
> > Subject: [PATCH v3] sched: enable CMAN at runtime
> >
> > Added changes to enable CMAN (RED or PIE) at init from profile
> > configuration file.
> >
> > By default CMAN code is enable but not in use, when there is no RED or
> > PIE profile configured.
> >
> > Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> > ---
> > Log: v2 change in rte_sched.h to avoid ABI breakage.
> > v3 changes from comments
> > ---
>
> Marcin,
>
> Your patch does not apply cleanly on top of DPDK main latest, can you please
> fix.
>
> Regards,
> Cristian
^ permalink raw reply [relevance 0%]
* [PATCH] devtools: unify cross-compilation tests
@ 2022-06-08 15:50 15% Thomas Monjalon
2022-06-08 16:34 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-08 15:50 UTC (permalink / raw)
To: dev; +Cc: david.marchand, Bruce Richardson
Reduce the number of Arm builds from 3 to 1:
only generic armv8 with GCC.
The specific PPC builds on Ubuntu are skipped.
The build directories for PPC and RISC-V
are also renamed for consistency:
- build-arm64-generic-gcc
- build-ppc64-power8-gcc
- build-riscv64-generic-gcc
The cross file is always saved in variable "f" for readability.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
devtools/test-meson-builds.sh | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index f732dccf6c..2cdc2d813d 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -253,31 +253,20 @@ if check_cc_flags '-m32' ; then
fi
# x86 MinGW
-build build-x86-mingw $srcdir/config/x86/cross-mingw skipABI \
- -Dexamples=helloworld
+f=$srcdir/config/x86/cross-mingw
+build build-x86-mingw $f skipABI -Dexamples=helloworld
-# generic armv8a with clang as host compiler
+# generic armv8
f=$srcdir/config/arm/arm64_armv8_linux_gcc
-export CC="clang"
-build build-arm64-host-clang $f ABI $use_shared
-unset CC
-# some gcc/arm configurations
-for f in $srcdir/config/arm/arm64_[bdo]*gcc ; do
- export CC="$CCACHE gcc"
- targetdir=build-$(basename $f | tr '_' '-' | cut -d'-' -f-2)
- build $targetdir $f skipABI $use_shared
- unset CC
-done
+build build-arm64-generic-gcc $f ABI $use_shared
-# ppc configurations
-for f in $srcdir/config/ppc/ppc* ; do
- targetdir=build-$(basename $f | cut -d'-' -f-2)
- build $targetdir $f ABI $use_shared
-done
+# IBM POWER
+f=$srcdir/config/ppc/ppc64le-power8-linux-gcc
+build build-ppc64-power8-gcc $f ABI $use_shared
-# RISC-V configuration
-build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
- $use_shared
+# generic RISC-V
+f=$srcdir/config/riscv/riscv64_linux_gcc
+build build-riscv64-generic-gcc $f ABI $use_shared
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
--
2.36.0
^ permalink raw reply [relevance 15%]
* [PATCH v6] pcap: support MTU set for linux interafces
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
@ 2022-06-08 16:04 3% ` Ido Goshen
0 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-08 16:04 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v6:
Fixes for v5 approach
1. freebsd compilation fix
2. checkpatch warning fix
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 42 ++++++++++++++++++++++++++
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 +++++
drivers/net/pcap/pcap_osdep_linux.c | 21 +++++++++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 +++++
6 files changed, 81 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 0ed4f92820..b90cfefc55 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -95,6 +95,9 @@ New Features
* Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
* Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
+* **Updated pcap driver.**
+
+ * Added support for MTU on Linux network interfaces
Removed Items
-------------
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..2221c53051 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -807,6 +807,47 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ unsigned int i;
+ struct pmd_internals *internals = dev->data->dev_private;
+ int is_supported = 0;
+ int is_err = 0;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ struct pcap_rx_queue *queue = &internals->rx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_IN_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ struct pcap_tx_queue *queue = &internals->tx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_TX_IFACE_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ if (!is_supported)
+ return -ENOTSUP;
+
+ if (is_err)
+ return -1;
+
+ PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1045,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
diff --git a/drivers/net/pcap/pcap_osdep.h b/drivers/net/pcap/pcap_osdep.h
index bf41cba982..ef8be7543c 100644
--- a/drivers/net/pcap/pcap_osdep.h
+++ b/drivers/net/pcap/pcap_osdep.h
@@ -14,5 +14,6 @@ extern int eth_pcap_logtype;
int osdep_iface_index_get(const char *name);
int osdep_iface_mac_get(const char *name, struct rte_ether_addr *mac);
+int osdep_iface_mtu_set(const char *if_name, uint16_t mtu);
#endif
diff --git a/drivers/net/pcap/pcap_osdep_freebsd.c b/drivers/net/pcap/pcap_osdep_freebsd.c
index 20556b3e92..a9961ba3e3 100644
--- a/drivers/net/pcap/pcap_osdep_freebsd.c
+++ b/drivers/net/pcap/pcap_osdep_freebsd.c
@@ -57,3 +57,10 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
rte_free(buf);
return 0;
}
+
+int
+osdep_iface_mtu_set(__rte_unused const char *if_name, __rte_unused uint16_t mtu)
+{
+ PMD_LOG(ERR, "mtu set not supported on freebsd\n");
+ return -ENOTSUP;
+}
diff --git a/drivers/net/pcap/pcap_osdep_linux.c b/drivers/net/pcap/pcap_osdep_linux.c
index 97033f57c5..b0b4a716fe 100644
--- a/drivers/net/pcap/pcap_osdep_linux.c
+++ b/drivers/net/pcap/pcap_osdep_linux.c
@@ -40,3 +40,24 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
close(if_fd);
return 0;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ struct ifreq ifr;
+ int if_fd = socket(AF_INET, SOCK_DGRAM, 0);
+
+ if (if_fd == -1)
+ return -1;
+
+ rte_strscpy(ifr.ifr_name, if_name, sizeof(ifr.ifr_name));
+ ifr.ifr_mtu = mtu;
+ if (ioctl(if_fd, SIOCSIFMTU, &ifr)) {
+ PMD_LOG(ERR, "%s mtu set to %d failed\n", if_name, mtu);
+ close(if_fd);
+ return -1;
+ }
+
+ close(if_fd);
+ return 0;
+}
diff --git a/drivers/net/pcap/pcap_osdep_windows.c b/drivers/net/pcap/pcap_osdep_windows.c
index 1d398dc7ed..69cf052e6d 100644
--- a/drivers/net/pcap/pcap_osdep_windows.c
+++ b/drivers/net/pcap/pcap_osdep_windows.c
@@ -116,3 +116,10 @@ osdep_iface_mac_get(const char *device_name, struct rte_ether_addr *mac)
free(info);
return ret;
}
+
+int
+osdep_iface_mtu_set(__rte_unused const char *if_name, __rte_unused uint16_t mtu)
+{
+ PMD_LOG(ERR, "mtu set not supported on Windows\n");
+ return -ENOTSUP;
+}
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH] devtools: unify cross-compilation tests
2022-06-08 15:50 15% [PATCH] devtools: unify cross-compilation tests Thomas Monjalon
@ 2022-06-08 16:34 4% ` David Marchand
2022-06-08 17:20 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-06-08 16:34 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bruce Richardson
On Wed, Jun 8, 2022 at 5:50 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Reduce the number of Arm builds from 3 to 1:
> only generic armv8 with GCC.
> The specific PPC builds on Ubuntu are skipped.
>
> The build directories for PPC and RISC-V
> are also renamed for consistency:
> - build-arm64-generic-gcc
> - build-ppc64-power8-gcc
> - build-riscv64-generic-gcc
>
> The cross file is always saved in variable "f" for readability.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Thanks, this reduction is something I already had locally (via some
configuration).
I like the renaming, though this change will trigger ABI reference
regeneration for people who do test ABI.
Otherwise the change lgtm.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] build: ccache support for cross build
@ 2022-06-08 17:13 3% ` jerinj
2022-06-14 16:01 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: jerinj @ 2022-06-08 17:13 UTC (permalink / raw)
To: dev, Jan Viktorin, Ruifeng Wang, Bruce Richardson,
David Christensen, Stanislaw Kardach, Konstantin Ananyev
Cc: thomas, david.marchand, juraj.linkes, fengchengwen, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
By default, ccache is not used for cross build[1].
Update all cross files to use ccache if it is available
in build machine.
Also, updated devtools/test-meson-builds.sh
script to find the correct DPDK_TARGET due to
change in cross file syntax.
[1]
https://mesonbuild.com/Machine-files.html
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v2:
- Rebased with master, therefore added update riscv64 cross files
- Fixed DPDK_TARGET detection with devtools/test-meson-builds.sh
due to cross file synatx update.
config/arm/arm32_armv8_linux_gcc | 4 ++--
config/arm/arm64_armada_linux_gcc | 4 ++--
config/arm/arm64_armv8_linux_clang_ubuntu | 4 ++--
config/arm/arm64_armv8_linux_gcc | 4 ++--
config/arm/arm64_bluefield_linux_gcc | 4 ++--
config/arm/arm64_centriq2400_linux_gcc | 4 ++--
config/arm/arm64_cn10k_linux_gcc | 4 ++--
config/arm/arm64_cn9k_linux_gcc | 4 ++--
config/arm/arm64_dpaa_linux_gcc | 4 ++--
config/arm/arm64_emag_linux_gcc | 4 ++--
config/arm/arm64_graviton2_linux_gcc | 4 ++--
config/arm/arm64_kunpeng920_linux_gcc | 4 ++--
config/arm/arm64_kunpeng930_linux_gcc | 4 ++--
config/arm/arm64_n1sdp_linux_gcc | 4 ++--
config/arm/arm64_n2_linux_gcc | 4 ++--
config/arm/arm64_stingray_linux_gcc | 4 ++--
config/arm/arm64_thunderx2_linux_gcc | 4 ++--
config/arm/arm64_thunderxt83_linux_gcc | 4 ++--
config/arm/arm64_thunderxt88_linux_gcc | 4 ++--
config/ppc/ppc64le-power8-linux-gcc | 4 ++--
config/ppc/ppc64le-power8-linux-gcc-ubuntu | 4 ++--
config/riscv/riscv64_linux_gcc | 4 ++--
config/riscv/riscv64_sifive_u740_linux_gcc | 4 ++--
config/x86/cross-mingw | 4 ++--
devtools/test-meson-builds.sh | 3 ++-
25 files changed, 50 insertions(+), 49 deletions(-)
diff --git a/config/arm/arm32_armv8_linux_gcc b/config/arm/arm32_armv8_linux_gcc
index 89f8a12881..7f2977e49d 100644
--- a/config/arm/arm32_armv8_linux_gcc
+++ b/config/arm/arm32_armv8_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'arm-linux-gnueabihf-gcc'
-cpp = 'arm-linux-gnueabihf-cpp'
+c = ['ccache', 'arm-linux-gnueabihf-gcc']
+cpp = ['ccache', 'arm-linux-gnueabihf-cpp']
ar = 'arm-linux-gnueabihf-gcc-ar'
strip = 'arm-linux-gnueabihf-strip'
pkgconfig = 'arm-linux-gnueabihf-pkg-config'
diff --git a/config/arm/arm64_armada_linux_gcc b/config/arm/arm64_armada_linux_gcc
index 301418949b..1566999101 100644
--- a/config/arm/arm64_armada_linux_gcc
+++ b/config/arm/arm64_armada_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-ar'
as = 'aarch64-linux-gnu-as'
strip = 'aarch64-linux-gnu-strip'
diff --git a/config/arm/arm64_armv8_linux_clang_ubuntu b/config/arm/arm64_armv8_linux_clang_ubuntu
index db488d75f4..86ae43937b 100644
--- a/config/arm/arm64_armv8_linux_clang_ubuntu
+++ b/config/arm/arm64_armv8_linux_clang_ubuntu
@@ -1,6 +1,6 @@
[binaries]
-c = 'clang'
-cpp = 'clang++'
+c = ['ccache', 'clang']
+cpp = ['ccache', 'clang++']
ar = 'llvm-ar'
strip = 'llvm-strip'
llvm-config = 'llvm-config'
diff --git a/config/arm/arm64_armv8_linux_gcc b/config/arm/arm64_armv8_linux_gcc
index 5391d35389..048c2d9f29 100644
--- a/config/arm/arm64_armv8_linux_gcc
+++ b/config/arm/arm64_armv8_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_bluefield_linux_gcc b/config/arm/arm64_bluefield_linux_gcc
index 248a9f031a..38df3c198b 100644
--- a/config/arm/arm64_bluefield_linux_gcc
+++ b/config/arm/arm64_bluefield_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_centriq2400_linux_gcc b/config/arm/arm64_centriq2400_linux_gcc
index dfe9110331..0966eef2c5 100644
--- a/config/arm/arm64_centriq2400_linux_gcc
+++ b/config/arm/arm64_centriq2400_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_cn10k_linux_gcc b/config/arm/arm64_cn10k_linux_gcc
index a3578c03a1..201e0ccd59 100644
--- a/config/arm/arm64_cn10k_linux_gcc
+++ b/config/arm/arm64_cn10k_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_cn9k_linux_gcc b/config/arm/arm64_cn9k_linux_gcc
index a94b44a551..a9b4d51958 100644
--- a/config/arm/arm64_cn9k_linux_gcc
+++ b/config/arm/arm64_cn9k_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_dpaa_linux_gcc b/config/arm/arm64_dpaa_linux_gcc
index e9d5fd31fc..0d5761bd72 100644
--- a/config/arm/arm64_dpaa_linux_gcc
+++ b/config/arm/arm64_dpaa_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-ar'
as = 'aarch64-linux-gnu-as'
strip = 'aarch64-linux-gnu-strip'
diff --git a/config/arm/arm64_emag_linux_gcc b/config/arm/arm64_emag_linux_gcc
index 9cdd931180..16ec49fc32 100644
--- a/config/arm/arm64_emag_linux_gcc
+++ b/config/arm/arm64_emag_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_graviton2_linux_gcc b/config/arm/arm64_graviton2_linux_gcc
index 8016fd236c..094c540f50 100644
--- a/config/arm/arm64_graviton2_linux_gcc
+++ b/config/arm/arm64_graviton2_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_kunpeng920_linux_gcc b/config/arm/arm64_kunpeng920_linux_gcc
index c4685b2458..fc057c9063 100644
--- a/config/arm/arm64_kunpeng920_linux_gcc
+++ b/config/arm/arm64_kunpeng920_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_kunpeng930_linux_gcc b/config/arm/arm64_kunpeng930_linux_gcc
index fb85d2d710..5f43941fae 100644
--- a/config/arm/arm64_kunpeng930_linux_gcc
+++ b/config/arm/arm64_kunpeng930_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_n1sdp_linux_gcc b/config/arm/arm64_n1sdp_linux_gcc
index 0df283e2f4..fc123ab53f 100644
--- a/config/arm/arm64_n1sdp_linux_gcc
+++ b/config/arm/arm64_n1sdp_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_n2_linux_gcc b/config/arm/arm64_n2_linux_gcc
index 036aee2b0a..930bd5c236 100644
--- a/config/arm/arm64_n2_linux_gcc
+++ b/config/arm/arm64_n2_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_stingray_linux_gcc b/config/arm/arm64_stingray_linux_gcc
index 319a4a151d..5dfcd974fd 100644
--- a/config/arm/arm64_stingray_linux_gcc
+++ b/config/arm/arm64_stingray_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_thunderx2_linux_gcc b/config/arm/arm64_thunderx2_linux_gcc
index 69c71cbc82..c1f5995d93 100644
--- a/config/arm/arm64_thunderx2_linux_gcc
+++ b/config/arm/arm64_thunderx2_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_thunderxt83_linux_gcc b/config/arm/arm64_thunderxt83_linux_gcc
index 47102c900b..52746e2e59 100644
--- a/config/arm/arm64_thunderxt83_linux_gcc
+++ b/config/arm/arm64_thunderxt83_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_thunderxt88_linux_gcc b/config/arm/arm64_thunderxt88_linux_gcc
index 372097ba01..fed7eb791e 100644
--- a/config/arm/arm64_thunderxt88_linux_gcc
+++ b/config/arm/arm64_thunderxt88_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/ppc/ppc64le-power8-linux-gcc b/config/ppc/ppc64le-power8-linux-gcc
index 51f7ceebf3..465044e427 100644
--- a/config/ppc/ppc64le-power8-linux-gcc
+++ b/config/ppc/ppc64le-power8-linux-gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'powerpc64le-linux-gcc'
-cpp = 'powerpc64le-linux-cpp'
+c = ['ccache', 'powerpc64le-linux-gcc']
+cpp = ['ccache', 'powerpc64le-linux-cpp']
ar = 'powerpc64le-linux-gcc-ar'
strip = 'powerpc64le-linux-strip'
diff --git a/config/ppc/ppc64le-power8-linux-gcc-ubuntu b/config/ppc/ppc64le-power8-linux-gcc-ubuntu
index 803c612cbc..44d7e0100a 100644
--- a/config/ppc/ppc64le-power8-linux-gcc-ubuntu
+++ b/config/ppc/ppc64le-power8-linux-gcc-ubuntu
@@ -1,6 +1,6 @@
[binaries]
-c = 'powerpc64le-linux-gnu-gcc'
-cpp = 'powerpc64le-linux-gnu-cpp'
+c = ['ccache', 'powerpc64le-linux-gnu-gcc']
+cpp = ['ccache', 'powerpc64le-linux-gnu-cpp']
ar = 'powerpc64le-linux-gnu-ar'
strip = 'powerpc64le-linux-gnu-strip'
diff --git a/config/riscv/riscv64_linux_gcc b/config/riscv/riscv64_linux_gcc
index ed4d3ce7fb..5e58781193 100644
--- a/config/riscv/riscv64_linux_gcc
+++ b/config/riscv/riscv64_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'riscv64-linux-gnu-gcc'
-cpp = 'riscv64-linux-gnu-g++'
+c = ['ccache', 'riscv64-linux-gnu-gcc']
+cpp = ['ccache', 'riscv64-linux-gnu-g++']
ar = 'riscv64-linux-gnu-ar'
strip = 'riscv64-linux-gnu-strip'
pcap-config = ''
diff --git a/config/riscv/riscv64_sifive_u740_linux_gcc b/config/riscv/riscv64_sifive_u740_linux_gcc
index 3d1905c434..58d2c92f8c 100644
--- a/config/riscv/riscv64_sifive_u740_linux_gcc
+++ b/config/riscv/riscv64_sifive_u740_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'riscv64-unknown-linux-gnu-gcc'
-cpp = 'riscv64-unknown-linux-gnu-g++'
+c = ['ccache', 'riscv64-unknown-linux-gnu-gcc']
+cpp = ['ccache', 'riscv64-unknown-linux-gnu-g++']
ar = 'riscv64-unknown-linux-gnu-ar'
strip = 'riscv64-unknown-linux-gnu-strip'
pcap-config = ''
diff --git a/config/x86/cross-mingw b/config/x86/cross-mingw
index 09f7af0928..cddebda5b5 100644
--- a/config/x86/cross-mingw
+++ b/config/x86/cross-mingw
@@ -1,6 +1,6 @@
[binaries]
-c = 'x86_64-w64-mingw32-gcc'
-cpp = 'x86_64-w64-mingw32-g++'
+c = ['ccache', 'x86_64-w64-mingw32-gcc']
+cpp = ['ccache', 'x86_64-w64-mingw32-g++']
ld = 'x86_64-w64-mingw32-ld'
ar = 'x86_64-w64-mingw32-ar'
strip = 'x86_64-w64-mingw32-strip'
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index f732dccf6c..e44a2b1995 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -160,7 +160,8 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
if [ -n "$crossfile" ] ; then
cross="--cross-file $crossfile"
targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
- $crossfile | tr -d "'" | tr -d '"')
+ $crossfile | cut -d ',' -f 2 | \
+ tr -d "'" | tr -d '"' | tr -d ']' | tr -d ' ')
else
cross=
fi
--
2.36.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH] devtools: unify cross-compilation tests
2022-06-08 16:34 4% ` David Marchand
@ 2022-06-08 17:20 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-08 17:20 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Bruce Richardson
08/06/2022 18:34, David Marchand:
> On Wed, Jun 8, 2022 at 5:50 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > Reduce the number of Arm builds from 3 to 1:
> > only generic armv8 with GCC.
> > The specific PPC builds on Ubuntu are skipped.
> >
> > The build directories for PPC and RISC-V
> > are also renamed for consistency:
> > - build-arm64-generic-gcc
> > - build-ppc64-power8-gcc
> > - build-riscv64-generic-gcc
> >
> > The cross file is always saved in variable "f" for readability.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>
> Thanks, this reduction is something I already had locally (via some
> configuration).
>
> I like the renaming, though this change will trigger ABI reference
> regeneration for people who do test ABI.
>
> Otherwise the change lgtm.
> Acked-by: David Marchand <david.marchand@redhat.com>
Applied quickly before -rc1.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
@ 2022-06-08 17:46 3% ` Thomas Monjalon
2022-06-09 0:17 3% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-08 17:46 UTC (permalink / raw)
To: Andrew Rybchenko, Spike Du
Cc: dev, Xiaoyun Li, Aman Singh, Yuying Zhang, Ferruh Yigit,
Ray Kinsella, dev
08/06/2022 19:22, Thomas Monjalon:
> 08/06/2022 18:35, Andrew Rybchenko:
> > From: Spike Du <spiked@nvidia.com>
> >
> > A new event RTE_ETH_EVENT_RX_AVAIL_THRESH should be generated by HW
> > when number of available descriptors in Rx queue goes below the
> > threshold.
> >
> > The threshold is defined as a percentage of an Rx queue size with valid
> > values from 0 to 99 (inclusive). Zero (default) value disables it.
> >
> > There is no capability reporting for the feature. Application should
> > simply try to set required threshold value and handle result.
> >
> > Add testpmd commands to control the threshold:
> > set port <port_id> rxq <rxq_id> avail_thresh <avail_thresh_num>
> >
> > Signed-off-by: Spike Du <spiked@nvidia.com>
> > Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > ---
> > v6:
> > - try to make descriptor shorter and more useful
> > - refine terminology to use "available descriptors threshold"
> > everywhere (plural "descriptors")
> > - fix ethdev API documenation
> > - define negative return values
> > - define rules to convert percentage to descriptors number
> > in drivers
> > - avoid extra checks in testpmd helper to allow ethdev API
> > to do its job
> > - minor fixes in testpmd variables naming
> > - fix testpmd help to be human oriented
> > - update testpmd users guide
> > - add release notes
>
> What a (more than) review work, thanks a lot for this v6!
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>
> With a few minor arrangements,
> applied, thanks.
PS: some ABI exceptions have to be added as discussed in the thread:
+; Ignore ethdev event enum update
+; because new event cannot be received if not registered
+[suppress_type]
+ type_kind = enum
+ changed_enumerators = RTE_ETH_EVENT_MAX
+
+; Ignore fields inserted in cacheline boundary of rte_eth_rxq_info
+; because the struct size is unchanged
+[suppress_type]
+ name = rte_eth_rxq_info
+ has_data_member_inserted_between = {offset_of(rx_buf_size), end}
^ permalink raw reply [relevance 3%]
* RE: [PATCH v1] bbdev: add device status info
2022-06-07 16:42 0% ` Stephen Hemminger
@ 2022-06-08 22:44 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-06-08 22:44 UTC (permalink / raw)
To: Stephen Hemminger, Maxime Coquelin
Cc: dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, June 7, 2022 9:43 AM
> To: Maxime Coquelin <maxime.coquelin@redhat.com>
> Cc: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> gakhil@marvell.com; trix@redhat.com; hemant.agrawal@nxp.com; Vargas,
> Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v1] bbdev: add device status info
>
> On Tue, 7 Jun 2022 18:20:38 +0200
> Maxime Coquelin <maxime.coquelin@redhat.com> wrote:
>
> > Hi Nicolas,
> >
> > On 6/7/22 17:44, Chautru, Nicolas wrote:
> > > Hi Maxime,
> > >
> > >> -----Original Message-----
> > >> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> > >> Sent: Tuesday, June 7, 2022 5:43 AM
> > >> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru,
> > >> Nicolas <nicolas.chautru@intel.com>
> > >> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
> > >> hemant.agrawal@nxp.com; Vargas, Hernan
> <hernan.vargas@intel.com>
> > >> Subject: Re: [PATCH v1] bbdev: add device status info
> > >>
> > >> Hi Stephen,
> > >>
> > >> On 6/7/22 02:09, Stephen Hemminger wrote:
> > >>> On Mon, 6 Jun 2022 15:50:08 -0700 Nicolas Chautru
> > >>> <nicolas.chautru@intel.com> wrote:
> > >>>
> > >>>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> > >>>> const struct rte_bbdev_op_cap *capabilities;
> > >>>> /** Device cpu_flag requirements */
> > >>>> const enum rte_cpu_flag_t *cpu_flag_reqs;
> > >>>> + /** Device Status */
> > >>>> + enum rte_bbdev_device_status device_status;
> > >>>> };
> > >>>>
> > >>>
> > >>> This ends up being an ABI breakage, can't change a struct like
> > >>> that until 22.11 release.
> > >>>
> > >>
> > >> Indeed, but Nicolas mentioned in the cover-letter that the patch
> > >> targets v22.11; not this release.
> > >>
> > >> However, a deprecation notice should be sent for v22.07 if it
> > >> hasn't been done yet.
> > >
> > > I have sent this deprecation Maxime:
> > > https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-s
> > > end-email-nicolas.chautru@intel.com/
> > > Do you believe this needs to be extended to cover more details the
> > > change and including this device status info explicitly? I can
> > > update the verbiage in more details if required
> >
> > Thanks for the pointer, I missed it.
> > Reading the deprecation notice, it is not clear to me it is about the
> > device status info enum.
> >
> > Maybe rewording it a bit to be more specific would help.
>
> You might want to use one the existing empty padding slots (holes) in that
> structure. It appears to have been laid out haphazardly.
>
I don't see such one single hole to fill that enum but I can shuffle a bit that structure. In that case total size would no longer change but a few offsets would differ and padding would be reduced.
Thanks
Nic
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
2022-06-08 17:46 3% ` Thomas Monjalon
@ 2022-06-09 0:17 3% ` fengchengwen
2022-06-09 7:05 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: fengchengwen @ 2022-06-09 0:17 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko, Spike Du
Cc: dev, Xiaoyun Li, Aman Singh, Yuying Zhang, Ferruh Yigit,
Ray Kinsella, mdr
Hi Thomas,
Could it possible accept the patch ' [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events'
which was delayed by ABI exceptions like this patch ?
PS: I noticed RC-1 was released just now and there may be no window left, but I think since this patch can be an
exception, why not that patch ?
Thanks.
On 2022/6/9 1:46, Thomas Monjalon wrote:
> 08/06/2022 19:22, Thomas Monjalon:
>> 08/06/2022 18:35, Andrew Rybchenko:
>>> From: Spike Du <spiked@nvidia.com>
>>>
>>> A new event RTE_ETH_EVENT_RX_AVAIL_THRESH should be generated by HW
>>> when number of available descriptors in Rx queue goes below the
>>> threshold.
>>>
>>> The threshold is defined as a percentage of an Rx queue size with valid
>>> values from 0 to 99 (inclusive). Zero (default) value disables it.
>>>
>>> There is no capability reporting for the feature. Application should
>>> simply try to set required threshold value and handle result.
>>>
>>> Add testpmd commands to control the threshold:
>>> set port <port_id> rxq <rxq_id> avail_thresh <avail_thresh_num>
>>>
>>> Signed-off-by: Spike Du <spiked@nvidia.com>
>>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>> ---
>>> v6:
>>> - try to make descriptor shorter and more useful
>>> - refine terminology to use "available descriptors threshold"
>>> everywhere (plural "descriptors")
>>> - fix ethdev API documenation
>>> - define negative return values
>>> - define rules to convert percentage to descriptors number
>>> in drivers
>>> - avoid extra checks in testpmd helper to allow ethdev API
>>> to do its job
>>> - minor fixes in testpmd variables naming
>>> - fix testpmd help to be human oriented
>>> - update testpmd users guide
>>> - add release notes
>>
>> What a (more than) review work, thanks a lot for this v6!
>>
>> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>>
>> With a few minor arrangements,
>> applied, thanks.
>
> PS: some ABI exceptions have to be added as discussed in the thread:
>
> +; Ignore ethdev event enum update
> +; because new event cannot be received if not registered
> +[suppress_type]
> + type_kind = enum
> + changed_enumerators = RTE_ETH_EVENT_MAX
> +
> +; Ignore fields inserted in cacheline boundary of rte_eth_rxq_info
> +; because the struct size is unchanged
> +[suppress_type]
> + name = rte_eth_rxq_info
> + has_data_member_inserted_between = {offset_of(rx_buf_size), end}
>
>
>
>
>
> .
>
^ permalink raw reply [relevance 3%]
* [PATCH v3] doc: announce changes in bbdev related to enum extension
@ 2022-06-09 0:20 3% ` Nicolas Chautru
2022-06-09 0:20 3% ` Nicolas Chautru
2022-06-09 0:34 3% ` [PATCH v4] " Nicolas Chautru
1 sibling, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:20 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
v3: being more explicit wrt the list of intended changes for 22.11
v2: indentation fix
Realizing when submitting new bbdev operation in this patch
(https://patchwork.dpdk.org/project/dpdk/list/?series=22111) that this is not workable in practice to extend this API into 22.07 without fundamental ABI breakage even by using existing versionning framework.
Some existing learnings to be applied here to prevent extension being blocked, hence accouncing changes in bbdev intended for 22.11 to make this more future-proof, including dropping max value from enum, as well as deferring extension of the API for FFT operation into DPDK 22.11.
Let me know if any comments or in case this should be captured differently.
Thanks
Nic
Nicolas Chautru (1):
doc: announce changes in bbdev related to enum extension
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v3] doc: announce changes in bbdev related to enum extension
2022-06-09 0:20 3% ` [PATCH v3] " Nicolas Chautru
@ 2022-06-09 0:20 3% ` Nicolas Chautru
0 siblings, 0 replies; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:20 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
Intent to resolve in DPDK 22.11 historical usage which prevents
graceful extension of enum and API without troublesome ABI breakage
as well as extending API RTE_BBDEV_OP_FFT for new operation type
in bbdev as well as other new members in existing structures.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c..c75f43e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -112,6 +112,16 @@ Deprecation Notices
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``.
+* bbdev: Will be deprecating ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
+ and use fixed array size when required to allow for future enum extension.
+ Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
+ RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
+ Will be adding new members in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired
+ by this RFC https://patches.dpdk.org/project/dpdk/list/?series=22076
+ Will be adding new member in ``rte_bbdev_driver_info`` to expose the device status as per
+ this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
+ This should be updated in DPDK 22.11.
+
* security: Hide structure ``rte_security_session`` and expose an opaque
pointer for the private data to the application which can be attached
to the packet while enqueuing.
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:20 3% ` [PATCH v3] " Nicolas Chautru
@ 2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 0:34 3% ` Nicolas Chautru
1 sibling, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:34 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
v4: correcting typo. Hemant, Maxime kindly review/ack.
v3: being more explicit wrt the list of intended changes for 22.11
v2: indentation fix
Realizing when submitting new bbdev operation in this patch
(https://patchwork.dpdk.org/project/dpdk/list/?series=22111) that this is not workable in practice to extend this API into 22.07 without fundamental ABI breakage even by using existing versionning framework.
Some existing learnings to be applied here to prevent extension being blocked, hence accouncing changes in bbdev intended for 22.11 to make this more future-proof, including dropping max value from enum, as well as deferring extension of the API for FFT operation into DPDK 22.11.
Let me know if any comments or in case this should be captured differently.
Thanks
Nic
Nicolas Chautru (1):
doc: announce changes in bbdev related to enum extension
doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` [PATCH v4] " Nicolas Chautru
@ 2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
2022-06-09 7:53 0% ` Maxime Coquelin
0 siblings, 2 replies; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:34 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
Intent to resolve in DPDK 22.11 historical usage which prevents
graceful extension of enum and API without troublesome ABI breakage
as well as extending API RTE_BBDEV_OP_FFT for new operation type
in bbdev as well as other new members in existing structures.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c..c8ab1ec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -112,6 +112,17 @@ Deprecation Notices
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``.
+* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
+ enum will be deprecated and instead use fixed array size when required to allow for
+ future enum extension.
+ Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
+ RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
+ New members will be added in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired
+ by this RFC https://patches.dpdk.org/project/dpdk/list/?series=22076
+ New member will be added in ``rte_bbdev_driver_info`` to expose the device status as per
+ this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
+ This should be updated in DPDK 22.11.
+
* security: Hide structure ``rte_security_session`` and expose an opaque
pointer for the private data to the application which can be attached
to the packet while enqueuing.
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` Nicolas Chautru
@ 2022-06-09 5:14 0% ` Hemant Agrawal
2022-06-09 7:53 0% ` Maxime Coquelin
1 sibling, 0 replies; 200+ results
From: Hemant Agrawal @ 2022-06-09 5:14 UTC (permalink / raw)
To: Nicolas Chautru, dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, david.marchand, stephen
> -----Original Message-----
> From: Nicolas Chautru <nicolas.chautru@intel.com>
> Sent: Thursday, June 9, 2022 6:05 AM
> To: dev@dpdk.org; gakhil@marvell.com; thomas@monjalon.net;
> maxime.coquelin@redhat.com
> Cc: trix@redhat.com; ray.kinsella@intel.com; bruce.richardson@intel.com;
> Hemant Agrawal <hemant.agrawal@nxp.com>;
> david.marchand@redhat.com; stephen@networkplumber.org; Nicolas
> Chautru <nicolas.chautru@intel.com>
> Subject: [PATCH v4] doc: announce changes in bbdev related to enum
> extension
> Importance: High
>
> Intent to resolve in DPDK 22.11 historical usage which prevents graceful
> extension of enum and API without troublesome ABI breakage as well as
> extending API RTE_BBDEV_OP_FFT for new operation type in bbdev as well
> as other new members in existing structures.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..c8ab1ec 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -112,6 +112,17 @@ Deprecation Notices
> 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``.
>
> +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the
> +``rte_bbdev_op_type``
> + enum will be deprecated and instead use fixed array size when
> +required to allow for
> + future enum extension.
> + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as
> +per this
> + RFC
> +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> h
> +work.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D22111&da
> ta=05%7
> +C01%7Chemant.agrawal%40nxp.com%7Ce8c1b946f9ba4152d02d08da49b1
> 5297%7C686
> +ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637903323196944926%7C
> Unknown%7C
> +TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI
> +6Mn0%3D%7C3000%7C%7C%7C&sdata=zDwsoIF4tF0eP2py43nwUHUz
> pS3XlDTQDiRMd
> +JxBqwg%3D&reserved=0
> + New members will be added in ``rte_bbdev_driver_info`` to expose PMD
> +queue topology inspired
> + by this RFC
> +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> h
> +es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D22076&data=
> 05%7C0
> +1%7Chemant.agrawal%40nxp.com%7Ce8c1b946f9ba4152d02d08da49b152
> 97%7C686ea
> +1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637903323196944926%7CUn
> known%7CTW
> +FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6M
> +n0%3D%7C3000%7C%7C%7C&sdata=tx8iueWoLEbbCyFQFQHKsvs9nkib
> c0ANem5dyai
> +mspQ%3D&reserved=0
> + New member will be added in ``rte_bbdev_driver_info`` to expose the
> +device status as per
> + this RFC
> +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> h
> +es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D23367&data=
> 05%7C0
> +1%7Chemant.agrawal%40nxp.com%7Ce8c1b946f9ba4152d02d08da49b152
> 97%7C686ea
> +1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637903323196944926%7CUn
> known%7CTW
> +FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6M
> +n0%3D%7C3000%7C%7C%7C&sdata=rHnuL7B63SoFIIo1M4kdRnnDm0
> xqmCwML8CEo%2
> +BsxDBA%3D&reserved=0
> + This should be updated in DPDK 22.11.
> +
> * security: Hide structure ``rte_security_session`` and expose an opaque
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
2022-06-09 0:17 3% ` fengchengwen
@ 2022-06-09 7:05 0% ` Thomas Monjalon
2022-06-10 0:01 3% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-09 7:05 UTC (permalink / raw)
To: fengchengwen
Cc: Andrew Rybchenko, Spike Du, dev, Xiaoyun Li, Aman Singh,
Yuying Zhang, Ferruh Yigit, Ray Kinsella, mdr
09/06/2022 02:17, fengchengwen:
> Hi Thomas,
>
> Could it possible accept the patch ' [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events'
> which was delayed by ABI exceptions like this patch ?
I suppose you refer to this explanation:
+; Ignore ethdev event enum update
+; because new event cannot be received if not registered
That's true we discussed in the past that it should have no effect
on applications compiled with an old version of DPDK.
> PS: I noticed RC-1 was released just now and there may be no window left, but I think since this patch can be an
> exception, why not that patch ?
As far as I remember, the reset and recovery events patch
have other comments to address before it can be accepted.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
@ 2022-06-09 7:53 0% ` Maxime Coquelin
2022-06-17 16:13 0% ` Chautru, Nicolas
1 sibling, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-09 7:53 UTC (permalink / raw)
To: Nicolas Chautru, dev, gakhil, thomas
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen
Hi Nicolas,
On 6/9/22 02:34, Nicolas Chautru wrote:
> Intent to resolve in DPDK 22.11 historical usage which prevents
> graceful extension of enum and API without troublesome ABI breakage
> as well as extending API RTE_BBDEV_OP_FFT for new operation type
> in bbdev as well as other new members in existing structures.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..c8ab1ec 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -112,6 +112,17 @@ Deprecation Notices
> 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``.
>
> +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
> + enum will be deprecated and instead use fixed array size when required to allow for
> + future enum extension.
> + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
> + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
> + New members will be added in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired
> + by this RFC https://patches.dpdk.org/project/dpdk/list/?series=22076
> + New member will be added in ``rte_bbdev_driver_info`` to expose the device status as per
> + this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
> + This should be updated in DPDK 22.11.
> +
> * security: Hide structure ``rte_security_session`` and expose an opaque
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
Thanks for rewording the notice.
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
2022-06-09 7:05 0% ` Thomas Monjalon
@ 2022-06-10 0:01 3% ` fengchengwen
0 siblings, 0 replies; 200+ results
From: fengchengwen @ 2022-06-10 0:01 UTC (permalink / raw)
To: Thomas Monjalon, Kalesh A P
Cc: Andrew Rybchenko, Spike Du, dev, Xiaoyun Li, Aman Singh,
Yuying Zhang, Ferruh Yigit, Ray Kinsella
Hi Thomas,
On 2022/6/9 15:05, Thomas Monjalon wrote:
> 09/06/2022 02:17, fengchengwen:
>> Hi Thomas,
>>
>> Could it possible accept the patch ' [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events'
>> which was delayed by ABI exceptions like this patch ?
>
> I suppose you refer to this explanation:
Yes
>
> +; Ignore ethdev event enum update
> +; because new event cannot be received if not registered
>
> That's true we discussed in the past that it should have no effect
> on applications compiled with an old version of DPDK.
>
>> PS: I noticed RC-1 was released just now and there may be no window left, but I think since this patch can be an
>> exception, why not that patch ?
>
> As far as I remember, the reset and recovery events patch
> have other comments to address before it can be accepted.
Yes, but the ABI exceptions is the primary cause of blockage.
There's two weeks left to fully discuss I think.
We have product requirements for this feature ("device reset and recovery events"), So:
Hi kalesh-anakkur,
Could you please send a new version about it ? If not, do you mind if I re-develop over it ?
>
>
>
> .
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events
2022-05-24 15:11 0% ` Ray Kinsella
@ 2022-06-10 0:16 0% ` fengchengwen
0 siblings, 0 replies; 200+ results
From: fengchengwen @ 2022-06-10 0:16 UTC (permalink / raw)
To: Ray Kinsella
Cc: Thomas Monjalon, Ferruh Yigit, Kalesh A P, dev, ajit.khaparde,
asafp, David Marchand, Andrew Rybchenko, lizhenyi1,
shuliubin 00419723
On 2022/5/24 23:11, Ray Kinsella wrote:
>
> fengchengwen <fengchengwen@huawei.com> writes:
>
>> Hi all,
>>
>> This patch lasts for a long time. Are we waiting for 22.11 to deal with it?
>
> That was my read, as can't reliably change the value of _MAX at this
> stage without it having impact elsewhere.
>
>
>> We have the same requirements for the reset or recovery mechanism, but there are differences:
>>
>> APP PMD
>> | |
>> | detect error
>> | <---report error event--- |
>> | |
>> do error stats |
>> and report |
>> | ---start recover--> |
>> | do recover
>> | <---report recover result |
>> | |
>> if succ just log
>> else may migrate
>> service
>>
>> Can we generalize these processes(means that the implementation is at the framework layer)? or only at PMD API?
>>
>>
>> On 2022/2/15 0:06, Ray Kinsella wrote:
>>>
>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>
>>>> 14/02/2022 11:16, Ray Kinsella:
>>>>> Ray Kinsella <mdr@ashroe.eu> writes:
>>>>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>>>>> 02/02/2022 12:44, Ray Kinsella:
>>>>>>>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>>>>>>>> On 1/28/2022 12:48 PM, Kalesh A P wrote:
>>>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>>>> @@ -3818,6 +3818,24 @@ enum rte_eth_event_type {
>>>>>>>>>> RTE_ETH_EVENT_DESTROY, /**< port is released */
>>>>>>>>>> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */
>>>>>>>>>> RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
>>>>>>>>>> + RTE_ETH_EVENT_ERR_RECOVERING,
>>>>>>>>>> + /**< port recovering from an error
>>>>>>>>>> + *
>>>>>>>>>> + * PMD detected a FW reset or error condition.
>>>>>>>>>> + * PMD will try to recover from the error.
>>>>>>>>>> + * Data path may be quiesced and Control path operations
>>>>>>>>>> + * may fail at this time.
>>>>>>>>>> + */
I think we should standard error reason which could pass to application, so that
application know the really reason. the error reason could as the ret_param of
rte_eth_dev_callback_process().
But I think it could be done later.
>>>>>>>>>> + RTE_ETH_EVENT_RECOVERED,
>>>>>>>>>> + /**< port recovered from an error
>>>>>>>>>> + *
>>>>>>>>>> + * PMD has recovered from the error condition.
>>>>>>>>>> + * Control path and Data path are up now.
>>>>>>>>>> + * PMD re-configures the port to the state prior to the error.
>>>>>>>>>> + * Since the device has undergone a reset, flow rules
>>>>>>>>>> + * offloaded prior to reset may be lost and
>>>>>>>>>> + * the application should recreate the rules again.
>>>>>>>>>> + */
please add RTE_ETH_EVENT_RECOVER_FAIL event, the RTE_ETH_EVENT_INTR_RMV event is
a big event, it has its own usecase. So please add the RECOVER_FAIL event to let
application decide remove or keep it.
>>>>>>>>>> RTE_ETH_EVENT_MAX /**< max value of this enum */
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also ABI check complains about 'RTE_ETH_EVENT_MAX' value check, cc'ed more people
>>>>>>>>> to evaluate if it is a false positive:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1 function with some indirect sub-type change:
>>>>>>>>> [C] 'function int rte_eth_dev_callback_register(uint16_t, rte_eth_event_type, rte_eth_dev_cb_fn, void*)' at rte_ethdev.c:4637:1 has some indirect sub-type changes:
>>>>>>>>> parameter 3 of type 'typedef rte_eth_dev_cb_fn' has sub-type changes:
>>>>>>>>> underlying type 'int (typedef uint16_t, enum rte_eth_event_type, void*, void*)*' changed:
>>>>>>>>> in pointed to type 'function type int (typedef uint16_t, enum rte_eth_event_type, void*, void*)':
>>>>>>>>> parameter 2 of type 'enum rte_eth_event_type' has sub-type changes:
>>>>>>>>> type size hasn't changed
>>>>>>>>> 2 enumerator insertions:
>>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_ERR_RECOVERING' value '11'
>>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_RECOVERED' value '12'
>>>>>>>>> 1 enumerator change:
>>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_MAX' from value '11' to '13' at rte_ethdev.h:3807:1
>>>>>>>>
>>>>>>>> I don't immediately see the problem that this would cause.
>>>>>>>> There are no array sizes etc dependent on the value of MAX for instance.
>>>>>>>>
>>>>>>>> Looks safe?
>>>>>>>
>>>>>>> We never know how this enum will be used by the application.
>>>>>>> The max value may be used for the size of an event array.
>>>>>>> It looks a real ABI issue unfortunately.
>>>>>>
>>>>>> Right - but we only really care about it when an array size based on MAX
>>>>>> is likely to be passed to DPDK, which doesn't apply in this case.
>>>>
>>>> I don't completely agree.
>>>> A developer may assume an event will never exceed MAX value.
>>>> However, after an upgrade of DPDK without app rebuild,
>>>> a higher event value may be received in the app,
>>>> breaking the assumption.
>>>> Should we consider this case as an ABI breakage?
>>>
>>> Nope - I think we should explicitly exclude MAX values from any
>>> ABI guarantee, as being able to change them is key to our be able to
>>> evolve DPDK while maintaining ABI stability.
>>>
>>> Consider what it means applying the ABI policy to a MAX value, you are
>>> in effect saying that that no value can be added to this enumeration
>>> until the next ABI version, for me this is very restrictive without a
>>> solid reason.
>>>
>>>>
>>>>>> I noted that some Linux folks explicitly mark similar MAX values as not
>>>>>> part of the ABI.
>>>>>>
>>>>>> /usr/include/linux/perf_event.h
>>>>>> 37: PERF_TYPE_MAX, /* non-ABI */
>>>>>> 60: PERF_COUNT_HW_MAX, /* non-ABI */
>>>>>> 79: PERF_COUNT_HW_CACHE_MAX, /* non-ABI */
>>>>>> 87: PERF_COUNT_HW_CACHE_OP_MAX, /* non-ABI */
>>>>>> 94: PERF_COUNT_HW_CACHE_RESULT_MAX, /* non-ABI */
>>>>>> 116: PERF_COUNT_SW_MAX, /* non-ABI */
>>>>>> 149: PERF_SAMPLE_MAX = 1U << 24, /* non-ABI */
>>>>>> 151: __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /*
>>>>>> non-ABI; internal use */
>>>>>> 189: PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */
>>>>>> 267: PERF_TXN_MAX = (1 << 8), /* non-ABI */
>>>>>> 301: PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
>>>>>> 1067: PERF_RECORD_MAX, /* non-ABI */
>>>>>> 1078: PERF_RECORD_KSYMBOL_TYPE_MAX /* non-ABI */
>>>>>> 1087: PERF_BPF_EVENT_MAX, /* non-ABI */
>>>>>
>>>>> Any thoughts on similarly annotating all our _MAX enums in the same way?
>>>>> We could also add a section in the ABI Policy to make it explicit _MAX
>>>>> enum values are not part of the ABI - what do folks think?
>>>>
>>>> Interesting. I am not sure it is always ABI-safe though.
>>>
>>>
>
>
^ permalink raw reply [relevance 0%]
* [PATCH v4] sched: enable CMAN at runtime
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2022-06-08 11:59 0% ` Dumitrescu, Cristian
@ 2022-06-13 9:09 1% ` Marcin Danilewicz
2022-06-17 11:48 0% ` Dumitrescu, Cristian
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
1 sibling, 2 replies; 200+ results
From: Marcin Danilewicz @ 2022-06-13 9:09 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 8eb29c1525..1740a1d053 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-#undef RTE_SCHED_CMAN
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [PATCH v7] eal: add bus cleanup to eal cleanup
2022-06-07 15:12 3% ` David Marchand
@ 2022-06-13 15:58 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-06-13 15:58 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, Kevin Laatz, dev, Morten Brørup, Li Zhang,
Matan Azrad, Stephen Hemminger, lihuisong
On Tue, Jun 07, 2022 at 05:12:02PM +0200, David Marchand wrote:
> On Tue, Jun 7, 2022 at 1:09 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 03/06/2022 16:36, Kevin Laatz:
> > > During EAL init, all buses are probed and the devices found are
> > > initialized. On eal_cleanup(), the inverse does not happen, meaning any
> > > allocated memory and other configuration will not be cleaned up
> > > appropriately on exit.
> > [...]
> > > --- a/devtools/libabigail.abignore
> > > +++ b/devtools/libabigail.abignore
> > > @@ -56,3 +56,12 @@
> > > ; Ignore libabigail false-positive in clang builds, after moving code.
> > > [suppress_function]
> > > name = rte_eal_remote_launch
> > > +
> > > +; Ignore field inserted to rte_bus, adding cleanup function
> > > +[suppress_type]
> > > + name = rte_bus
> > > + has_data_member_inserted_at = end
> > > +
> > > +; Ignore changes to internally used structs containing rte_bus
> > > +[suppress_type]
> > > + name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus
>
> (This change is strange as there is no rte_vdev_bus type, but I won't
> investigate the relevance of this rule for now).
>
> >
> > I'm not sure we can safely consider these structs as internal.
> > The right process is to send a deprecation notice,
> > and then remove them from the public API.
>
> Same for me, I don't think we can safely ignore.
>
> A rte_bus struct is embedded in rte_pci_bus (resp. rte_vmbus_bus).
> If we make it grow, any inlined access (like walk in device_list or
> driver_list) after the rte_bus object is broken for code accessing it
> out of DPDK.
> Such code might exist out there, since we expose
> FOREACH_DEVICE_ON_PCIBUS, for example.
>
>
> >
> > For info, Li has sent a patch for the bus cleanup
> > which is not updating the bus code:
> > https://patches.dpdk.org/project/dpdk/patch/20220606114650.209612-3-lizh@nvidia.com/
> > It may be a temporary solution before the deprecation.
>
> On the principle, that's probably the best, there is no question about
> unclear frontier of the ABI.
> (In practice though, the mentionned patch is triggering segfaults in
> two CI, for pdump).
>
> Hiding rte_bus object should be straightforward in v22.11, I had some
> patches, but never finished the work.
>
> It would be great too, to look into rte_driver and rte_device which
> are exposed important types, but that's another story.
>
Agreed, we need to look into all this for 22.11 release, let's defer this
patch until we get proper deprecation process. Temporary patch looks fine
as a fix too.
/Bruce
^ permalink raw reply [relevance 0%]
* [PATCH v1] bbdev: allow operation type enum for growth
@ 2022-06-13 18:24 4% Nicolas Chautru
0 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-13 18:24 UTC (permalink / raw)
To: dev, thomas
Cc: maxime.coquelin, trix, mdr, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
Hi Thomas,
I would like to get your view on this topic and best recommendation moving forward.
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Note: Such a change is aimed for 22.11.
Thanks and regards,
Nic
Nicolas Chautru (1):
bbdev: allow operation type enum for growth
lib/bbdev/rte_bbdev.c | 5 ++++-
lib/bbdev/rte_bbdev_op.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* RE: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-02 22:53 0% ` Ferruh Yigit
@ 2022-06-14 8:49 3% ` Kevin Liu
2022-06-14 9:21 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Kevin Liu @ 2022-06-14 8:49 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: Niklas Soderlund, Diana Wang, Nole Zhang, Chaoyong He
We also want to just use one function 'nfp_net_tx_queue_release()' to service both NFD3 and NFDk, But we can not get the version of NFD in function 'nfp_net_tx_queue_release()', now get NFD version through 'hw->ver'
For the function 'nfp_net_ethdev_ops_mount()', the logic below is in two different C files, nfp_ethdev.c and nfp_ethdev_vf.c And the variable of struct eth_dev_ops is defined as static, if we want to use function both in nfp_ethdev.c and nfp_ethdev_vf.c We need to change the eth_dev_ops variable as non-static, this is not we want.
> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> + case NFP_NET_CFG_VERSION_DP_NFD3:
> + break;
> + case NFP_NET_CFG_VERSION_DP_NFDK:
> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> + return -EINVAL;
> + }
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> + return -EINVAL;
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
Sent: Friday, June 3, 2022 06:54
To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
On 6/2/2022 2:52 AM, Jin Liu wrote:
> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment,
> will according to the firmware version, mount different driver functions.
>
Creating a new set of dev_ops for new FW is a way and it works, but it looks like it creates some duplication of the code, and maintaining multiple dev_ops can be difficult (driver already has different ones for PF & VF).
Another option can be keeping ethdev interface same, but manage different FWs closer to FW, where directly interacted with FW.
Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing different FW within this function, instead of having two dev_ops, 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
If difference is small, this can be better to reduce duplication.
What is the difference between two FWs, as far as I can see Tx descriptor is different and queue setup is affected, is it only diff?
> Signed-off-by: Jin Liu <jin.liu@corigine.com>
> Signed-off-by: Diana Wang <na.wang@corigine.com>
> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
<...>
> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>
> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
> + if (hw->ctrl_bar == NULL) {
> + PMD_DRV_LOG(ERR,
> + "hw->ctrl_bar is NULL. BAR0 not configured");
> + return -ENODEV;
> + }
> +
> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
> +
> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
> +
> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> + case NFP_NET_CFG_VERSION_DP_NFD3:
> + break;
> + case NFP_NET_CFG_VERSION_DP_NFDK:
> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> + return -EINVAL;
> + }
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> + return -EINVAL;
> + }
> +
This part seems extracted to its own function for PF ('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same logic between them.
^ permalink raw reply [relevance 3%]
* Re: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-14 8:49 3% ` Kevin Liu
@ 2022-06-14 9:21 0% ` Ferruh Yigit
2022-06-14 9:30 0% ` Kevin Liu
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-06-14 9:21 UTC (permalink / raw)
To: Kevin Liu, dev; +Cc: Niklas Soderlund, Diana Wang, Nole Zhang, Chaoyong He
On 6/14/2022 9:49 AM, Kevin Liu wrote:
> We also want to just use one function 'nfp_net_tx_queue_release()' to service both NFD3 and NFDk, But we can not get the version of NFD in function 'nfp_net_tx_queue_release()', now get NFD version through 'hw->ver'
>
Again, it is up to you, but it should be possible to add 'dev' or 'hw'
reference to the queue struct, to be able to access the version information.
And it can be possible to have something like 'struct fw_ops', set it
during initialization and use in rest of the dev_ops.
> For the function 'nfp_net_ethdev_ops_mount()', the logic below is in two different C files, nfp_ethdev.c and nfp_ethdev_vf.c And the variable of struct eth_dev_ops is defined as static, if we want to use function both in nfp_ethdev.c and nfp_ethdev_vf.c We need to change the eth_dev_ops variable as non-static, this is not we want.
>
> > + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> > + case NFP_NET_CFG_VERSION_DP_NFD3:
> > + break;
> > + case NFP_NET_CFG_VERSION_DP_NFDK:
> > + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> > + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> > + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> > + return -EINVAL;
> > + }
> > + break;
> > + default:
> > + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> > + return -EINVAL;
>
My comment was to extract the logic into its own function as it is done
is PF, so to have something like 'nfp_netvf_ethdev_ops_mount()'.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> Sent: Friday, June 3, 2022 06:54
> To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
> Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
> Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
>
> On 6/2/2022 2:52 AM, Jin Liu wrote:
>> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment,
>> will according to the firmware version, mount different driver functions.
>>
>
> Creating a new set of dev_ops for new FW is a way and it works, but it looks like it creates some duplication of the code, and maintaining multiple dev_ops can be difficult (driver already has different ones for PF & VF).
>
> Another option can be keeping ethdev interface same, but manage different FWs closer to FW, where directly interacted with FW.
> Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing different FW within this function, instead of having two dev_ops, 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
> If difference is small, this can be better to reduce duplication.
>
> What is the difference between two FWs, as far as I can see Tx descriptor is different and queue setup is affected, is it only diff?
>
>> Signed-off-by: Jin Liu <jin.liu@corigine.com>
>> Signed-off-by: Diana Wang <na.wang@corigine.com>
>> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>
> <...>
>
>> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
>> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
>> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>>
>> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
>> + if (hw->ctrl_bar == NULL) {
>> + PMD_DRV_LOG(ERR,
>> + "hw->ctrl_bar is NULL. BAR0 not configured");
>> + return -ENODEV;
>> + }
>> +
>> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
>> +
>> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
>> +
>> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
>> + case NFP_NET_CFG_VERSION_DP_NFD3:
>> + break;
>> + case NFP_NET_CFG_VERSION_DP_NFDK:
>> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
>> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
>> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
>> + return -EINVAL;
>> + }
>> + break;
>> + default:
>> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
>> + return -EINVAL;
>> + }
>> +
>
> This part seems extracted to its own function for PF ('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same logic between them.
>
>
^ permalink raw reply [relevance 0%]
* RE: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-14 9:21 0% ` Ferruh Yigit
@ 2022-06-14 9:30 0% ` Kevin Liu
0 siblings, 0 replies; 200+ results
From: Kevin Liu @ 2022-06-14 9:30 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: Niklas Soderlund, Diana Wang, Nole Zhang, Chaoyong He
Now, I modify logic, just keep 'nfp_net_tx_queue_release()', delete 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'
>>> My comment was to extract the logic into its own function as it is done is PF, so to have something like 'nfp_netvf_ethdev_ops_mount()'.
the logic I just use once in nfp_ethdev_vf.c, so not create a function. I will create 'nfp_netvf_ethdev_ops_mount()' in nfp_ethdev_vf.c later
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
Sent: Tuesday, June 14, 2022 17:22
To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
On 6/14/2022 9:49 AM, Kevin Liu wrote:
> We also want to just use one function 'nfp_net_tx_queue_release()' to service both NFD3 and NFDk, But we can not get the version of NFD in function 'nfp_net_tx_queue_release()', now get NFD version through 'hw->ver'
>
Again, it is up to you, but it should be possible to add 'dev' or 'hw'
reference to the queue struct, to be able to access the version information.
And it can be possible to have something like 'struct fw_ops', set it during initialization and use in rest of the dev_ops.
> For the function 'nfp_net_ethdev_ops_mount()', the logic below is in two different C files, nfp_ethdev.c and nfp_ethdev_vf.c And the variable of struct eth_dev_ops is defined as static, if we want to use function both in nfp_ethdev.c and nfp_ethdev_vf.c We need to change the eth_dev_ops variable as non-static, this is not we want.
>
> > + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> > + case NFP_NET_CFG_VERSION_DP_NFD3:
> > + break;
> > + case NFP_NET_CFG_VERSION_DP_NFDK:
> > + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> > + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> > + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> > + return -EINVAL;
> > + }
> > + break;
> > + default:
> > + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> > + return -EINVAL;
>
My comment was to extract the logic into its own function as it is done is PF, so to have something like 'nfp_netvf_ethdev_ops_mount()'.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> Sent: Friday, June 3, 2022 06:54
> To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
> Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
> Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
>
> On 6/2/2022 2:52 AM, Jin Liu wrote:
>> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment,
>> will according to the firmware version, mount different driver functions.
>>
>
> Creating a new set of dev_ops for new FW is a way and it works, but it looks like it creates some duplication of the code, and maintaining multiple dev_ops can be difficult (driver already has different ones for PF & VF).
>
> Another option can be keeping ethdev interface same, but manage different FWs closer to FW, where directly interacted with FW.
> Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing different FW within this function, instead of having two dev_ops, 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
> If difference is small, this can be better to reduce duplication.
>
> What is the difference between two FWs, as far as I can see Tx descriptor is different and queue setup is affected, is it only diff?
>
>> Signed-off-by: Jin Liu <jin.liu@corigine.com>
>> Signed-off-by: Diana Wang <na.wang@corigine.com>
>> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>
> <...>
>
>> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
>> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
>> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>>
>> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
>> + if (hw->ctrl_bar == NULL) {
>> + PMD_DRV_LOG(ERR,
>> + "hw->ctrl_bar is NULL. BAR0 not configured");
>> + return -ENODEV;
>> + }
>> +
>> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
>> +
>> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
>> +
>> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
>> + case NFP_NET_CFG_VERSION_DP_NFD3:
>> + break;
>> + case NFP_NET_CFG_VERSION_DP_NFDK:
>> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
>> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
>> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
>> + return -EINVAL;
>> + }
>> + break;
>> + default:
>> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
>> + return -EINVAL;
>> + }
>> +
>
> This part seems extracted to its own function for PF ('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same logic between them.
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] build: ccache support for cross build
2022-06-08 17:13 3% ` [dpdk-dev] [PATCH v2] " jerinj
@ 2022-06-14 16:01 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-14 16:01 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, Jan Viktorin, Ruifeng Wang, Bruce Richardson,
David Christensen, Stanislaw Kardach, Konstantin Ananyev,
david.marchand, juraj.linkes, fengchengwen
08/06/2022 19:13, jerinj@marvell.com:
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -160,7 +160,8 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
> if [ -n "$crossfile" ] ; then
> cross="--cross-file $crossfile"
> targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
> - $crossfile | tr -d "'" | tr -d '"')
> + $crossfile | cut -d ',' -f 2 | \
> + tr -d "'" | tr -d '"' | tr -d ']' | tr -d ' ')
The last line can be shortened to
tr -d "'"'"] '
I'll change while merging.
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/5] usertools: use non-strict when json-loads in telemetry
@ 2022-06-15 18:01 3% ` Morten Brørup
2022-06-15 20:09 0% ` Morten Brørup
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-15 18:01 UTC (permalink / raw)
To: Bruce Richardson, Ciara Power, Chengwen Feng
Cc: thomas, ferruh.yigit, kevin.laatz, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
+CC Ciara Power, Telemetry lib maintainer
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 15 June 2022 18.55
>
> On Wed, Jun 15, 2022 at 03:54:57PM +0200, Morten Brørup wrote:
> > > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > Sent: Wednesday, 15 June 2022 09.39
> > >
> > > Use 'strict=False' in json-loads, it will ignore control characters
> > > (e.g. '\n\t'), this patch is prepared for the support of telemetry
> dump
> > > in the future.
> > >
> > > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > ---
> > > usertools/dpdk-telemetry.py | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/usertools/dpdk-telemetry.py b/usertools/dpdk-
> telemetry.py
> > > index a81868a547..63f8004566 100755
> > > --- a/usertools/dpdk-telemetry.py
> > > +++ b/usertools/dpdk-telemetry.py
> > > @@ -27,7 +27,7 @@ def read_socket(sock, buf_len, echo=True):
> > > """ Read data from socket and return it in JSON format """
> > > reply = sock.recv(buf_len).decode()
> > > try:
> > > - ret = json.loads(reply)
> > > + ret = json.loads(reply, strict=False)
> > > except json.JSONDecodeError:
> > > print("Error in reply: ", reply)
> > > sock.close()
> > > --
> > > 2.33.0
> > >
> >
> > As I understand this patch, it accepts non-JSON data from the
> telemetry socket.
> >
> > Isn't it is a major protocol violation if the telemetry socket
> produces output requiring this modification? Doing that would break
> other applications expecting strictly JSON formatted output from the
> telemetry socket.
> >
>
> I would tend to agree.
>
> As an alternative, I think you should add to the telemetry library an
> "escape string" function which can then be used by the telemetry
> functions
> to properly json encode the strings back from the dump functions before
> sending them out.
Instead of adding a separate JSON encode function, the rte_tel_data_string() and rte_tel_data_add_array_string() functions should simply JSON encode the provided strings if required. Their descriptions do not mention any requirements to the strings provided, and being control plane functions, I would certainly expect them to JSON encode.
Warning: Although I consider such a change a bugfix, others might consider it an ABI breakage. :-(
@Ciara, what is your opinion about my suggestion here?
For minimal changes, RTE_TEL_MAX_STRING_LEN and RTE_TEL_MAX_SINGLE_STRING_LEN should keep their meaning, i.e. define the maximum length of the string after any JSON encoding.
And optionally, new rte_tel_data_[array_]string_raw() performance optimized functions could be provided for strings known not to require any encoding.
^ permalink raw reply [relevance 3%]
* RE: [PATCH 1/5] usertools: use non-strict when json-loads in telemetry
2022-06-15 18:01 3% ` Morten Brørup
@ 2022-06-15 20:09 0% ` Morten Brørup
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-15 20:09 UTC (permalink / raw)
To: Bruce Richardson, Ciara Power, Chengwen Feng
Cc: thomas, ferruh.yigit, kevin.laatz, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
> From: Morten Brørup
> Sent: Wednesday, 15 June 2022 20.01
>
> +CC Ciara Power, Telemetry lib maintainer
>
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 15 June 2022 18.55
> >
> > On Wed, Jun 15, 2022 at 03:54:57PM +0200, Morten Brørup wrote:
> > > > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > > Sent: Wednesday, 15 June 2022 09.39
> > > >
> > > > Use 'strict=False' in json-loads, it will ignore control
> characters
> > > > (e.g. '\n\t'), this patch is prepared for the support of
> telemetry
> > dump
> > > > in the future.
> > > >
> > > > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > > ---
> > > > usertools/dpdk-telemetry.py | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/usertools/dpdk-telemetry.py b/usertools/dpdk-
> > telemetry.py
> > > > index a81868a547..63f8004566 100755
> > > > --- a/usertools/dpdk-telemetry.py
> > > > +++ b/usertools/dpdk-telemetry.py
> > > > @@ -27,7 +27,7 @@ def read_socket(sock, buf_len, echo=True):
> > > > """ Read data from socket and return it in JSON format """
> > > > reply = sock.recv(buf_len).decode()
> > > > try:
> > > > - ret = json.loads(reply)
> > > > + ret = json.loads(reply, strict=False)
> > > > except json.JSONDecodeError:
> > > > print("Error in reply: ", reply)
> > > > sock.close()
> > > > --
> > > > 2.33.0
> > > >
> > >
> > > As I understand this patch, it accepts non-JSON data from the
> > telemetry socket.
> > >
> > > Isn't it is a major protocol violation if the telemetry socket
> > produces output requiring this modification? Doing that would break
> > other applications expecting strictly JSON formatted output from the
> > telemetry socket.
> > >
> >
> > I would tend to agree.
> >
> > As an alternative, I think you should add to the telemetry library an
> > "escape string" function which can then be used by the telemetry
> > functions
> > to properly json encode the strings back from the dump functions
> before
> > sending them out.
>
> Instead of adding a separate JSON encode function, the
> rte_tel_data_string() and rte_tel_data_add_array_string() functions
> should simply JSON encode the provided strings if required. Their
> descriptions do not mention any requirements to the strings provided,
> and being control plane functions, I would certainly expect them to
> JSON encode.
>
> Warning: Although I consider such a change a bugfix, others might
> consider it an ABI breakage. :-(
>
> @Ciara, what is your opinion about my suggestion here?
>
> For minimal changes, RTE_TEL_MAX_STRING_LEN and
> RTE_TEL_MAX_SINGLE_STRING_LEN should keep their meaning, i.e. define
> the maximum length of the string after any JSON encoding.
>
> And optionally, new rte_tel_data_[array_]string_raw() performance
> optimized functions could be provided for strings known not to require
> any encoding.
Forget my suggestion above!!! It would mess up the telemetry database, which could be used for SNMP too, and thus should not be JSON formatted.
Any JSON encoding needs to happen in the presentation layer, which seems to reside in /lib/telemetry/telemetry.c, and it looks like it already does JSON encode strings, except the rte_tel_json_str() function and friends in /lib/telemetry/telemetry_json.h don't implement it.
So the bug is in the JSON string functions in /lib/telemetry/telemetry_json.h: Their descriptions say that they take a string and copy it into a buffer in JSON format, which I interpret as JSON encoding. But they don't JSON encode the string. I have filed a bug in Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1037
^ permalink raw reply [relevance 0%]
* [PATCH v2 09/15] net/nfp: support firmware with NFDk
@ 2022-06-16 2:39 6% ` Jin Liu
1 sibling, 0 replies; 200+ results
From: Jin Liu @ 2022-06-16 2:39 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
drivers/net/nfp/nfp_ctrl.h | 2 ++
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++++++-------
drivers/net/nfp/nfp_ethdev_vf.c | 53 ++++++++++++++++++++++++---------
3 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index cb84dc3188..1bbba9187e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -402,11 +428,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -441,6 +462,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -473,7 +499,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -939,6 +964,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -988,11 +1014,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"secondary process attach failed, ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index c46ee0f913..0b4660aba6 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -265,6 +265,32 @@ static const struct eth_dev_ops nfp_netvf_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_netvf_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_netvf_init(struct rte_eth_dev *eth_dev)
{
@@ -292,10 +318,19 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
- eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_netvf_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -313,15 +348,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -354,7 +380,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
--
2.27.0
^ permalink raw reply [relevance 6%]
* Re: [PATCH v1] bbdev: allow operation type enum for growth
@ 2022-06-17 8:21 3% ` Thomas Monjalon
2022-06-17 16:12 0% ` Chautru, Nicolas
2022-06-23 16:09 0% ` Ray Kinsella
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2022-06-17 8:21 UTC (permalink / raw)
To: Nicolas Chautru
Cc: dev, maxime.coquelin, trix, mdr, bruce.richardson,
hemant.agrawal, david.marchand, stephen, techboard
This solution is what I proposed to the techboard some years ago,
but the preference was to completely remove the MAX values.
13/06/2022 20:24, Nicolas Chautru:
> Updating the last enum for rte_bbdev_op_type
> to allow for enum insertion.
Please explain that the reason is to keep ABI compatible,
and you want to keep the MAX value for array needs.
> --- a/lib/bbdev/rte_bbdev.c
> +++ b/lib/bbdev/rte_bbdev.c
> @@ -1122,7 +1122,10 @@ struct rte_mempool *
> "RTE_BBDEV_OP_TURBO_DEC",
> "RTE_BBDEV_OP_TURBO_ENC",
> "RTE_BBDEV_OP_LDPC_DEC",
> - "RTE_BBDEV_OP_LDPC_ENC",
> + "RTE_BBDEV_OP_RESERVED_1",
> + "RTE_BBDEV_OP_RESERVED_2",
> + "RTE_BBDEV_OP_RESERVED_3",
> + "RTE_BBDEV_OP_RESERVED_4",
As Stephen said, you should make sure that using these values
with the API functions will lead to a clear and expected error.
> @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
> RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
> RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
> RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
> - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
> + RTE_BBDEV_OP_TYPE_COUNT = 8, /**< Count of different op types */
You must update the comment to explain there may be a padding,
it is not exactly the count.
Maybe "MAX" is a better fit than "COUNT" in this case.
^ permalink raw reply [relevance 3%]
* [PATCH v3 07/13] net/nfp: support firmware with NFDk
@ 2022-06-17 9:34 5% ` Jin Liu
1 sibling, 0 replies; 200+ results
From: Jin Liu @ 2022-06-17 9:34 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
doc/guides/nics/nfp.rst | 7 ++--
doc/guides/rel_notes/release_22_07.rst | 1 +
drivers/net/nfp/nfp_ctrl.h | 2 +
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++-----
drivers/net/nfp/nfp_ethdev_vf.c | 53 +++++++++++++++++++-------
5 files changed, 85 insertions(+), 27 deletions(-)
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index dcefac3ef6..55539accc2 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -100,9 +100,10 @@ more than one SmartNIC, same type of SmartNIC or different ones, and to upload a
different firmware to each SmartNIC.
.. Note::
- Currently the NFP PMD supports using the PF with Agilio Basic Firmware. See
- https://help.netronome.com/support/solutions for more information on the
- various firmwares supported by the Netronome Agilio CX smartNIC.
+ Currently the NFP PMD supports using the PF with Agilio Firmware with NFD3
+ and Agilio Firmware with NFDk. See https://help.netronome.com/support/solutions
+ for more information on the various firmwares supported by the Netronome
+ Agilio CX smartNIC.
PF multiport support
--------------------
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index d5d8c735b1..64308e6c1a 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -111,6 +111,7 @@ New Features
* **Updated Netronome nfp driver.**
* Added support for NFP3800 NIC.
+ * Added support for firmware with NFDk.
* **Updated VMware vmxnet3 networking driver.**
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index cb84dc3188..1bbba9187e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -402,11 +428,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -441,6 +462,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -473,7 +499,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -939,6 +964,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -988,11 +1014,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"secondary process attach failed, ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index c46ee0f913..0b4660aba6 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -265,6 +265,32 @@ static const struct eth_dev_ops nfp_netvf_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_netvf_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_netvf_init(struct rte_eth_dev *eth_dev)
{
@@ -292,10 +318,19 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
- eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_netvf_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -313,15 +348,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -354,7 +380,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
--
2.27.0
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 0/6] Vhost checksum offload improvements
2022-06-08 12:49 3% [PATCH v2 0/6] Vhost checksum offload improvements Maxime Coquelin
@ 2022-06-17 14:06 0% ` Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2022-06-17 14:06 UTC (permalink / raw)
To: dev, jasowang, chenbo.xia, david.marchand, olivier.matz,
wenwux.ma, yuying.zhang, aman.deep.singh
On 6/8/22 14:49, Maxime Coquelin wrote:
> This series aims at improving Vhost checksum offloading
> support.
>
> The first patch reverts overwritting MAC address in
> testpmd CSUM forward mode. This is required to be able to
> test checksum offloading with real traffic. MAC forwarding
> mode should be used if the MAC addresses need to be
> changed.
>
> Second patch is a Vhost library fix to be compliant with
> the Virtio specification, which requires that the
> pseudo-header checksum is being set by the device when
> offloading the checksum to the guest.
>
> Third patch enables the compliant offloading mode of Vhost
> library in Vhost PMD by default, since the legacy mode
> violates the mbuf API by setting Tx flags in the receive
> path. A new devarg is introduced for application willing
> to use the legacy mode.
>
> Fourth patch is just a small cleanup to represent a boolean
> value as a boolean.
>
> The two last patches introduces compatibility layers
> that performs checksum in SW when the ethdev and Virtio
> features are not aligned.
>
> Note that the two last patches are not tagged as fixes
> because they rely on the new compliant offload mode of
> Vhost library, and so would casue an ABI breakage if
> backported.
>
> With this series, it is now possible to perform IO
> forwarding between a vhost-user port and a Vitio-user
> with kernel backend port even if the guest has negotiated
> VIRTIO_NET_F_CSUM.
>
> With csum forward mode, it now works whathever the
> offloading configuration set either on Virtio or Ethdev
> sides.
>
> Changes in v2:
> ==============
> - Add the new devarg to validation array (Wenwu)
> - Fix typos in commit messages (Chenbo, checkpatch, Yuying)
>
> Maxime Coquelin (6):
> Revert "app/testpmd: modify mac in csum forwarding"
> vhost: fix missing enqueue pseudo-header calculation
> net/vhost: enable compliant offloading mode
> net/vhost: make VLAN stripping flag a boolean
> net/vhost: perform SW checksum in Rx path
> net/vhost: perform SW checksum in Tx path
>
> app/test-pmd/csumonly.c | 4 -
> doc/guides/nics/features/vhost.ini | 1 +
> doc/guides/nics/vhost.rst | 6 ++
> drivers/net/vhost/rte_eth_vhost.c | 167 ++++++++++++++++++++++++++++-
> lib/vhost/virtio_net.c | 10 ++
> 5 files changed, 180 insertions(+), 8 deletions(-)
>
Applied to dpdk-next-virtio/main.
Thanks,
Maxime
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] sched: enable CMAN at runtime
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
@ 2022-06-17 11:48 0% ` Dumitrescu, Cristian
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
1 sibling, 0 replies; 200+ results
From: Dumitrescu, Cristian @ 2022-06-17 11:48 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Monday, June 13, 2022 10:09 AM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v4] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> Log: v2 change in rte_sched.h to avoid ABI breakage.
> v3 changes from comments
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 11 +-
> examples/qos_sched/cfg_file.h | 2 -
> examples/qos_sched/init.c | 4 -
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 130 ++++++++++-----------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 47 +-------
> 11 files changed, 359 insertions(+), 141 deletions(-)
> create mode 100644 examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
Marcin,
Code changes look good to me, but still not able to cleanly apply this patch on top of DPDK latest with git am, can you please make sure this gets fixed?
Applying: sched: enable CMAN at runtime
error: patch failed: config/rte_config.h:88
error: config/rte_config.h: patch does not apply
Patch failed at 0001 sched: enable CMAN at runtime
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Regards,
Cristian
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 7:53 0% ` Maxime Coquelin
@ 2022-06-17 16:13 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-06-17 16:13 UTC (permalink / raw)
To: dev, thomas
Cc: trix, Kinsella, Ray, Richardson, Bruce, hemant.agrawal,
david.marchand, stephen, Maxime Coquelin, gakhil
Hi Thomas,
Can this one be applied based on your review?
Thanks
Nic
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Thursday, June 9, 2022 12:54 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> gakhil@marvell.com; thomas@monjalon.net
> Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; hemant.agrawal@nxp.com;
> david.marchand@redhat.com; stephen@networkplumber.org
> Subject: Re: [PATCH v4] doc: announce changes in bbdev related to enum
> extension
>
> Hi Nicolas,
>
> On 6/9/22 02:34, Nicolas Chautru wrote:
> > Intent to resolve in DPDK 22.11 historical usage which prevents
> > graceful extension of enum and API without troublesome ABI breakage as
> > well as extending API RTE_BBDEV_OP_FFT for new operation type in bbdev
> > as well as other new members in existing structures.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 4e5b23c..c8ab1ec 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -112,6 +112,17 @@ Deprecation Notices
> > 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``.
> >
> > +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the
> > +``rte_bbdev_op_type``
> > + enum will be deprecated and instead use fixed array size when
> > +required to allow for
> > + future enum extension.
> > + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT``
> > +as per this
> > + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
> > + New members will be added in ``rte_bbdev_driver_info`` to expose
> > +PMD queue topology inspired
> > + by this RFC
> > +https://patches.dpdk.org/project/dpdk/list/?series=22076
> > + New member will be added in ``rte_bbdev_driver_info`` to expose the
> > +device status as per
> > + this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
> > + This should be updated in DPDK 22.11.
> > +
> > * security: Hide structure ``rte_security_session`` and expose an opaque
> > pointer for the private data to the application which can be attached
> > to the packet while enqueuing.
>
> Thanks for rewording the notice.
>
> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>
> Maxime
^ permalink raw reply [relevance 0%]
* RE: [PATCH v1] bbdev: allow operation type enum for growth
2022-06-17 8:21 3% ` Thomas Monjalon
@ 2022-06-17 16:12 0% ` Chautru, Nicolas
2022-06-23 16:09 0% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-06-17 16:12 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, maxime.coquelin, trix, mdr, Richardson, Bruce,
hemant.agrawal, david.marchand, stephen, techboard
> From: Thomas Monjalon <thomas@monjalon.net>
>
> This solution is what I proposed to the techboard some years ago, but the
> preference was to completely remove the MAX values.
>
Thanks, good to see you had similar thought! I don't believe there is an actual recommendation captured in term of how to remove completely MAX values in that case below. I believe that this option is still compatible with the spirit of keeping AB future proof.
>
> 13/06/2022 20:24, Nicolas Chautru:
> > Updating the last enum for rte_bbdev_op_type to allow for enum
> > insertion.
>
> Please explain that the reason is to keep ABI compatible, and you want to keep
> the MAX value for array needs.
>
> > --- a/lib/bbdev/rte_bbdev.c
> > +++ b/lib/bbdev/rte_bbdev.c
> > @@ -1122,7 +1122,10 @@ struct rte_mempool *
> > "RTE_BBDEV_OP_TURBO_DEC",
> > "RTE_BBDEV_OP_TURBO_ENC",
> > "RTE_BBDEV_OP_LDPC_DEC",
> > - "RTE_BBDEV_OP_LDPC_ENC",
> > + "RTE_BBDEV_OP_RESERVED_1",
> > + "RTE_BBDEV_OP_RESERVED_2",
> > + "RTE_BBDEV_OP_RESERVED_3",
> > + "RTE_BBDEV_OP_RESERVED_4",
>
> As Stephen said, you should make sure that using these values with the API
> functions will lead to a clear and expected error.
Yes will do this.
>
> > @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
> > RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
> > RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
> > RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
> > - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
> > + RTE_BBDEV_OP_TYPE_COUNT = 8, /**< Count of different op types */
>
> You must update the comment to explain there may be a padding, it is not
> exactly the count.
> Maybe "MAX" is a better fit than "COUNT" in this case.
>
OK
^ permalink raw reply [relevance 0%]
* [PATCH v2 0/5] bbdev changes for 22.11
@ 2022-06-17 18:37 4% ` Nicolas Chautru
2022-06-17 18:37 3% ` [PATCH v2 1/5] bbdev: allow operation type enum for growth Nicolas Chautru
0 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-17 18:37 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Hi,
Agregating together in a single serie a number of bbdev api changes previously submitted over the last few months and all targeted for 22.11 (4 different series detailed below). Related deprecation notice being pushed in 22.07 in parallel.
* bbdev: add device status info
* bbdev: add new operation for FFT processing
* bbdev: add device info on queue topology
* bbdev: allow operation type enum for growth
v2: Update to the RTE_BBDEV_COUNT removal based on feedback from Thomas/Stephen : rejecting out of range op type and adjusting the new name for the padded maximum value used for fixed size arrays.
---
Previous cover letters agregated below:
* bbdev: add device status info
https://patches.dpdk.org/project/dpdk/list/?series=23367
The updated structure will allow PMDs to expose through info_get what be may the status of the underlying accelerator, notably in case an HW error event having happened.
* bbdev: add new operation for FFT processing
https://patches.dpdk.org/project/dpdk/list/?series=22111
This contribution adds a new operation type to the existing ones already supported by the bbdev PMDs.
This set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental).
I plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test.
* bbdev: add device info on queue topology
https://patches.dpdk.org/project/dpdk/list/?series=22076
Addressing an historical concern that the device info struct only
imperfectly captured what queues are available on the device
(number of operation and priority). This ended up being an iterative
process for application to find each queue could be configured.
ie. the gap was captured as technical debt previously in comments
/* This isn't ideal because it reports the maximum number of queues but
* does not provide info on how many can be uplink/downlink or different
* priorities
*/
This is now being exposed explictly based on the what the device actually
supports using the existing info_get api
* bbdev: allow operation type enum for growth
https://patches.dpdk.org/project/dpdk/list/?series=23509
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Nicolas Chautru (5):
bbdev: allow operation type enum for growth
bbdev: add device status info
bbdev: add device info on queue topology
drivers/baseband: update PMDs to expose queue per operation
bbdev: add new operation for FFT processing
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 +-
doc/guides/prog_guide/bbdev.rst | 130 ++++++++++++++++++
drivers/baseband/acc100/rte_acc100_pmd.c | 30 ++--
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 9 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 9 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 10 +-
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 12 ++
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 37 ++++-
lib/bbdev/rte_bbdev.h | 115 +++++++++++++++-
lib/bbdev/rte_bbdev_op.h | 151 ++++++++++++++++++++-
lib/bbdev/version.map | 10 ++
14 files changed, 499 insertions(+), 23 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [PATCH v2 1/5] bbdev: allow operation type enum for growth
2022-06-17 18:37 4% ` [PATCH v2 0/5] bbdev changes for 22.11 Nicolas Chautru
@ 2022-06-17 18:37 3% ` Nicolas Chautru
0 siblings, 0 replies; 200+ results
From: Nicolas Chautru @ 2022-06-17 18:37 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Updating the enum for rte_bbdev_op_type
to allow to keep ABI compatible for enum insertion
while adding padded maximum value for array need.
Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
RTE_BBDEV_OP_TYPE_PADDED_MAX.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 ++--
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 9 +++++----
lib/bbdev/rte_bbdev_op.h | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index ac06d73..1063f6e 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
rte_mempool_free(mp);
TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
- RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
+ RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) == NULL,
"Failed test for rte_bbdev_op_pool_create: "
"returned value is not NULL for invalid type");
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index fad3b1e..1abda2d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device *ad,
/* Find capabilities */
const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
- for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
+ do {
if (cap->type == test_vector.op_type) {
capabilities = cap;
break;
}
cap++;
- }
+ } while (cap->type != RTE_BBDEV_OP_NONE);
TEST_ASSERT_NOT_NULL(capabilities,
"Couldn't find capabilities");
diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fc7e8b8..ef0ba76 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
void *sigret;
struct app_config_params app_params = def_app_config;
struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
- struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
+ struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
struct stats_lcore_params stats_lcore;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index aaee7b7..22bd894 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -23,6 +23,8 @@
#define DEV_NAME "BBDEV"
+/* Number of supported operation types */
+#define BBDEV_OP_TYPE_COUNT 5
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -890,10 +892,10 @@ struct rte_mempool *
return NULL;
}
- if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
+ if (type >= BBDEV_OP_TYPE_COUNT) {
rte_bbdev_log(ERR,
"Invalid op type (%u), should be less than %u",
- type, RTE_BBDEV_OP_TYPE_COUNT);
+ type, BBDEV_OP_TYPE_COUNT);
return NULL;
}
@@ -1122,10 +1124,9 @@ struct rte_mempool *
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
"RTE_BBDEV_OP_LDPC_DEC",
- "RTE_BBDEV_OP_LDPC_ENC",
};
- if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
+ if (op_type < BBDEV_OP_TYPE_COUNT)
return op_types[op_type];
rte_bbdev_log(ERR, "Invalid operation type");
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 6d56133..cd82418 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
- RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
+ RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number including padding */
};
/** Bit indexes of possible errors reported through status field */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2 1/5] telemetry: escape special char when tel string
@ 2022-06-18 3:52 3% ` fengchengwen
2022-06-18 9:59 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: fengchengwen @ 2022-06-18 3:52 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: Morten Brørup, thomas, ferruh.yigit, kevin.laatz,
andrew.rybchenko, jerinj, sachin.saxena, hemant.agrawal, dev
On 2022/6/18 1:05, Stephen Hemminger wrote:
> On Fri, 17 Jun 2022 12:25:04 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
>>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
>>>> Sent: Friday, 17 June 2022 11.46
>>>>
>>>> This patch supports escape special characters (including: \",\\,/,\b,
>>>> /f,/n,/r,/t) when telemetry string.
>>>> This patch is used to support telemetry xxx-dump commands which the
>>>> string may include special characters.
>>>>
>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>> ---
>>>> lib/telemetry/telemetry.c | 96 +++++++++++++++++++++++++++++++++++++--
>>>> 1 file changed, 93 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
>>>> index c6fd03a5ab..0f762f633e 100644
>>>> --- a/lib/telemetry/telemetry.c
>>>> +++ b/lib/telemetry/telemetry.c
>>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data *d,
>>>> char *out_buf, size_t buf_len)
>>>> return used;
>>>> }
>>>>
>>>> +static bool
>>>> +json_is_special_char(char ch)
>>>> +{
>>>> + static unsigned char is_spec[256] = { 0 };
>>>> + static bool init_once;
>>>> +
>>>> + if (!init_once) {
>>>> + is_spec['\"'] = 1;
>>>> + is_spec['\\'] = 1;
>>>> + is_spec['/'] = 1;
>>>> + is_spec['\b'] = 1;
>>>> + is_spec['\f'] = 1;
>>>> + is_spec['\n'] = 1;
>>>> + is_spec['\r'] = 1;
>>>> + is_spec['\t'] = 1;
>>>> + init_once = true;
>>>> + }
>>>> +
>>>> + return (bool)is_spec[(unsigned char)ch];
>>>> +}
>>
>> According to the json spec at [1], the characters that need to be escaped
>> are:
>> a) any characters <0x20
>> b) inverted commas/quote character \"
>> c) the "reverse solidus character", better known to you and I as the
>> back-slash.
>>
>> Therefore, I think this table generation could be simplified, but also
>> expanded using this. For completeness we should also see about handling all
>> control characters if they are encountered.
>>
>> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
>>
>> /Bruce
>
> Since it is trivial could be initializer?
>
> static const uint8_t is_spec[256] = {
> [0 ... 0x20] = 1,
> ['\"' ] = 1,
> ['\\' ] = 1,
> ['/'] = 1,
>
> etc
>
> Or we could change the telemetry API to disallow control characters?
I was thinking about converting 0~0x20, but I don't think there's a scenario.
I prefer change the telemetry API to disallow control characters, and this may not
be a violation of the ABI, if yes, the dpdk-telemetry.py will returns an error.
So I think we could add declaring and checking functions to make sure telemetry string
do not allow control characters.
>
>
> .
>
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-18 3:52 3% ` fengchengwen
@ 2022-06-18 9:59 0% ` Morten Brørup
2022-06-22 7:57 0% ` Power, Ciara
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-06-18 9:59 UTC (permalink / raw)
To: fengchengwen, Stephen Hemminger, Bruce Richardson
Cc: thomas, ferruh.yigit, kevin.laatz, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev, Ciara Power
+CC: Ciara Power, Telemetry library maintainer
> From: fengchengwen [mailto:fengchengwen@huawei.com]
> Sent: Saturday, 18 June 2022 05.52
>
> On 2022/6/18 1:05, Stephen Hemminger wrote:
> > On Fri, 17 Jun 2022 12:25:04 +0100
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> >>>> Sent: Friday, 17 June 2022 11.46
> >>>>
> >>>> This patch supports escape special characters (including:
> \",\\,/,\b,
> >>>> /f,/n,/r,/t) when telemetry string.
> >>>> This patch is used to support telemetry xxx-dump commands which
> the
> >>>> string may include special characters.
> >>>>
> >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>>> ---
> >>>> lib/telemetry/telemetry.c | 96
> +++++++++++++++++++++++++++++++++++++--
> >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
> >>>> index c6fd03a5ab..0f762f633e 100644
> >>>> --- a/lib/telemetry/telemetry.c
> >>>> +++ b/lib/telemetry/telemetry.c
> >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> *d,
> >>>> char *out_buf, size_t buf_len)
> >>>> return used;
> >>>> }
> >>>>
> >>>> +static bool
> >>>> +json_is_special_char(char ch)
> >>>> +{
> >>>> + static unsigned char is_spec[256] = { 0 };
> >>>> + static bool init_once;
> >>>> +
> >>>> + if (!init_once) {
> >>>> + is_spec['\"'] = 1;
> >>>> + is_spec['\\'] = 1;
> >>>> + is_spec['/'] = 1;
> >>>> + is_spec['\b'] = 1;
> >>>> + is_spec['\f'] = 1;
> >>>> + is_spec['\n'] = 1;
> >>>> + is_spec['\r'] = 1;
> >>>> + is_spec['\t'] = 1;
> >>>> + init_once = true;
> >>>> + }
> >>>> +
> >>>> + return (bool)is_spec[(unsigned char)ch];
> >>>> +}
> >>
> >> According to the json spec at [1], the characters that need to be
> escaped
> >> are:
> >> a) any characters <0x20
> >> b) inverted commas/quote character \"
> >> c) the "reverse solidus character", better known to you and I as the
> >> back-slash.
> >>
> >> Therefore, I think this table generation could be simplified, but
> also
> >> expanded using this. For completeness we should also see about
> handling all
> >> control characters if they are encountered.
> >>
> >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> >>
> >> /Bruce
> >
> > Since it is trivial could be initializer?
> >
> > static const uint8_t is_spec[256] = {
> > [0 ... 0x20] = 1,
> > ['\"' ] = 1,
> > ['\\' ] = 1,
> > ['/'] = 1,
> >
> > etc
> >
> > Or we could change the telemetry API to disallow control characters?
>
> I was thinking about converting 0~0x20, but I don't think there's a
> scenario.
>
> I prefer change the telemetry API to disallow control characters, and
> this may not
> be a violation of the ABI, if yes, the dpdk-telemetry.py will returns
> an error.
I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
So we need to define exactly what the STRING type contains.
I hope we can all agree that control characters should be disallowed.
The more complicated question is: Do we want to use the ASCII character set only, or do we want to use UTF-8 encoded Unicode?
Personally, think UTF-8 encoded Unicode is more future proof, and would vote for that.
But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce another data type for UTF-8 strings.
UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many SNMP MIBs.
>
> So I think we could add declaring and checking functions to make sure
> telemetry string
> do not allow control characters.
Input validation (when storing a string in the telemetry database) has a performance cost, so it could be a compile time debug option, like the memory cookies and mbuf integrity checks. Just a thought.
^ permalink raw reply [relevance 0%]
* [PATCH v7 0/3] pcap: support MTU set for linux interfaces
` (2 preceding siblings ...)
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
@ 2022-06-19 9:30 3% ` Ido Goshen
2022-06-20 8:39 3% ` [PATCH v8 " Ido Goshen
4 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-19 9:30 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
patch series:
[PATCH v7 1/3] pcap: support MTU set for linux interfaces
[PATCH v7 2/3] pcap: support MTU set for linux interfaces TX
[PATCH v7 3/3] pcap: support MTU set for linux interfaces count
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 126 +++++++++++++++++++++++++++++++++-----------
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 +++
drivers/net/pcap/pcap_osdep_linux.c | 21 ++++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 +++
6 files changed, 134 insertions(+), 31 deletions(-)
---
v7:
1. TX drop only individual oversized packets and not the entire burst
2. Count oversize drops by i/oerrors
v6:
Fixes for v5 approach
1. freebsd compilation fix
2. checkpatch warning fix
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
^ permalink raw reply [relevance 3%]
* [PATCH v8 0/3] pcap: support MTU set for linux interfaces
` (3 preceding siblings ...)
2022-06-19 9:30 3% ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
@ 2022-06-20 8:39 3% ` Ido Goshen
4 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-20 8:39 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
patch series:
[PATCH v8 1/3] pcap: support MTU set for linux interfaces
[PATCH v8 2/3] pcap: support MTU set for linux interfaces TX
[PATCH v8 3/3] pcap: support MTU set for linux interfaces count
doc/guides/rel_notes/release_22_07.rst | 3 +
drivers/net/pcap/pcap_ethdev.c | 126 +++++++++++++++++++++++++--------
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 ++
drivers/net/pcap/pcap_osdep_linux.c | 21 ++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 ++
6 files changed, 134 insertions(+), 31 deletions(-)
---
v8:
cosmetics only
1. checkpatch typo fix
2. rel_notes apply patch fix by rebasing on latest main
v7:
1. TX drop only individual oversized packets and not the entire burst
2. Count oversize drops by i/oerrors
v6:
Fixes for v5 approach
1. freebsd compilation fix
2. checkpatch warning fix
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
^ permalink raw reply [relevance 3%]
* [PATCH v5] ched: enable CMAN at runtime
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
2022-06-17 11:48 0% ` Dumitrescu, Cristian
@ 2022-06-20 13:56 1% ` Marcin Danilewicz
2022-06-21 8:16 1% ` [PATCH v6] sched: " Marcin Danilewicz
1 sibling, 1 reply; 200+ results
From: Marcin Danilewicz @ 2022-06-20 13:56 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* [PATCH v6] sched: enable CMAN at runtime
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
@ 2022-06-21 8:16 1% ` Marcin Danilewicz
0 siblings, 0 replies; 200+ results
From: Marcin Danilewicz @ 2022-06-21 8:16 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
v6 commit message fixed
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* [PATCH] config/riscv: name the cross file properly
@ 2022-06-21 12:29 5% Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-06-21 12:29 UTC (permalink / raw)
To: David Marchand; +Cc: Stanislaw Kardach, dev, upstream
Since the riscv64_linux_gcc was in fact a Ubuntu-specific cross-file,
rename it.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
.ci/linux-build.sh | 2 +-
config/riscv/{riscv64_linux_gcc => riscv64_linux_gcc_ubuntu} | 0
devtools/test-meson-builds.sh | 2 +-
doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst | 4 ++--
4 files changed, 4 insertions(+), 4 deletions(-)
rename config/riscv/{riscv64_linux_gcc => riscv64_linux_gcc_ubuntu} (100%)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 06104eca22..dcf4d4ccb3 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -75,7 +75,7 @@ if [ "$PPC64LE" = "true" ]; then
fi
if [ "$RISCV64" = "true" ]; then
- cross_file=config/riscv/riscv64_linux_gcc
+ cross_file=config/riscv/riscv64_linux_gcc_ubuntu
fi
if [ -n "$cross_file" ]; then
diff --git a/config/riscv/riscv64_linux_gcc b/config/riscv/riscv64_linux_gcc_ubuntu
similarity index 100%
rename from config/riscv/riscv64_linux_gcc
rename to config/riscv/riscv64_linux_gcc_ubuntu
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 04a85fe987..00b97a3e50 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -265,7 +265,7 @@ f=$srcdir/config/ppc/ppc64le-power8-linux-gcc
build build-ppc64-power8-gcc $f ABI $use_shared
# generic RISC-V
-f=$srcdir/config/riscv/riscv64_linux_gcc
+f=$srcdir/config/riscv/riscv64_linux_gcc_ubuntu
build build-riscv64-generic-gcc $f ABI $use_shared
# Test installation of the x86-generic target, to be used for checking
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst b/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst
index 9e121645a8..84d1ea3aa6 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst
@@ -74,7 +74,7 @@ To cross-compile DPDK for a desired target machine use the following command::
For example if the target machine is a generic rv64gc RISC-V, use the following
command::
- meson riscv64-build-gcc --cross-file config/riscv/riscv64_linux_gcc
+ meson riscv64-build-gcc --cross-file config/riscv/riscv64_linux_gcc_ubuntu
ninja -C riscv64-build-gcc
If riscv-gnu-toolchain is used, binary names should be updated to match. Update
@@ -106,7 +106,7 @@ Supported cross-compilation targets
Currently the following targets are supported:
-* Generic rv64gc ISA: ``config/riscv/riscv64_linux_gcc``
+* Generic rv64gc ISA: ``config/riscv/riscv64_linux_gcc_ubuntu``
* SiFive U740 SoC: ``config/riscv/riscv64_sifive_u740_linux_gcc``
--
2.30.2
^ permalink raw reply [relevance 5%]
* RE: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-18 9:59 0% ` Morten Brørup
@ 2022-06-22 7:57 0% ` Power, Ciara
2022-06-22 9:19 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Power, Ciara @ 2022-06-22 7:57 UTC (permalink / raw)
To: Morten Brørup, fengchengwen, Stephen Hemminger, Richardson, Bruce
Cc: thomas, ferruh.yigit, Laatz, Kevin, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
Hi folks,
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Saturday 18 June 2022 10:59
> To: fengchengwen <fengchengwen@huawei.com>; Stephen Hemminger
> <stephen@networkplumber.org>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Cc: thomas@monjalon.net; ferruh.yigit@xilinx.com; Laatz, Kevin
> <kevin.laatz@intel.com>; andrew.rybchenko@oktetlabs.ru;
> jerinj@marvell.com; sachin.saxena@oss.nxp.com;
> hemant.agrawal@nxp.com; dev@dpdk.org; Power, Ciara
> <ciara.power@intel.com>
> Subject: RE: [PATCH v2 1/5] telemetry: escape special char when tel string
>
> +CC: Ciara Power, Telemetry library maintainer
>
> > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > Sent: Saturday, 18 June 2022 05.52
> >
> > On 2022/6/18 1:05, Stephen Hemminger wrote:
> > > On Fri, 17 Jun 2022 12:25:04 +0100
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > >
> > >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> > >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > >>>> Sent: Friday, 17 June 2022 11.46
> > >>>>
> > >>>> This patch supports escape special characters (including:
> > \",\\,/,\b,
> > >>>> /f,/n,/r,/t) when telemetry string.
> > >>>> This patch is used to support telemetry xxx-dump commands which
> > the
> > >>>> string may include special characters.
> > >>>>
> > >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > >>>> ---
> > >>>> lib/telemetry/telemetry.c | 96
> > +++++++++++++++++++++++++++++++++++++--
> > >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> > >>>>
> > >>>> diff --git a/lib/telemetry/telemetry.c
> > >>>> b/lib/telemetry/telemetry.c index c6fd03a5ab..0f762f633e 100644
> > >>>> --- a/lib/telemetry/telemetry.c
> > >>>> +++ b/lib/telemetry/telemetry.c
> > >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> > *d,
> > >>>> char *out_buf, size_t buf_len)
> > >>>> return used;
> > >>>> }
> > >>>>
> > >>>> +static bool
> > >>>> +json_is_special_char(char ch)
> > >>>> +{
> > >>>> + static unsigned char is_spec[256] = { 0 };
> > >>>> + static bool init_once;
> > >>>> +
> > >>>> + if (!init_once) {
> > >>>> + is_spec['\"'] = 1;
> > >>>> + is_spec['\\'] = 1;
> > >>>> + is_spec['/'] = 1;
> > >>>> + is_spec['\b'] = 1;
> > >>>> + is_spec['\f'] = 1;
> > >>>> + is_spec['\n'] = 1;
> > >>>> + is_spec['\r'] = 1;
> > >>>> + is_spec['\t'] = 1;
> > >>>> + init_once = true;
> > >>>> + }
> > >>>> +
> > >>>> + return (bool)is_spec[(unsigned char)ch]; }
> > >>
> > >> According to the json spec at [1], the characters that need to be
> > escaped
> > >> are:
> > >> a) any characters <0x20
> > >> b) inverted commas/quote character \"
> > >> c) the "reverse solidus character", better known to you and I as
> > >> the back-slash.
> > >>
> > >> Therefore, I think this table generation could be simplified, but
> > also
> > >> expanded using this. For completeness we should also see about
> > handling all
> > >> control characters if they are encountered.
> > >>
> > >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > >>
> > >> /Bruce
> > >
> > > Since it is trivial could be initializer?
> > >
> > > static const uint8_t is_spec[256] = {
> > > [0 ... 0x20] = 1,
> > > ['\"' ] = 1,
> > > ['\\' ] = 1,
> > > ['/'] = 1,
> > >
> > > etc
> > >
> > > Or we could change the telemetry API to disallow control characters?
> >
> > I was thinking about converting 0~0x20, but I don't think there's a
> > scenario.
> >
> > I prefer change the telemetry API to disallow control characters, and
> > this may not be a violation of the ABI, if yes, the dpdk-telemetry.py
> > will returns an error.
>
> I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
>
> So we need to define exactly what the STRING type contains.
>
> I hope we can all agree that control characters should be disallowed.
>
> The more complicated question is: Do we want to use the ASCII character set
> only, or do we want to use UTF-8 encoded Unicode?
>
> Personally, think UTF-8 encoded Unicode is more future proof, and would
> vote for that.
>
> But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce
> another data type for UTF-8 strings.
>
> UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many
> SNMP MIBs.
>
[CP]
Just from looking at the spec [1] , I would say UTF-8, as it seems to suggest its use for JSON (section 8.1).
[1] https://www.rfc-editor.org/rfc/rfc8259.txt
> >
> > So I think we could add declaring and checking functions to make sure
> > telemetry string do not allow control characters.
[CP]
I am not sure why we don't want these at all - I thought we do want some of them, like tab (\u0009) for example.
<snip>
In general, I think Bruce's suggestion of using a customised printf function instead of snprintf would be a good way forward, to scan the chars as they are being copied in.
Thanks,
Ciara
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-22 7:57 0% ` Power, Ciara
@ 2022-06-22 9:19 0% ` Bruce Richardson
2022-06-23 16:45 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-06-22 9:19 UTC (permalink / raw)
To: Power, Ciara
Cc: Morten Brørup, fengchengwen, Stephen Hemminger, thomas,
ferruh.yigit, Laatz, Kevin, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
On Wed, Jun 22, 2022 at 08:57:43AM +0100, Power, Ciara wrote:
> Hi folks,
>
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Saturday 18 June 2022 10:59
> > To: fengchengwen <fengchengwen@huawei.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; Richardson, Bruce
> > <bruce.richardson@intel.com>
> > Cc: thomas@monjalon.net; ferruh.yigit@xilinx.com; Laatz, Kevin
> > <kevin.laatz@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > jerinj@marvell.com; sachin.saxena@oss.nxp.com;
> > hemant.agrawal@nxp.com; dev@dpdk.org; Power, Ciara
> > <ciara.power@intel.com>
> > Subject: RE: [PATCH v2 1/5] telemetry: escape special char when tel string
> >
> > +CC: Ciara Power, Telemetry library maintainer
> >
> > > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > > Sent: Saturday, 18 June 2022 05.52
> > >
> > > On 2022/6/18 1:05, Stephen Hemminger wrote:
> > > > On Fri, 17 Jun 2022 12:25:04 +0100
> > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > >
> > > >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> > > >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > >>>> Sent: Friday, 17 June 2022 11.46
> > > >>>>
> > > >>>> This patch supports escape special characters (including:
> > > \",\\,/,\b,
> > > >>>> /f,/n,/r,/t) when telemetry string.
> > > >>>> This patch is used to support telemetry xxx-dump commands which
> > > the
> > > >>>> string may include special characters.
> > > >>>>
> > > >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > >>>> ---
> > > >>>> lib/telemetry/telemetry.c | 96
> > > +++++++++++++++++++++++++++++++++++++--
> > > >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> > > >>>>
> > > >>>> diff --git a/lib/telemetry/telemetry.c
> > > >>>> b/lib/telemetry/telemetry.c index c6fd03a5ab..0f762f633e 100644
> > > >>>> --- a/lib/telemetry/telemetry.c
> > > >>>> +++ b/lib/telemetry/telemetry.c
> > > >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> > > *d,
> > > >>>> char *out_buf, size_t buf_len)
> > > >>>> return used;
> > > >>>> }
> > > >>>>
> > > >>>> +static bool
> > > >>>> +json_is_special_char(char ch)
> > > >>>> +{
> > > >>>> + static unsigned char is_spec[256] = { 0 };
> > > >>>> + static bool init_once;
> > > >>>> +
> > > >>>> + if (!init_once) {
> > > >>>> + is_spec['\"'] = 1;
> > > >>>> + is_spec['\\'] = 1;
> > > >>>> + is_spec['/'] = 1;
> > > >>>> + is_spec['\b'] = 1;
> > > >>>> + is_spec['\f'] = 1;
> > > >>>> + is_spec['\n'] = 1;
> > > >>>> + is_spec['\r'] = 1;
> > > >>>> + is_spec['\t'] = 1;
> > > >>>> + init_once = true;
> > > >>>> + }
> > > >>>> +
> > > >>>> + return (bool)is_spec[(unsigned char)ch]; }
> > > >>
> > > >> According to the json spec at [1], the characters that need to be
> > > escaped
> > > >> are:
> > > >> a) any characters <0x20
> > > >> b) inverted commas/quote character \"
> > > >> c) the "reverse solidus character", better known to you and I as
> > > >> the back-slash.
> > > >>
> > > >> Therefore, I think this table generation could be simplified, but
> > > also
> > > >> expanded using this. For completeness we should also see about
> > > handling all
> > > >> control characters if they are encountered.
> > > >>
> > > >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > > >>
> > > >> /Bruce
> > > >
> > > > Since it is trivial could be initializer?
> > > >
> > > > static const uint8_t is_spec[256] = {
> > > > [0 ... 0x20] = 1,
> > > > ['\"' ] = 1,
> > > > ['\\' ] = 1,
> > > > ['/'] = 1,
> > > >
> > > > etc
> > > >
> > > > Or we could change the telemetry API to disallow control characters?
> > >
> > > I was thinking about converting 0~0x20, but I don't think there's a
> > > scenario.
> > >
> > > I prefer change the telemetry API to disallow control characters, and
> > > this may not be a violation of the ABI, if yes, the dpdk-telemetry.py
> > > will returns an error.
> >
> > I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
> >
> > So we need to define exactly what the STRING type contains.
> >
> > I hope we can all agree that control characters should be disallowed.
> >
> > The more complicated question is: Do we want to use the ASCII character set
> > only, or do we want to use UTF-8 encoded Unicode?
> >
> > Personally, think UTF-8 encoded Unicode is more future proof, and would
> > vote for that.
> >
> > But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce
> > another data type for UTF-8 strings.
> >
> > UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many
> > SNMP MIBs.
> >
> [CP]
>
> Just from looking at the spec [1] , I would say UTF-8, as it seems to suggest its use for JSON (section 8.1).
>
> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
>
> > >
> > > So I think we could add declaring and checking functions to make sure
> > > telemetry string do not allow control characters.
> [CP]
>
> I am not sure why we don't want these at all - I thought we do want some of them, like tab (\u0009) for example.
>
> <snip>
>
> In general, I think Bruce's suggestion of using a customised printf function instead of snprintf would be a good way forward, to scan the chars as they are being copied in.
>
I'm hoping to have some time to try and prototype this myself soon, and
send out a draft patch to this mailing list for consideration.
/Bruce
^ permalink raw reply [relevance 0%]
* [PATCH v4 07/13] net/nfp: support firmware with NFDk
@ 2022-06-23 2:26 5% ` Jin Liu
0 siblings, 0 replies; 200+ results
From: Jin Liu @ 2022-06-23 2:26 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
doc/guides/nics/nfp.rst | 7 ++--
doc/guides/rel_notes/release_22_07.rst | 1 +
drivers/net/nfp/nfp_ctrl.h | 2 +
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++-----
drivers/net/nfp/nfp_ethdev_vf.c | 53 +++++++++++++++++++-------
5 files changed, 85 insertions(+), 27 deletions(-)
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index dcefac3ef6..55539accc2 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -100,9 +100,10 @@ more than one SmartNIC, same type of SmartNIC or different ones, and to upload a
different firmware to each SmartNIC.
.. Note::
- Currently the NFP PMD supports using the PF with Agilio Basic Firmware. See
- https://help.netronome.com/support/solutions for more information on the
- various firmwares supported by the Netronome Agilio CX smartNIC.
+ Currently the NFP PMD supports using the PF with Agilio Firmware with NFD3
+ and Agilio Firmware with NFDk. See https://help.netronome.com/support/solutions
+ for more information on the various firmwares supported by the Netronome
+ Agilio CX smartNIC.
PF multiport support
--------------------
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index d5d8c735b1..64308e6c1a 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -111,6 +111,7 @@ New Features
* **Updated Netronome nfp driver.**
* Added support for NFP3800 NIC.
+ * Added support for firmware with NFDk.
* **Updated VMware vmxnet3 networking driver.**
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index cb84dc3188..1bbba9187e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -402,11 +428,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -441,6 +462,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -473,7 +499,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -939,6 +964,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -988,11 +1014,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"secondary process attach failed, ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index c46ee0f913..0b4660aba6 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -265,6 +265,32 @@ static const struct eth_dev_ops nfp_netvf_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_netvf_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_netvf_init(struct rte_eth_dev *eth_dev)
{
@@ -292,10 +318,19 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
- eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_netvf_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -313,15 +348,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -354,7 +380,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
--
2.27.0
^ permalink raw reply [relevance 5%]
* Re: [PATCH v1] bbdev: allow operation type enum for growth
2022-06-17 8:21 3% ` Thomas Monjalon
2022-06-17 16:12 0% ` Chautru, Nicolas
@ 2022-06-23 16:09 0% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2022-06-23 16:09 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Nicolas Chautru, dev, maxime.coquelin, trix, bruce.richardson,
hemant.agrawal, david.marchand, stephen, techboard
Thomas Monjalon <thomas@monjalon.net> writes:
> This solution is what I proposed to the techboard some years ago,
> but the preference was to completely remove the MAX values.
I am mindful we don't have an explicit guidance in the documentation.
I am including to add something to the abi_versioning document, that
basically says
1. Try not to use _MAX values with enumerations.
2. If you have to use _MAX values with enumeration, consider giving
yourself some headroom along with rigourous checking?
>
>
> 13/06/2022 20:24, Nicolas Chautru:
>> Updating the last enum for rte_bbdev_op_type
>> to allow for enum insertion.
>
> Please explain that the reason is to keep ABI compatible,
> and you want to keep the MAX value for array needs.
>
>> --- a/lib/bbdev/rte_bbdev.c
>> +++ b/lib/bbdev/rte_bbdev.c
>> @@ -1122,7 +1122,10 @@ struct rte_mempool *
>> "RTE_BBDEV_OP_TURBO_DEC",
>> "RTE_BBDEV_OP_TURBO_ENC",
>> "RTE_BBDEV_OP_LDPC_DEC",
>> - "RTE_BBDEV_OP_LDPC_ENC",
>> + "RTE_BBDEV_OP_RESERVED_1",
>> + "RTE_BBDEV_OP_RESERVED_2",
>> + "RTE_BBDEV_OP_RESERVED_3",
>> + "RTE_BBDEV_OP_RESERVED_4",
>
> As Stephen said, you should make sure that using these values
> with the API functions will lead to a clear and expected error.
>
>> @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
>> RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
>> RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
>> RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
>> - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
>> + RTE_BBDEV_OP_TYPE_COUNT = 8, /**< Count of different op types */
>
> You must update the comment to explain there may be a padding,
> it is not exactly the count.
> Maybe "MAX" is a better fit than "COUNT" in this case.
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-22 9:19 0% ` Bruce Richardson
@ 2022-06-23 16:45 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-06-23 16:45 UTC (permalink / raw)
To: Power, Ciara
Cc: Morten Brørup, fengchengwen, Stephen Hemminger, thomas,
ferruh.yigit, Laatz, Kevin, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
On Wed, Jun 22, 2022 at 10:19:48AM +0100, Bruce Richardson wrote:
> On Wed, Jun 22, 2022 at 08:57:43AM +0100, Power, Ciara wrote:
> > Hi folks,
> >
> > > -----Original Message-----
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: Saturday 18 June 2022 10:59
> > > To: fengchengwen <fengchengwen@huawei.com>; Stephen Hemminger
> > > <stephen@networkplumber.org>; Richardson, Bruce
> > > <bruce.richardson@intel.com>
> > > Cc: thomas@monjalon.net; ferruh.yigit@xilinx.com; Laatz, Kevin
> > > <kevin.laatz@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > > jerinj@marvell.com; sachin.saxena@oss.nxp.com;
> > > hemant.agrawal@nxp.com; dev@dpdk.org; Power, Ciara
> > > <ciara.power@intel.com>
> > > Subject: RE: [PATCH v2 1/5] telemetry: escape special char when tel string
> > >
> > > +CC: Ciara Power, Telemetry library maintainer
> > >
> > > > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > > > Sent: Saturday, 18 June 2022 05.52
> > > >
> > > > On 2022/6/18 1:05, Stephen Hemminger wrote:
> > > > > On Fri, 17 Jun 2022 12:25:04 +0100
> > > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > > >
> > > > >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> > > > >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > > >>>> Sent: Friday, 17 June 2022 11.46
> > > > >>>>
> > > > >>>> This patch supports escape special characters (including:
> > > > \",\\,/,\b,
> > > > >>>> /f,/n,/r,/t) when telemetry string.
> > > > >>>> This patch is used to support telemetry xxx-dump commands which
> > > > the
> > > > >>>> string may include special characters.
> > > > >>>>
> > > > >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > > >>>> ---
> > > > >>>> lib/telemetry/telemetry.c | 96
> > > > +++++++++++++++++++++++++++++++++++++--
> > > > >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> > > > >>>>
> > > > >>>> diff --git a/lib/telemetry/telemetry.c
> > > > >>>> b/lib/telemetry/telemetry.c index c6fd03a5ab..0f762f633e 100644
> > > > >>>> --- a/lib/telemetry/telemetry.c
> > > > >>>> +++ b/lib/telemetry/telemetry.c
> > > > >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> > > > *d,
> > > > >>>> char *out_buf, size_t buf_len)
> > > > >>>> return used;
> > > > >>>> }
> > > > >>>>
> > > > >>>> +static bool
> > > > >>>> +json_is_special_char(char ch)
> > > > >>>> +{
> > > > >>>> + static unsigned char is_spec[256] = { 0 };
> > > > >>>> + static bool init_once;
> > > > >>>> +
> > > > >>>> + if (!init_once) {
> > > > >>>> + is_spec['\"'] = 1;
> > > > >>>> + is_spec['\\'] = 1;
> > > > >>>> + is_spec['/'] = 1;
> > > > >>>> + is_spec['\b'] = 1;
> > > > >>>> + is_spec['\f'] = 1;
> > > > >>>> + is_spec['\n'] = 1;
> > > > >>>> + is_spec['\r'] = 1;
> > > > >>>> + is_spec['\t'] = 1;
> > > > >>>> + init_once = true;
> > > > >>>> + }
> > > > >>>> +
> > > > >>>> + return (bool)is_spec[(unsigned char)ch]; }
> > > > >>
> > > > >> According to the json spec at [1], the characters that need to be
> > > > escaped
> > > > >> are:
> > > > >> a) any characters <0x20
> > > > >> b) inverted commas/quote character \"
> > > > >> c) the "reverse solidus character", better known to you and I as
> > > > >> the back-slash.
> > > > >>
> > > > >> Therefore, I think this table generation could be simplified, but
> > > > also
> > > > >> expanded using this. For completeness we should also see about
> > > > handling all
> > > > >> control characters if they are encountered.
> > > > >>
> > > > >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > > > >>
> > > > >> /Bruce
> > > > >
> > > > > Since it is trivial could be initializer?
> > > > >
> > > > > static const uint8_t is_spec[256] = {
> > > > > [0 ... 0x20] = 1,
> > > > > ['\"' ] = 1,
> > > > > ['\\' ] = 1,
> > > > > ['/'] = 1,
> > > > >
> > > > > etc
> > > > >
> > > > > Or we could change the telemetry API to disallow control characters?
> > > >
> > > > I was thinking about converting 0~0x20, but I don't think there's a
> > > > scenario.
> > > >
> > > > I prefer change the telemetry API to disallow control characters, and
> > > > this may not be a violation of the ABI, if yes, the dpdk-telemetry.py
> > > > will returns an error.
> > >
> > > I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
> > >
> > > So we need to define exactly what the STRING type contains.
> > >
> > > I hope we can all agree that control characters should be disallowed.
> > >
> > > The more complicated question is: Do we want to use the ASCII character set
> > > only, or do we want to use UTF-8 encoded Unicode?
> > >
> > > Personally, think UTF-8 encoded Unicode is more future proof, and would
> > > vote for that.
> > >
> > > But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce
> > > another data type for UTF-8 strings.
> > >
> > > UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many
> > > SNMP MIBs.
> > >
> > [CP]
> >
> > Just from looking at the spec [1] , I would say UTF-8, as it seems to suggest its use for JSON (section 8.1).
> >
> > [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> >
> > > >
> > > > So I think we could add declaring and checking functions to make sure
> > > > telemetry string do not allow control characters.
> > [CP]
> >
> > I am not sure why we don't want these at all - I thought we do want some of them, like tab (\u0009) for example.
> >
> > <snip>
> >
> > In general, I think Bruce's suggestion of using a customised printf function instead of snprintf would be a good way forward, to scan the chars as they are being copied in.
> >
>
> I'm hoping to have some time to try and prototype this myself soon, and
> send out a draft patch to this mailing list for consideration.
>
Here is an RFC of my current prototype of this:
http://patches.dpdk.org/project/dpdk/list/?series=23739
Feedback welcome.
Regards,
/Bruce
^ permalink raw reply [relevance 0%]
Results 11401-11600 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2020-10-09 3:48 [dpdk-dev] [PATCH v6 0/3] librte_ethdev: error recovery support Kalesh A P
2022-02-11 10:09 ` [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events Ray Kinsella
2022-02-14 10:16 ` Ray Kinsella
2022-02-14 11:15 ` Thomas Monjalon
2022-02-14 16:06 ` Ray Kinsella
2022-05-21 10:33 0% ` fengchengwen
2022-05-24 15:11 0% ` Ray Kinsella
2022-06-10 0:16 0% ` fengchengwen
2022-02-17 17:23 [PATCH v3 0/4] app/test: add inline IPsec and reassembly cases Akhil Goyal
2022-04-16 19:25 ` [PATCH v4 00/10] " Akhil Goyal
2022-04-16 19:25 ` [PATCH v4 07/10] ethdev: add IPsec SA expiry event subtypes Akhil Goyal
2022-04-19 8:58 3% ` Thomas Monjalon
2022-04-19 10:14 3% ` [EXT] " Akhil Goyal
2022-04-19 10:19 0% ` Anoob Joseph
2022-04-19 10:47 0% ` Thomas Monjalon
2022-04-19 12:27 0% ` Akhil Goyal
2022-04-19 15:41 0% ` Ray Kinsella
2022-04-20 13:51 0% ` Akhil Goyal
2022-03-01 8:58 [PATCH v3 1/1] ethdev: mtr: support input color selection skori
2022-04-21 18:02 5% ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2022-04-26 10:19 0% ` Ray Kinsella
2022-05-01 14:46 5% ` [dpdk-dev] [PATCH v5] " jerinj
2022-03-09 0:22 [PATCH v1 2/2] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-06-17 18:37 4% ` [PATCH v2 0/5] bbdev changes for 22.11 Nicolas Chautru
2022-06-17 18:37 3% ` [PATCH v2 1/5] bbdev: allow operation type enum for growth Nicolas Chautru
2022-03-10 23:49 [PATCH v1] bbdev: add new operation for FFT processing Nicolas Chautru
2022-03-10 23:49 ` Nicolas Chautru
2022-05-25 22:07 ` Chautru, Nicolas
2022-05-26 6:05 ` Hemant Agrawal
2022-06-07 11:29 3% ` David Marchand
2022-03-17 17:43 [PATCH] net/pcap: support MTU set ido g
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
2022-05-30 18:05 0% ` Ferruh Yigit
2022-05-31 13:12 0% ` Ido Goshen
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
2022-06-06 17:10 0% ` Stephen Hemminger
2022-06-06 19:07 3% ` Ido Goshen
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
2022-06-08 16:04 3% ` [PATCH v6] " Ido Goshen
2022-06-19 9:30 3% ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-20 8:39 3% ` [PATCH v8 " Ido Goshen
2022-03-17 18:37 [PATCH v2] doc: announce changes in bbdev related to enum extension Nicolas Chautru
2022-06-09 0:20 3% ` [PATCH v3] " Nicolas Chautru
2022-06-09 0:20 3% ` Nicolas Chautru
2022-06-09 0:34 3% ` [PATCH v4] " Nicolas Chautru
2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
2022-06-09 7:53 0% ` Maxime Coquelin
2022-06-17 16:13 0% ` Chautru, Nicolas
2022-03-25 11:16 [PATCH 0/2] Session crypto event metadata api Volodymyr Fialko
2022-03-25 11:16 ` [PATCH 1/2] security: introduce per session event metadata Volodymyr Fialko
2022-04-04 8:38 ` Gujjar, Abhinandan S
2022-04-04 9:48 ` Akhil Goyal
2022-04-04 10:42 ` Gujjar, Abhinandan S
2022-04-13 7:13 ` Akhil Goyal
2022-04-18 19:36 0% ` Akhil Goyal
2022-03-29 13:10 [PATCH 0/6] Extend and set event queue attributes at runtime Shijith Thotton
2022-04-05 5:40 ` [PATCH v2 " Shijith Thotton
2022-04-05 5:40 ` [PATCH v2 2/6] eventdev: add weight and affinity to queue attributes Shijith Thotton
2022-05-09 12:46 0% ` Jerin Jacob
2022-05-15 9:53 3% ` [PATCH v3 0/5] Extend and set event queue attributes at runtime Shijith Thotton
2022-05-15 9:53 3% ` [PATCH v3 2/5] eventdev: add weight and affinity to queue attributes Shijith Thotton
2022-05-16 17:35 3% ` [PATCH v4 0/5] Extend and set event queue attributes at runtime Shijith Thotton
2022-05-16 17:35 3% ` [PATCH v4 2/5] eventdev: add weight and affinity to queue attributes Shijith Thotton
2022-04-01 3:22 [RFC 1/6] net/mlx5: add LWM support for Rxq Spike Du
2022-05-06 3:56 ` [RFC v1 0/7] net/mlx5: introduce limit watermark and host shaper Spike Du
2022-05-06 3:56 ` [RFC v1 3/7] ethdev: introduce Rx queue based limit watermark Spike Du
2022-05-19 9:37 4% ` Andrew Rybchenko
2022-05-22 5:58 ` [RFC v2 0/7] introduce per-queue limit watermark and host shaper Spike Du
2022-05-22 5:58 ` [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark Spike Du
2022-05-22 15:23 3% ` Stephen Hemminger
2022-05-23 3:01 0% ` Spike Du
2022-05-23 21:45 4% ` Thomas Monjalon
2022-05-24 2:50 3% ` Spike Du
2022-05-24 8:18 3% ` Thomas Monjalon
2022-05-25 12:59 4% ` Andrew Rybchenko
2022-05-25 13:58 3% ` Thomas Monjalon
2022-05-25 14:23 0% ` Andrew Rybchenko
2022-05-23 22:54 0% ` Stephen Hemminger
2022-05-24 3:46 0% ` Spike Du
2022-04-01 10:22 21.11.1 patches review and test Kevin Traynor
2022-04-20 5:50 3% ` Christian Ehrhardt
2022-04-25 13:39 0% ` Kevin Traynor
2022-04-02 10:41 [v4 1/3] ethdev: introduce protocol type based header split wenxuanx.wu
2022-04-26 11:13 ` [PATCH v5 0/3] ethdev: introduce protocol based buffer split wenxuanx.wu
2022-04-26 11:13 ` [PATCH v5 1/4] lib/ethdev: introduce protocol type " wenxuanx.wu
2022-05-17 21:12 3% ` Thomas Monjalon
2022-05-19 14:40 0% ` Ding, Xuan
2022-05-26 14:58 0% ` Ding, Xuan
2022-04-15 17:31 [PATCH 0/3] Enable ASan in GHA David Marchand
2022-05-05 9:29 ` [PATCH v2 0/2] " David Marchand
2022-05-05 9:29 3% ` [PATCH v2 2/2] ci: build some job with ASan David Marchand
2022-04-18 19:33 [PATCH v2 0/7] Add new cryptodev op for event metadata Akhil Goyal
2022-04-21 14:37 4% ` [PATCH v3 " Akhil Goyal
2022-04-21 14:37 2% ` [PATCH v3 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-04-27 15:38 0% ` Zhang, Roy Fan
2022-04-28 14:42 0% ` Gujjar, Abhinandan S
2022-04-27 15:37 0% ` [PATCH v3 0/7] Add new cryptodev op for " Zhang, Roy Fan
2022-04-28 14:24 0% ` Gujjar, Abhinandan S
2022-05-01 19:24 4% ` [PATCH v4 " Akhil Goyal
2022-05-01 19:24 2% ` [PATCH v4 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-05-02 9:01 0% ` Anoob Joseph
2022-05-02 11:06 0% ` Gujjar, Abhinandan S
2022-05-02 11:08 0% ` [PATCH v4 0/7] Add new cryptodev op for " Gujjar, Abhinandan S
2022-05-12 12:45 4% ` [PATCH v5 " Akhil Goyal
2022-05-12 12:45 2% ` [PATCH v5 1/7] cryptodev: add APIs to get/set " Akhil Goyal
2022-05-16 18:30 0% ` [PATCH v5 0/7] Add new cryptodev op for " Akhil Goyal
2022-04-19 9:01 15% [PATCH] doc: fix typos 'depreciated' instead of 'deprecated' Stephen Coleman
2022-04-19 15:44 0% ` Ray Kinsella
2022-04-19 16:14 [RFC] eal: add bus cleanup to eal cleanup Kevin Laatz
2022-04-20 6:55 4% ` Morten Brørup
2022-04-22 9:18 4% ` Kevin Laatz
2022-04-22 12:14 0% ` Morten Brørup
2022-06-03 14:36 ` [PATCH v7] " Kevin Laatz
2022-06-07 11:09 ` Thomas Monjalon
2022-06-07 15:12 3% ` David Marchand
2022-06-13 15:58 0% ` Bruce Richardson
2022-04-21 4:38 16% kni: check abi version between kmod and lib Stephen Coleman
2022-04-21 14:16 4% ` Ray Kinsella
2022-04-21 14:54 4% ` Stephen Hemminger
2022-04-21 15:40 8% ` Ray Kinsella
2022-04-21 15:50 4% ` Stephen Hemminger
2022-04-22 8:46 8% ` Ray Kinsella
2022-04-22 10:07 4% ` Stephen Coleman
2022-04-21 16:34 15% ` [PATCH v2] " youcai
2022-04-24 8:51 15% ` [PATCH v3] " youcai
2022-04-24 10:35 4% ` Stephen Coleman
2022-04-21 12:30 [PATCH 0/6] move DPAA2 QDMA driver freom raw to dma nipun.gupta
2022-05-05 9:05 ` [PATCH v3 " nipun.gupta
2022-05-26 6:00 ` Hemant Agrawal
2022-05-31 15:29 3% ` Thomas Monjalon
2022-04-25 23:38 librte_bpf: roadmap or any specific plans for this library Björn Svensson A
2022-04-28 10:34 4% ` David Marchand
2022-04-26 7:18 4% [PATCH 1/2] ci: switch to Ubuntu 20.04 David Marchand
2022-05-06 11:57 4% ` [PATCH v2 " David Marchand
2022-04-26 13:58 1% DPDK 21.11.1 released Kevin Traynor
2022-04-27 11:32 [PATCH 1/3] eventdev: add function to quiesce an event port Pavan Nikhilesh
2022-05-09 17:29 3% ` Jerin Jacob
2022-05-05 10:27 3% [PATCH 0/6] Vhost checksum offload improvements Maxime Coquelin
2022-05-05 17:29 [PATCH 00/11] Introduce support for RISC-V architecture Stanislaw Kardach
2022-05-05 17:30 9% ` [PATCH 10/11] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-05-10 15:07 ` [PATCH v2 0/8] Introduce support for RISC-V architecture Stanislaw Kardach
2022-05-10 15:07 9% ` [PATCH v2 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-05-10 15:35 0% ` Stanisław Kardach
2022-05-10 15:48 ` [PATCH v3 0/8] Introduce support for RISC-V architecture Stanislaw Kardach
2022-05-10 15:48 9% ` [PATCH v3 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-05-10 11:58 [PATCH 1/1] lpm: add a scalar version of lookupx4 function Stanislaw Kardach
2022-05-19 17:02 ` Medvedkin, Vladimir
2022-05-24 16:28 ` Stanisław Kardach
2022-05-27 11:16 ` Stanisław Kardach
2022-05-27 13:16 3% ` Medvedkin, Vladimir
2022-05-27 18:18 3% ` [PATCH v2 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
2022-05-30 20:38 0% ` Stephen Hemminger
2022-06-01 9:35 0% ` Medvedkin, Vladimir
2022-05-11 13:53 [PATCH] sched: enable CMAN at runtime Marcin Danilewicz
2022-05-12 13:10 4% ` [PATCH v2] " Marcin Danilewicz
2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 14:03 4% ` Danilewicz, MarcinX
2022-06-02 9:57 3% ` Danilewicz, MarcinX
2022-05-30 11:35 0% ` Dumitrescu, Cristian
2022-06-07 10:40 0% ` Danilewicz, MarcinX
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2022-06-08 11:59 0% ` Dumitrescu, Cristian
2022-06-08 15:29 0% ` Danilewicz, MarcinX
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
2022-06-17 11:48 0% ` Dumitrescu, Cristian
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
2022-06-21 8:16 1% ` [PATCH v6] sched: " Marcin Danilewicz
2022-05-18 10:16 [PATCH 00/12] Fix compilation with gcc 12 David Marchand
2022-05-18 10:16 ` [PATCH 04/12] net/ena: fix build with GCC 12 David Marchand
2022-05-20 20:28 ` Stephen Hemminger
2022-05-21 9:49 3% ` Morten Brørup
2022-05-21 16:23 0% ` Stephen Hemminger
2022-05-22 20:30 0% ` Morten Brørup
2022-05-20 5:54 3% [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-20 5:54 8% ` [PATCH 02/40] cryptodev: remove list end enumerators Arek Kusztal
2022-05-20 7:19 0% ` [EXT] " Akhil Goyal
2022-05-20 7:30 0% ` [EXT] [PATCH 00/40] cryptodev: rsa, dh, ecdh changes Akhil Goyal
2022-05-20 7:37 0% ` Kusztal, ArkadiuszX
2022-05-24 18:46 3% [RFT 0/2] pie: floating point fixes Stephen Hemminger
2022-05-24 19:31 0% ` Morten Brørup
2022-05-25 9:53 4% [PATCH] eal/ppc: undefine AltiVec keyword vector Thomas Monjalon
2022-05-25 11:48 ` Ray Kinsella
2022-05-25 15:40 ` Thomas Monjalon
2022-05-25 18:02 3% ` Ray Kinsella
2022-05-25 18:34 3% ` Tyler Retzlaff
2022-05-26 10:18 0% ` Thomas Monjalon
2022-05-26 11:02 0% ` Ray Kinsella
2022-06-01 15:04 0% ` Thomas Monjalon
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
2022-05-31 1:09 0% ` Min Hu (Connor)
2022-05-31 16:09 0% ` Stephen Hemminger
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-05-31 7:49 0% ` [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Zhang, Roy Fan
2022-05-31 11:52 0% ` [EXT] " Akhil Goyal
2022-05-31 14:12 [PATCH v4 0/8] Introduce support for RISC-V architecture Stanislaw Kardach
2022-05-31 14:13 9% ` [PATCH v4 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-06-01 9:02 [PATCH v5 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-06-01 9:02 4% ` [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
2022-06-02 14:21 0% ` Ray Kinsella
2022-06-02 14:25 0% ` Akhil Goyal
2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
2022-06-03 13:26 4% ` Ray Kinsella
2022-06-01 11:15 3% [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
2022-06-02 20:52 0% ` Thomas Monjalon
2022-06-03 7:29 0% ` Bruce Richardson
2022-06-03 7:43 0% ` Thomas Monjalon
2022-06-02 1:52 [PATCH 00/14] Add support of NFP3800 chip and firmware with NFDk Jin Liu
2022-06-02 1:52 6% ` [PATCH 07/14] net/nfp: support NFDK firmware Jin Liu
2022-06-02 22:53 0% ` Ferruh Yigit
2022-06-14 8:49 3% ` Kevin Liu
2022-06-14 9:21 0% ` Ferruh Yigit
2022-06-14 9:30 0% ` Kevin Liu
2022-06-16 2:39 ` [PATCH v2 00/15] Add support of NFP3800 chip and firmware with NFDk Jin Liu
2022-06-16 2:39 6% ` [PATCH v2 09/15] net/nfp: support " Jin Liu
2022-06-17 9:34 ` [PATCH v3 00/13] Add support of NFP3800 chip and " Jin Liu
2022-06-17 9:34 5% ` [PATCH v3 07/13] net/nfp: support " Jin Liu
2022-06-23 2:26 ` [PATCH v4 00/13] Add support of NFP3800 chip and " Jin Liu
2022-06-23 2:26 5% ` [PATCH v4 07/13] net/nfp: support " Jin Liu
2022-06-02 9:23 [dpdk-dev] [PATCH v1] build: ccache support for cross build jerinj
2022-06-08 17:13 3% ` [dpdk-dev] [PATCH v2] " jerinj
2022-06-14 16:01 0% ` Thomas Monjalon
2022-06-04 9:09 3% Optimizations are not features Morten Brørup
2022-06-04 9:33 0% ` Jerin Jacob
2022-06-04 10:00 0% ` Andrew Rybchenko
2022-06-04 11:10 0% ` Jerin Jacob
2022-06-04 12:19 3% ` Morten Brørup
2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
2022-06-05 16:05 0% ` Stephen Hemminger
2022-06-06 9:35 0% ` Konstantin Ananyev
2022-06-06 22:50 [PATCH v1] bbdev: add device status info Nicolas Chautru
2022-06-06 22:50 ` Nicolas Chautru
2022-06-07 0:09 3% ` Stephen Hemminger
2022-06-07 12:42 0% ` Maxime Coquelin
2022-06-07 15:44 0% ` Chautru, Nicolas
2022-06-07 16:20 0% ` Maxime Coquelin
2022-06-07 16:42 0% ` Stephen Hemminger
2022-06-08 22:44 0% ` Chautru, Nicolas
2022-06-07 10:46 [PATCH RESEND v4 0/8] Introduce support for RISC-V architecture Stanislaw Kardach
2022-06-07 10:46 9% ` [PATCH RESEND v4 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-06-07 12:59 [PATCH v5 0/7] introduce per-queue available descriptor threshold and host shaper Spike Du
2022-06-08 16:35 ` [PATCH v6] ethdev: introduce available Rx descriptors threshold Andrew Rybchenko
2022-06-08 17:22 ` Thomas Monjalon
2022-06-08 17:46 3% ` Thomas Monjalon
2022-06-09 0:17 3% ` fengchengwen
2022-06-09 7:05 0% ` Thomas Monjalon
2022-06-10 0:01 3% ` fengchengwen
2022-06-07 13:48 4% Minutes of Technical Board Meeting, 2022-06-01 Olivier Matz
2022-06-08 12:49 3% [PATCH v2 0/6] Vhost checksum offload improvements Maxime Coquelin
2022-06-17 14:06 0% ` Maxime Coquelin
2022-06-08 15:50 15% [PATCH] devtools: unify cross-compilation tests Thomas Monjalon
2022-06-08 16:34 4% ` David Marchand
2022-06-08 17:20 0% ` Thomas Monjalon
2022-06-13 18:24 4% [PATCH v1] bbdev: allow operation type enum for growth Nicolas Chautru
2022-06-13 18:24 ` Nicolas Chautru
2022-06-17 8:21 3% ` Thomas Monjalon
2022-06-17 16:12 0% ` Chautru, Nicolas
2022-06-23 16:09 0% ` Ray Kinsella
2022-06-15 7:39 [PATCH 0/5] support telemetry dump dev Chengwen Feng
2022-06-15 7:39 ` [PATCH 1/5] usertools: use non-strict when json-loads in telemetry Chengwen Feng
2022-06-15 13:54 ` Morten Brørup
2022-06-15 16:54 ` Bruce Richardson
2022-06-15 18:01 3% ` Morten Brørup
2022-06-15 20:09 0% ` Morten Brørup
2022-06-17 9:46 ` [PATCH v2 0/5] support telemetry dump Chengwen Feng
2022-06-17 9:46 ` [PATCH v2 1/5] telemetry: escape special char when tel string Chengwen Feng
2022-06-17 11:16 ` Morten Brørup
2022-06-17 11:25 ` Bruce Richardson
2022-06-17 17:05 ` Stephen Hemminger
2022-06-18 3:52 3% ` fengchengwen
2022-06-18 9:59 0% ` Morten Brørup
2022-06-22 7:57 0% ` Power, Ciara
2022-06-22 9:19 0% ` Bruce Richardson
2022-06-23 16:45 0% ` Bruce Richardson
2022-06-21 12:29 5% [PATCH] config/riscv: name the cross file properly Stanislaw Kardach
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).