From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [PATCH net-next 0/9] net: Kernel side filtering for route dumps Date: Thu, 11 Oct 2018 09:32:29 -0600 Message-ID: <02e2a1eb-07be-5a13-c9fc-e0a47287fdbf@gmail.com> References: <20181011150627.4010-1-dsahern@kernel.org> <20181011082637.3e7833c9@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, davem@davemloft.net To: Stephen Hemminger , David Ahern Return-path: Received: from mail-pf1-f194.google.com ([209.85.210.194]:46426 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727226AbeJKXAN (ORCPT ); Thu, 11 Oct 2018 19:00:13 -0400 Received: by mail-pf1-f194.google.com with SMTP id r64-v6so4590808pfb.13 for ; Thu, 11 Oct 2018 08:32:32 -0700 (PDT) In-Reply-To: <20181011082637.3e7833c9@xeon-e3> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/11/18 9:26 AM, Stephen Hemminger wrote: >> > > You can do the something like this already with BPF socket filters. > But writing BPF for multi-part messages is hard. > > Maybe a generic eBPF filter mechanism would be more flexible? > That exists today and does not cover what is needed here: 1. The filters apply *after* the skb has been filled in. 2. an skb will have many routes within it and the user filter could apply to any of those messages within the skb. It is not efficient to generate the skb and then re-create it with a bpf filter. The point here is to not even fill in the skb for something userspace does not care about. Route dumps are done for the entire FIB for each address family. As we approach internet routing tables (700k+ routes for IPv4, currently around 55k for IPv6) with many VRFs dumping the entire table is grossly inefficient when for example only a single VRF table is wanted.