lkml.org 
[lkml]   [2011]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH 0/9] XSHM: Shared Memory Driver for ST-E Thor M7400 LTE modem
Hi Arnd,

>> 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.
>
> Is the rpmsg support something that can be done with the current low-level
> protocol? It would be really nice if you could at least share some code
> for the general infrastructure, even if both the underlying transport
> and the high-level protocols are different.

I have already been challenged in this area by Linux Walleij :-),
but I'm afraid I don't see how this could be done in a sensible way.

The modem doesn't understand the virtual-ring format, and implements
a different "protocol" - so the virtual-ring format cannot be used to
talk to the modem. And using virtqueue as a packet elevator between
Kernel internal modules doesn't seem like the right thing either.

If the virtqueue_ops structure hadn't been removed, we could have used
this as an abstraction. But this structure was killed off.

I might be missing something here, but currently I don't see how I
could reuse any of the virtio architecture for the current implementation.
However it is definitely something we want to look into for the future.

>> As mentioned above, the modem is in different run modes, stream device
>> is only used when modem runs in OS-less mode, during boot or crash-dump.
>> Except for boot and crash-dump the CAIF stack is used.
>> A similar approach is used for HSI, where we use a bare
>> HSI channel in OS-less mode, and CAIF over HSI otherwise.
>
> 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.

The M7400 modem implements other physical interfaces such as HSI and USB. We
have a daemon in user space controlling the run modes and "life-cycle" of the
modem (boot, shutdown, upgrade, etc) and we are trying to keep the interface
to the different physical interfaces aligned. So for both HSI and USB we're
using a stream interface (tty or char device) for the flash-less boot protocol.
Due to this I'd prefer to stick to a plain char/tty interface and not use netlink
or mmap interfaces.

The overall modem boot time is certainly important. But I don't have performance
figures of how much of the overall boot time is used for transferring the flash-
less boot image in front of me. So it's hard to make a judgment of exactly how
performance critical this is. With the current implementation there is *one* copy
from user-space to the shared memory area so it should be reasonably efficient.

Regards,
Sjur
\
 
 \ /
  Last update: 2011-12-12 10:07    [W:0.287 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site