Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon wrote: > > From: Elena Agostini > > In heterogeneous computing system, processing is not only in the CPU. > Some tasks can be delegated to devices working in parallel. > > The goal of this new library is to enhance the collaboration between > DPDK, that's primarily a CPU framework, and other type of devices like GPUs. > > When mixing network activity with task processing on a non-CPU device, > there may be the need to put in communication the CPU with the device > in order to manage the memory, synchronize operations, exchange info, etc.. > > This library provides a number of new features: > - Interoperability with device specific library with generic handlers > - Possibility to allocate and free memory on the device > - Possibility to allocate and free memory on the CPU but visible from the > device > - Communication functions to enhance the dialog between the CPU and the device > > The infrastructure is prepared to welcome drivers in drivers/hc/ > as the upcoming NVIDIA one, implementing the hcdev API. > > Some parts are not complete: > - locks > - memory allocation table > - memory freeing > - guide documentation > - integration in devtools/check-doc-vs-code.sh > - unit tests > - integration in testpmd to enable Rx/Tx to/from GPU memory. Since the above line is the crux of the following text, I will start from this point. + Techboard I can give my honest feedback on this. I can map similar stuff in Marvell HW, where we do machine learning as compute offload on a different class of CPU. In terms of RFC patch features 1) memory API - Use cases are aligned 2) communication flag and communication list Our structure is completely different and we are using HW ring kind of interface to post the job to compute interface and the job completion result happens through the event device. Kind of similar to the DMA API that has been discussed on the mailing list. Now the bigger question is why need to Tx and then Rx something to compute the device Isn't ot offload something? If so, why not add the those offload in respective subsystem to improve the subsystem(ethdev, cryptiodev etc) features set to adapt new features or introduce new subsystem (like ML, Inline Baseband processing) so that it will be an opportunity to implement the same in HW or compute device. For example, if we take this path, ML offloading will be application code like testpmd, which deals with "specific" device commands(aka glorified rawdev) to deal with specific computing device offload "COMMANDS" (The commands will be specific to offload device, the same code wont run on other compute device) Just my _personal_ preference is to have specific subsystems to improve the DPDK instead of raw device kind of path. If we decide another path as a community it is _fine_ too(as a _project manager_ point of view it will be an easy path to dump SDK stuff to DPDK without introducing the pain of the subsystem nor improving the DPDK). > > Below is a pseudo-code to give an example about how to use functions > in this library in case of a CUDA application. > > > Elena Agostini (4): > hcdev: introduce heterogeneous computing device library > hcdev: add memory API > hcdev: add communication flag > hcdev: add communication list > > Thomas Monjalon (3): > hcdev: add event notification > hcdev: add child device representing a device context > hcdev: support multi-process > > .gitignore | 1 + > MAINTAINERS| 6 + > doc/api/doxy-api-index.md | 1 + > doc/api/doxy-api.conf.in | 1 + > doc/guides/conf.py | 8 + > doc/guides/hcdevs/features/default.ini | 13 + > doc/guides/hcdevs/index.rst| 11 + > doc/guides/hcdevs/overview.rst | 11 + > doc/guides/index.rst | 1 + > doc/guides/prog_guide/hcdev.rst| 5 + > doc/guides/prog_guide/index.rst| 1 + > doc/guides/rel_notes/release_21_08.rst | 5 + > drivers/hc/meson.build | 4 + > drivers/meson.build| 1 + > lib/hcdev/hcdev.c | 789 + > lib/hcdev/hcdev_driver.h | 96 +++ > lib/hcdev/meson.build | 12 + > lib/hcdev/rte_hcdev.h | 592 +++ > lib/hcdev/version.map | 35 ++ > lib/meson.build| 1 + > 20 files changed, 1594 insertions(+) > create mode 100644 doc/guides/hcdevs/features/default.ini > create mode 100644 doc/guides/hcdevs/index.rst > create mode 100644 doc/guides/hcdevs/overview.rst > create mode 100644 doc/guides/prog_guide/hcdev.rst > create mode 100644 drivers/hc/meson.build > create mode 100644 lib/hcdev/hcdev.c > create mode 100644 lib/hcdev/hcdev_driver.h > create mode 100644 lib/hcdev/meson.build > create mode 100644 lib/hcdev/rte_hcdev.h > cre
[dpdk-dev] [Bug 766] Best sites to download free antivirus
https://bugs.dpdk.org/show_bug.cgi?id=766 Bug ID: 766 Summary: Best sites to download free antivirus Product: DPDK Version: 20.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: doc Assignee: dev@dpdk.org Reporter: imaddycrip...@gmail.com Target Milestone: --- Hello, I'm Addy, and I'm a Microsoft expert, if you face any technical problem then you can use these support service team members and find a solution to complex issues related to antivirus. http://nortoncomsetupl.com/ http://mybtmailx.com/bt-email-login/ https://contactassistance.com/hp-printer-offline/ https://contactassistance.com/linksys-router-support/ https://contactassistance.com/netgear-router-support/ https://contactassistance.com/office-365-outlook-setup-support/ https://sites.google.com/view/goaolmail/ https://sites.google.com/view/gocashapplogin/ https://sites.google.com/view/bitdefender-central-usa https://sites.google.com/view/roadrunneremail-us/ https://sites.google.com/view/netgearextendersetup-process https://sites.google.com/view/tomtomupdate-guide https://sites.google.com/view/avastlogindesk https://sites.google.com/view/myavastcom-desk https://sites.google.com/view/mywifiext-setupp https://sites.google.com/view/extenderlinksyscom-setup https://sites.google.com/view/office365loginhere https://sites.google.com/view/nortonlogindesk https://sites.google.com/view/belkinrangehelp https://sites.google.com/view/ijstartcannonsetup-guide https://sites.google.com/view/webrootdownloadus https://sites.google.com/view/belkinn300setup-guide -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
31/07/2021 09:06, Jerin Jacob: > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon wrote: > > > > From: Elena Agostini > > > > In heterogeneous computing system, processing is not only in the CPU. > > Some tasks can be delegated to devices working in parallel. > > > > The goal of this new library is to enhance the collaboration between > > DPDK, that's primarily a CPU framework, and other type of devices like GPUs. > > > > When mixing network activity with task processing on a non-CPU device, > > there may be the need to put in communication the CPU with the device > > in order to manage the memory, synchronize operations, exchange info, etc.. > > > > This library provides a number of new features: > > - Interoperability with device specific library with generic handlers > > - Possibility to allocate and free memory on the device > > - Possibility to allocate and free memory on the CPU but visible from the > > device > > - Communication functions to enhance the dialog between the CPU and the > > device > > > > The infrastructure is prepared to welcome drivers in drivers/hc/ > > as the upcoming NVIDIA one, implementing the hcdev API. > > > > Some parts are not complete: > > - locks > > - memory allocation table > > - memory freeing > > - guide documentation > > - integration in devtools/check-doc-vs-code.sh > > - unit tests > > - integration in testpmd to enable Rx/Tx to/from GPU memory. > > Since the above line is the crux of the following text, I will start > from this point. > > + Techboard > > I can give my honest feedback on this. > > I can map similar stuff in Marvell HW, where we do machine learning > as compute offload > on a different class of CPU. > > In terms of RFC patch features > > 1) memory API - Use cases are aligned > 2) communication flag and communication list > Our structure is completely different and we are using HW ring kind of > interface to post the job to compute interface and > the job completion result happens through the event device. > Kind of similar to the DMA API that has been discussed on the mailing list. Interesting. > Now the bigger question is why need to Tx and then Rx something to > compute the device > Isn't ot offload something? If so, why not add the those offload in > respective subsystem > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt > new features or > introduce new subsystem (like ML, Inline Baseband processing) so that > it will be an opportunity to > implement the same in HW or compute device. For example, if we take > this path, ML offloading will > be application code like testpmd, which deals with "specific" device > commands(aka glorified rawdev) > to deal with specific computing device offload "COMMANDS" > (The commands will be specific to offload device, the same code wont > run on other compute device) Having specific features API is convenient for compatibility between devices, yes, for the set of defined features. Our approach is to start with a flexible API that the application can use to implement any processing because with GPU programming, there is no restriction on what can be achieved. This approach does not contradict what you propose, it does not prevent extending existing classes. > Just my _personal_ preference is to have specific subsystems to > improve the DPDK instead of raw device kind of > path. If we decide another path as a community it is _fine_ too(as a > _project manager_ point of view it will be an easy path to dump SDK > stuff to DPDK without introducing the pain of the subsystem nor > improving the DPDK). Adding a new class API is also improving DPDK.
Re: [dpdk-dev] [PATCH v1] test/func_reentrancy: free memzones after creating test case
> -Original Message-
> From: Olivier Matz
> Sent: Friday, July 30, 2021 7:27 PM
> To: Joyce Kong
> Cc: anatoly.bura...@intel.com; andrew.rybche...@oktetlabs.ru;
> yipeng1.w...@intel.com; sameh.gobr...@intel.com;
> bruce.richard...@intel.com; vladimir.medved...@intel.com;
> konstantin.anan...@intel.com; Honnappa Nagarahalli
> ; Ruifeng Wang
> ; dev@dpdk.org; nd ;
> sta...@dpdk.org
> Subject: Re: [PATCH v1] test/func_reentrancy: free memzones after creating
> test case
>
> Hi Joyce,
>
> On Wed, Jul 28, 2021 at 02:33:22AM -0500, Joyce Kong wrote:
> > Function reentrancy test limits maximum number of iterations
> > simultaneously, however it doesn't free the 'fr_test_once'
> > memzones after the fact, so introduce freeing 'fr_test_once'
> > in ring/mempool/hash/fbk/lpm_clean.
> >
> > Fixes: 104a92bd026f ("app: add reentrancy tests")
> > Fixes: 995eec619024 ("test: clean up memory for function reentrancy
> > test")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Joyce Kong
> > Reviewed-by: Ruifeng Wang
> > Reviewed-by: Feifei Wang
> > ---
> > app/test/test_func_reentrancy.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/app/test/test_func_reentrancy.c
> > b/app/test/test_func_reentrancy.c index 231c99a9eb..e4e9c2cc7c 100644
> > --- a/app/test/test_func_reentrancy.c
> > +++ b/app/test/test_func_reentrancy.c
> > @@ -89,6 +89,10 @@ ring_clean(unsigned int lcore_id)
> > char ring_name[MAX_STRING_SIZE];
> > int i;
> >
> > + rp = rte_ring_lookup("fr_test_once");
> > + if (rp != NULL)
> > + rte_ring_free(rp);
> > +
> > for (i = 0; i < MAX_ITER_MULTI; i++) {
> > snprintf(ring_name, sizeof(ring_name),
> > "fr_test_%d_%d", lcore_id, i);
> > @@ -148,7 +152,10 @@ mempool_clean(unsigned int lcore_id)
> > char mempool_name[MAX_STRING_SIZE];
> > int i;
> >
> > - /* verify all ring created successful */
> > + mp = rte_mempool_lookup("fr_test_once");
> > + if (mp != NULL)
> > + rte_mempool_free(mp);
> > +
> > for (i = 0; i < MAX_ITER_MULTI; i++) {
> > snprintf(mempool_name, sizeof(mempool_name),
> "fr_test_%d_%d",
> > lcore_id, i);
> > @@ -208,6 +215,10 @@ hash_clean(unsigned lcore_id)
> > struct rte_hash *handle;
> > int i;
> >
> > + handle = rte_hash_find_existing("fr_test_once");
> > + if (handle != NULL)
> > + rte_hash_free(handle);
> > +
> > for (i = 0; i < MAX_ITER_MULTI; i++) {
> > snprintf(hash_name, sizeof(hash_name), "fr_test_%d_%d",
> lcore_id,
> > i);
> >
> > @@ -272,6 +283,10 @@ fbk_clean(unsigned lcore_id)
> > struct rte_fbk_hash_table *handle;
> > int i;
> >
> > + handle = rte_fbk_hash_find_existing("fr_test_once");
> > + if (handle != NULL)
> > + rte_fbk_hash_free(handle);
> > +
> > for (i = 0; i < MAX_ITER_MULTI; i++) {
> > snprintf(fbk_name, sizeof(fbk_name), "fr_test_%d_%d",
> lcore_id,
> > i);
> >
> > @@ -338,6 +353,10 @@ lpm_clean(unsigned int lcore_id)
> > struct rte_lpm *lpm;
> > int i;
> >
> > + lpm = rte_lpm_find_existing("fr_test_once");
> > + if (lpm != NULL)
> > + rte_lpm_free(lpm);
> > +
> > for (i = 0; i < MAX_LPM_ITER_TIMES; i++) {
> > snprintf(lpm_name, sizeof(lpm_name), "fr_test_%d_%d",
> lcore_id,
> > i);
> >
> > @@ -454,6 +473,9 @@ launch_test(struct test_case *pt_case)
> > pt_case->clean(lcore_id);
> > }
> >
> > + if (pt_case->clean != NULL)
> > + pt_case->clean(rte_get_main_lcore());
> > +
>
> Is it the same issue? It looks it adds the missing frees for the main thread
> (not
> only "fr_test_once"). I don't think it requires another patch, but a word
> could
> be added about it in the commit log.
>
Thanks, Olivier, will send another version to add this in the commit log.
>
> > count = rte_atomic32_read(&obj_count);
> > if (count != 1) {
> > printf("%s: common object allocated %d times (should be
> 1)\n",
> > --
> > 2.17.1
> >
[dpdk-dev] [PATCH] net/bnxt: fix incorrect action record calculation
For Thor, the number of action records is being wrongly configured
to 128 because of incorrect definition of divider. This results in
an incorrect number of action records being negotiated with the FW.
Remove the divider from the templates and delete the logic which
uses the field in the resource manager logic.
Fixes: 3fe124d2536c ("net/bnxt: support Thor platform")
Cc: sta...@dpdk.org
Tested-by: Shuanglin Wang
Signed-off-by: Ajit Khaparde
---
drivers/net/bnxt/tf_core/tf_device_p58.h | 14
drivers/net/bnxt/tf_core/tf_rm.c | 22 ---
.../generic_templates/ulp_template_db_tbl.c | 2 +-
3 files changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/net/bnxt/tf_core/tf_device_p58.h
b/drivers/net/bnxt/tf_core/tf_device_p58.h
index b5e2598cb6..66b0f4e983 100644
--- a/drivers/net/bnxt/tf_core/tf_device_p58.h
+++ b/drivers/net/bnxt/tf_core/tf_device_p58.h
@@ -84,42 +84,36 @@ struct tf_rm_element_cfg tf_tbl_p58[TF_TBL_TYPE_MAX] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_1,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_COMPACT_ACT_RECORD] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_FULL_ACT_RECORD,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_1,
.slices = 1,
- .divider = 8,
},
/* Policy - Encaps in bank 2 */
[TF_TBL_TYPE_ACT_ENCAP_8B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_ENCAP_16B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_ENCAP_32B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_ENCAP_64B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
/* Policy - Modify in bank 2 with Encaps */
[TF_TBL_TYPE_ACT_MODIFY_8B] = {
@@ -127,56 +121,48 @@ struct tf_rm_element_cfg tf_tbl_p58[TF_TBL_TYPE_MAX] = {
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_MODIFY_16B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_MODIFY_32B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_MODIFY_64B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
/* Policy - SP in bank 0 */
[TF_TBL_TYPE_ACT_SP_SMAC] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_0,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_SP_SMAC_IPV4] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_SP_SMAC,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_0,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_SP_SMAC_IPV6] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_SP_SMAC,
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: fix incorrect action record calculation
31/07/2021 06:48, Ajit Khaparde:
> For Thor, the number of action records is being wrongly configured
> to 128 because of incorrect definition of divider. This results in
> an incorrect number of action records being negotiated with the FW.
> Remove the divider from the templates and delete the logic which
> uses the field in the resource manager logic.
>
> Fixes: 3fe124d2536c ("net/bnxt: support Thor platform")
> Cc: sta...@dpdk.org
>
> Tested-by: Shuanglin Wang
> Signed-off-by: Ajit Khaparde
This block should be in chronological order,
so the test comes after the Sign-off.
Re: [dpdk-dev] [EXT] [PATCH] crypto/mlx5: fix driver probing error flow
30/07/2021 21:23, Akhil Goyal:
> > In crypto driver probing, there are two validations after context
> > allocation.
> >
> > When one of them fails, the context structure was not freed what caused
> > a memory leak.
> >
> > Free it.
> >
> > Fixes: debb27ea3442 ("crypto/mlx5: create login object using DevX")
> > Fixes: e8db4413cba5 ("crypto/mlx5: add keytag configuration")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Michael Baum
> > Acked-by: Matan Azrad
> > ---
> Applied to dpdk-next-crypto
> @Thomas Monjalon: I do not think title and patch description are inline.
> You may fix it while pulling on main branch.
New title:
crypto/mlx5: fix leaks on probing failure
[dpdk-dev] DPDK 19.11.3 AWS perf issue
Hi, We are running TCP/UDP based performance tests using teravm with DPDK 19.11. We see a performance drop of around 15% in DPDK 19.11 for AWS C5XL instance compared to DPDK 18.11 Are there any known issues? Please let us know. Thanks Nagesh
Re: [dpdk-dev] [PATCH v2] net/memif: fix abstract socket addr_len
Thanks ! Le ven. 30 juil. 2021 à 13:23, Thomas Monjalon a écrit : > > > This fixes using abstract sockets with memifs. > > > we were not passing the exact addr_len, which requires zeroing the > remaining > > > sun_path and doesn't appear well in other utilities (e.g. > > > lsof -U) > > > > > > Signed-off-by: Nathan Skrzypczak > > > > Looks ok to me. > > > > Reviewed-by: Jakub Grajciar > > Applied, thanks. > > >
Re: [dpdk-dev] [EXT] [PATCH 1/2] drivers/qat: fix wrong return value for invalid service
30/07/2021 21:18, Akhil Goyal:
> > Subject: [EXT] [PATCH 1/2] drivers/qat: fix wrong return value for invalid
> > service
> >
> Title changed as " drivers: fix return value for QAT PMDs "
> Please check ./devtools/check-git-log.sh before sending patch.
>
> > Fix invalid value that is returned when asymmetric crypto
> > or compression service is selected.
>
> Description is also updated. Please check.
> >
> > Fixes: 8f393c4ffdc1 ("common/qat: support GEN4 devices")
> >
> > Signed-off-by: Arek Kusztal
> > ---
>
> Applied to dpdk-next-crypto
>
> Braces across 'EFAULT' are not needed. I tried fixing it, but it is being
> Used at many places. Please fix that in a separate patch.
There are not parenthesis for every returns,
so I will remove those introduced by this patch.
[dpdk-dev] [Bug 767] Why do the Outlook rules not work in my account?
https://bugs.dpdk.org/show_bug.cgi?id=767 Bug ID: 767 Summary: Why do the Outlook rules not work in my account? Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: woakeschri...@gmail.com Target Milestone: --- Outlook rules are set to run on any system automatically to make the system efficient and easy to use. However, when certain changes are made or when some of the files running in the background are corrupt, Outlook Rules not Working issue arises. One of the best possible ways to fix the issue is Resetting the SRS File. Check the instructions below to understand how it is done. • Visit the location on your system: C:\Users\%username%\AppData\Roaming\Microsoft\Outlook • Rename the existing Outlook.srs file to Outlook.old.srs • Restart Outlook. This will create a new and proper SRS file. Hope this helps you in fixing the issue. If not, feel free to write to us and we are up for the discussion. There are numerous possible solutions to this issue. So, get connected with the experts to find which one works for you. Visit Us: https://www.limksys.com/outlook-rules-are-not-working/ -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH 2/2] maint changes for marvell qlogic drivers
30/07/2021 08:27, Devendra Singh Rawat: > >Adding Marvell prefix for qlogic drivers. > >Removing myself as I'm no longer responsible for qede driver > > > >Signed-off-by: Igor Russkikh > >Signed-off-by: Rasesh Mody > > Acked. Applied, thanks.
[dpdk-dev] [PATCH v2] test/func_reentrancy: free memzones after creating test case
Function reentrancy test limits maximum number of iterations
simultaneously, however it doesn't free the 'fr_test_once'
memzones after the fact, so introduce freeing 'fr_test_once'
in ring/mempool/hash/fbk/lpm_clean.
Meanwhile, add the missing free for test case on main thread.
Fixes: 104a92bd026f ("app: add reentrancy tests")
Fixes: 995eec619024 ("test: clean up memory for function reentrancy test")
Cc: sta...@dpdk.org
Signed-off-by: Joyce Kong
Reviewed-by: Ruifeng Wang
Reviewed-by: Feifei Wang
---
app/test/test_func_reentrancy.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index 231c99a9eb..e4e9c2cc7c 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -89,6 +89,10 @@ ring_clean(unsigned int lcore_id)
char ring_name[MAX_STRING_SIZE];
int i;
+ rp = rte_ring_lookup("fr_test_once");
+ if (rp != NULL)
+ rte_ring_free(rp);
+
for (i = 0; i < MAX_ITER_MULTI; i++) {
snprintf(ring_name, sizeof(ring_name),
"fr_test_%d_%d", lcore_id, i);
@@ -148,7 +152,10 @@ mempool_clean(unsigned int lcore_id)
char mempool_name[MAX_STRING_SIZE];
int i;
- /* verify all ring created successful */
+ mp = rte_mempool_lookup("fr_test_once");
+ if (mp != NULL)
+ rte_mempool_free(mp);
+
for (i = 0; i < MAX_ITER_MULTI; i++) {
snprintf(mempool_name, sizeof(mempool_name), "fr_test_%d_%d",
lcore_id, i);
@@ -208,6 +215,10 @@ hash_clean(unsigned lcore_id)
struct rte_hash *handle;
int i;
+ handle = rte_hash_find_existing("fr_test_once");
+ if (handle != NULL)
+ rte_hash_free(handle);
+
for (i = 0; i < MAX_ITER_MULTI; i++) {
snprintf(hash_name, sizeof(hash_name), "fr_test_%d_%d",
lcore_id, i);
@@ -272,6 +283,10 @@ fbk_clean(unsigned lcore_id)
struct rte_fbk_hash_table *handle;
int i;
+ handle = rte_fbk_hash_find_existing("fr_test_once");
+ if (handle != NULL)
+ rte_fbk_hash_free(handle);
+
for (i = 0; i < MAX_ITER_MULTI; i++) {
snprintf(fbk_name, sizeof(fbk_name), "fr_test_%d_%d",
lcore_id, i);
@@ -338,6 +353,10 @@ lpm_clean(unsigned int lcore_id)
struct rte_lpm *lpm;
int i;
+ lpm = rte_lpm_find_existing("fr_test_once");
+ if (lpm != NULL)
+ rte_lpm_free(lpm);
+
for (i = 0; i < MAX_LPM_ITER_TIMES; i++) {
snprintf(lpm_name, sizeof(lpm_name), "fr_test_%d_%d",
lcore_id, i);
@@ -454,6 +473,9 @@ launch_test(struct test_case *pt_case)
pt_case->clean(lcore_id);
}
+ if (pt_case->clean != NULL)
+ pt_case->clean(rte_get_main_lcore());
+
count = rte_atomic32_read(&obj_count);
if (count != 1) {
printf("%s: common object allocated %d times (should be 1)\n",
--
2.17.1
Re: [dpdk-dev] [PATCH] doc: announce renaming of mbuf offload flags
On 7/30/21 6:57 PM, Olivier Matz wrote: The mbuf offload flags do not match the DPDK namespace (they are not prefixed by RTE_). Announce their rename in 21.11, and the removal of the old names in 22.11. A draft coccinelle script is provided to anticipate what the renaming will be. Signed-off-by: Olivier Matz Acked-by: Andrew Rybchenko [snip] diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 9584d6bfd7..04cb141de7 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -147,3 +147,8 @@ Deprecation Notices * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific content. On Linux and FreeBSD, supported prior to DPDK 20.11, original structure will be kept until DPDK 21.11. + +* mbuf: The mbuf offload flags ``PKT_*`` will be renamed as ``RTE_MBUF_F_*``. + A compatibility layer will be kept until DPDK 22.11, except for the flags + that are already deprecated (ex: ``PKT_RX_L4_CKSUM_BAD``), which will + be removed. I think it is better to be explicit with defines to be removed: PKT_RX_L4_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD, PKT_TX_QINQ_PKT, PKT_RX_EIP_CKSUM_BAD.
Re: [dpdk-dev] [PATCH v2 1/2] vhost: announce vDPA driver API marking as internal
On 7/30/21 11:12 AM, Maxime Coquelin wrote: This patch announces the marking of all the vDPA driver APIs as internal. Acked-by: Chenbo Xia Signed-off-by: Maxime Coquelin Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH v2 2/2] vhost: notice Vhost ops struct renaming
On 7/30/21 11:12 AM, Maxime Coquelin wrote: This patch announces the renaming of struct vhost_device_ops to rte_vhost_device_ops in DPDK v21.11. Acked-by: Chenbo Xia Signed-off-by: Maxime Coquelin Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH v3] net: fix Intel-specific Prepare the outer ipv4 hdr for checksum
On 7/30/21 2:11 PM, Olivier Matz wrote:
On Wed, Jul 28, 2021 at 06:46:53PM +0300, Andrew Rybchenko wrote:
On 7/7/21 12:40 PM, Mohsin Kazmi wrote:
Preparation the headers for the hardware offload
misses the outer ipv4 checksum offload.
It results in bad checksum computed by hardware NIC.
This patch fixes the issue by setting the outer ipv4
checksum field to 0.
Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
Cc: sta...@dpdk.org
Signed-off-by: Mohsin Kazmi
Acked-by: Qi Zhang
---
v3:
* Update the conditional test with PKT_TX_OUTER_IP_CKSUM.
* Update the commit title with "Intel-specific".
v2:
* Update the commit message with Fixes.
lib/net/rte_net.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/net/rte_net.h b/lib/net/rte_net.h
index 434435ffa2..3f4c8c58b9 100644
--- a/lib/net/rte_net.h
+++ b/lib/net/rte_net.h
@@ -125,11 +125,22 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m,
uint64_t ol_flags)
* Mainly it is required to avoid fragmented headers check if
* no offloads are requested.
*/
- if (!(ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG)))
+ if (!(ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG |
+ PKT_TX_OUTER_IP_CKSUM)))
return 0;
- if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
+ if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6)) {
inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
+ /*
+* prepare outer ipv4 header checksum by setting it to 0,
+* in order to be computed by hardware NICs.
+*/
+ if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
+ ipv4_hdr = rte_pktmbuf_mtod_offset(m,
+ struct rte_ipv4_hdr *, m->outer_l2_len);
+ ipv4_hdr->hdr_checksum = 0;
Here we assume that the field is located in the first segment.
Unlikely but it still could be false. We must handle it properly.
This is specified in the API comment, so I think it has to be checked
by the caller.
If no, what's the point to spoil memory here if stricter check is
done few lines below.
+ }
+ }
/*
* Check if headers are fragmented.
Re: [dpdk-dev] [RFC PATCH v2 0/7] heterogeneous computing library
On Sat, Jul 31, 2021 at 1:51 PM Thomas Monjalon wrote: > > 31/07/2021 09:06, Jerin Jacob: > > On Fri, Jul 30, 2021 at 7:25 PM Thomas Monjalon wrote: > > > > > > From: Elena Agostini > > > > > > In heterogeneous computing system, processing is not only in the CPU. > > > Some tasks can be delegated to devices working in parallel. > > > > > > The goal of this new library is to enhance the collaboration between > > > DPDK, that's primarily a CPU framework, and other type of devices like > > > GPUs. > > > > > > When mixing network activity with task processing on a non-CPU device, > > > there may be the need to put in communication the CPU with the device > > > in order to manage the memory, synchronize operations, exchange info, > > > etc.. > > > > > > This library provides a number of new features: > > > - Interoperability with device specific library with generic handlers > > > - Possibility to allocate and free memory on the device > > > - Possibility to allocate and free memory on the CPU but visible from the > > > device > > > - Communication functions to enhance the dialog between the CPU and the > > > device > > > > > > The infrastructure is prepared to welcome drivers in drivers/hc/ > > > as the upcoming NVIDIA one, implementing the hcdev API. > > > > > > Some parts are not complete: > > > - locks > > > - memory allocation table > > > - memory freeing > > > - guide documentation > > > - integration in devtools/check-doc-vs-code.sh > > > - unit tests > > > - integration in testpmd to enable Rx/Tx to/from GPU memory. > > > > Since the above line is the crux of the following text, I will start > > from this point. > > > > + Techboard > > > > I can give my honest feedback on this. > > > > I can map similar stuff in Marvell HW, where we do machine learning > > as compute offload > > on a different class of CPU. > > > > In terms of RFC patch features > > > > 1) memory API - Use cases are aligned > > 2) communication flag and communication list > > Our structure is completely different and we are using HW ring kind of > > interface to post the job to compute interface and > > the job completion result happens through the event device. > > Kind of similar to the DMA API that has been discussed on the mailing list. > > Interesting. It is hard to generalize the communication mechanism. Is other GPU vendors have a similar communication mechanism? AMD, Intel ?? > > > Now the bigger question is why need to Tx and then Rx something to > > compute the device > > Isn't ot offload something? If so, why not add the those offload in > > respective subsystem > > to improve the subsystem(ethdev, cryptiodev etc) features set to adapt > > new features or > > introduce new subsystem (like ML, Inline Baseband processing) so that > > it will be an opportunity to > > implement the same in HW or compute device. For example, if we take > > this path, ML offloading will > > be application code like testpmd, which deals with "specific" device > > commands(aka glorified rawdev) > > to deal with specific computing device offload "COMMANDS" > > (The commands will be specific to offload device, the same code wont > > run on other compute device) > > Having specific features API is convenient for compatibility > between devices, yes, for the set of defined features. > Our approach is to start with a flexible API that the application > can use to implement any processing because with GPU programming, > there is no restriction on what can be achieved. > This approach does not contradict what you propose, > it does not prevent extending existing classes. It does prevent extending the existing classes as no one is going to extent it there is the path of not doing do. If an application can run only on a specific device, it is similar to a raw device, where the device definition is not defined. (i.e JOB metadata is not defined and it is specific to the device). > > > Just my _personal_ preference is to have specific subsystems to > > improve the DPDK instead of raw device kind of > > path. If we decide another path as a community it is _fine_ too(as a > > _project manager_ point of view it will be an easy path to dump SDK > > stuff to DPDK without introducing the pain of the subsystem nor > > improving the DPDK). > > Adding a new class API is also improving DPDK. But the class is similar as raw dev class. The reason I say, Job submission and response is can be abstracted as queue/dequeue APIs. Taks/Job metadata is specific to compute devices (and it can not be generalized). If we generalize it makes sense to have a new class that does "specific function". > >
Re: [dpdk-dev] [PATCH v2] doc/sample_app_ug: use code snippets in sample app guides
> Currently the sample app user guides use hard coded code snippets,
> this patch changes these to use literalinclude which will dynamically
> update the snippets as changes are made to the code.
> This was introduced in commit 413c75c33c40 ("doc: show how to include
> code in guides"). Comments within the sample apps were updated to
> accommodate this as part of this patch. This will help to ensure that
> the code within the sample app user guides is up to date and not out
> of sync with the actual code.
>
> Signed-off-by: Conor Fogarty
> Signed-off-by: Conor Walsh
> Acked-by: John McNamara
Applied, thanks
Re: [dpdk-dev] [PATCH] doc: enhance arm64 profiling documentation
> > From: Jerin Jacob > > > > Documented the role of RTE_ARM_EAL_RDTSC_USE_PMU to enable PMU > > based rte_rdtsc(). > > > > Signed-off-by: Jerin Jacob > Acked-by: Ruifeng Wang Applied, thanks.
Re: [dpdk-dev] [EXT] [PATCH] doc: announce extension of crypto data-unit length
Ping for more votes. Please ack or reject. 17/05/2021 21:41, Akhil Goyal: > > The struct member dataunit_len is introduced in DPDK 21.05. > > It is limited to 16 bits to fit a padding hole in 32-bit build. > > This means the maximum data-unit length is 64 KB. > > Some use cases may benefit of a bigger size as the proposed 32 bits. > > > > Signed-off-by: Thomas Monjalon > > --- > Acked-by: Akhil Goyal > > Thomas, > Please take this patch directly on main, if it gets the required Acks.
Re: [dpdk-dev] [PATCH v3] doc/rel_notes: remove old deprecation notice for sched
14/06/2021 18:39, Andrew Rybchenko:
> On 6/14/21 7:30 PM, Jasvinder Singh wrote:
> > APIs and data structures hasve been modified as per deprecation
> > note, so removing deprecation notice from the notes.
> >
> > Fixes: 85f52aa422d6 ("sched: add pipe config params to subport struct")
> >
> > Signed-off-by: Jasvinder Singh
>
> Acked-by: Andrew Rybchenko
Applied, thanks.
Re: [dpdk-dev] [PATCH v2] doc/guides: add details for new test structure
16/07/2021 15:40, Ciara Power: > The testing guide is now updated to include details about > using sub-testsuites. Some example code is given to demonstrate how > they can be used. The trend is to avoid adding code in the doc, but include some existing code with literalinclude instead. Can it be applied here?
[dpdk-dev] [PATCH] doc: announce SA config option struct changes
From: Archana Muniganti Propose new fields to support offloads like - IPsec inner checksum(L3/L4) - IPsec tunnel header verification - TSO - etc in the structure ``rte_security_ipsec_sa_options``. Signed-off-by: Archana Muniganti Signed-off-by: Tejasree Kondoj Acked-by: Akhil Goyal --- Proposal for changes are floated as per below links. https://mails.dpdk.org/archives/dev/2021-June/212977.html https://mails.dpdk.org/archives/dev/2021-July/213484.html https://mails.dpdk.org/archives/dev/2021-July/214521.html Cc: Radu Nicolau doc/guides/rel_notes/deprecation.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 6a35c7649a..96192b4a41 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -151,3 +151,7 @@ Deprecation Notices * security: The functions ``rte_security_set_pkt_metadata`` and ``rte_security_get_userdata`` will be made inline functions and additional flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. + +* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options`` + will be updated with new fields to support new features like IPsec inner + checksum, tunnel header verification, TSO in case of protocol offload. -- 2.25.1
Re: [dpdk-dev] [PATCH] app/test: flush stdout after forking
26/07/2021 14:27, Bruce Richardson: > On Mon, Jul 26, 2021 at 01:16:27PM +0100, John Levon wrote: > > meson test was not capturing the intended output from the child > > process; force a flush to ensure it reaches the test log. > > > > Signed-off-by: John Levon > > Acked-by: Bruce Richardson Applied, thanks.
Re: [dpdk-dev] [PATCH] app/test: quieten noise while forking
26/07/2021 14:17, John Levon: > When closing file descriptors post-fork, ignore "." and ".." > directory entries. > > Signed-off-by: John Levon Please could you add an example of the noise in the commit explanation? Thanks
Re: [dpdk-dev] [EXT] [PATCH 01/10] security: add support for TSO on IPsec session
> > Allow user to provision a per security session maximum segment size > > (MSS) for use when Transmit Segmentation Offload (TSO) is supported. > > The MSS value will be used when PKT_TX_TCP_SEG or PKT_TX_UDP_SEG > > ol_flags are specified in mbuf. > > > > Signed-off-by: Declan Doherty > > Signed-off-by: Radu Nicolau > > Signed-off-by: Abhijit Sinha > > Signed-off-by: Daniel Martin Buckley > > --- > Can we have deprecation notice for the changes introduced in this series. > > Also there are 2 other features which modify same struct. Can we have a > Single deprecation notice for all the changes in the > rte_security_ipsec_sa_options? > The notice can be something like: > +* security: The IPsec SA config options structure ``struct > rte_security_ipsec_sa_options`` > + will be updated to support more features. > And we may have a reserved bit fields for rest of the vacant bits so that ABI > is > not broken > When a new bit field is added. > > http://patches.dpdk.org/project/dpdk/patch/20210630112049.3747-1- > march...@marvell.com/ > http://patches.dpdk.org/project/dpdk/patch/20210705131335.21070-1- > ktejas...@marvell.com/ I have sent the consolidated deprecation notice for all three features. Can you guys Ack it? https://mails.dpdk.org/archives/dev/2021-July/215906.html Also, please send deprecation notice for changes in ipsec xform as well.
Re: [dpdk-dev] [PATCH] doc: announce IPsec SA config option struct changes
> Proposing following new field for IPsec tunnel header verification > in the structure ``rte_security_ipsec_sa_options``. > enum rte_security_ipsec_tunnel_verify_mode tunnel_hdr_verify; > > It is used to indicate whether outer header verification > need to be done as part of inbound IPsec processing. > > https://mails.dpdk.org/archives/dev/2021-July/213484.html > > Signed-off-by: Tejasree Kondoj > --- Marking this patch as Not applicable, As a new patch is submitted for consolidating all notices for same structure. https://mails.dpdk.org/archives/dev/2021-July/215906.html
Re: [dpdk-dev] [PATCH] doc: announce SA config option struct changes
> Proposing following two new fields for IPsec inner checksum > configuration in the structure ``rte_security_ipsec_sa_options``. > uint32_t ip_csum_enable : 1; > uint32_t l4_csum_enable : 1; > > With these config options, per SA, application can specify if > the inner checksum(compute/verify) to be offloaded to the > security device. > > https://mails.dpdk.org/archives/dev/2021-June/212977.html > > Signed-off-by: Archana Muniganti > --- Marking this patch as Not applicable, As a new patch is submitted for consolidating all notices for same structure. https://mails.dpdk.org/archives/dev/2021-July/215906.html
Re: [dpdk-dev] [EXT] [PATCH] compress/mlx5: fix level translation in xform API
> Compression Level is interpreted by each PMD differently.
> However, lower numbers give faster compression
> at the expense of compression ratio, while higher numbers
> may give better compression ratios but are likely slower.
> The level affects the block size, which affects performance,
> the bigger the block, the faster the compression is.
>
> The problem was that higher levels caused bigger blocks:
> size = min_block_size - 1 + level.
>
> the solution is to reverse the above:
> size = max_block_size + 1 - level.
>
> Fixes: 39a2c8715f8f ("compress/mlx5: add transformation operations")
> Cc: ma...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> ---
This patch is not acked, hence not applied for RC3.
@Thomas Monjalon can you pick it directly if it gets acked?
Re: [dpdk-dev] [dpdk-stable] [PATCH v5] doc: spell check
29/07/2021 18:48, Henry Nadeau: > Spell checked and corrected documentation. If there are any > errors, or I have changed something that wasn't an error please reach out to > me so I can update the dictionary. > > Cc: sta...@dpdk.org > > Signed-off-by: Henry Nadeau Applied, thanks.
[dpdk-dev] [PATCH 0/4] cryptodev and security ABI improvements
This is a first series planned for ABI improvements in cryptodev and security library. Other planned improvements under development. - cryptodev: export driver interface as internal - cryptodev: split and hide struct rte_cryptodev, struct rte_cryptodev_data - cryptodev: hide struct rte_cryptodev_sym_session, rte_cryptodev_asym_session - security: hide struct rte_security_session Request everyone to review and contribute for the missing pieces to improve ABI stability. Akhil Goyal (4): cryptodev: remove LIST_END enumerators cryptodev: promote asym APIs to stable security: hide internal API security: add reserved bitfields app/test/test_cryptodev_asym.c | 4 ++-- devtools/libabigail.abignore | 4 drivers/crypto/qat/qat_asym.c | 2 +- lib/cryptodev/rte_crypto_asym.h| 4 lib/cryptodev/rte_cryptodev.h | 10 -- lib/cryptodev/version.map | 24 +--- lib/security/rte_security.h| 6 ++ lib/security/rte_security_driver.h | 2 +- lib/security/version.map | 7 ++- 9 files changed, 33 insertions(+), 30 deletions(-) -- 2.25.1
[dpdk-dev] [PATCH 1/4] cryptodev: remove LIST_END enumerators
Remove *_LIST_END enumerators from asymmetric crypto
lib to avoid ABI breakage for every new addition in
enums.
Signed-off-by: Akhil Goyal
---
app/test/test_cryptodev_asym.c | 4 ++--
drivers/crypto/qat/qat_asym.c | 2 +-
lib/cryptodev/rte_crypto_asym.h | 4
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 847b074a4f..afa0e91a45 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -542,7 +542,7 @@ test_one_case(const void *test_case, int sessionless)
printf(" %u) TestCase %s %s\n", test_index++,
tc.modex.description, test_msg);
} else {
- for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+ for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++)
{
if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
if (tc.rsa_data.op_type_flags & (1 << i)) {
if (tc.rsa_data.key_exp) {
@@ -1028,7 +1028,7 @@ static inline void print_asym_capa(
rte_crypto_asym_xform_strings[capa->xform_type]);
printf("operation supported -");
- for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+ for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
/* check supported operations */
if (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
printf(" %s",
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 85973812a8..026625a4d2 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev *dev,
err = -EINVAL;
goto error;
}
- } else if (xform->xform_type >= RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
+ } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
|| xform->xform_type <= RTE_CRYPTO_ASYM_XFORM_NONE) {
QAT_LOG(ERR, "Invalid asymmetric crypto xform");
err = -EINVAL;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 9c866f553f..5edf658572 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
*/
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
- RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
- /**< End of list */
};
/**
@@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
/**< DH Public Key generation operation */
RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
/**< DH Shared Secret compute operation */
- RTE_CRYPTO_ASYM_OP_LIST_END
};
/**
@@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
/**< RSA PKCS#1 OAEP padding scheme */
RTE_CRYPTO_RSA_PADDING_PSS,
/**< RSA PKCS#1 PSS padding scheme */
- RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
};
/**
--
2.25.1
[dpdk-dev] [PATCH 2/4] cryptodev: promote asym APIs to stable
Asymmetric crypto APIs have been stable from
quite some time, hence moving them from experimental
to stable in DPDK 21.11
Signed-off-by: Akhil Goyal
---
lib/cryptodev/rte_cryptodev.h | 10 --
lib/cryptodev/version.map | 24 +---
2 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 11f4e6fdbf..425f459143 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -247,7 +247,6 @@ rte_cryptodev_sym_capability_get(uint8_t dev_id,
* - Return description of the asymmetric crypto capability if exist.
* - Return NULL if the capability not exist.
*/
-__rte_experimental
const struct rte_cryptodev_asymmetric_xform_capability *
rte_cryptodev_asym_capability_get(uint8_t dev_id,
const struct rte_cryptodev_asym_capability_idx *idx);
@@ -317,7 +316,6 @@ rte_cryptodev_sym_capability_check_aead(
* - Return 1 if the op type is supported
* - Return 0 if unsupported
*/
-__rte_experimental
int
rte_cryptodev_asym_xform_capability_check_optype(
const struct rte_cryptodev_asymmetric_xform_capability *capability,
@@ -333,7 +331,6 @@ rte_cryptodev_asym_xform_capability_check_optype(
* - Return 0 if the parameters are in range of the capability.
* - Return -1 if the parameters are out of range of the capability.
*/
-__rte_experimental
int
rte_cryptodev_asym_xform_capability_check_modlen(
const struct rte_cryptodev_asymmetric_xform_capability *capability,
@@ -395,7 +392,6 @@ rte_cryptodev_get_aead_algo_enum(enum
rte_crypto_aead_algorithm *algo_enum,
* - Return -1 if string is not valid
* - Return 0 if the string is valid
*/
-__rte_experimental
int
rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
const char *xform_string);
@@ -1192,7 +1188,6 @@ rte_cryptodev_sym_session_create(struct rte_mempool
*mempool);
* - On success return pointer to asym-session
* - On failure returns NULL
*/
-__rte_experimental
struct rte_cryptodev_asym_session *
rte_cryptodev_asym_session_create(struct rte_mempool *mempool);
@@ -1223,7 +1218,6 @@ rte_cryptodev_sym_session_free(struct
rte_cryptodev_sym_session *sess);
* - -EINVAL if session is NULL.
* - -EBUSY if not all device private data has been freed.
*/
-__rte_experimental
int
rte_cryptodev_asym_session_free(struct rte_cryptodev_asym_session *sess);
@@ -1264,7 +1258,6 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
* - -ENOTSUP if crypto device does not support the crypto transform.
* - -ENOMEM if the private session could not be allocated.
*/
-__rte_experimental
int
rte_cryptodev_asym_session_init(uint8_t dev_id,
struct rte_cryptodev_asym_session *sess,
@@ -1299,7 +1292,6 @@ rte_cryptodev_sym_session_clear(uint8_t dev_id,
* - 0 if successful.
* - -EINVAL if device is invalid or session is NULL.
*/
-__rte_experimental
int
rte_cryptodev_asym_session_clear(uint8_t dev_id,
struct rte_cryptodev_asym_session *sess);
@@ -1336,7 +1328,6 @@ rte_cryptodev_sym_get_existing_header_session_size(
* @return
* Size of the asymmetric header session.
*/
-__rte_experimental
unsigned int
rte_cryptodev_asym_get_header_session_size(void);
@@ -1364,7 +1355,6 @@ rte_cryptodev_sym_get_private_session_size(uint8_t
dev_id);
* - Size of the asymmetric private data, if successful
* - 0 if device is invalid or does not have private session
*/
-__rte_experimental
unsigned int
rte_cryptodev_asym_get_private_session_size(uint8_t dev_id);
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 9f04737aed..707a2e32d3 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -1,4 +1,4 @@
-DPDK_21 {
+DPDK_22 {
global:
rte_crypto_aead_algorithm_strings;
@@ -9,6 +9,18 @@ DPDK_21 {
rte_crypto_cipher_operation_strings;
rte_crypto_op_pool_create;
rte_cryptodev_allocate_driver;
+
+ rte_cryptodev_asym_capability_get;
+ rte_cryptodev_asym_get_header_session_size;
+ rte_cryptodev_asym_get_private_session_size;
+ rte_cryptodev_asym_get_xform_enum;
+ rte_cryptodev_asym_session_clear;
+ rte_cryptodev_asym_session_create;
+ rte_cryptodev_asym_session_free;
+ rte_cryptodev_asym_session_init;
+ rte_cryptodev_asym_xform_capability_check_modlen;
+ rte_cryptodev_asym_xform_capability_check_optype;
+
rte_cryptodev_callback_register;
rte_cryptodev_callback_unregister;
rte_cryptodev_close;
@@ -61,16 +73,6 @@ DPDK_21 {
EXPERIMENTAL {
global:
- rte_cryptodev_asym_capability_get;
- rte_cryptodev_asym_get_header_session_size;
- rte_cryptodev_asym_get_private_session_size;
- rte_cryptodev_asym_get_xform_enum;
- rte_cryptodev_asym_session_clear;
- rte_cryptodev_asym_session_create;
-
[dpdk-dev] [PATCH 3/4] security: hide internal API
rte_security_dynfield_register() is an internal
API to be used by the driver, hence moving it to internal.
Signed-off-by: Akhil Goyal
---
lib/security/rte_security_driver.h | 2 +-
lib/security/version.map | 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/security/rte_security_driver.h
b/lib/security/rte_security_driver.h
index 938373205c..b0253e962e 100644
--- a/lib/security/rte_security_driver.h
+++ b/lib/security/rte_security_driver.h
@@ -89,7 +89,7 @@ typedef int (*security_session_stats_get_t)(void *device,
struct rte_security_session *sess,
struct rte_security_stats *stats);
-__rte_experimental
+__rte_internal
int rte_security_dynfield_register(void);
/**
diff --git a/lib/security/version.map b/lib/security/version.map
index 22775558c8..bd91d9a16c 100644
--- a/lib/security/version.map
+++ b/lib/security/version.map
@@ -16,8 +16,13 @@ EXPERIMENTAL {
global:
rte_security_dynfield_offset;
- rte_security_dynfield_register;
rte_security_get_userdata;
rte_security_session_stats_get;
rte_security_session_update;
};
+
+INTERNAL {
+ global:
+
+ rte_security_dynfield_register;
+};
--
2.25.1
[dpdk-dev] [PATCH 4/4] security: add reserved bitfields
In struct rte_security_ipsec_sa_options, for every new option
added, there is an ABI breakage, to avoid, a reserved_opts
bitfield is added to for the remaining bits available in the
structure.
Now for every new sa option, these reserved_opts can be reduced
and new option can be added. A corresponding exception is also
added in devtools/libabigail.abignore
Signed-off-by: Akhil Goyal
---
devtools/libabigail.abignore | 4
lib/security/rte_security.h | 6 ++
2 files changed, 10 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 93158405e0..5d8da28e55 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -52,3 +52,7 @@
; https://sourceware.org/bugzilla/show_bug.cgi?id=28060
[suppress_type]
name = rte_eth_dev_data
+
+; Ignore changes in reserved_opts bitfield of rte_security_ipsec_sa_options
+[suppress_variable]
+ name = reserved_opts
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 88d31de0a6..4606425e8d 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -181,6 +181,12 @@ struct rte_security_ipsec_sa_options {
* * 0: Disable per session security statistics collection for this SA.
*/
uint32_t stats : 1;
+
+ /** Reserved bit fields for future extension
+*
+* Note: reduce number of bits in reserved_opts for every new option
+*/
+ uint32_t reserved_opts : 24;
};
/** IPSec security association direction */
--
2.25.1
Re: [dpdk-dev] [PATCH 0/4] cryptodev and security ABI improvements
> Subject: [PATCH 0/4] cryptodev and security ABI improvements > > This is a first series planned for ABI improvements > in cryptodev and security library. > > Other planned improvements under development. > - cryptodev: export driver interface as internal > - cryptodev: split and hide struct rte_cryptodev, struct > rte_cryptodev_data > - cryptodev: hide struct rte_cryptodev_sym_session, > rte_cryptodev_asym_session > - security: hide struct rte_security_session > > Request everyone to review and contribute for the missing > pieces to improve ABI stability. > Forgot to mention, this is an RFC series for DPDK 21.11 > Akhil Goyal (4): > cryptodev: remove LIST_END enumerators > cryptodev: promote asym APIs to stable > security: hide internal API > security: add reserved bitfields > > app/test/test_cryptodev_asym.c | 4 ++-- > devtools/libabigail.abignore | 4 > drivers/crypto/qat/qat_asym.c | 2 +- > lib/cryptodev/rte_crypto_asym.h| 4 > lib/cryptodev/rte_cryptodev.h | 10 -- > lib/cryptodev/version.map | 24 +--- > lib/security/rte_security.h| 6 ++ > lib/security/rte_security_driver.h | 2 +- > lib/security/version.map | 7 ++- > 9 files changed, 33 insertions(+), 30 deletions(-) > > -- > 2.25.1
[dpdk-dev] [PATCH] net/bnxt: fix incorrect action record calculation
For Thor, the number of action records is being wrongly configured
to 128 because of incorrect definition of divider. This results in
an incorrect number of action records being negotiated with the FW.
Remove the divider from the templates and delete the logic which
uses the field in the resource manager logic.
Fixes: 3fe124d2536c ("net/bnxt: support Thor platform")
Cc: sta...@dpdk.org
Signed-off-by: Ajit Khaparde
Tested-by: Shuanglin Wang
---
drivers/net/bnxt/tf_core/tf_device_p58.h | 14
drivers/net/bnxt/tf_core/tf_rm.c | 22 ---
.../generic_templates/ulp_template_db_tbl.c | 2 +-
3 files changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/net/bnxt/tf_core/tf_device_p58.h
b/drivers/net/bnxt/tf_core/tf_device_p58.h
index b5e2598cb6..66b0f4e983 100644
--- a/drivers/net/bnxt/tf_core/tf_device_p58.h
+++ b/drivers/net/bnxt/tf_core/tf_device_p58.h
@@ -84,42 +84,36 @@ struct tf_rm_element_cfg tf_tbl_p58[TF_TBL_TYPE_MAX] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_1,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_COMPACT_ACT_RECORD] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_FULL_ACT_RECORD,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_1,
.slices = 1,
- .divider = 8,
},
/* Policy - Encaps in bank 2 */
[TF_TBL_TYPE_ACT_ENCAP_8B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_ENCAP_16B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_ENCAP_32B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_ENCAP_64B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
/* Policy - Modify in bank 2 with Encaps */
[TF_TBL_TYPE_ACT_MODIFY_8B] = {
@@ -127,56 +121,48 @@ struct tf_rm_element_cfg tf_tbl_p58[TF_TBL_TYPE_MAX] = {
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_MODIFY_16B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_MODIFY_32B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_MODIFY_64B] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
.slices = 1,
- .divider = 8,
},
/* Policy - SP in bank 0 */
[TF_TBL_TYPE_ACT_SP_SMAC] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_0,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_SP_SMAC_IPV4] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_SP_SMAC,
.hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_0,
.slices = 1,
- .divider = 8,
},
[TF_TBL_TYPE_ACT_SP_SMAC_IPV6] = {
.cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
.parent_subtype = TF_TBL_TYPE_ACT_SP_SMAC,
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: fix incorrect action record calculation
On Sat, Jul 31, 2021 at 2:25 AM Thomas Monjalon wrote:
>
> 31/07/2021 06:48, Ajit Khaparde:
> > For Thor, the number of action records is being wrongly configured
> > to 128 because of incorrect definition of divider. This results in
> > an incorrect number of action records being negotiated with the FW.
> > Remove the divider from the templates and delete the logic which
> > uses the field in the resource manager logic.
> >
> > Fixes: 3fe124d2536c ("net/bnxt: support Thor platform")
> > Cc: sta...@dpdk.org
> >
> > Tested-by: Shuanglin Wang
> > Signed-off-by: Ajit Khaparde
>
> This block should be in chronological order,
> so the test comes after the Sign-off.
I had cleaned it up. But the automated script put it in the end
and I missed it.
Sending a v2 with that fixed.
>
>
>
Re: [dpdk-dev] [PATCH] net/bnxt: fix incorrect action record calculation
On Sat, Jul 31, 2021 at 7:49 AM Ajit Khaparde
wrote:
>
> For Thor, the number of action records is being wrongly configured
> to 128 because of incorrect definition of divider. This results in
> an incorrect number of action records being negotiated with the FW.
> Remove the divider from the templates and delete the logic which
> uses the field in the resource manager logic.
>
> Fixes: 3fe124d2536c ("net/bnxt: support Thor platform")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ajit Khaparde
> Tested-by: Shuanglin Wang
Patch applied to dpdk-next-net-brcm.
> ---
> drivers/net/bnxt/tf_core/tf_device_p58.h | 14
> drivers/net/bnxt/tf_core/tf_rm.c | 22 ---
> .../generic_templates/ulp_template_db_tbl.c | 2 +-
> 3 files changed, 1 insertion(+), 37 deletions(-)
>
> diff --git a/drivers/net/bnxt/tf_core/tf_device_p58.h
> b/drivers/net/bnxt/tf_core/tf_device_p58.h
> index b5e2598cb6..66b0f4e983 100644
> --- a/drivers/net/bnxt/tf_core/tf_device_p58.h
> +++ b/drivers/net/bnxt/tf_core/tf_device_p58.h
> @@ -84,42 +84,36 @@ struct tf_rm_element_cfg tf_tbl_p58[TF_TBL_TYPE_MAX] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_1,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_COMPACT_ACT_RECORD] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_FULL_ACT_RECORD,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_1,
> .slices = 1,
> - .divider = 8,
> },
> /* Policy - Encaps in bank 2 */
> [TF_TBL_TYPE_ACT_ENCAP_8B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_ENCAP_16B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_ENCAP_32B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_ENCAP_64B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> /* Policy - Modify in bank 2 with Encaps */
> [TF_TBL_TYPE_ACT_MODIFY_8B] = {
> @@ -127,56 +121,48 @@ struct tf_rm_element_cfg tf_tbl_p58[TF_TBL_TYPE_MAX] = {
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_MODIFY_16B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_MODIFY_32B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_MODIFY_64B] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_ENCAP_8B,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_2,
> .slices = 1,
> - .divider = 8,
> },
> /* Policy - SP in bank 0 */
> [TF_TBL_TYPE_ACT_SP_SMAC] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_PARENT,
> .hcapi_type = CFA_RESOURCE_TYPE_P58_SRAM_BANK_0,
> .slices = 1,
> - .divider = 8,
> },
> [TF_TBL_TYPE_ACT_SP_SMAC_IPV4] = {
> .cfg_type= TF_RM_ELEM_CFG_HCAPI_BA_CHILD,
> .parent_subtype = TF_TBL_TYPE_ACT_SP_SMAC,
> .hcapi_type = CFA_R
Re: [dpdk-dev] [PATCH v2] doc: update atomic operation deprecation
23/07/2021 11:49, Joyce Kong:
> Update the incorrect description about atomic operations
> with provided wrappers in deprecation doc[1].
>
> [1]https://mails.dpdk.org/archives/dev/2021-July/21.html
>
> Fixes: 7518c5c4ae6a ("doc: announce adoption of C11 atomic operations
> semantics")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Joyce Kong
> Reviewed-by: Ruifeng Wang
Applied, thanks.
Considering all the questions regarding usage of atomics,
I still think we need a documentation about their correct use.
Re: [dpdk-dev] [PATCH] doc: announce removal of ABIs in PCI bus driver
27/07/2021 10:44, Bruce Richardson: > On Mon, Jul 26, 2021 at 05:56:17AM +, Xia, Chenbo wrote: > > From: Yigit, Ferruh > > > On 7/23/2021 8:39 AM, Xia, Chenbo wrote: > > > > From: dev On Behalf Of Chenbo Xia > > > >> +* pci: To reduce unnecessary ABIs exposed by DPDK bus driver, > > > "rte_bus_pci.h" > > > >> + will be made internal in 21.11 and macros/data structures/functions > > > defined > > > >> + in the header will not be considered as ABI anymore. This change is > > > >> inspired > > > >> + by the RFC > > > https://patchwork.dpdk.org/project/dpdk/list/?series=17176. > > > > > > > > I see there's some ABI improvement work on-going and I think it could be > > > part of > > > > the work. If it makes sense to you, I'd like some ACKs. > > > > > > > > > > Acked-by: Ferruh Yigit > > > > > > I am for reducing the public ABI as much as possible. How big will the > > > change > > > be? Is the 'rte_bus_pci.h' used other than './drivers/bus/pci/'? > > > > I don't see big change here. And I am not sure if I understand your second > > question. The rte_bus_pci.h will still be used by drivers (maybe remove the > > rte prefix and change the file name). > > > The file itself will still be exported in some cases, where the end-user > has their own drivers which need to be compiled, so I'd recommend keeping > the rte_ prefix. However, I think making all bus APIs internal-only to DPDK > is a good idea. I don't understand how it can exported _and_ internal. And about the rte_ prefix, it should be kept even if it used only in internal drivers because it prevent from namespace clash with other libraries included by the drivers. As a rule we should always have rte_ prefix for each symbol used outside of its own library. That said I am OK with the direction of hiding PCI bus API. Applied, thanks.
Re: [dpdk-dev] [PATCH] doc: announce common prefix for ethdev
> > > > > > Announce adding 'RTE_ETH_' prefix to all public ethdev macros/enums > > > on > > > > > > v21.11. > > > > > > Backward compatibility macros will be added on v21.11 and they will > > > > > > be > > > > > > removed on v22.11. > > > > > > > > > > > > Signed-off-by: Ferruh Yigit > > > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > > > +* ethdev: Will add 'RTE_ETH_' prefix to all ethdev macros/enums in > > > v21.11. Macros > > > > > > + will be added for backward compatibility. Backward compatibility > > > macros will be > > > > > > + removed on v22.11. A few old backward compatibility macros from > > > 2013 that does > > > > > > + not have proper prefix will be removed on v21.11. > > > > > > + > > > > > > > > > > Acked-by: Andrew Rybchenko > > > > Acked-by: Jerin Jacob > > > Acked-by: Ajit Khaparde > > Acked-by: Raslan Darawsheh > Acked-by: Tyler Retzlaff Applied, thanks.
[dpdk-dev] [dpdk-announce] release candidate 21.08-rc3
A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v21.08-rc3 There are 70 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_21_08.html Please check all pending announces of deprecations for 21.11. https://patches.dpdk.org/project/dpdk/list/?q=announce You may share some release validation results by replying to this message at dev@dpdk.org. DPDK 21.08-rc4 is expected on Wednesday. Thank you everyone
Re: [dpdk-dev] [PATCH] doc: announce extension of crypto data-unit length
On Wed, Apr 14, 2021 at 1:15 PM Thomas Monjalon wrote: > > The struct member dataunit_len is introduced in DPDK 21.05. > It is limited to 16 bits to fit a padding hole in 32-bit build. > This means the maximum data-unit length is 64 KB. > Some use cases may benefit of a bigger size as the proposed 32 bits. > > Signed-off-by: Thomas Monjalon Acked-by: Ajit Khaparde > --- > doc/guides/rel_notes/deprecation.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 2afc84c396..a17f30c2ff 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -118,6 +118,10 @@ Deprecation Notices >consistent with existing outer header checksum status flag naming, which >should help in reducing confusion about its usage. > > +* cryptodev: The field ``dataunit_len`` of the ``struct > rte_crypto_cipher_xform`` > + has a limited size ``uint16_t``. > + It will be moved and extended as ``uint32_t`` in DPDK 21.11. > + > * eventdev: The structure ``rte_event_eth_rx_adapter_queue_conf`` will be >extended to include ``rte_event_eth_rx_adapter_event_vector_config`` > elements >and the function ``rte_event_eth_rx_adapter_queue_event_vector_config`` > will > -- > 2.31.1 >
