All of lore.kernel.org
 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 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.