From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: David Miller <davem@davemloft.net>
Cc: hzpeterchen@gmail.com, linux-usb@vger.kernel.org,
ville.syrjala@linux.intel.com, stable@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: u_ether: remove interrupt throttling
Date: Mon, 07 Nov 2016 14:39:21 +0200 [thread overview]
Message-ID: <877f8fjwg6.fsf@linux.intel.com> (raw)
In-Reply-To: <20161103.130402.357203788680388748.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]
Hi,
David Miller <davem@davemloft.net> writes:
> From: Felipe Balbi <felipe.balbi@linux.intel.com>
> Date: Thu, 03 Nov 2016 09:04:54 +0200
>
>> What Dave Miller is saying is that it's ALWAYS a bug to delay
>> completion of SKBs. The only thing you're doing with chipidea is
>> delaying interrupt by up to 125us; which is still a bug from the
>> point of view of the networking layer, but it's more difficult to
>> perceive any problems because of the short time where interrupt is
>> delayed.
>
> I didn't say delaying was illegal.
>
> I said that the SKB free must occur in a reasonable, finite, amount of
> time.
"reasonable" is rather subjective. Completions are, of course,
finite. It just means that once a transfer completes *and* has interrupt
enabled, then several other SKBs will be completed along with it.
That doesn't mean *all* SKBs completed at the same time, it means once
we get an interrupt, we give back all previous ones, but we don't know
exactly when they completed.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
next prev parent reply other threads:[~2016-11-07 12:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-01 11:29 [PATCH] usb: gadget: u_ether: remove interrupt throttling Felipe Balbi
2016-11-01 12:21 ` Ville Syrjälä
2016-11-02 6:02 ` Peter Chen
2016-11-02 7:55 ` Felipe Balbi
2016-11-02 8:36 ` Peter Chen
2016-11-02 11:02 ` Felipe Balbi
2016-11-03 0:32 ` Peter Chen
2016-11-03 8:36 ` Felipe Balbi
2016-11-02 15:22 ` David Miller
2016-11-03 0:23 ` Peter Chen
2016-11-03 7:04 ` Felipe Balbi
2016-11-03 9:03 ` Peter Chen
2016-11-03 9:53 ` Peter Chen
2016-11-03 10:48 ` Felipe Balbi
2016-11-04 2:11 ` Peter Chen
2016-11-07 12:36 ` Felipe Balbi
2016-11-08 1:42 ` Peter Chen
2016-11-03 10:42 ` Felipe Balbi
2016-11-04 1:12 ` Peter Chen
2016-11-04 1:14 ` Peter Chen
2016-11-03 17:04 ` David Miller
2016-11-07 12:39 ` Felipe Balbi [this message]
2016-11-07 15:50 ` David Miller
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=877f8fjwg6.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=davem@davemloft.net \
--cc=hzpeterchen@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=ville.syrjala@linux.intel.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.