I’m trying to understand what will be the benefit of sending packet to main core.
Even if you send packet to main core which is possible, you will not get much benefit of that action as you cennot send packet to the process node. Why you cannot build control plane feature as separate application which programs VPP via API instead of trying to insert control plane into dataplane? On 9 Mar 2017, at 09:43, wang.hu...@zte.com.cn<mailto:wang.hu...@zte.com.cn> wrote: thanks a lot to xiyun! which kind of scenario you want to pass the pkt from work thread to main thread. Although the pkt is already processed by work thread and still need to put it to main thread for further processing? What’s your real case☺ //In fact, our use case is that, we wanna do some control-plane(slow-path) things in main thread instead of worker thread, such as dynamic routing protocol OSPF/BGP. But there is not a high performance method to do this. The handoff mechanism which queuing between two different work threads maybe a good way, we will deep learning it first. And one more question, vlib_process_signal_event can be called in worker thread ? No concurrency problem? Is it safe when there are Multiple worker thread ? 王辉 wanghui IT开发工程师 IT Development Engineer 虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D Institute/Wireless Product Operation Division 原始邮件 发件人： ＜xiyun...@intel.com<mailto:xiyun...@intel.com>＞; 收件人： ＜dbar...@cisco.com<mailto:dbar...@cisco.com>＞;王辉10067165; ＜hongjun...@intel.com<mailto:hongjun...@intel.com>＞; ＜damar...@cisco.com<mailto:damar...@cisco.com>＞; 抄送人： ＜vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>＞;顾剑10036178;赵志刚10017628;潘凤艳00024606; 日 期 ：2017年03月09日 14:38 主 题 ：RE: [vpp-dev] R Signal events between graph nodes within different threads Do be a little confusion. AFAIK, the original question from ZTE, key message should be: so we want to transfer some packet to main thread to continue processing Is this right, @ZTE wanghui which kind of scenario you want to pass the pkt from work thread to main thread. Although the pkt is already processed by work thread and still need to put it to main thread for further processing? What’s your real case☺ Did you consider the handoff mechanism before? But it seems to pkt queuing btw two different work threads Thanks. Regards BTW: In my understanding, Hongjun and ZTE guys mentions following two ways (1) vlib_process_signal_event it seems to be just pass the event/message(Event type + opaque data) to process nodes which belong to main threads, instead of passing pkt from worker thread to main thread. It is asynchronous way. (2) vl_api_rpc_call_main_thread it is synchronous method to call the RPC function belongs to main thread context, seems to be also not pkt passing btw two threads. Let Dave and Damjan to correct me☺. Thanks! From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Dave Barach (dbarach) Sent: Wednesday, March 8, 2017 9:47 PM To: wang.hu...@zte.com.cn<mailto:wang.hu...@zte.com.cn>; Ni, Hongjun ＜hongjun...@intel.com<mailto:hongjun...@intel.com>＞; Damjan Marion (damarion) ＜damar...@cisco.com<mailto:damar...@cisco.com>＞ Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; gu.ji...@zte.com.cn<mailto:gu.ji...@zte.com.cn>; zhao.zhig...@zte.com.cn<mailto:zhao.zhig...@zte.com.cn>; pan.feng...@zte.com.cn<mailto:pan.feng...@zte.com.cn> Subject: Re: [vpp-dev] R Signal events between graph nodes within different threads Guys, Oh, you want the main thread to process packets? Why didn’t you simply ask how to do that in the first place? At worst, a few lines’ worth of code - to enable e.g. dpdk-input in thread-0 - might be required. Copying Damjan. Thanks… Dave From: wang.hu...@zte.com.cn<mailto:wang.hu...@zte.com.cn> [mailto:wang.hu...@zte.com.cn] Sent: Wednesday, March 8, 2017 2:50 AM To: hongjun...@intel.com<mailto:hongjun...@intel.com> Cc: alaga...@gmail.com<mailto:alaga...@gmail.com>; Dave Barach (dbarach) ＜dbar...@cisco.com<mailto:dbar...@cisco.com>＞; zhao.zhig...@zte.com.cn<mailto:zhao.zhig...@zte.com.cn>; gu.ji...@zte.com.cn<mailto:gu.ji...@zte.com.cn>; pan.feng...@zte.com.cn<mailto:pan.feng...@zte.com.cn>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: 答复: RE: R[vpp-dev] Signal events between graph nodes within different threads Yes, I realize that, it could be work. Thanks to hongjun. But vl_api_rpc_call_main_thread will degrade packet handling performance in worker thread, I don't know if there is a common and high performance way to do this? And also I guess vlib_process_signal_event can only be used in main thread? just my opinion, since I have not gone deep into the signal event code. 王辉 wanghui IT开发工程师 IT Development Engineer 虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D Institute/Wireless Product Operation Division 原始邮件 发件人： ＜hongjun...@intel.com<mailto:hongjun...@intel.com>＞; 收件人：王辉10067165; ＜alaga...@gmail.com<mailto:alaga...@gmail.com>＞; 抄送人： ＜dbar...@cisco.com<mailto:dbar...@cisco.com>＞;赵志刚10017628;顾剑10036178;潘凤艳00024606; ＜vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>＞; 日 期 ：2017年03月08日 15:18 主 题 ：RE: R[vpp-dev] Signal events between graph nodes within different threads Hi Hui, I think the SNAT example maybe meet what you want: snat_in2out_node_fn_inline: (in worker thread) slow_path snat_ipfix_logging_nat44_ses_create vl_api_rpc_call_main_thread Regards, Hongjun From: wang.hu...@zte.com.cn<mailto:wang.hu...@zte.com.cn> [mailto:wang.hu...@zte.com.cn] Sent: Wednesday, March 8, 2017 2:58 PM To: alaga...@gmail.com<mailto:alaga...@gmail.com> Cc: dbar...@cisco.com<mailto:dbar...@cisco.com>; Ni, Hongjun ＜hongjun...@intel.com<mailto:hongjun...@intel.com>＞; zhao.zhig...@zte.com.cn<mailto:zhao.zhig...@zte.com.cn>; gu.ji...@zte.com.cn<mailto:gu.ji...@zte.com.cn>; pan.feng...@zte.com.cn<mailto:pan.feng...@zte.com.cn>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: 答复: Re: [vpp-dev] 答复: Re: Signal events between graph nodes within different threads Maybe if you could expand on what it is you are trying to achieve? //when starting worker thread , the main thread can't receive packet from IO, so we want to transfer some packet to main thread to continue processing. Is it specifically to do with DHCP (and proxy) or is that just the code you found that looks like the kind of functionality you believe you need for your use-case? // that just looks like our use-case. vlib_process_signal_event called in worker thread, and signal an event to the dhcp proccess node in main thread. can vlib_process_signal_event do this? 王辉 wanghui IT开发工程师 IT Development Engineer 虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D Institute/Wireless Product Operation Division 原始邮件 发件人： ＜alaga...@gmail.com<mailto:alaga...@gmail.com>＞; 收件人：王辉10067165; ＜dbar...@cisco.com<mailto:dbar...@cisco.com>＞; ＜hongjun...@intel.com<mailto:hongjun...@intel.com>＞; 抄送人：赵志刚10017628;顾剑10036178;潘凤艳00024606; ＜vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>＞; 日 期 ：2017年03月08日 13:04 主 题 ：Re: [vpp-dev] 答复: Re: Signal events between graph nodes within different threads On Wed, Mar 8, 2017 at 2:29 PM ＜wang.hu...@zte.com.cn<mailto:wang.hu...@zte.com.cn>＞ wrote: hi Dave and hongjun: We also got confused with below code. Dos it works correctly? Maybe the dhcp_proxy_to_client_input fuction runs in the worker thread, and it will call vlib_process_signal_event function to trigger dhcp-proccess node in the main thread. If it works, maybe the question of mail title could be solved. But We can't find any other use like this until now. Maybe if you could expand on what it is you are trying to achieve? Is it specifically to do with DHCP (and proxy) or is that just the code you found that looks like the kind of functionality you believe you need for your use-case? dhcp_proxy_to_client_input dhcp_client_for_us vlib_process_signal_event (vm, dhcp_client_process_node.index, EVENT_DHCP_CLIENT_WAKEUP, c - dcm-＞clients); 王辉 wanghui IT开发工程师 IT Development Engineer 虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D Institute/Wireless Product Operation Division
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
