Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753400AbaF0KT6 (ORCPT ); Fri, 27 Jun 2014 06:19:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57600 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752952AbaF0KTz (ORCPT ); Fri, 27 Jun 2014 06:19:55 -0400 Message-ID: <53AD4514.9040708@redhat.com> Date: Fri, 27 Jun 2014 12:19:00 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Chema Gonzalez CC: Alexei Starovoitov , Ingo Molnar , Steven Rostedt , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , David Miller , Eric Dumazet , Network Development , LKML Subject: Re: [PATCH v6 net-next 1/4] net: flow_dissector: avoid multiple calls in eBPF References: <1398882591-30422-1-git-send-email-chema@google.com> <1401389758-13252-1-git-send-email-chema@google.com> <5387C8AD.6000909@redhat.com> <538C6FD8.9040305@redhat.com> <538D884E.5030007@redhat.com> <538EDE1A.8060305@redhat.com> <53A9337F.50707@redhat.com> In-Reply-To: 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 06/26/2014 12:00 AM, Chema Gonzalez wrote: ... > There's still the problem of whether we want to obsolete classic BPF > in the kernel before the tools (libpcap mainly) accept eBPF. This can > take a lot. > > Finally, what's the user's CLI interface you have in mind? Right now, > tcpdump expressions are very handy: I know I can pass "ip[2:2] == > 1500" or "(tcp[13] & 0x03)" to any libpcap-based application. This is > very handy to log into a machine, and quickly run tcpdump to get the > packets I'm interested on. What would be the model for using C-- eBPF > filters in the same manner? Yes, imho, it's a valid question to ask. I think there are a couple of possibilities for libpcap/tcpdump from a user point of view (note, I don't strictly think it's the _only_ main user though): 1) iff a llvm and/or gcc backend gets merged from the compiler side, one could add a cli interface to run the generated opcodes from a file for advanced filters while perhaps classic BPF continues to be supported via its high-level filter expressions; 2) there could be a Linux-only compiler in libpcap that translates and makes use of full eBPF (though significantly more effort to implement); 3) libpcap continues to use classic BPF as it's currently doing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/