Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Darren Reed <darrenr%netbsd.org@localhost> wrote:
> Mindaugas Rasiukevicius wrote:
> > Hi,
> >
> > OK, to summarise what has been discussed:
> >
> > - Problem
> >
> > There is a need to perform more complex operations from the BPF program.
> > Currently, there is no (practical) way to do that from the byte-code.
> > Such functionality is useful for the packet filters or other components,
> > which could integrate with BPF.  For example, while most of the packet
> > inspection logic can stay in the byte-code, such operations as looking
> > up an IP address in some container or walking the IPv6 headers and
> > returning some offsets have to be done externally.  The first existing
> > user of such capability would be NPF in NetBSD.
> >   
> 
> I'd argue that the IPv6 problem is of such a generic nature that
> it deserves its own instruction/s. We may look at IPv6 today and
> think nobody uses it much but over time that is going to change.
> Thus there will be an outcome not possible with co-processor
> approach if an instruction is created for that purpose and is
> common across all platforms through libpcap. Unless the IPv6
> problem is too complex for a single instruction (this has not
> been demonstrated.) In that case maybe BPF itself needs to evolve
> such that it can support more complex instructions.

This is a separate issue.  Feel free to propose an new instruction to
parse IPv6 headers.

> The current implementation of BPF makes it very hard to expand
> the instruction set without impinging on the ability to make
> future changes due to the way in which instructions are codified
> into 32bits. Whilst the method of supporting a co-processor gets
> around that, it does so in such a generic fashion that it becomes
> too easy to use it as a bit-bucket for anything you think might
> be a good idea if BPF could do without really evaluating if it
> should do.

It is certainly possible that some operations, which will be implemented
using BPF coprocessor, will be useful in general.  Again, whether such
operations should be "promoted" to be new BPF instructions or there should
be a global "standardised" coprocessor or how BPF should evolve (including
RISC vs CISC-like instruction set debate) is a separate discussion.

-- 
Mindaugas