回复: [EXT] [PATCH 1/2] lib/cryptodev/: Add SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK
Hi all: SM3 and SM4 are widely used in China, and they are Chinese national standards. I'm very to tell you that I didn't find the relevant RFC documents for SM3 and SM4, but I found the national standards for SM3 and SM4 in the full text disclosure system of Chinese national standards, but they are all in Chinese. The links are shown below: SM3: http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=45B1A67F20F3BF339211C391E9278F5E SM4: http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=7803DE42D3BC5E80B0C3E5D8E873D56A If these modes(SM3_HMAC / SM4_OFB / SM4_CFB) are not necessary, I can resubmit a patch, delete the corresponding test cases for these modes, and retain only the test cases for the mods currently supported by DPdK. -邮件原件- 发件人: Akhil Goyal 发送时间: 2023年3月16日 18:43 收件人: Sunyang Wu ; dev@dpdk.org 抄送: kai...@intel.com 主题: RE: [EXT] [PATCH 1/2] lib/cryptodev/: Add SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK > Add SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK. > Can you give reference to some documentation for each of these modes. Cannot find RFCs for SM3_HMAC etc. > Signed-off-by: Sunyang Wu > --- > lib/cryptodev/rte_crypto_sym.h | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-)
Re: [PATCH v6] eal/unix: fix thread creation
On Fri, Mar 17, 2023 at 10:24 PM Tyler Retzlaff
wrote:
>
> On Fri, Mar 17, 2023 at 07:52:29PM +0100, David Marchand wrote:
> > From: Tyler Retzlaff
> >
> > In rte_thread_create setting affinity after pthread_create may fail.
> > Such a failure should result in the entire rte_thread_create failing
> > but doesn't.
> >
> > Additionally if there is a failure to set affinity a race exists where
> > the creating thread will free ctx and depending on scheduling of the new
> > thread it may also free ctx (double free).
> >
> > Resolve the above by setting the affinity from the newly created thread
> > using a condition variable to signal the completion of the thread
> > start wrapper having completed.
> >
> > Since we are now waiting for the thread start wrapper to complete we can
> > allocate the thread start wrapper context on the stack. While here clean
> > up the variable naming in the context to better highlight the fields of
> > the context require synchronization between the creating and created
> > thread.
> >
> > Fixes: ce6e911d20f6 ("eal: add thread lifetime API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Tyler Retzlaff
> > Signed-off-by: David Marchand
> > ---
>
> Looks good to me, not sure if you need a Reviewed-by: from me for the
> changes but here is one anyway.
>
> v5
> Reviewed-by: Tyler Retzlaff
Thanks for the review, I'll keep your SoB only on the patch.
--
David Marchand
Re: [PATCH v6] eal/unix: fix thread creation
On Fri, Mar 17, 2023 at 7:52 PM David Marchand
wrote:
>
> From: Tyler Retzlaff
>
> In rte_thread_create setting affinity after pthread_create may fail.
> Such a failure should result in the entire rte_thread_create failing
> but doesn't.
>
> Additionally if there is a failure to set affinity a race exists where
> the creating thread will free ctx and depending on scheduling of the new
> thread it may also free ctx (double free).
>
> Resolve the above by setting the affinity from the newly created thread
> using a condition variable to signal the completion of the thread
> start wrapper having completed.
>
> Since we are now waiting for the thread start wrapper to complete we can
> allocate the thread start wrapper context on the stack. While here clean
> up the variable naming in the context to better highlight the fields of
> the context require synchronization between the creating and created
> thread.
>
> Fixes: ce6e911d20f6 ("eal: add thread lifetime API")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Tyler Retzlaff
> Signed-off-by: David Marchand
Applied thanks.
--
David Marchand
RE: [PATCH v8] app/procinfo: display eventdev xstats
> +static void
> +get_eventdev_xstats(uint8_t dev_id,
>+You can separate this function (basically the code inside this function) into
>3 functions, one for reset and one for display stats values.
>+And move the common code(stats storage calculation logic and getting stats
>name logic) to a another function, so you can call that function from reset
>and display functions.
This can be done, but we will have 2 API calls for each now, if we have
this flag we will be able to reset withing one API call.
> +
> + if (enable_dump_eventdev_xstats) {
> + ret = rte_event_dev_dump(evdev_id, stdout);
> + if (ret)
> + rte_panic("dump failed with err=%d\n", ret);
> + }
> +
> + process_eventdev_xstats(false);
> +
> + if (enable_eventdev_reset_xstats)
> + process_eventdev_xstats(true);
>+For easy code readability, I would say have a sperate function for reset
>stats, do not mix display and resets by just passing reset bool value.
Same for this one as above, one API call to the xstats instead of two
separate calls if we use this flag.
Thanks,
Reshma
