[tcpdump-workers] BPF_COP support for libpcap
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 
>> > 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
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
handle those tasks.
More information about the tcpdump-workers