[Q/RFC] BPF use in broader scope

[Q/RFC] BPF use in broader scope

[Jiri Pirko]

Hi all.

I came to an idea of using BPF infrastructure currently used in kernel,
for computing hashes selecting TX ports in team device. Since the same
data (skb) are alalyzed/used as for socket filtering, BPF seems so be quite
suitable for this. It would allow userspace daemon to specify various
kinds of TX selection algorithms.

Here are proposed things to be done:
1) introduce in-kernel api for creating sk-unattached filters (I have
   the patch cooked up already)

2) extend current BPF machine to allow XOR operation. Not sure if this
   is doable or what the best of doing this is.

3) add possibility to pass some data to the machine via
   pre-filling "Scratch Memory Store". I think this can be done easily
   moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
   second function parameter. That should not break anything.

Then the computed hash can be either stored into Scratch memory or returned
directly (where ordinary sk filters return len).

Does this seems reasonable? Thoughts, comments?

Thanks!

Jirka

Re: [Q/RFC] BPF use in broader scope

[David Miller]

From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 29 Mar 2012 09:44:43 +0200

> Here are proposed things to be done:
> 1) introduce in-kernel api for creating sk-unattached filters (I have
>    the patch cooked up already)
> 
> 2) extend current BPF machine to allow XOR operation. Not sure if this
>    is doable or what the best of doing this is.
> 
> 3) add possibility to pass some data to the machine via
>    pre-filling "Scratch Memory Store". I think this can be done easily
>    moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
>    second function parameter. That should not break anything.
> 
> Then the computed hash can be either stored into Scratch memory or returned
> directly (where ordinary sk filters return len).
> 
> Does this seems reasonable? Thoughts, comments?

No fundamental objections, but we have all of these JITs now to
update when adding new operations or semantics, so be careful.

Re: [Q/RFC] BPF use in broader scope

[Jiri Pirko]

Thu, Mar 29, 2012 at 09:49:57AM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jpirko@redhat.com>
>Date: Thu, 29 Mar 2012 09:44:43 +0200
>
>> Here are proposed things to be done:
>> 1) introduce in-kernel api for creating sk-unattached filters (I have
>>    the patch cooked up already)
>> 
>> 2) extend current BPF machine to allow XOR operation. Not sure if this
>>    is doable or what the best of doing this is.
>> 
>> 3) add possibility to pass some data to the machine via
>>    pre-filling "Scratch Memory Store". I think this can be done easily
>>    moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
>>    second function parameter. That should not break anything.
>> 
>> Then the computed hash can be either stored into Scratch memory or returned
>> directly (where ordinary sk filters return len).
>> 
>> Does this seems reasonable? Thoughts, comments?
>
>No fundamental objections, but we have all of these JITs now to
>update when adding new operations or semantics, so be careful.

Yep, I'm aware. I must admit that the JIT code scares me a litte :(

Re: [Q/RFC] BPF use in broader scope

[Eric Dumazet]

On Thu, 2012-03-29 at 09:44 +0200, Jiri Pirko wrote:
> Hi all.
> 
> I came to an idea of using BPF infrastructure currently used in kernel,
> for computing hashes selecting TX ports in team device. Since the same
> data (skb) are alalyzed/used as for socket filtering, BPF seems so be quite
> suitable for this. It would allow userspace daemon to specify various
> kinds of TX selection algorithms.
> 
> Here are proposed things to be done:
> 1) introduce in-kernel api for creating sk-unattached filters (I have
>    the patch cooked up already)
> 
> 2) extend current BPF machine to allow XOR operation. Not sure if this
>    is doable or what the best of doing this is.
> 
> 3) add possibility to pass some data to the machine via
>    pre-filling "Scratch Memory Store". I think this can be done easily
>    moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
>    second function parameter. That should not break anything.
> 
> Then the computed hash can be either stored into Scratch memory or returned
> directly (where ordinary sk filters return len).
> 
> Does this seems reasonable? Thoughts, comments?
> 

Sure it seems good ideas.

