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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 31 Jan 2023 23:53:55 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        John Fastabend <john.fastabend@...il.com>,
        Jamal Hadi Salim <hadi@...atatu.com>,
        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:

> So while going through this thought process, things to consider:
> 1) The autonomy of the tc infra, essentially the skip_sw/hw  controls
> and their packet driven iteration. Perhaps (the patch i pointed to
> from Paul Blakey) where part of the action graph runs in sw.

Yeah, I agree that mixed-mode operation is an important consideration,
and presumably attaching metadata directly to a packet on the hardware
side, and accessing that in sw, is in scope as well? We seem to have
landed on exposing that sort of thing via kfuncs in XDP, so expanding on
that seems reasonable at a first glance.

> 2) The dynamicity of being able to trigger table offloads and/or
> kernel table updates which are packet driven (consider scenario where
> they have iterated the hardware and ingressed into the kernel).

That could be done by either interface, though: the kernel can propagate
a bpf_map_update() from a BPF program to the hardware version of the
table as well. I suspect a map-based API at least on the BPF side would
be more natural, but I don't really have a strong opinion on this :)

-Toke