From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop Date: Mon, 04 Apr 2016 09:37:47 +0200 Message-ID: <1459755467.18188.16.camel@sipsolutions.net> References: <1459560118-5582-1-git-send-email-bblanco@plumgrid.com> <1459622491.18188.6.camel@sipsolutions.net> (sfid-20160403_042824_139777_98CD13EB) Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Brenden Blanco , "David S. Miller" , Linux Kernel Network Developers , Alexei Starovoitov , gerlitz@mellanox.com, Daniel Borkmann , john fastabend , Jesper Dangaard Brouer To: Lorenzo Colitti , Tom Herbert Return-path: Received: from s3.sipsolutions.net ([5.9.151.49]:44808 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751386AbcDDHhw (ORCPT ); Mon, 4 Apr 2016 03:37:52 -0400 In-Reply-To: (sfid-20160403_042824_139777_98CD13EB) Sender: netdev-owner@vger.kernel.org List-ID: On Sun, 2016-04-03 at 11:28 +0900, Lorenzo Colitti wrote: > That said, getting BPF to the driver is part of the picture. On the > chipsets we're targeting for APF, we're only seeing 2k-4k of memory > (that's 256-512 BPF instructions) available for filtering code, which > means that BPF might be too large. That's true, but I think that as far as the userspace API is concerned that shouldn't really be an issue. I think we can compile the BPF into APF, similar to how BPF can be compiled into machine code today. Additionally, I'm not sure we can realistically expect all devices to really implement APF "natively", I think there's a good chance but there's also a possibility of compiling to the native firmware environment, for example. johannes