Re: BPF_COP support for libpcap

[Darren Reed <darrenr () netbsd org>]

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