Re: ethtool: ring configuration for CAN devices

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

 



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


[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