tcpdump mailing list archives
Re: BPF_COP support for libpcap
From: Darren Reed <darrenr () netbsd org>
Date: Wed, 20 May 2015 08:59:22 +1000
On 18/05/2015 9:31 AM, Mindaugas Rasiukevicius wrote:
Michael Richardson <mcr () sandelman ca> wrote:Mindaugas Rasiukevicius <rmind () 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.
Yes.
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 instruction
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 expectations.
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. Cheers, Darren _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- BPF_COP support for libpcap Mindaugas Rasiukevicius (May 12)
- Message not available
- Re: BPF_COP support for libpcap Mindaugas Rasiukevicius (May 17)
- Re: BPF_COP support for libpcap Darren Reed (May 19)
- Re: BPF_COP support for libpcap Paul "LeoNerd" Evans (May 20)
- Re: BPF_COP support for libpcap Mindaugas Rasiukevicius (May 25)
- Message not available
- Re: BPF_COP support for libpcap Mindaugas Rasiukevicius (Jun 10)
- Re: BPF_COP support for libpcap Mindaugas Rasiukevicius (May 17)
- Message not available