Message-ID: <81C3A93C17462B4BBD7E272753C105792060B42C9C@EXDCVYMBSTM005.EQ1STM.local>
Date:	Thu, 22 Mar 2012 15:31:39 +0100
From:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"sjurbren@...il.com" <sjurbren@...il.com>
Subject: RE: [PATCH 0/9] XSHM: Shared Memory Driver for ST-E Thor M7400 LTE
 modem

Hi Arnd,

I've got some updates since my last reply from December...

[Arnd]
>>> Also, to what degree is the protocol design flexible? Is the modem
>>> side fixed, so you have to live with any shortcomings of the interface,
>>> or are you at this point able to improve both sides when something
>>> is found to be lacking?

I have started working on the next generation shared memory interface for
ST-Ericsson modems. So the interface design is now flexible! This means that
I can be open to input and new ideas, at least for the next month or two.
I'm hoping (if time allows) to prototype and post some patches while working
on the specification.

The primary goal for the new interface design, besides getting it accepted
in the mainline kernel, is to implement zero-copy for IP traffic on the modem
side. Zero-copy on host side would be the next step.

[Sjur]
>> However for the long term perspective: we expect this interface to evolve
>> for future products, so suggestions and input for improvements is welcome.
>> rpmsg or at least the use of virtio-ring combined with a true end-to-end
>> zero copy is something we definitely are interested to look into for the
>> future.

My current idea for the new interface design is to use Virtio channels for
transporting CAIF frames. The CAIF interface could be implemented as a
virtio-driver using separate RX and TX rings.

For uplink traffic (TX) we could (initially) copy SKB into a buffer located in
the shared-memory area, and add the buffer to the Virtio-ring. We will need
to manage a fixed size buffer pool of uplink data buffers. (I don't think we
will be able to access the kernel memory from the modem, so I cannot put SKB
content directly on the virtio-ring as virtio-net does)

For Downlink payload (RX) I'm planning on using a reversed virtio-ring.
The modem has its own sophisticated memory allocator for payload and
implements mechanisms for efficient buffer handling inside the modem.
The modem could add the payload buffer on the virtual-ring without
copying and kick the host.

[Sjur:]
>>>> The driver for the stream channel is implemented as a character device
...
[Arnd:]
> My feeling is that a character device is not the ideal implementation here,
> but I'm not sure what is. One option I can see is to declare the stream
> interface part of the configuration logic and do everything through netlink,
> packetizing the stream data in netlink frames. Alternatively, a tty port
> device might be more appropriate than a plain chardev. Both of these
> are likely a bit slower than what you have today, but my impression is that
> performance is not the main design goal for the stream interface. If it is,
> the best option would probably be to allow user space to mmap the buffer and
> do the implementation in an application outside of the kernel.

For the stream interface it's tempting to reuse the ring buffer interface
to the modem from last time. But perhaps the Virtio-console could be as the
user-space interface, with a slim virtual device underneath feeding data
from the ring-buffer into a virtual-ring...?

Regards,
Sjur

Powered by blists - more mailing lists