Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Dec 2012 16:18:38 +0400
From:      "Alexander V. Chernikov" <>
To:        Gleb Smirnoff <>
Cc:, Hiroki Sato <>,, "" <>
Subject:   Re: [CFT] Virtual BPF interfaces
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 03.12.2012 12:11, Gleb Smirnoff wrote:
> On Sun, Dec 02, 2012 at 04:48:18AM +0400, Alexander V. Chernikov wrote:
> A> On 10.06.2012 18:20, Alexander V. Chernikov wrote:
> A> > On 27.04.2012 03:44, Hiroki Sato wrote:
> A> >> "Alexander V. Chernikov"<> wrote
> A> >> in<>:
> A> >>
> A> >> me> On 24.04.2012 21:05, Hiroki Sato wrote:
> A> >
> A> > Proof-of-concept patch attached.
> A>
> A> Hopefully, libcap code is easily extendable.
> A> New version attached:
> A> * BPF code is now able to use 'virtual' interfaces without real ifnet
> A> * New bpfattach3() / bpfdetach3() routines were added to attach virtual
> A> ifaces
> A> * New BIOCGIFLIST ioctl is added to permit userland to retrieve
> A> available virtual interfaces
> A> * freebsd-specific 'platform_finddevs' version is added to libpcap code
> A> (new file)
> A>
> A> There are some rough edges (conditional code in pcap-bpf.c, lack of
> A> documentation, maybe some style issues), but generally it seems to work
> A> and does not interfere with contrib/ code much (from my point of view).
> A>
> A> ipfw log device was converted to use new bpf(4) api, see attached patch.
> Nice proof of concept, Alexander!
> What does prevent us from unifing all bpf providers to be "virtual" in
> current terms? I think if we finish divorce between ifnet and bpf, the code
> would get simplier and you can proceed further with reducing locking
> overhead.

We have to jump from ifnet to the list of per-ifnet BPF consumers 
somehow, so I'm not sure if we can do much more here. BPF itself doesn't 
require much from parent ifnet.

What I really want to do next is the following:

1) Make BPF_PEERS_PRESENT(ifp) to be (ifp->if_bpf != NULL). This saves 
some processing time and permits 'bpf_if' to be be totally opaque 
without any hacks.
2) Set if_bpf pointer IFF there are some consumers (and set it back to 
NULL when all consumers are detached). This should work well for 'main' 
BPF DLT, but single (currently, 802.11) interface can hold more than one 
DLTs. Probably we can save dst pointer passed to bpfattach2() to given 
bpf_if structure, and set this value instead of ->if_bpf.
This, however, can lead to hard-to-find problems, since bpfattach[2] is 
usually not called by driver directly.


WBR, Alexander

Want to link to this message? Use this URL: <>