All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: linux-can <linux-can@vger.kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev@vger.kernel.org
Subject: ethtool: ring configuration for CAN devices
Date: Sun, 24 Oct 2021 23:37:59 +0200	[thread overview]
Message-ID: <20211024213759.hwhlb4e3repkvo6y@pengutronix.de> (raw)

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

Hello,

I'm currently working on runtime configurable RX/TX ring sizes for a the
mcp251xfd CAN driver.

Unlike modern Ethernet cards with DMA support, most CAN IP cores come
with a fixed size on chip RAM that's used to store received CAN frames
and frames that should be sent.

For CAN-2.0 only devices that can be directly supported via ethtools's
set/get_ringparam. A minor unaesthetic is, as the on chip RAM is usually
shared between RX and TX, the maximum values for RX and TX cannot be set
at the same time.

The mcp251xfd chip I'm enhancing supports CAN-2.0 and CAN-FD mode. The
relevant difference of these modes is the size of the CAN frame. 8 vs 64
bytes of payload + 12 bytes of header. This means we have different
maximum values for both RX and TX for those modes.

How do we want to deal with the configuration of the two different
modes? As the current set/get_ringparam interface can configure the
mini- and jumbo frames for RX, but has only a single TX value.

Hao Chen and Guangbin Huang are laying the groundwork to extend the
ringparam interface via netlink:

| https://lore.kernel.org/all/20211014113943.16231-1-huangguangbin2@huawei.com

I was thinking about adding rx/tx_pending for CAN-FD. The use case would
be to configure the ring parameters independent of the current active
CAN mode. For example in systemd the RX/TX ring parameters are
configured in the .link file, while the CAN FD mode is configured in a
.network file. When switching to the other CAN mode, the previously
configured ring configuration of that CAN mode will be applied to the
hardware.

In my proof of concept implementation I'm misusing the struct
ethtool_ringparam's mini and jumbo values to pre-configure the CAN-2.0
and CAN-FD mode's RX ring size, but this is not mainlinable from my
point of view.

I'm interested in your opinion and use cases.

regards,
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-10-24 21:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-24 21:37 Marc Kleine-Budde [this message]
2021-10-25  9:00 ` ethtool: ring configuration for CAN devices Kurt Van Dijck
2021-10-25  9:21   ` Marc Kleine-Budde
2021-10-25 12:27 ` Andrew Lunn
2021-10-25 12:43   ` Marc Kleine-Budde
2021-10-25 12:58     ` Andrew Lunn
2021-10-25 13:14       ` Marc Kleine-Budde
2021-10-25 18:43       ` Jakub Kicinski

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=20211024213759.hwhlb4e3repkvo6y@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=linux-can@vger.kernel.org \
    --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 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.