From: Niklas Cassel <niklas.cassel@axis.com>
To: Joao.Pinto@synopsys.com,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Jose.Abreu@synopsys.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues
Date: Fri, 8 Dec 2017 00:57:45 +0100 [thread overview]
Message-ID: <20171207235745.GA15639@axis.com> (raw)
In-Reply-To: <20171207225610.15572-1-niklas.cassel@axis.com>
On Thu, Dec 07, 2017 at 11:56:10PM +0100, Niklas Cassel wrote:
> Since each DMA channel can be used for rx and tx simultaneously,
> the current code should probably be rewritten so that napi_struct is
> embedded in a new struct stmmac_channel.
> That way, stmmac_poll() can call stmmac_tx_clean() on just the tx queue
> where we got the IRQ, instead of looping through all tx queues.
> This is also how the xgbe driver does it (another driver for this IP).
Did anyone at Synopsys ever try this driver with a device tree
where num tx queues != num rx queues?
I know your hardware has 8 rx queues and 8 tx queues, but
that doesn't mean that you have to enable them all.
After fixing this crash, I'm still seeing tx timeouts with multi-queue
device trees. (At Axis we usually only enable 1 tx queue and 1 rx queue).
The multi-queue code seems a bit messy.. refactoring so that napi_struct
is in a struct stmmac_channel might help you guys with overall code
readability, since this would then actually match how the hardware works.
With the xgbe driver, xgbe_one_poll disable tx+rx irqs for a specific
channel, then calls futher function only with that specific channel.
With the stmmac driver, there is no connection between napi_struct
and tx. Disable irqs for tx? stmmac_poll loops through all tx queues :)
next prev parent reply other threads:[~2017-12-07 23:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 22:56 [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues Niklas Cassel
2017-12-07 23:57 ` Niklas Cassel [this message]
2017-12-08 19:19 ` David Miller
2017-12-13 10:04 ` Joao Pinto
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=20171207235745.GA15639@axis.com \
--to=niklas.cassel@axis.com \
--cc=Joao.Pinto@synopsys.com \
--cc=Jose.Abreu@synopsys.com \
--cc=alexandre.torgue@st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peppe.cavallaro@st.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.