Improving TX for m_can peripherals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Good morning candevs,

I've been testing the TCAN4550 recently with proper kit (no more jumper
wires, hooray!) and I'm happy to say the RX path is fixed in v5.12 with
the latest patches, and even with heavy load I see no missed frames or
errors.

However, TX still needs work. It's easy to break the driver due to the
following logic in m_can_start_xmit():

| 	if (cdev->tx_skb) {
| 		netdev_err(dev, "hard_xmit called while tx busy\n");
| 		return NETDEV_TX_BUSY;
| 	}

Regardless of your netif TX queue length or the number of TX buffers
allocated in the M_CAN core, if you try to transmit too quickly, you
will hit this. For the application I'm working on, I run into this very
quickly with real-world scenarios.

Also, the queue is always stopped before the tx work is queued in
m_can_start_xmit(), which seems wrong and clearly doesn't solve the
problem:

| 	/* Need to stop the queue to avoid numerous requests
| 	 * from being sent.  Suggested improvement is to create
| 	 * a queueing mechanism that will queue the skbs and
| 	 * process them in order.
| 	 */
| 	cdev->tx_skb = skb;
| 	netif_stop_queue(cdev->net);
| 	queue_work(cdev->tx_wq, &cdev->tx_work);


So - I'd like to fix this. The comment in the snippet above suggests a
queueing mechanism. It would be good to hear your take on this, Marc -
AFAIU you have written a similar mechanism for mcp251xfd. :)

--
Regards,

Torin Cooper-Bennun
Software Engineer | maxiluxsystems.com




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux