Date: Fri, 30 Aug 2013 08:35:57 +0200 From: Darren Reed <darrenr@netbsd.org> To: Mindaugas Rasiukevicius <rmind@netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch) Message-ID: <1377844557.1741.15873957.4FB18641@webmail.messagingengine.com> In-Reply-To: <20130829152757.030C414A13C@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130822101623.3837E14A21D@mail.netbsd.org> <521F4522.5070403@netbsd.org> <20130829152757.030C414A13C@mail.netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote: > Darren Reed <darrenr@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1377844557.1741.15873957.4FB18641>