From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753239AbbJaKnb (ORCPT ); Sat, 31 Oct 2015 06:43:31 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:4503 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbbJaKna (ORCPT ); Sat, 31 Oct 2015 06:43:30 -0400 Message-ID: <56349AB5.4000907@huawei.com> Date: Sat, 31 Oct 2015 18:40:53 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo CC: , , , , , , , , , , , , , Subject: Re: [PATCH 13/31] bpf tools: Load a program with different instances using preprocessor References: <1444826502-49291-1-git-send-email-wangnan0@huawei.com> <1444826502-49291-14-git-send-email-wangnan0@huawei.com> <20151029224407.GM2923@kernel.org> In-Reply-To: <20151029224407.GM2923@kernel.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/10/30 6:44, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 14, 2015 at 12:41:24PM +0000, Wang Nan escreveu: >> In this patch, caller of libbpf is able to control the loaded programs >> by installing a preprocessor callback for a BPF program. With >> preprocessor, different instances can be created from one BPF program. > Why would one want to do that? I'm new to eBPF, as many other here, I > guess, so giving some more context as to what will this achieve will > help me in processing these patches. > I'll explain at the bottom of this reply. >> This patch will be used by perf to generate different prologue for >> different 'struct probe_trace_event' instances matched by one >> 'struct perf_probe_event'. >> >> bpf_program__set_prep() is added to support this feature. Caller >> should pass libbpf the number of instances should be created and a > that >> preprocessor function which will be called when doing real loading. > the >> The callback should return instructions arrays for each instances. > instruction arrays for each instance. >> fd field in bpf_programs is replaced by instance, which has an nr field > The fd field in the bpf_programs struct is replaced by instance > (instance of what?) Instance of program. It is a new concept introduced in this patch. Before this patch, one program create one fd. This patch enables one program to create multiple fds. Each fd is a program instance. In summary, this and following patches try to solve a important problem in such tracing tool that: how to access kernel data in BPF program. Our core methode on this is BPF prologue that we automatically generate some BPF asm code for fetching them. However, after we implement it another problem arises. We found that there are many cases that multiple entries share one symbol. Most of the time caused by function inlining. We also support using glob to match multiple symbol. For example: SEC("func=my_func_*_abcd arg1") int func(...) { } In the above example, it is highly possible that arg1 exist for all my_func_*_abcd, but in different registers or on different place in the stack. When probing, perf would create one tev for each actual probing point. Due to prologues for fetching arg1 are different, we need to create multiple BPF prologue (so different BPF fd) for each probing point. This is why we need this patch: Load a program with different instances. I have to admit that the design of this patch is not very easy to be understand. However I believe it is the best way we can find. The biggest reason of current design is that I don't want libbpf be bounded with perf tightly. The prologue generation should be done by perf, libbpf should never though about it. What it should provide is to give caller (perf) a way to decorate the BPF binary in multiple ways for different instances. Therefore I let caller to inject a helper (preprocessor) for adjusting the code. What the caller need to tell libbpf is the total instances it want to create, and the preprocessor should maintain the mapping between the No. of instance and the binary BPF program it want to create. For instance, as the caller of libbpf, perf should know how to generate prologue for my_func_a_abcd and my_func_b_abcd, then it should maintain a mapping: No. 0 --> my_func_a_abcd No. 1 --> my_func_b_abcd Then it need to tell libbpf that it would create 2 instances of a BPF program. In the preprocessor perf inject into libbpf, it should generate prologue for each probing point according to the ID. Thank you.