From: Vincent Whitchurch <vincent.whitchurch@xxxxxxxx> Sent: Tuesday, January 22, 2019 7:20 AM To: Arnd Bergmann Cc: Liming Sun; Olof Johansson; David Woods; Robin Murphy; arm-soc; DTML; Linux ARM; linux-pci; linux-ntb@xxxxxxxxxxxxxxxx; Christoph Hellwig; virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx Subject: Re: [PATCH v6 5/9] soc: mellanox: host: Add the common host side Rshim driver On Fri, Jan 18, 2019 at 05:02:21PM +0100, Arnd Bergmann wrote: >> On Thu, Nov 1, 2018 at 5:49 PM Liming Sun <lsun@xxxxxxxxxxxx> wrote: >> > >> > An external host can connect to a Mellanox BlueField SoC via an >> > interface called Rshim. The Rshim driver provides boot, console, >> > and networking services over this interface. This commit is >> > the common driver where the other backend (transport) driver will >> > use. >> > >> > Reviewed-by: David Woods <dwoods@xxxxxxxxxxxx> >> > Signed-off-by: Liming Sun <lsun@xxxxxxxxxxxx> >> >> Hi Liming, >> >> I've taken a new look at your patch series for drivers/soc/ now, >> thanks for your continued submissions. >> >> This is again just a set of very high-level comments, but I think we >> should resolve some of the fundamental questions first. >> Incidentally, Vincent Whitchurch has recently posted another >> patch series with a very similar intention, but for other hardware >> and taking a different approach. >> >> In both cases, the idea is to use virtio based drivers to provide >> services from a host machine into another Linux instance running >> on an embedded system behind a PCIe slot or similar. Your >> Bluefield SoC patches are well written, but are intentionally >> kept specific to a particular use case and tied to one piece >> of hardware. In contrast, Vincent uses the existing code from >> drivers/misc/mic/vop/ that is equally hardware specific, but he >> extends it to be applicable to other hardware as well. >> >> It would be good if you could look at each other's approaches >> to see where we could take it from here. I think ideally we >> should have a common driver framework for doing the same >> thing across both of your devices and as well as others. > As far as I can see the biggest difference is that Rshim appears to > support interfaces which do not have shared memory between the host and > the card, which means that it has to jump through a lot more hoops to > make virtio work. > For example, the card side seems to use normal virtio-net and > virto-console drivers, but the drivers/soc/mellanox/tmfifo.c driver, > also running on the card, appears to have to actually look inside the > virtqueues and shuffle the data over the TmFifo interface, and this > driver has hard-coded support for only network and console, since it > apparently needs to know the details of how the virtio drivers use their > virtqueues (see tmfifo_virtio_rxtx()). > And the host side appears to _also_ run the virtio-net driver and there > the drivers/soc/mellanox/host/rshim_net.c code instead has to look > inside the virtqueues and shuffle the data over the other side of the > TmFifo interface. > So to me this looks very different from a traditional virtio > driver/device setup (which is what mic/vop uses). I may be missing > something, but I don't quite understand why it's even using virtio in > the first place. Thanks Vincent! This appears to be very good summary of this driver does on the tmfifo part and the difference between mic/vop. The fifo is accessed by register instead of shared memory. The reason to use virtio framework is that it can be easily used to add more virtual devices as needed without implementing driver details for each one. For example, the device side supports console and networking for now over the FIFO. It only needs to implement function tmfifo_virtio_rxtx() once to take care of the virtqueues Rx/Tx, which are shared by all virtual devices. With minimum changes, we could easily add another device over tmfifo, like a virtio block device, since the queue handling is already there. The host side handles the virtqueues as well in rshim_net.c. It behaves like a peer-to-peer to the device side while the tmfifo behaves like a 'wire' (transport) to pass data between the host and the device without worrying about the data details.
