On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote: > Darren Reed <darr...@netbsd.org> 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.
To do this requires understanding what we want to do with the extension headers. Do we want to: 1) find a particular extension header 2) find the start of the last extension header 3) get a list of all extension headers (including L4 protocols) 4) as per (3) but also their offset 5) ... anything else? For example, if you were to write a tcpdump expression to filter fragments for IPv6, what should the BPF look like? Alternatively if you wanted to display all packets that had both a routing header, fragment header and were UDP, how complex should the BPF instruction set that results be? > > 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. Oh, my comment above was much more open than that. Effectively what I'm proposing is moving beyond the single 32bit instruction word for BPF: maybe it is time for BPF to join the 64bit world. The current design of BPF enforces a certain amount of rigour because it can't be expanded ad-hoc due to the design and the implementation of that design. It forces you to consider "should I do it" not just "can I do it." My comment above about the "should" part refers to the co-processor argument taking away a certain amount of engineering discipline that currently goes with BPF. Currently you can't just use it for "anything and everything." Cheers, Darren _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
