DPDK patches and discussions
 help / color / mirror / Atom feed
From: =?gb18030?B?1ebO0rfnssk=?= <1534057243@qq.com>
To: =?gb18030?B?QW5hbnlldiwgS29uc3RhbnRpbg==?=
	<konstantin.ananyev@intel.com>, =?gb18030?B?ZGV2?= <dev@dpdk.org>
Subject: [dpdk-dev] =?gb18030?b?u9i4tKO6UkU6ILvYuLSjulJFOiAgVGhyZWFkIHNh?= =?gb18030?q?fety_in_rte=5Facl?=
Date: Mon, 8 Jan 2018 21:43:18 +0800	[thread overview]
Message-ID: <tencent_8FAB07F12F9A263C136DB742A4A48031BA07@qq.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725880E388DC@irsmsx105.ger.corp.intel.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 3174 bytes --]

>> 2. Is it safe that one
>> thread will run  "rte_acl_classify" when another thread tries to add new rules to same ctx? thanks,

>Just add new rules is safe, but applying them (calling rte_acl_build()) is not.

> In my case, there are two process sharing hugepage memory£¨struct rte_acl_ctx£©,  one process call 'rte_acl_build' to add and apply rule, another process call  frequently 'rte_acl_classify' to > match rule, does it need to add lock? if not, is there other method to implement this safely?

>Yes, you'll need some sort of synchronization.
>Lock (or rwlock) is one option, but as build could take quite long time - probably not the best one.
>Another way - have a struct cthat ontains pointers to 2 ctx and an index for active one.
>Then you can do classify() on active one while doing add_rules/build on second one.
>Then when the second one is re-build you can switch an active index to it.
>I think librte_table uses that method.
>Of course you might need a reference counter or some other way to deternine that
>no-one is using old copy anymore and it is free to update it again.
>Konstantin 


thanks very much
------------------ ԭʼÓʼþ ------------------
·¢¼þÈË: "Ananyev, Konstantin";<konstantin.ananyev@intel.com>;
·¢ËÍʱ¼ä: 2018Äê1ÔÂ8ÈÕ(ÐÇÆÚÒ») ÍíÉÏ8:17
ÊÕ¼þÈË: "ÕæÎÒ·ç²É"<1534057243@qq.com>;"dev"<dev@dpdk.org>;

Ö÷Ìâ: RE: »Ø¸´£ºRE: [dpdk-dev] Thread safety in rte_acl






>> 2. Is it safe that one
>> thread will run  "rte_acl_classify" when another thread tries to add new rules to same ctx? thanks,

>Just add new rules is safe, but applying them (calling rte_acl_build()) is not.

> In my case, there are two process sharing hugepage memory£¨struct rte_acl_ctx£©,  one process call 'rte_acl_build' to add and apply rule, another process call  frequently 'rte_acl_classify' to > match rule, does it need to add lock? if not, is there other method to implement this safely?

Yes, you'll need some sort of synchronization.
Lock (or rwlock) is one option, but as build could take quite long time - probably not the best one.
Another way - have a struct cthat ontains pointers to 2 ctx and an index for active one.
Then you can do classify() on active one while doing add_rules/build on second one.
Then when the second one is re-build you can switch an active index to it.
I think librte_table uses that method.
Of course you might need a reference counter or some other way to deternine that
no-one is using old copy anymore and it is free to update it again.
Konstantin 


------------------ ԭʼÓʼþ ------------------
·¢¼þÈË: "Ananyev, Konstantin";<konstantin.ananyev@intel.com>;
·¢ËÍʱ¼ä: 2018Äê1ÔÂ8ÈÕ(ÐÇÆÚÒ») ÍíÉÏ7:42
ÊÕ¼þÈË: "ÕæÎÒ·ç²É"<1534057243@qq.com>;"dev"<dev@dpdk.org>;
Ö÷Ìâ: RE: [dpdk-dev] Thread safety in rte_acl

> 
> Hi, I have two questions : 1. Is it safe that multiple threads will run "rte_acl_classify" in parallel  (on the same ctx )?

Yes.

> 2. Is it safe that one
> thread will run  "rte_acl_classify" when another thread tries to add new rules to same ctx? thanks,

Just add new rules is safe, but applying them (calling rte_acl_build()) is not.
Konstantin

  reply	other threads:[~2018-01-08 13:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  5:42 [dpdk-dev] Thread safety in rte_acl  =?gb18030?B?1ebO0rfnssk=?=
2018-01-08 11:42 ` Ananyev, Konstantin
2018-01-08 11:59   ` [dpdk-dev] =?gb18030?b?u9i4tKO6UkU6ICBUaHJlYWQgc2FmZXR5IGluIHJ0?= =?gb18030?q?e=5Facl?=  =?gb18030?B?1ebO0rfnssk=?=
2018-01-08 12:17     ` [dpdk-dev] 回复:RE: Thread safety in rte_acl Ananyev, Konstantin
2018-01-08 13:43       `  =?gb18030?B?1ebO0rfnssk=?= [this message]
2018-01-10  2:50       ` [dpdk-dev] =?gb18030?b?u9i4tKO6UkU6ILvYuLSjulJFOiAgVGhyZWFkIHNh?= =?gb18030?q?fety_in_rte=5Facl?=  =?gb18030?B?1ebO0rfnssk=?=
2018-01-10  4:00         ` [dpdk-dev] 回复:RE: 回复:RE: Thread safety in rte_acl Ramia, Kannan Babu
2018-01-10 11:46         ` Ananyev, Konstantin
2018-01-15  2:01           ` [dpdk-dev] =?gb18030?b?u9i4tKO6UkU6ILvYuLSjulJFOiC72Li0o7pSRTog?= =?gb18030?q?_Thread_safety_in_rte=5Facl?=  =?gb18030?B?1ebO0rfnssk=?=
2018-01-15 10:34             ` [dpdk-dev] 回复:RE: 回复:RE: 回复:RE: Thread safety in rte_acl Ananyev, Konstantin
2018-01-15 10:41               ` [dpdk-dev] =?gb18030?b?u9i4tKO6UkU6ILvYuLSjulJFOiC72Li0o7pSRTogu9i4tKO6UkU6ICBUaHJlYWQgc2FmZXR5IGluIHJ0ZV9hY2w=?=  =?gb18030?B?1ebO0rfnssk=?=
2018-01-08 13:06     ` [dpdk-dev] 回复:RE: Thread safety in rte_acl Ramia, Kannan Babu
2018-01-08 13:42       ` [dpdk-dev] =?gb18030?b?u9i4tKO6UkU6ICC72Li0o7pSRTogIFRocmVhZCBz?= =?gb18030?q?afety_in_rte=5Facl?=  =?gb18030?B?1ebO0rfnssk=?=

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tencent_8FAB07F12F9A263C136DB742A4A48031BA07@qq.com \
    --to=1534057243@qq.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).