Maybe add :

4) be able to extend skb_flow_dissect() using BPF hooks

Re: [Q/RFC] BPF use in broader scope

[Eric Dumazet]

On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:

> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
> 

If you add a new XOR instruction in interpreter only, JIT compiler will
automatically aborts, so no risk.

Each arch maintainer will add the support for the new instructions as
separate patches.

So you can focus on net/core/filter.c file only.

Re: [Q/RFC] BPF use in broader scope

[Jiri Pirko]

Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>
>> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>> 
>
>If you add a new XOR instruction in interpreter only, JIT compiler will
>automatically aborts, so no risk.
>
>Each arch maintainer will add the support for the new instructions as
>separate patches.
>
>So you can focus on net/core/filter.c file only.
>

Ok - I can do this for 2). But for 3) JITs need to be modified. So I
would like to kindly ask you and Matt if you can do this modification so
bpf_func takes pointer to mem (scratch store) as second parameter. I'm
sure it's very easy for you to do.

Ccing Matt.

Thanks.

>
>

Re: [Q/RFC] BPF use in broader scope

[David Miller]

From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 29 Mar 2012 10:31:49 +0200

> Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>>On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>>
>>> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>>> 
>>
>>If you add a new XOR instruction in interpreter only, JIT compiler will
>>automatically aborts, so no risk.
>>
>>Each arch maintainer will add the support for the new instructions as
>>separate patches.
>>
>>So you can focus on net/core/filter.c file only.
>>
> 
> Ok - I can do this for 2). But for 3) JITs need to be modified. So I
> would like to kindly ask you and Matt if you can do this modification so
> bpf_func takes pointer to mem (scratch store) as second parameter. I'm
> sure it's very easy for you to do.

The ARM JIT just went into Linus's tree as well.

Re: [Q/RFC] BPF use in broader scope

[Eric Dumazet]

On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
> Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
> >On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
> >
> >> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
> >> 
> >
> >If you add a new XOR instruction in interpreter only, JIT compiler will
> >automatically aborts, so no risk.
> >
> >Each arch maintainer will add the support for the new instructions as
> >separate patches.
> >
> >So you can focus on net/core/filter.c file only.
> >
> 
> Ok - I can do this for 2). But for 3) JITs need to be modified. So I
> would like to kindly ask you and Matt if you can do this modification so
> bpf_func takes pointer to mem (scratch store) as second parameter. I'm
> sure it's very easy for you to do.

I am not sure why you want this.

This adds register pressure (at least for x86) ...

Re: [Q/RFC] BPF use in broader scope

[Jiri Pirko]

Thu, Mar 29, 2012 at 10:45:32AM CEST, eric.dumazet@gmail.com wrote:
>On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
>> Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>> >On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>> >
>> >> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>> >> 
>> >
>> >If you add a new XOR instruction in interpreter only, JIT compiler will
>> >automatically aborts, so no risk.
>> >
>> >Each arch maintainer will add the support for the new instructions as
>> >separate patches.
>> >
>> >So you can focus on net/core/filter.c file only.
>> >
>> 
>> Ok - I can do this for 2). But for 3) JITs need to be modified. So I
>> would like to kindly ask you and Matt if you can do this modification so
>> bpf_func takes pointer to mem (scratch store) as second parameter. I'm
>> sure it's very easy for you to do.
>
>I am not sure why you want this.
>
>This adds register pressure (at least for x86) ...

Well I think that there would become handy to be able to pass some data
to bpf_func (other than skb). But it's just an idea.

>
>
>

Re: [Q/RFC] BPF use in broader scope

[Li Yu]

