Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Dec 2012 18:34:12 +0100
From:      Andre Oppermann <>
To:        "Alexander V. Chernikov" <>
Cc:, Gleb Smirnoff <>,, 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 13:18, Alexander V. Chernikov wrote:
> 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.

You have to be a bit careful with locking, or rather not locking.  When
the consumer is not doing any lock operations it may not (immediately)
pick up that the pointer was changed on another CPU.

> 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.

Separate from the above BPF on the output side may be optimized by passing
the mbuf not from drv*_start() but from drv*_txeof().  There may be a few
microseconds delay but a mbuf (-chain) copy is saved in the transmit path.
As an additional benefit only those packets that actually were transmitted
are persented to bpf.


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