netdev - Re: [net-next v7 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] [day] [month] [year] [list]

Message-ID: <CAMDZJNUsYjQYM5LpoDm1P60-n5+y_dDi7CuRw8PYZrAw3aGdxA@mail.gmail.com>
Date:   Thu, 27 Jan 2022 09:13:38 +0800
From:   Tonghao Zhang <xiangxia.m.yue@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        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 v7 2/2] net: sched: support hash/classid/cpuid
 selecting tx queue

On Thu, Jan 27, 2022 at 3:49 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Fri, Dec 24, 2021 at 2:44 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Fri, 24 Dec 2021 11:28:45 -0800 Cong Wang wrote:
> > > On Fri, Dec 24, 2021 at 8:49 AM <xiangxia.m.yue@...il.com> wrote:
> > > > From: Tonghao Zhang <xiangxia.m.yue@...il.com>
> > > >
> > > > This patch allows user to select queue_mapping, range
> > > > from A to B. And user can use skbhash, cgroup classid
> > > > and cpuid to select Tx queues. Then we can load balance
> > > > packets from A to B queue. The range is an unsigned 16bit
> > > > value in decimal format.
> > > >
> > > > $ tc filter ... action skbedit queue_mapping skbhash A B
> > > >
> > > > "skbedit queue_mapping QUEUE_MAPPING" (from "man 8 tc-skbedit")
> > > > is enhanced with flags:
> > > > * SKBEDIT_F_TXQ_SKBHASH
> > > > * SKBEDIT_F_TXQ_CLASSID
> > > > * SKBEDIT_F_TXQ_CPUID
> > >
> > > NACK.
> > >
> > > These values can either obtained from user-space, or is nonsense
> > > at all.
> >
> > Can you elaborate? What values can be obtained from user space?
> > What is nonsense?
>
> Of course.
>
> 1. SKBHASH is nonsense, because from a user's point of view, it really
> has no meaning at all, skb hash itself is not visible to user and setting
> an invisible value to as an skb queue mapping is pretty much like setting
> a random value here.
Yes, use the skb hash as a random value, so different flows from same
pod can be balanced to different tx queues.
we can't pass a userspace value to do the balance, maybe we only match
the src ip of k8s pod.
> 2. CLASSID is obviously easy to obtain from user-space, as it is passed
> from user-space.
How about the case, multi pods share the same tx queue range, we use
the CLASSID to do balance, not as match filter.
> 3. CPUID is nonsense, because a process can be migrated easily from
> one CPU to another. Putting OOO packets side, users can't figure out
> which CPU the process is running *in general*. (Of course you can bind
> CPU but clearly you can't bind every process)
this is used for k8s pod, not for every applications on host. when the
pod share the tx queues range, so them can use
the tx queue according which cpu used.
> >
> > > Sorry, we don't accept enforcing such bad policies in kernel. Please
> > > drop this patch.
> >
> > Again, unclear what your objection is. There's plenty similar
> > functionality in TC. Please be more specific.
>
> What exact TC functionality are you talking about? Please be specific.
> If you mean Qdisc's, it is virtually just impossible to have a programmable
> Qdisc, even my eBPF Qdisc only provides very limited programmablities.
>
> If you mean TC filter or action, we already have eBPF filter and eBPF
> action.
>
> Thanks.



-- 
Best regards, Tonghao