于 2012年03月29日 15:44, Jiri Pirko 写道:
> Hi all.
>
> I came to an idea of using BPF infrastructure currently used in kernel,
> for computing hashes selecting TX ports in team device. Since the same
> data (skb) are alalyzed/used as for socket filtering, BPF seems so be quite
> suitable for this. It would allow userspace daemon to specify various
> kinds of TX selection algorithms.
>
> Here are proposed things to be done:
> 1) introduce in-kernel api for creating sk-unattached filters (I have
>     the patch cooked up already)
>
> 2) extend current BPF machine to allow XOR operation. Not sure if this
>     is doable or what the best of doing this is.
>
> 3) add possibility to pass some data to the machine via
>     pre-filling "Scratch Memory Store". I think this can be done easily
>     moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
>     second function parameter. That should not break anything.
>
> Then the computed hash can be either stored into Scratch memory or returned
> directly (where ordinary sk filters return len).
>
> Does this seems reasonable? Thoughts, comments?
>

Very interesting.

I am working on a blktrace like utility for networking subsystem. It
needs a trace events filter to avoid to generate too much results which
user does not interesting, it seem that the generic BPF is the best
choice here.

So far, the "skbtrace" need to filter two kinds of objects: the skb and 
socket, so I think that above "Scratch Memory Store" is necessary indeed.

Thanks.

Yu

> Thanks!
>
> Jirka
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [Q/RFC] BPF use in broader scope

[Nuno Martins]

On Thu, Mar 29, 2012 at 8:44 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Hi all.
>
> I came to an idea of using BPF infrastructure currently used in kernel,
> for computing hashes selecting TX ports in team device. Since the same
> data (skb) are alalyzed/used as for socket filtering, BPF seems so be quite
> suitable for this. It would allow userspace daemon to specify various
> kinds of TX selection algorithms.
>
> Here are proposed things to be done:
> 1) introduce in-kernel api for creating sk-unattached filters (I have
>   the patch cooked up already)
>
> 2) extend current BPF machine to allow XOR operation. Not sure if this
>   is doable or what the best of doing this is.
>
> 3) add possibility to pass some data to the machine via
>   pre-filling "Scratch Memory Store". I think this can be done easily
>   moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
>   second function parameter. That should not break anything.
>
> Then the computed hash can be either stored into Scratch memory or returned
> directly (where ordinary sk filters return len).
>
> Does this seems reasonable? Thoughts, comments?
>

Hi all,

I've also been working on mechanism that requires creating custom BFP
filters, but for PID based packet filtering. It allows attaching
custom filters to a
socket, through setsocketopt, making it possible to detect when packets belongs
 to a target process id (previously identified through kprobes).

The in-kernel api we use, enables registering and unregistering filter
functions,
 which are then stored on a filter function list.

When attaching the custom filter function, it replaces the current
filter, releasing the JIT code if necessary. However, the newly
attached filter function does not get JIT compiled (bpf_jit_compile)
to allow custom functions without having to provide the corresponding
ASM code.

Using the JIT extensions that Jirka mentions in step 3 could also allows to
compile custom.

We are in the process of making the source code available through a
project page dedicated to PID monitoring, and will (hopefully) send a
Q/RFC to this list tomorrow.

> Thanks!

Thanks.

>
> Jirka
>

Nuno Martins

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q/RFC] BPF use in broader scope

[Li Yu]

于 2012年03月29日 17:31, Jiri Pirko 写道:
> Thu, Mar 29, 2012 at 10:45:32AM CEST, eric.dumazet@gmail.com wrote:
>> On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
>>> Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>>>> On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>>>>
>>>>> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>>>>>
>>>>
>>>> If you add a new XOR instruction in interpreter only, JIT compiler will
>>>> automatically aborts, so no risk.
>>>>
>>>> Each arch maintainer will add the support for the new instructions as
>>>> separate patches.
>>>>
>>>> So you can focus on net/core/filter.c file only.
>>>>
>>>
>>> Ok - I can do this for 2). But for 3) JITs need to be modified. So I
>>> would like to kindly ask you and Matt if you can do this modification so
>>> bpf_func takes pointer to mem (scratch store) as second parameter. I'm
>>> sure it's very easy for you to do.
>>
>> I am not sure why you want this.
>>
>> This adds register pressure (at least for x86) ...
>
> Well I think that there would become handy to be able to pass some data
> to bpf_func (other than skb). But it's just an idea.
>

