tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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.

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.

When it comes to looking up addresses in tables, I don't see the
advantage in adding this to BPF to support NPF. My suspicioun is
that the goal is to support expressing the entire rule as just BPF
byte code. For rules, it makes no sense as the expensive operation
(table lookup) could just as easily be done after the rest of the
packet is matched with BPF. Or is there something else here at play
that I'm missing?





Home | Main Index | Thread Index | Old Index