From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754269AbbCaDXe (ORCPT ); Mon, 30 Mar 2015 23:23:34 -0400 Received: from mail-pd0-f181.google.com ([209.85.192.181]:35361 "EHLO mail-pd0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754053AbbCaDXb (ORCPT ); Mon, 30 Mar 2015 23:23:31 -0400 Message-ID: <551A132C.9040805@plumgrid.com> Date: Mon, 30 Mar 2015 20:23:24 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: He Kuang CC: wangnan0@huawei.com, LKML , "daniel@iogearbox.net >> Daniel Borkmann" Subject: Re: [RFC] bpf: Suggestion on bpf syscall interface References: <55169240.7040103@huawei.com> <5516E32B.6030502@plumgrid.com> <5518BF6F.4080406@huawei.com> In-Reply-To: <5518BF6F.4080406@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/29/15 8:13 PM, He Kuang wrote: > > By using current bpf syscalls, we should keep the program which > attaches bpf programs running background, use it or some other > processes communicate with it to adjust maps parameters, like > sample rate for sys_write. You can do all of the above by passing fds between processes. I still don't see a need for sysfs. > In current implementation, we have to use a large and relative > heavy daemon to deal with loading, configuration, adjusting and > unloading works together. This daemon is actually small and simple. Just take a look how Daniel did for tc: http://patchwork.ozlabs.org/patch/456387/ In that example 3 programs are sharing maps and single bpf_agent monitors maps. Note that tc loaded programs and exited while agent keeps running. Very straightforward.