Hi, Jiri Pirko, any progress of extended BPF? :)

I am interesting in 3) much. For my requirements,
it just only need BPF has ability to handle arbitrary
"pre-filled memory area", but not handle both a skb and
such a memory area at same time, so I think that register
pressure should not be become the performance bottleneck
here.

Otherwise, I must construct a fake sk_buff to execute filter
feature, it is ugly, isn't it?

I guess that Nuno Martins's requirements also are similar.

And, I also would like join this project, if you need.

Thanks

Yu

>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [Q/RFC] BPF use in broader scope

[Jiri Pirko]

Fri, May 11, 2012 at 04:41:31AM CEST, raise.sail@gmail.com wrote:
>于 2012年03月29日 17:31, Jiri Pirko 写道:
>>Thu, Mar 29, 2012 at 10:45:32AM CEST, eric.dumazet@gmail.com wrote:
>>>On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
>>>>Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>>>>>On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>>>>>
>>>>>>Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>>>>>>
>>>>>
>>>>>If you add a new XOR instruction in interpreter only, JIT compiler will
>>>>>automatically aborts, so no risk.
>>>>>
>>>>>Each arch maintainer will add the support for the new instructions as
>>>>>separate patches.
>>>>>
>>>>>So you can focus on net/core/filter.c file only.
>>>>>
>>>>
>>>>Ok - I can do this for 2). But for 3) JITs need to be modified. So I
>>>>would like to kindly ask you and Matt if you can do this modification so
>>>>bpf_func takes pointer to mem (scratch store) as second parameter. I'm
>>>>sure it's very easy for you to do.
>>>
>>>I am not sure why you want this.
>>>
>>>This adds register pressure (at least for x86) ...
>>
>>Well I think that there would become handy to be able to pass some data
>>to bpf_func (other than skb). But it's just an idea.
>>
>
>Hi, Jiri Pirko, any progress of extended BPF? :)
>
>I am interesting in 3) much. For my requirements,
>it just only need BPF has ability to handle arbitrary
>"pre-filled memory area", but not handle both a skb and
>such a memory area at same time, so I think that register
>pressure should not be become the performance bottleneck
>here.
>
>Otherwise, I must construct a fake sk_buff to execute filter
>feature, it is ugly, isn't it?
>
>I guess that Nuno Martins's requirements also are similar.
>
>And, I also would like join this project, if you need.

For my needs it turned out I do not need pre-filled memory. So I dropped
that point.

>
>Thanks
>
>Yu
>
>>>
>>>
>>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe netdev" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

Re: [Q/RFC] BPF use in broader scope

[Li Yu]

于 2012年05月11日 14:22, Jiri Pirko 写道:
> Fri, May 11, 2012 at 04:41:31AM CEST, raise.sail@gmail.com wrote:
>> 于 2012年03月29日 17:31, Jiri Pirko 写道:
>>> Thu, Mar 29, 2012 at 10:45:32AM CEST, eric.dumazet@gmail.com wrote:
>>>> On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
>>>>> Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>>>>>> On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>>>>>>
>>>>>>> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>>>>>>>
>>>>>>
>>>>>> If you add a new XOR instruction in interpreter only, JIT compiler will
>>>>>> automatically aborts, so no risk.
>>>>>>
>>>>>> Each arch maintainer will add the support for the new instructions as
>>>>>> separate patches.
>>>>>>
>>>>>> So you can focus on net/core/filter.c file only.
>>>>>>
>>>>>
>>>>> Ok - I can do this for 2). But for 3) JITs need to be modified. So I
>>>>> would like to kindly ask you and Matt if you can do this modification so
>>>>> bpf_func takes pointer to mem (scratch store) as second parameter. I'm
>>>>> sure it's very easy for you to do.
>>>>
>>>> I am not sure why you want this.
>>>>
>>>> This adds register pressure (at least for x86) ...
>>>
>>> Well I think that there would become handy to be able to pass some data
>>> to bpf_func (other than skb). But it's just an idea.
>>>
>>
>> Hi, Jiri Pirko, any progress of extended BPF? :)
>>
>> I am interesting in 3) much. For my requirements,
>> it just only need BPF has ability to handle arbitrary
>> "pre-filled memory area", but not handle both a skb and
>> such a memory area at same time, so I think that register
>> pressure should not be become the performance bottleneck
>> here.
>>
>> Otherwise, I must construct a fake sk_buff to execute filter
>> feature, it is ugly, isn't it?
>>
>> I guess that Nuno Martins's requirements also are similar.
>>
>> And, I also would like join this project, if you need.
>
> For my needs it turned out I do not need pre-filled memory. So I dropped
> that point.
>

