Date: Thu, 29 Aug 2013 12:35:07 +0000 (UTC) From: christos@astron.com (Christos Zoulas) To: freebsd-net@freebsd.org Cc: tech-net@netbsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch) Message-ID: <kvnf5q$i26$1@ger.gmane.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130822101623.3837E14A21D@mail.netbsd.org> <521F4522.5070403@netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <521F4522.5070403@netbsd.org>, Darren Reed <darrenr@netbsd.org> wrote: > >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. I think that the COP/COPX encapsulation does not leak outside the kernel (in principle), so the functionality that the COP/COPX subroutines NPF provides doesn't become part of the BPF feature set and cannot be re-used outside the kernel. As such, this technique can be used to experiment and see what offloading mechanisms are required for efficient IPv6 processing. Once that is better understood, we can think about turning them into real and officially supported BPF instructions. christos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?kvnf5q$i26$1>