netdev - Re: ethtool: ring configuration for CAN devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Oct 2021 11:00:08 +0200
From:   Kurt Van Dijck <dev.kurt@...dijck-laurijssen.be>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
Cc:     linux-can <linux-can@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: ethtool: ring configuration for CAN devices

On Sun, 24 Oct 2021 23:37:59 +0200, Marc Kleine-Budde wrote:
> 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.

Isn't the simplest setup to stick to the current CAN mode (2.0 vs. FD).

Certain values/combinations may be valid in 2.0 and not in FD. So what?
This is true also for data-bittiming and what not.

I see no advantage in putting your configuration in different files
(.link and .network), since they influence each other.
I can imaging one network operating in FD, with certain rx/tx settings,
and another network operating in 2.0, with different rx/tx settings.
and a 3rd network operating in FD, with also different rx/tx settings.

If that is a problem for systemd, then ... fix systemd?
(systemd is really out of my scope, I'm not used to it)

IMHO, you try to provide different default settings (rx/tx split) for FD
and 2.0 mode.

> 
> 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 |