Oops, I may try to work on this, would you like send
a copy of your sk-unattached filters patch to me ?
I think that it is a good start.

Thanks for your time.

Yu

>>
>> Thanks
>>
>> Yu
>>
>>>>
>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>

Re: [Q/RFC] BPF use in broader scope

[Jiri Pirko]

Fri, May 11, 2012 at 09:06:42AM CEST, raise.sail@gmail.com wrote:
>于 2012年05月11日 14:22, Jiri Pirko 写道:
>>Fri, May 11, 2012 at 04:41:31AM CEST, raise.sail@gmail.com wrote:
>>>于 2012年03月29日 17:31, Jiri Pirko 写道:
>>>>Thu, Mar 29, 2012 at 10:45:32AM CEST, eric.dumazet@gmail.com wrote:
>>>>>On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
>>>>>>Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>>>>>>>On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>>>>>>>
>>>>>>>>Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>>>>>>>>
>>>>>>>
>>>>>>>If you add a new XOR instruction in interpreter only, JIT compiler will
>>>>>>>automatically aborts, so no risk.
>>>>>>>
>>>>>>>Each arch maintainer will add the support for the new instructions as
>>>>>>>separate patches.
>>>>>>>
>>>>>>>So you can focus on net/core/filter.c file only.
>>>>>>>
>>>>>>
>>>>>>Ok - I can do this for 2). But for 3) JITs need to be modified. So I
>>>>>>would like to kindly ask you and Matt if you can do this modification so
>>>>>>bpf_func takes pointer to mem (scratch store) as second parameter. I'm
>>>>>>sure it's very easy for you to do.
>>>>>
>>>>>I am not sure why you want this.
>>>>>
>>>>>This adds register pressure (at least for x86) ...
>>>>
>>>>Well I think that there would become handy to be able to pass some data
>>>>to bpf_func (other than skb). But it's just an idea.
>>>>
>>>
>>>Hi, Jiri Pirko, any progress of extended BPF? :)
>>>
>>>I am interesting in 3) much. For my requirements,
>>>it just only need BPF has ability to handle arbitrary
>>>"pre-filled memory area", but not handle both a skb and
>>>such a memory area at same time, so I think that register
>>>pressure should not be become the performance bottleneck
>>>here.
>>>
>>>Otherwise, I must construct a fake sk_buff to execute filter
>>>feature, it is ugly, isn't it?
>>>
>>>I guess that Nuno Martins's requirements also are similar.
>>>
>>>And, I also would like join this project, if you need.
>>
>>For my needs it turned out I do not need pre-filled memory. So I dropped
>>that point.
>>
>
>Oops, I may try to work on this, would you like send
>a copy of your sk-unattached filters patch to me ?
>I think that it is a good start.
>
>Thanks for your time.


commit 302d663740cfaf2c364df6bb61cd339014ed714c
Author: Jiri Pirko <jpirko@redhat.com>
Date:   Sat Mar 31 11:01:19 2012 +0000

    filter: Allow to create sk-unattached filters
    
    Today, BPF filters are bind to sockets. Since BPF machine becomes handy
    for other purposes, this patch allows to create unattached filter.
    
    Signed-off-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>


I use that in drivers/net/team/team_mode_loadbalance.c

Jirka



>
>Yu
>
>>>
>>>Thanks
>>>
>>>Yu
>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>the body of a message to majordomo@vger.kernel.org
>>>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>