netdev - Re: [PATCH net-next RFC 00/20] Introducing P4TC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Jan 2023 13:17:14 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     John Fastabend <john.fastabend@...il.com>,
        Jamal Hadi Salim <hadi@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Willem de Bruijn <willemb@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        kernel@...atatu.com, deb.chatterjee@...el.com,
        anjali.singhai@...el.com, namrata.limaye@...el.com,
        khalidm@...dia.com, tom@...anda.io, pratyush@...anda.io,
        xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, vladbu@...dia.com, simon.horman@...igine.com,
        stefanc@...vell.com, seong.kim@....com, mattyk@...dia.com,
        dan.daly@...el.com, john.andy.fingerhut@...el.com
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC

Jamal Hadi Salim <jhs@...atatu.com> writes:

> Toke, i dont think i have managed to get across that there is an
> "autonomous" control built into the kernel. It is not just things that
> come across netlink. It's about the whole infra.

I'm not disputing the need for the TC infra to configure the pipelines
and their relationship in the hardware. I'm saying that your
implementation *of the SW path* is the wrong approach and it would be
better done by using BPF (not talking about the existing TC-BPF,
either).

It's a bit hard to know your thinking for sure here, since your patch
series doesn't include any of the offload control bits. But from the
slides and your hints in this series, AFAICT, the flow goes something
like:

hw_pipeline_id = devlink_program_hardware(dev, p4_compiled_blob);
sw_pipeline_id = `tc p4template create ...` (etc, this is generated by P4C)

tc_act = tc_act_create(hw_pipeline_id, sw_pipeline_id)

which will turn into something like:

struct p4_cls_offload ofl = {
  .classid = classid,
  .pipeline_id = hw_pipeline_id
};

if (check_sw_and_hw_equivalence(hw_pipeline_id, sw_pipeline_id)) /* some magic check here */
  return -EINVAL;

netdev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_P4, &ofl);

I.e, all that's being passed to the hardware is the ID of the
pre-programmed pipeline, because that programming is going to be
out-of-band via devlink anyway.

In which case, you could just as well replace the above:

sw_pipeline_id = `tc p4template create ...` (etc, this is generated by P4C)

with

sw_pipeline_id = bpf_prog_load(BPF_PROG_TYPE_P4TC, "my_obj_file.o"); /* my_obj_file is created by P4c */

and achieve exactly the same.

Having all the P4 data types and concepts exist inside the kernel
*might* make sense if the kernel could then translate those into the
hardware representations and manage their lifecycle in a uniform way.
But as far as I can tell from the slides and what you've been saying in
this thread that's not going to be possible anyway, so why do you need
anything more granular than the pipeline ID?

-Toke