thanks. I think I get it. By maintaining the ownership, vPP is able to enqueue all buffers destinated to the same target node into the owner's next frame at one time. This avoids dispatching the node function multiple times.
The bug is still there. I will create a patch later for further discussion. And, maybe there has some space to improve: considering we have two input nodes which will both add elements to the third node, we will see the ownership of this node being switched per frame basis. - Kingwel -------- 原始邮件 -------- 主题： RE: Question about vlib_next_frame_change_ownership 来自： "Dave Barach (dbarach)" <dbar...@cisco.com> 发至： 2019年1月23日 下午8:49 抄送： Kingwel Xie <kingwel....@ericsson.com>,vpp-dev <vpp-dev@lists.fd.io> As you've probably noticed, the buffer manager has been under active development. That may or may not have anything to do with the issue. Please follow the bug reporting process: https://wiki.fd.io/view/VPP/BugReports. In this case, using master/latest, please create a Jira ticket including the exact configuration, packet generator input script, and a dispatch pcap trace: * "pcap dispatch trace on file dtrace max 10000 buffer-trace pg-input 1000", * start the pg stream * "pcap dispatch trace off". * Results in /tmp/dtrace. I'm not going to speculate on what's going on at this point. Please write up the issue so we can look at it. For a decent explanation of the frame ownership scheme, take a look at https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html under "Complications". HTH... Dave -----Original Message----- From: Kingwel Xie <kingwel....@ericsson.com> Sent: Wednesday, January 23, 2019 2:16 AM To: Dave Barach (dbarach) <dbar...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io> Subject: Question about vlib_next_frame_change_ownership Hi Dave and all, I'm looking at a buffer trace issue with DPDK IPSEC. It turns out the flag VLIB_FRAME_TRACE is broken in vlib_next_frame_change_ownership(). The node path in my setup is: pg-input -> ip-input -> ip-lookup -> ... -> dkdp-esp-encrypt -> cryptodev -> crypto-input -> ip-lookup -> ... As you can see, the ip-lookup node has the owner node ip-input in the beginning, then owner will be changed to crypto-input shortly. This change causes that we swap the current next_frame with the owner's in vlib_next_frame_change_ownership(). As a result, the VLIB_FRAME_TRACE in next_frame->flag will be overwritten. The fix could be very simple, but I'm wondering why we have to change the ownership of the next_frame? Actually I can observe the ownership is changed back and forth between ip-input and crypto-input for every frame, which leads to performance degradation. However, it looks good to me even that we don’t care the ownership. In this case, ip-lookup will be dispatched by either ip-input or crypto-input, with different next_frame. I guess I must have missed something, appreciate if you can elaborate. Regards, Kingwel
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11982): https://lists.fd.io/g/vpp-dev/message/11982 Mute This Topic: https://lists.fd.io/mt/29430823/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
