From owner-freebsd-net@FreeBSD.ORG  Thu Aug 29 12:35:30 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 4AA164E2
 for <freebsd-net@freebsd.org>; Thu, 29 Aug 2013 12:35:30 +0000 (UTC)
 (envelope-from freebsd-net@m.gmane.org)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 091B72370
 for <freebsd-net@freebsd.org>; Thu, 29 Aug 2013 12:35:29 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
 (envelope-from <freebsd-net@m.gmane.org>) id 1VF1Re-0008SY-GO
 for freebsd-net@freebsd.org; Thu, 29 Aug 2013 14:35:26 +0200
Received: from rebar.astron.com ([208.77.212.97])
 by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <freebsd-net@freebsd.org>; Thu, 29 Aug 2013 14:35:26 +0200
Received: from christos by rebar.astron.com with local (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <freebsd-net@freebsd.org>; Thu, 29 Aug 2013 14:35:26 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: christos@astron.com (Christos Zoulas)
Subject: Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch)
Date: Thu, 29 Aug 2013 12:35:07 +0000 (UTC)
Lines: 22
Message-ID: <kvnf5q$i26$1@ger.gmane.org>
References: <20130804191310.2FFBB14A152@mail.netbsd.org>
 <20130822101623.3837E14A21D@mail.netbsd.org> <521F4522.5070403@netbsd.org>
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: rebar.astron.com
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Cc: tech-net@netbsd.org
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 12:35:30 -0000

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