netdev - Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup

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] [day] [month] [year] [list]

Date:   Fri, 20 Jul 2018 12:07:24 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     daniel@...earbox.net
Cc:     roopa@...ulusnetworks.com, pablo@...filter.org,
        netdev@...r.kernel.org, jiri@...nulli.us, thomas.lendacky@....com,
        f.fainelli@...il.com, ariel.elior@...ium.com,
        michael.chan@...adcom.com, santosh@...lsio.com,
        madalin.bucur@....com, yisen.zhuang@...wei.com,
        salil.mehta@...wei.com, jeffrey.t.kirsher@...el.com,
        tariqt@...lanox.com, saeedm@...lanox.com, jiri@...lanox.com,
        idosch@...lanox.com, ganeshgr@...lsio.com,
        jakub.kicinski@...ronome.com, linux-net-drivers@...arflare.com,
        peppe.cavallaro@...com, alexandre.torgue@...com,
        joabreu@...opsys.com, grygorii.strashko@...com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com
Subject: Re: [PATCH net-next,v2] net: rename ndo_setup_tc to
 ndo_setup_offload

From: Daniel Borkmann <daniel@...earbox.net>
Date: Fri, 20 Jul 2018 19:28:23 +0200

> This might be fine as new ndo depending on the use case this will have (?),
> but fwiw the term 'flow' or 'rule' would be misleading for what tc offload
> would be doing today (e.g. to name one, there's no notion of 'flow' in BPF
> offload). Given today this interface is deeply baked into tc, just a rename
> might not suffice but should probably move the whole handling around it such
> as assembling the offload info into generic net/core/netdev.c as well if this
> is the way to go.

I would much rather see a new NDO for handling a new offload.  That is
consistent with our overall game plan of the past few years ever since
this TC offload NDO went in.

We can't pretend to be able to predict the future and know that these
various things can be consolidated into a single interface beforehand.

It is important to see what implementing a new offload looks like, in
a couple of drivers, first.  And then we can have something to look
at, and discuss, with respect to NDO consolidation.

What is happening with this patch is you are brute force making this
NDO generic, and then saying "I will show you how it can be generic."

Sorry, that's the wrong way around.  Make a new NDO op for your flow
offloading, show how it works and is implemented in a few drivers,
and then (and only then) can you talk about whether consolidating
is possible or appropriate.

Thank you.