netdev - Re: [net-next v8 2/2] net: sched: support hash/classid/cpuid selecting tx queue

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:   Mon, 31 Jan 2022 08:12:18 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Cong Wang <xiyou.wangcong@...il.com>,
        Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Alexander Lobakin <alobakin@...me>,
        Paolo Abeni <pabeni@...hat.com>,
        Talal Ahmad <talalahmad@...gle.com>,
        Kevin Hao <haokexin@...il.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Kees Cook <keescook@...omium.org>,
        Kumar Kartikeya Dwivedi <memxor@...il.com>,
        Antoine Tenart <atenart@...nel.org>,
        Wei Wang <weiwan@...gle.com>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [net-next v8 2/2] net: sched: support hash/classid/cpuid
 selecting tx queue

On 2022-01-26 14:52, Cong Wang wrote:
> You really should just use eBPF, with eBPF code you don't even need
> to send anything to upstream, you can do whatever you want without
> arguing with anyone. It is a win-win.

Cong,

This doesnt work in some environments. Example:

1) Some data centres (telco large and medium sized enteprises that
i have personally encountered) dont allow for anything that requires
compilation to be introduced (including ebpf).
They depend on upstream - if something is already in the kernel and
requires a script it becomes an operational issue which is a simpler
process.
This is unlike large organizations who have staff of developers
dedicated to coding stuff. Most of the folks i am talking about
have zero developers in house. But even if they did have a few,
introducing code into the kernel that has to be vetted by a
multitude of internal organizations tends to be a very
long process.

2) In some cases adding new code voids the distro vendor's
support warranty and you have to pay the distro vendor to
vet and put your changes via their regression testing.
Most of these organizations are tied to one or other distro
vendor and they dont want to mess with the warranty or pay
extra fees which causes more work for them (a lot of them
have their own vetting process after the distro vendors vetting).

I am not sure what the OP's situation is - but what i described
above is _real_. If there is some extension to existing features like
skbedit and there is a good use case IMO we should allow for it.

cheers,
jamal