On 15-10-05 10:24 AM, Jiri Pirko wrote:
> Mon, Oct 05, 2015 at 07:07:30PM CEST, john.fastab...@gmail.com wrote:
>
> <snip>
>
>>>
>>> Again, to make this clear, worlds are not just a rehash of tables.
>>>
>>
>> what are they then? Lets model those bits and let users configure them
>> at runtime.
>>
>> So far I've had really good results modelling hardware as a 'parser',
>> a set of tables, and a set of modify blocks. Now this breaks when you
>> start to add black boxes in there for other functions such as encryption
>> but I don't think your getting at that. Do you see something that
>> couldn't be configured/modelled with those blocks?
>
> How about an arbitrary BPF program? I can implement world that bases
> mangling/forwarding packets on intensity of gravitational field.
> Rocker hw is very free in that and cannot be pushed down to "table boxes".
>
> That is making it a wild animal and challenges us to wrap it up in
> kernel, somehow.
>
Just for fun ;)
I would model this as a parser that matches on gravitational field and
and an action that does mangling/forwarding.
So a table,
table { name "gravitational_field_table",
id 10,
size 1024,
matches {(gfield,mask)},
actions {mangle, forward},
}
rules would look like,
match (gfield=0x1000, mask(0xff00)) -> action (mangle), action(forward)
The user can populate these tables using some interface, the ebpf maps
API looks nice and then programs running against hardware and software
use the same API. Or the hardware could populate the table using a
learning algorithm of some sort. Also you could push your bpf program
to user space via an API so that we can create a software equiv of your
hardware.
I think we can tame the wild animal a bit by scoping it to the set of
useful bpf programs. I guess we can argue about what useful is in this
context. I'm going to argue forwarding by gravitational fields is going
to be not so useful in practice.
Thanks,
.John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
