Hi,
Adrian Chadd wrote:
> >> > It provides us a capability to offload more complex packet
> >> > processing. My primary user would be NPF in NetBSD, e.g. one of the
> >> > operations is to lookup an IP address in a table/ipset.
> >
> > I would like to coordinate the reservation of BPF opcodes tho
Darren Reed 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 (pra
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 wi
Thor Lancelot Simon wrote:
> On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote:
> > Steven,
> >
> > Steven Bellovin wrote:
> > > There's a one-word summary: *assurance*. With the current design,
> > > it's easy t
Steven,
Steven Bellovin wrote:
> There's a one-word summary: *assurance*. With the current design,
> it's easy to *know* what can happen. With a Turing-complete extension,
> it isn't.
It is still easy and the concept itself is very simple. I mentioned that
this extension does not make byte-co
Darren Reed wrote:
> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
> > Darren Reed wrote:
> >>>
> >>> You do not have to use it.
> >>
> >> I get no choice - it is in the kernel by default.
> >>
> >
> > There is no
Darren Reed wrote:
> >
> > You do not have to use it.
>
> I get no choice - it is in the kernel by default.
>
There is no default coprocessor. Here is your choice: do not call
bpf_set_cop(9) and those instructions will effectively be NOPs.
> <...>
>
> No. It's not about calling a function,
Alexander Nasonov wrote:
> Mindaugas Rasiukevicius wrote:
> > Why is it a problem? Given that the byte-code and the functions would
> > come from the same source, some coupling seems natural to me. It is
> > simplistic anyway: some already parsed offsets or values could
Darren Reed wrote:
> >
> > I would like propose new BPF instructions for the misc category: BPF_COP
> > and BPF_COPX. It would provide a capability of calling an external
> > function - think of BPF "coprocessor".
>
> No.
>
You do not have to use it.
> A BPF program is an entity that can be v
Alexander Nasonov wrote:
> > Yes, I may want to keep the state in the memory store or pass the
> > arguments through it, since the accumulator might not be enough.
>
> You have access to a whole packet, why do you need to pass additional
> arguments through the store? I'm worried about introducin
Hello Alex,
Let's keep freebsd-net CCed in case there is any interest.
Alexander Nasonov wrote:
>
> I like the idea but I have some questions:
>
> 1. Why do you need access to scratch memory? Is your goal to keep a
> state for C code between cop calls? In this case, you can use
> the stand
chris...@astron.com (Christos Zoulas) wrote:
> >> <...>
> >>
> >>BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */
> >>
> >>typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt,
> >>uint32_t A, uint32_t *M);
> >>
> >>int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], siz
Adrian Chadd wrote:
> I think it's slightly unfair to propose a new extension for BPF
> without any in-tree users.
>
We have in-tree user in NetBSD as mentioned in the previous email:
> > It provides us a capability to offload more complex packet processing.
> > My primary user would be NPF in
Rui Paulo wrote:
> >
> > Comments?
>
>
> Why do you need this in the first place?
It provides us a capability to offload more complex packet processing.
My primary user would be NPF in NetBSD, e.g. one of the operations is to
lookup an IP address in a table/ipset.
> Are you sure this is a sa
Hello,
I would like propose new BPF instructions for the misc category: BPF_COP
and BPF_COPX. It would provide a capability of calling an external
function - think of BPF "coprocessor". The argument for BPF_COP is an
index to a pre-loaded array of function pointers. BPF_COPX takes the
function
15 matches
Mail list logo
