[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6e12e0c3-3e7a-44cc-8fc1-0e85fa55b3f5@mojatatu.com>
Date: Wed, 24 Jan 2024 08:52:33 -0300
From: Pedro Tammela <pctammela@...atatu.com>
To: Trevor Gross <tmgross@...ch.edu>, Jamal Hadi Salim <jhs@...atatu.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: Suggestions for TC Rust Projects
On 24/01/2024 03:10, Trevor Gross wrote:
> On Tue, Jan 23, 2024 at 3:23 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> [...]
>>
>> I think a good starting point would be tc actions. You can write a
>> simple hello world action.
>> Actions will put to test your approach for implementing netlink and
>> skbs which are widely used in the net stack for both control(by
>> netlink) and the runtime datapath. If you can jump that hoop it will
>> open a lot of doors for you into the network stack.
>> Here's a simple action:
>> https://elixir.bootlin.com/linux/v6.8-rc1/source/net/sched/act_simple.c
>> Actually that one may be hiding a lot of abstractions - but if you
>> look at it we can discuss what it is hiding.
>
> That sounds great, getting an OOT equivalent should be a feasible
> first step. I will pass the information along.
>
>> Note: We have written user space netlink code using rust and it was
>> fine but the kernel side is more complex.
>
> Would that be the code at https://github.com/rust-netlink?
Not really, we wrote a small low level netlink library for an internal tool.
What Jamal means is that dealing with netlink as it was intended in Rust
is not a huge hassle[1]. When we were writing the tool we saw that all
of the existing netlink libraries at the time were doing a serialization
model, which was not acceptable to us. We wanted to build the message in
place without any intermediate structs.
The challenging part for the kernel part will probably be the
abstraction and the interfacing with all the C API that exists to
validate the netlink attributes which is a must.
As for documentation `man 7 netlink` is pretty complete and the iproute2
source code is usually a good test suite for responses.
[1]
Take a look at this snippet for instance:
```
#[derive(Default, NetlinkPolicy)]
pub struct P4TCActOpts {
#[nlattr(nldefs::P4TC_ACT_OPT)]
sel: nltypes::DynaSel,
}
#[derive(Default, NetlinkPolicy)]
pub struct TCAction {
#[nlattr_str(nldefs::TCA_ACT_KIND)]
kind: String,
#[nlnest(nldefs::TCA_ACT_OPTIONS)]
opt: P4TCActOpts,
}
```
The NetlinkPolicy trait handles all the boilerplate to construct the
message in place and in our implementation it's method base:
```
let action = TCAction::default();
action.kind(msg, "foo"); // Adds the attribute `TCA_ACT_KIND` to the msg
in place
```
It kind of resembles the netlink policies in the kernel, so perhaps the
above could be a good starting point for the kernel abstraction.
Powered by blists - more mailing lists