linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@corigine.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
	Chandrasekar Ramakrishnan <rcsekar@samsung.com>,
	Wolfgang Grandegger <wg@grandegger.com>,
	Vincent MAILHOL <mailhol.vincent@wanadoo.fr>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 14/16] can: m_can: Use tx_fifo_in_flight for netif_queue control
Date: Fri, 17 Mar 2023 17:04:14 +0100	[thread overview]
Message-ID: <ZBSPfmWEvl1eSWBV@corigine.com> (raw)
In-Reply-To: <20230315110546.2518305-15-msp@baylibre.com>

On Wed, Mar 15, 2023 at 12:05:44PM +0100, Markus Schneider-Pargmann wrote:
> The network queue is currently always stopped in start_xmit and
> continued in the interrupt handler. This is not possible anymore if we
> want to keep multiple transmits in flight in parallel.
> 
> Use the previously introduced tx_fifo_in_flight counter to control the
> network queue instead. This has the benefit of not needing to ask the
> hardware about fifo status.
> 
> This patch stops the network queue in start_xmit if the number of
> transmits in flight reaches the size of the fifo and wakes up the queue
> from the interrupt handler once the transmits in flight drops below the
> fifo size. This means any skbs over the limit will be rejected
> immediately in start_xmit (it shouldn't be possible at all to reach that
> state anyways).
> 
> The maximum number of transmits in flight is the size of the fifo.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> ---
>  drivers/net/can/m_can/m_can.c | 71 +++++++++++++----------------------
>  1 file changed, 26 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 4ad8f08f8284..3cb3d01e1a61 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c

...

> @@ -1033,17 +1023,31 @@ static void m_can_finish_tx(struct m_can_classdev *cdev, int transmitted)
>  	unsigned long irqflags;
>  
>  	spin_lock_irqsave(&cdev->tx_handling_spinlock, irqflags);
> +	if (cdev->tx_fifo_in_flight >= cdev->tx_fifo_size && transmitted > 0)
> +		netif_wake_queue(cdev->net);
>  	cdev->tx_fifo_in_flight -= transmitted;
>  	spin_unlock_irqrestore(&cdev->tx_handling_spinlock, irqflags);
>  }
>  
> -static void m_can_start_tx(struct m_can_classdev *cdev)
> +static netdev_tx_t m_can_start_tx(struct m_can_classdev *cdev)
>  {
>  	unsigned long irqflags;
> +	int tx_fifo_in_flight;
>  
>  	spin_lock_irqsave(&cdev->tx_handling_spinlock, irqflags);
> -	++cdev->tx_fifo_in_flight;
> +	tx_fifo_in_flight = cdev->tx_fifo_in_flight + 1;
> +	if (tx_fifo_in_flight >= cdev->tx_fifo_size) {
> +		netif_stop_queue(cdev->net);
> +		if (tx_fifo_in_flight > cdev->tx_fifo_size) {
> +			netdev_err(cdev->net, "hard_xmit called while TX FIFO full\n");

Perhaps I misunderstand things.
But it seems that this message is triggered in the datapath.
Thus I think it should be rate limited, or perhaps only logged once.

> +			spin_unlock_irqrestore(&cdev->tx_handling_spinlock, irqflags);
> +			return NETDEV_TX_BUSY;
> +		}
> +	}
> +	cdev->tx_fifo_in_flight = tx_fifo_in_flight;
>  	spin_unlock_irqrestore(&cdev->tx_handling_spinlock, irqflags);
> +
> +	return NETDEV_TX_OK;
>  }
>  
>  static int m_can_echo_tx_event(struct net_device *dev)

...

> @@ -1830,11 +1810,6 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev,
>  		m_can_write(cdev, M_CAN_TXBAR, (1 << putidx));
>  		cdev->tx_fifo_putidx = (++cdev->tx_fifo_putidx >= cdev->can.echo_skb_max ?
>  					0 : cdev->tx_fifo_putidx);
> -
> -		/* stop network queue if fifo full */
> -		if (m_can_tx_fifo_full(cdev) ||
> -		    m_can_next_echo_skb_occupied(dev, putidx))
> -			netif_stop_queue(dev);
>  	}

smatch tells me that m_can_next_echo_skb_occupied is now defined but unused.

>  
>  	return NETDEV_TX_OK;

...

  reply	other threads:[~2023-03-17 16:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-15 11:05 [PATCH v3 00/16] can: m_can: Optimizations for m_can/tcan part 2 Markus Schneider-Pargmann
2023-03-15 11:05 ` [PATCH v3 01/16] can: m_can: Remove repeated check for is_peripheral Markus Schneider-Pargmann
2023-03-16  9:06   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 02/16] can: m_can: Always acknowledge all interrupts Markus Schneider-Pargmann
2023-03-16  9:08   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 03/16] can: m_can: Remove double interrupt enable Markus Schneider-Pargmann
2023-03-16  9:09   ` Simon Horman
2023-03-16  9:10     ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 04/16] can: m_can: Disable unused interrupts Markus Schneider-Pargmann
2023-03-16  9:15   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 05/16] can: m_can: Keep interrupts enabled during peripheral read Markus Schneider-Pargmann
2023-03-16 10:03   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 06/16] can: m_can: Write transmit header and data in one transaction Markus Schneider-Pargmann
2023-03-16  9:27   ` Simon Horman
2023-06-19 11:46     ` Markus Schneider-Pargmann
2023-03-24 18:32   ` Marc Kleine-Budde
2023-03-15 11:05 ` [PATCH v3 07/16] can: m_can: Implement receive coalescing Markus Schneider-Pargmann
2023-03-16 10:04   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 08/16] can: m_can: Implement transmit coalescing Markus Schneider-Pargmann
2023-03-16 10:05   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 09/16] can: m_can: Add rx coalescing ethtool support Markus Schneider-Pargmann
2023-03-16 10:05   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 10/16] can: m_can: Add tx " Markus Schneider-Pargmann
2023-03-16 10:06   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 11/16] can: m_can: Cache tx putidx Markus Schneider-Pargmann
2023-03-16  9:55   ` Simon Horman
2023-03-16 10:08     ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 12/16] can: m_can: Use the workqueue as queue Markus Schneider-Pargmann
2023-03-17 16:18   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 13/16] can: m_can: Introduce a tx_fifo_in_flight counter Markus Schneider-Pargmann
2023-03-17 16:02   ` Simon Horman
2023-06-20 12:53     ` Markus Schneider-Pargmann
2023-06-21 13:50       ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 14/16] can: m_can: Use tx_fifo_in_flight for netif_queue control Markus Schneider-Pargmann
2023-03-17 16:04   ` Simon Horman [this message]
2023-03-15 11:05 ` [PATCH v3 15/16] can: m_can: Implement BQL Markus Schneider-Pargmann
2023-03-17 16:05   ` Simon Horman
2023-03-15 11:05 ` [PATCH v3 16/16] can: m_can: Implement transmit submission coalescing Markus Schneider-Pargmann
2023-03-24 18:32 ` [PATCH v3 00/16] can: m_can: Optimizations for m_can/tcan part 2 Marc Kleine-Budde
2023-04-12  8:33   ` Markus Schneider-Pargmann

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=ZBSPfmWEvl1eSWBV@corigine.com \
    --to=simon.horman@corigine.com \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=mkl@pengutronix.de \
    --cc=msp@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=rcsekar@samsung.com \
    --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;
as well as URLs for NNTP newsgroup(s).