RE: [PATCH 0/9] XSHM: Shared Memory Driver for ST-E Thor M7400 LTEmodem

[Sjur BRENDELAND]

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
¢éì®&Þ~º&¶¬–+-±éÝ¥Šw®žË±Êâmébžìdz¹Þ)í…æèw*jg¬±¨¶‰šŽŠÝj/êäz¹ÞŠà2ŠÞ¨è­Ú&¢)ß«a¶Úþø®G«éh®æj:+v‰¨Šwè†Ù>Wš±êÞiÛaxPjØm¶ŸÿÃ-»+ƒùdš_