All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Chris Mi <chrism@mellanox.com>, netdev@vger.kernel.org
Subject: Re: [patch net-next 0/3] net/sched: Improve getting objects by indexes
Date: Wed, 16 Aug 2017 11:41:11 +0200	[thread overview]
Message-ID: <e13dd37c-f323-ba92-a7a6-cd3515c20ccc@amd.com> (raw)
In-Reply-To: <20170816093144.GE1868@nanopsycho>

Am 16.08.2017 um 11:31 schrieb Jiri Pirko:
> [SNIP]
> I don't. It is an API change, maintainers of the individual drivers are
> not expected to review the patches like this.

Yeah, completely agree.

>> If yes then it somehow makes sense to send the patch bit by bit, if no then
>> it doesn't seem to make to much sense to CC them all individually.
>>
>>>>>> I've never read the bsg code before, but that's certainly not correct. And
>>>>>> that incorrect pattern repeats over and over again in this code.
>>>>>>
>>>>>> Apart from that why the heck do you want to allocate more than 1<<31 handles?
>>>>> tc action indexes for example. That is part of this patchset.
>>>> Well, let me refine the question: Why does tc action indexes need more than
>>>> 31 bits? From an outside view that looks like pure overkill.
>>> That is current state, uapi. We have to live with it.
>> Is the range to allocate from part of the uapi or what is the issue here?
> Yes.

A bit strange uapi design, but ok in this case that change actually 
makes sense.

>> If the issue is that userspace can specify the handle then I suggest that you
>> use the radix tree directly instead of the idr wrapper around it.
> But why? idr is exactly the tool we need. Only signed int does not suit
> us. In fact, it does not make sense idr is using signed int when it
> uses radix tree with unsigned long under the hood.

Well it always depends on what you do and how to use it.

In amdgpu for example for have very very short lived objects and only 
few of them are active at the same time.

The solution was not to use and idr, but rather 64bit identifiers and a 
ring buffer with the last 128 entries.

But in your case changing the idr calling convention actually makes 
sense (at least from the tn mile high view), feel free to add an 
Acked-by: Christian König <christian.koenig@amd.com> on it.

Regards,
Christian.

  reply	other threads:[~2017-08-16  9:41 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16  2:12 [patch net-next 0/3] net/sched: Improve getting objects by indexes Chris Mi
2017-08-16  2:12 ` [Cluster-devel] " Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` [patch net-next 1/3] idr: Use unsigned long instead of int Chris Mi
2017-08-16  2:12   ` [Cluster-devel] " Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16 21:44   ` Alexey Dobriyan
2017-08-16 21:56   ` Frank Rowand
2017-08-16 21:56     ` Frank Rowand
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` [patch net-next 2/3] net/sched: Change cls_flower to use IDR Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12   ` [Cluster-devel] " Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12 ` [patch net-next 3/3] net/sched: Change act_api and act_xxx modules " Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  2:12   ` [Cluster-devel] " Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12   ` Chris Mi
2017-08-16  2:12 ` Chris Mi
2017-08-16  3:05 ` [patch net-next 0/3] net/sched: Improve getting objects by indexes David Miller
2017-08-16  3:38   ` Chris Mi
2017-08-16  7:49 ` Christian König
2017-08-16  7:49 ` Christian König
2017-08-16  7:49 ` Christian König
2017-08-16  7:49   ` [Cluster-devel] " Christian König
2017-08-16  7:49   ` Christian König
2017-08-16  7:49   ` Christian König
2017-08-16  7:49   ` Christian König
2017-08-16  8:16   ` Jiri Pirko
2017-08-16  8:31     ` Christian König
2017-08-16  8:39       ` Jiri Pirko
2017-08-16  8:55         ` Christian König
2017-08-16  9:31           ` Jiri Pirko
2017-08-16  9:41             ` Christian König [this message]
2017-08-16 14:28       ` David Laight
2017-08-16  9:19   ` Chris Wilson
2017-08-16  9:19   ` Chris Wilson
2017-08-16  9:19   ` Chris Wilson
2017-08-16  9:19     ` Chris Wilson
2017-08-16  9:19     ` [Cluster-devel] " Chris Wilson
2017-08-16  9:19     ` Chris Wilson
2017-08-16  9:19     ` Chris Wilson
2017-08-16  9:19     ` Chris Wilson
2017-08-16  9:19     ` Chris Wilson
2017-08-16  9:19   ` Chris Wilson
2017-08-16  7:49 ` Christian König
2017-08-16 21:51 ` Frank Rowand
2017-08-16 21:51   ` Frank Rowand
  -- strict thread matches above, loose matches on Subject: below --
2017-08-28  6:41 Chris Mi
2017-08-16  2:12 Chris Mi
2017-08-16  2:12 Chris Mi
2017-08-16  2:12 Chris Mi

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=e13dd37c-f323-ba92-a7a6-cd3515c20ccc@amd.com \
    --to=christian.koenig@amd.com \
    --cc=chrism@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    /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.