From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC net-next 3/4] gianfar: Separate out the Rx and Tx coalescing functions
Date: Wed, 8 Aug 2012 11:44:55 -0400 [thread overview]
Message-ID: <20120808154454.GA11043@windriver.com> (raw)
In-Reply-To: <1344428810-29923-4-git-send-email-claudiu.manoil@freescale.com>
[[RFC net-next 3/4] gianfar: Separate out the Rx and Tx coalescing functions] On 08/08/2012 (Wed 15:26) Claudiu Manoil wrote:
> Split the coalescing programming support by Rx and Tx h/w queues, in order to
> introduce a separate NAPI for the Tx confirmation path (next patch). This way,
> the Rx processing path will handle the coalescing settings for the Rx queues
> only, resp. the Tx confirmation processing path will handle the Tx queues.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> drivers/net/ethernet/freescale/gianfar.c | 36 +++++++++++++++++++++++------
> 1 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index ddd350a..919acb3 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -1794,8 +1794,8 @@ void gfar_start(struct net_device *dev)
> dev->trans_start = jiffies; /* prevent tx timeout */
> }
>
> -void gfar_configure_coalescing(struct gfar_private *priv,
> - unsigned long tx_mask, unsigned long rx_mask)
> +static inline void gfar_configure_tx_coalescing(struct gfar_private *priv,
I believe the preference is to not specify inline when all the chunks in
play are present in the one C file -- i.e. let gcc figure it out. Same
for the Rx instance below.
P.
--
> + unsigned long mask)
> {
> struct gfar __iomem *regs = priv->gfargrp[0].regs;
> u32 __iomem *baddr;
> @@ -1803,14 +1803,31 @@ void gfar_configure_coalescing(struct gfar_private *priv,
> if (priv->mode == MQ_MG_MODE) {
> int i;
> baddr = ®s->txic0;
> - for_each_set_bit(i, &tx_mask, priv->num_tx_queues) {
> + for_each_set_bit(i, &mask, priv->num_tx_queues) {
> gfar_write(baddr + i, 0);
> if (likely(priv->tx_queue[i]->txcoalescing))
> gfar_write(baddr + i, priv->tx_queue[i]->txic);
> }
> + } else {
> + /* Backward compatible case ---- even if we enable
> + * multiple queues, there's only single reg to program
> + */
> + gfar_write(®s->txic, 0);
> + if (likely(priv->tx_queue[0]->txcoalescing))
> + gfar_write(®s->txic, priv->tx_queue[0]->txic);
> + }
> +}
> +
> +static inline void gfar_configure_rx_coalescing(struct gfar_private *priv,
> + unsigned long mask)
> +{
> + struct gfar __iomem *regs = priv->gfargrp[0].regs;
> + u32 __iomem *baddr;
>
> + if (priv->mode == MQ_MG_MODE) {
> + int i;
> baddr = ®s->rxic0;
> - for_each_set_bit(i, &rx_mask, priv->num_rx_queues) {
> + for_each_set_bit(i, &mask, priv->num_rx_queues) {
> gfar_write(baddr + i, 0);
> if (likely(priv->rx_queue[i]->rxcoalescing))
> gfar_write(baddr + i, priv->rx_queue[i]->rxic);
> @@ -1819,16 +1836,19 @@ void gfar_configure_coalescing(struct gfar_private *priv,
> /* Backward compatible case ---- even if we enable
> * multiple queues, there's only single reg to program
> */
> - gfar_write(®s->txic, 0);
> - if (likely(priv->tx_queue[0]->txcoalescing))
> - gfar_write(®s->txic, priv->tx_queue[0]->txic);
> -
> gfar_write(®s->rxic, 0);
> if (likely(priv->rx_queue[0]->rxcoalescing))
> gfar_write(®s->rxic, priv->rx_queue[0]->rxic);
> }
> }
>
> +void gfar_configure_coalescing(struct gfar_private *priv,
> + unsigned long tx_mask, unsigned long rx_mask)
> +{
> + gfar_configure_tx_coalescing(priv, tx_mask);
> + gfar_configure_rx_coalescing(priv, rx_mask);
> +}
> +
> static int register_grp_irqs(struct gfar_priv_grp *grp)
> {
> struct gfar_private *priv = grp->priv;
> --
> 1.6.6
>
>
next prev parent reply other threads:[~2012-08-08 15:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 12:26 [RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing Claudiu Manoil
2012-08-08 12:26 ` [RFC net-next 1/4] gianfar: Remove redundant programming of [rt]xic registers Claudiu Manoil
2012-08-08 12:26 ` [RFC net-next 2/4] gianfar: Clear ievent from interrupt handler for [RT]x int Claudiu Manoil
2012-08-08 12:26 ` [RFC net-next 3/4] gianfar: Separate out the Rx and Tx coalescing functions Claudiu Manoil
2012-08-08 12:26 ` [RFC net-next 4/4] gianfar: Use separate NAPIs for Tx and Rx processing Claudiu Manoil
2012-08-14 0:51 ` Paul Gortmaker
2012-08-14 16:08 ` Claudiu Manoil
2012-08-08 15:44 ` Paul Gortmaker [this message]
2012-08-09 16:24 ` [RFC net-next 3/4] gianfar: Separate out the Rx and Tx coalescing functions Claudiu Manoil
2012-08-15 1:29 ` Paul Gortmaker
2012-08-08 16:11 ` [RFC net-next 2/4] gianfar: Clear ievent from interrupt handler for [RT]x int Paul Gortmaker
2012-08-09 16:04 ` Claudiu Manoil
2012-08-08 16:24 ` [RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing Paul Gortmaker
2012-08-08 16:44 ` Eric Dumazet
2012-08-08 23:06 ` Tomas Hruby
2012-08-09 15:07 ` Claudiu Manoil
2012-08-13 16:23 ` Claudiu Manoil
2012-08-14 1:15 ` Paul Gortmaker
2012-08-14 16:08 ` Claudiu Manoil
2012-08-16 15:36 ` Paul Gortmaker
2012-08-17 11:28 ` Claudiu Manoil
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=20120808154454.GA11043@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=claudiu.manoil@freescale.com \
--cc=davem@davemloft.net \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).