ble force_irqthreads also comes at
a cost, so that we may not see a benefit compared to calling
local_irq_save/local_irq_restore.
If more or less all users have to switch back, then the question is
whether we should remove __napi_schedule_irqoff.
Instead of touching all users we could make __napi_sche
On Mon, 19 Oct 2020 12:33:12 +0200 Thomas Gleixner wrote:
> On Sun, Oct 18 2020 at 10:19, Jakub Kicinski wrote:
> > On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
> >> >> Otherwise a non-solution could be to make IRQ_FORCED_THREADING
> >> >> configurable.
> >> >
> >> > I have to
On Sun, Oct 18 2020 at 10:19, Jakub Kicinski wrote:
> On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
>> >> Otherwise a non-solution could be to make IRQ_FORCED_THREADING
>> >> configurable.
>> >
>> > I have to say I do not understand why we want to defer to a thread the
>> > hard IRQ
On Sun, 18 Oct 2020 19:57:53 +0200 Heiner Kallweit wrote:
> > Dunno how acceptable this is to run in an IRQ handler on RT..
>
> If I understand this code right then it's not a loop that actually
> waits for something. It just retries if the value of n->state has
> changed in between. So I don't
On 18.10.2020 19:19, Jakub Kicinski wrote:
> On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
Otherwise a non-solution could be to make IRQ_FORCED_THREADING
configurable.
>>>
>>> I have to say I do not understand why we want to defer to a thread the
>>> hard IRQ that we use in
On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
> >> Otherwise a non-solution could be to make IRQ_FORCED_THREADING
> >> configurable.
> >
> > I have to say I do not understand why we want to defer to a thread the
> > hard IRQ that we use in NAPI model.
> >
> Seems like the current
le check. It's trivial enough to make
> it a static key.
>
Pretty cool. I have to admit that I wasn't aware of the jump label
mechanism.
>>> If more or less all users have to switch back, then the question is
>>> whether we should remove __napi_schedule_irqoff.
>>>
able force_irqthreads also comes at
>> a cost, so that we may not see a benefit compared to calling
>> local_irq_save/local_irq_restore.
This does not have to be a variable check. It's trivial enough to make
it a static key.
>> If more or less all users have to switch back, then the
d related discussion. I thought about a
>>> __napi_schedule version checking dynamically whether interrupts are
>>> disabled. But checking e.g. variable force_irqthreads also comes at
>>> a cost, so that we may not see a benefit compared to calling
>>> local_irq_save/lo
upts are
> > disabled. But checking e.g. variable force_irqthreads also comes at
> > a cost, so that we may not see a benefit compared to calling
> > local_irq_save/local_irq_restore.
> >
> > If more or less all users have to switch back, then the question is
ed to calling
> local_irq_save/local_irq_restore.
>
> If more or less all users have to switch back, then the question is
> whether we should remove __napi_schedule_irqoff.
> Instead of touching all users we could make __napi_schedule_irqoff
> an alias for __napi_schedule
11 matches
Mail list logo
