netdev - Re: [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e

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:   Wed, 11 Oct 2017 23:28:57 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     David Miller <davem@...emloft.net>
Cc:     alexander.duyck@...il.com, amritha.nambiar@...el.com,
        intel-wired-lan@...ts.osuosl.org, jeffrey.t.kirsher@...el.com,
        alexander.h.duyck@...el.com, netdev@...r.kernel.org,
        jhs@...atatu.com, xiyou.wangcong@...il.com
Subject: Re: [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters
 in i40e

Wed, Oct 11, 2017 at 11:19:29PM CEST, davem@...emloft.net wrote:
>From: Jiri Pirko <jiri@...nulli.us>
>Date: Wed, 11 Oct 2017 22:58:30 +0200
>
>> Well if I see classid, I expect it should refer to qdisc instance. So
>> far, this has been always a case. But for some drivers, this would mean
>> something totally different and unrelated. So what should I think?
>> What's next? Classid could be abused to identify something else. I don't
>> understand why.
>> 
>> classid in kernel and tclass in hw are 2 completely unrelated things.
>
>Why do they need to be different?
>
>It's qdisc instance in both cases.  The driver is just using it to
>refer to the qdisc as offloaded in the hardware.  It's a key, nothing
>more.  The context in which it is used doesn't change it's meaning.
>
>> Why they should share the same userspace api? What am I missing that
>> indicates this is not an abuse?
>
>Why invent a completely new ID space to refer to something we exactly
>have an ID for already?
>
>This duplication for the sake of "API" makes no sense to me.
>
>The handle is not going away.  It is not going to stop referring to
>a specific qdisc.
>
>So it's stable and appropriate to use to refer to a qdisc, whatever
>operation being performed, or offload being we are going to perform of
>it.

Okay, fair enough. Yet, I can't say I'm happy with it :/ But I guess
that what you say makes sense.


>
>I notice you are quite feisty lately in your reviews of other people's
>work, so I have to ask if things are very stressful in your life?

:) Yeah, that is probably coincidental. Lots of odd offloading stuff is
happening lately.


>Please drink a nice warm cup of tea and calm down :-)

I'm perfectly calm. But thanks for showing the care :)