All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Schaa <helmut.schaa@googlemail.com>
To: Kim Phillips <kim.phillips@freescale.com>
Cc: linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH] crypto: talitos: Avoid excessive loops in softirq context
Date: Fri, 12 Sep 2014 09:39:12 +0200	[thread overview]
Message-ID: <CAGXE3d-EiYmJQfEwS9VeR3-5vePNzc2+N20hQTw0vY8FKhJYRA@mail.gmail.com> (raw)
In-Reply-To: <20140911194918.9ea4795f7bb3f9d6e32490eb@freescale.com>

On Fri, Sep 12, 2014 at 2:49 AM, Kim Phillips
<kim.phillips@freescale.com> wrote:
> On Wed, 10 Sep 2014 10:34:47 +0200
> Helmut Schaa <helmut.schaa@googlemail.com> wrote:
>
>> The talitos driver can cause starvation of other softirqs and as such
>> it can also cause rcu stalls like:
> ...
>> Work around this by processing a maximum amount of 16 finished requests
>> and rescheduling the done-tasklet if any work is left.
>> This allows other softirqs to run.
>
> 16 sounds rather arbitrary, and application-dependent - talitos'
> FIFO size is 24.

Yep, 16 is arbitrary, I can also do "fifo_len" if you prefer?

> IIRC, netdev's NAPI can be refactored out of just being able to work
> on network devices, and be made to apply to crypto devices, too.  In
> fact, some old Freescale hacks of this nature have improved
> performance.  Can we do something like refactor NAPI instead?

That would indeed be nice but sounds like quite some more work and
I won't have time to do so. Especially since my system was taken down
completely by the talitos tasklet under some circumstances. If there is
any work going on in that regard I'd be fine with just dropping that patch
(and carrying it myself until the refactoring is done).

Regards,
Helmut

  reply	other threads:[~2014-09-12  7:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10  8:34 [PATCH] crypto: talitos: Avoid excessive loops in softirq context Helmut Schaa
2014-09-12  0:49 ` Kim Phillips
2014-09-12  7:39   ` Helmut Schaa [this message]
2014-09-12 23:21     ` Kim Phillips
2014-09-15  8:40       ` Helmut Schaa

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=CAGXE3d-EiYmJQfEwS9VeR3-5vePNzc2+N20hQTw0vY8FKhJYRA@mail.gmail.com \
    --to=helmut.schaa@googlemail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kim.phillips@freescale.com \
    --cc=linux-crypto@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.