On 25.10.2021 11:00:08, Kurt Van Dijck wrote: > 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@xxxxxxxxxx > > > > 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. That's the way systemd has chosen to put these values.... > 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. ACK - the .link and .network files are per network interface, so that should be no problem to have different settings for different CAN interfaces. > 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. ACK - the driver provides default settings for CAN-2.0 and CAN-FD mode and I want to overwrite both default settings via ethtool ring settings. So that these overwritten settings are used when switching from CAN to CAN-FD mode an back. 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:
signature.asc
Description: PGP signature
