From: Jiri Pirko <jiri@resnulli.us>
To: David Miller <davem@davemloft.net>
Cc: alexander.duyck@gmail.com, amritha.nambiar@intel.com,
intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com,
alexander.h.duyck@intel.com, netdev@vger.kernel.org,
jhs@mojatatu.com, xiyou.wangcong@gmail.com
Subject: Re: [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e
Date: Wed, 11 Oct 2017 23:28:57 +0200 [thread overview]
Message-ID: <20171011212857.GE9297@nanopsycho> (raw)
In-Reply-To: <20171011.141929.2232480660433567821.davem@davemloft.net>
Wed, Oct 11, 2017 at 11:19:29PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.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 :)
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e
Date: Wed, 11 Oct 2017 23:28:57 +0200 [thread overview]
Message-ID: <20171011212857.GE9297@nanopsycho> (raw)
In-Reply-To: <20171011.141929.2232480660433567821.davem@davemloft.net>
Wed, Oct 11, 2017 at 11:19:29PM CEST, davem at davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.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 :)
next prev parent reply other threads:[~2017-10-11 21:28 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 0:24 [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 1/6] cls_flower: Offload classid to hardware Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 2/6] i40e: Map TCs with the VSI seids Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 3/6] i40e: Cloud filter mode for set_switch_config command Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 23:30 ` Shannon Nelson
2017-10-11 23:30 ` Shannon Nelson
2017-10-26 21:10 ` Nambiar, Amritha
2017-10-26 21:10 ` Nambiar, Amritha
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 4/6] i40e: Admin queue definitions for cloud filters Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 23:30 ` Shannon Nelson
2017-10-11 23:30 ` Shannon Nelson
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 5/6] i40e: Clean up of " Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 23:30 ` Shannon Nelson
2017-10-11 23:30 ` Shannon Nelson
2017-10-11 0:24 ` [jkirsher/next-queue PATCH v4 6/6] i40e: Enable cloud filters via tc-flower Amritha Nambiar
2017-10-11 0:24 ` [Intel-wired-lan] " Amritha Nambiar
2017-10-11 23:30 ` Shannon Nelson
2017-10-11 23:30 ` Shannon Nelson
2017-10-26 21:29 ` Nambiar, Amritha
2017-10-26 21:29 ` Nambiar, Amritha
2017-10-26 21:35 ` Shannon Nelson
2017-10-26 21:35 ` Shannon Nelson
2017-10-26 21:47 ` Nambiar, Amritha
2017-10-26 21:47 ` Nambiar, Amritha
2017-10-11 12:42 ` [jkirsher/next-queue PATCH v4 0/6] tc-flower based cloud filters in i40e Jamal Hadi Salim
2017-10-11 12:42 ` [Intel-wired-lan] " Jamal Hadi Salim
2017-10-11 22:41 ` Nambiar, Amritha
2017-10-11 22:41 ` [Intel-wired-lan] " Nambiar, Amritha
2017-10-11 12:56 ` Jiri Pirko
2017-10-11 12:56 ` [Intel-wired-lan] " Jiri Pirko
2017-10-11 17:46 ` Alexander Duyck
2017-10-11 17:46 ` [Intel-wired-lan] " Alexander Duyck
2017-10-11 20:38 ` Jiri Pirko
2017-10-11 20:38 ` [Intel-wired-lan] " Jiri Pirko
2017-10-11 20:46 ` David Miller
2017-10-11 20:46 ` [Intel-wired-lan] " David Miller
2017-10-11 20:58 ` Jiri Pirko
2017-10-11 20:58 ` [Intel-wired-lan] " Jiri Pirko
2017-10-11 21:19 ` David Miller
2017-10-11 21:19 ` [Intel-wired-lan] " David Miller
2017-10-11 21:28 ` Jiri Pirko [this message]
2017-10-11 21:28 ` Jiri Pirko
2017-10-12 7:05 ` Alexander Duyck
2017-10-12 7:05 ` [Intel-wired-lan] " Alexander Duyck
2017-10-12 7:30 ` Jiri Pirko
2017-10-12 7:30 ` [Intel-wired-lan] " Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171011212857.GE9297@nanopsycho \
--to=jiri@resnulli.us \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=amritha.nambiar@intel.com \
--cc=davem@davemloft.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.