linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Dario Binacchi <dariobin@libero.it>
Cc: linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Gianluca Falavigna <gianluca.falavigna@inwind.it>,
	Jakub Kicinski <kuba@kernel.org>,
	Oliver Hartkopp <socketcan@hartkopp.net>,
	Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
	Wolfgang Grandegger <wg@grandegger.com>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] can: c_can: cache frames to operate as a true FIFO
Date: Mon, 10 May 2021 14:25:12 +0200	[thread overview]
Message-ID: <20210510122512.5lcvvvwzk6ujamzb@pengutronix.de> (raw)
In-Reply-To: <20210509124309.30024-4-dariobin@libero.it>

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On 09.05.2021 14:43:09, Dario Binacchi wrote:
> As reported by a comment in the c_can_start_xmit() this was not a FIFO.
> C/D_CAN controller sends out the buffers prioritized so that the lowest
> buffer number wins.
> 
> What did c_can_start_xmit() do if it found tx_active = 0x80000000 ? It
> waited until the only frame of the FIFO was actually transmitted by the
> controller. Only one message in the FIFO but we had to wait for it to
> empty completely to ensure that the messages were transmitted in the
> order in which they were loaded.
> 
> By storing the frames in the FIFO without requiring its transmission, we
> will be able to use the full size of the FIFO even in cases such as the
> one described above. The transmission interrupt will trigger their
> transmission only when all the messages previously loaded but stored in
> less priority positions of the buffers have been transmitted.

The algorithm you implemented looks a bit too complicated to me. Let me
sketch the algorithm that's implemented by several other drivers.

- have a power of two number of TX objects
- add a number of objects to struct priv (tx_num)
  (or make it a define, if the number of tx objects is compile time fixed)
- add two "unsigned int" variables to your struct priv,
  one "tx_head", one "tx_tail"
- the hard_start_xmit() writes to priv->tx_head & (priv->tx_num - 1)
- increment tx_head
- stop the tx_queue if there is no space or if the object with the
  lowest prio has been written
- in TX complete IRQ, handle priv->tx_tail object
- increment tx_tail
- wake queue if there is space but don't wake if we wait for the lowest
  prio object to be TX completed.

Special care needs to be taken to implement that lock-less and race
free. I suggest to look the the mcp251xfd driver.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-05-10 13:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-09 12:43 [PATCH 0/3] can: c_can: cache frames to operate as a true FIFO Dario Binacchi
2021-05-09 12:43 ` [PATCH 1/3] can: c_can: remove the rxmasked unused variable Dario Binacchi
2021-05-10 13:29   ` Marc Kleine-Budde
2021-05-09 12:43 ` [PATCH 2/3] can: c_can: add ethtool support Dario Binacchi
2021-05-10 13:28   ` Marc Kleine-Budde
2021-05-09 12:43 ` [PATCH 3/3] can: c_can: cache frames to operate as a true FIFO Dario Binacchi
2021-05-10 12:25   ` Marc Kleine-Budde [this message]
2021-05-10 12:36     ` Marc Kleine-Budde
2021-05-13 11:23       ` Dario Binacchi
2021-06-06 20:17 [PATCH 0/3] " Dario Binacchi
2021-06-06 20:17 ` [PATCH 3/3] " Dario Binacchi

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=20210510122512.5lcvvvwzk6ujamzb@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=dariobin@libero.it \
    --cc=davem@davemloft.net \
    --cc=gianluca.falavigna@inwind.it \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=netdev@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).