From: "Ahmed S. Darwish" <darwish.07@gmail.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Olivier Sobrie <olivier@sobrie.be>,
Oliver Hartkopp <socketcan@hartkopp.net>,
Wolfgang Grandegger <wg@grandegger.com>,
Andri Yngvason <andri.yngvason@marel.com>,
Linux-CAN <linux-can@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH v4 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions
Date: Sat, 14 Mar 2015 17:19:45 +0200 [thread overview]
Message-ID: <20150314151945.GA18736@vivalin-002> (raw)
In-Reply-To: <55044C9F.2070105@pengutronix.de>
On Sat, Mar 14, 2015 at 03:58:39PM +0100, Marc Kleine-Budde wrote:
> On 03/14/2015 03:38 PM, Ahmed S. Darwish wrote:
> >> Applied to can. This will go into David's net tree and finally into
> >> net-next. Then I'll apply patches 2+3. Nag me, if I forget about them ;)
> >>
> >
> > Thanks! :-)
> >
> > So if I've understood correctly, this patch will go to -rc5 and
> > the rest will go into net-next?
> >
> > If so, IMHO patch #2 should also go to -rc5. I know it's usually
> > frowned up on to add further patches at this late -rc stage, but
> > here's my logic:
> >
> > The original driver code just _arbitrarily_ assumed a MAX_TX_URB
> > value of 16 parallel transmissions. This value was chosen, it seems,
> > because the driver was heavily based on esd_usb2.c and the esd code
> > just did so :-(
> >
> > Meanwhile, in the Kvaser hardware at hand, if I've increased the
> > driver's max parallel transmissions little above the recommended
> > limit reported by firmware, the firmware breaks up badly, reports a
> > massive list of internal errors, and the candump traces becomes
> > sort of an internal mess hardly related to the actual frames sent
> > and received.
>
> In this particular hardware, what's the limit as reported by the firmware?
>
48 max oustanding tx, which is quite big in itself it seems.
Other drivers in the tree range between 10 (Peak) and 20 tx (8dev).
> > In my case, I was lucky that the brand we own here (*) had a higher
> > max outstanding transmissions value than 16. But if there is hardware
>
> Okay - higher.
>
> > out there with a max oustanding tx support < 16 (#), such hardware
> > will break badly under a heavy transmission load :-(
>
> I see.
>
> If you add this motivation to the patch description and let the subject
> reflect that this is a "fix" or safety measure rather than a possible
> performance improvement, no-one will say anything against this patch :D
>
True; I admit the "fix" part should've been clearer :-)
Will send a better worded commit message then.
Thanks a lot,
Darwish
prev parent reply other threads:[~2015-03-14 15:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150226152011.GA6075@linux>
[not found] ` <20150226152202.GB6075@linux>
[not found] ` <20150226152436.GC6075@linux>
[not found] ` <20150226152558.GD6075@linux>
2015-02-26 15:29 ` [PATCH 5/5] can: kvaser_usb: Fix tx queue start/stop race conditions Ahmed S. Darwish
[not found] ` <20150311173744.GA13095@linux>
[not found] ` <5500B6EB.8050905@pengutronix.de>
2015-03-12 19:30 ` [PATCH v3 1/3] " Ahmed S. Darwish
2015-03-14 13:02 ` [PATCH v4 " Ahmed S. Darwish
2015-03-14 13:09 ` [PATCH v4 2/3] can: kvaser_usb: Utilize all possible tx URBs Ahmed S. Darwish
2015-03-14 13:11 ` [PATCH v4 3/3] can: kvaser_usb: Use can-dev unregistration mechanism Ahmed S. Darwish
2015-03-14 15:26 ` Marc Kleine-Budde
2015-03-14 15:41 ` Ahmed S. Darwish
2015-03-14 15:55 ` Marc Kleine-Budde
2015-03-14 16:06 ` Ahmed S. Darwish
2015-03-14 13:41 ` [PATCH v4 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions Marc Kleine-Budde
2015-03-14 14:02 ` according net pull-request - was " Oliver Hartkopp
2015-03-14 14:15 ` Marc Kleine-Budde
2015-03-14 14:38 ` Ahmed S. Darwish
2015-03-14 14:58 ` Marc Kleine-Budde
2015-03-14 15:19 ` Ahmed S. Darwish [this message]
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=20150314151945.GA18736@vivalin-002 \
--to=darwish.07@gmail.com \
--cc=andri.yngvason@marel.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=olivier@sobrie.be \
--cc=socketcan@hartkopp.net \
--cc=wg@grandegger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox