[tcpdump-workers] BPF_COP support for libpcap

Darren Reed darrenr at netbsd.org
Tue May 19 18:59:22 EDT 2015

On 18/05/2015 9:31 AM, Mindaugas Rasiukevicius wrote:
> Michael Richardson <mcr at sandelman.ca> wrote:
>> Mindaugas Rasiukevicius <rmind at noxt.eu> wrote:
>>      > A while ago NetBSD gained support for BPF_COP instruction, see [1]
>>      > for more details.  However, now there are use cases of it outside
>>      > the NetBSD kernel, e.g. standalone NPF packet filter running as a
>>      > program on Linux. Hence I would like to add the support for the
>>      > BPF_COP instruction to the pcap_compile() and pcap_dump() of the
>>      > libpcap library.
>> It seems like a good thing to have to evolve BPF forward, particularly
>> in light of more and more complex 802.1q and "metro-ethernet" ring
>> layer-2 formats, and walking IPv6 header chains.


>> It seems that we really wind up needing a registry of co-processor
>> function indexes... which begin to seem like new instructions in some
>> sense. Perhaps the difference is that they are better defined, and more
>> dynamic.

If libpcap/bpf goes down the path of having "BPF_COP" as part of the 
set but not defining any functions then how does libpcap use it? Or not?

Is it better to think of BPF_COP as being a "vendor private" instruction?
Does having a "vendor private" instruction allow for better compatibility
with hardware vendors that produce hardware based packet sniffers?

The thought here is that BPF_COP suggests that the vendor private thing
should be a coprocessor but if the instruction is just BPF_PRIVATE then it
allows the vendor to do with it whatever they wish, without imposing any

> Well, the patch just provides the capability to invoke the coprocessor.
> The benefit of BPF_COP approach is that the vendors can implement their
> custom coprocessor and use through libpcap/tcpdump without polluting the
> instruction space.  I think the RISC-like coprocessor approach (think of
> MIPS) is both clean and powerful compared to adding complex instructions.

This would suggest that "BPF_COP" is really a "vendor private" thing.
Why burden it with meaning something special such as coprocessor?

> It would be good to have some general purpose coprocessor (for walking
> IPv6 header chain and other operations), but that would probably be
> difficult to agree and standardise amongst the vendors.

Which speaks to BPF needing new instructions or a new instruction set 
that can
handle those tasks.


More information about the tcpdump-workers mailing list