DSS usage

Bjørn Mork bjorn at mork.no
Fri May 9 02:28:00 PDT 2014


Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:

> Hello Bjørn,
>
> ----- Original Message -----
>> Bjørn Mork <bjorn at mork.no> writes:
>> > Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:
>> >
>> >> Of course as the long term solution a DSS channel should be
>> >> visible as
>> >> a character device.
>> >
>> > A network device can easily be converted to a character device in
>> > userspace using a pty. socat is one userspace implementation.
>> >  There is
>> > nothing preventing the implementation of a similar proxying
>> > solution in
>> > software written for some specific DSS application.
>> >
>> > In any case, I see no reason to reimplement this proxying
>> > functionality
>> > as a kernel driver, having to add a driver specific API to manage
>> > the
>> > character devices.  The data manipulation would maybe be simpler,
>> > but
>> > the device management API most certainly would not.
>
> This approach still requires the network interface to be always "UP".

Yes, that does not change with this.

I do plan on adding the "IP Session 0 VLAN" to the API, which I believe
makes the restriction much easier to live with. The master must still
alwasy be up to allow any DSS or IP session, but you can then avoid
having any IP management application like dhclient or NM or whatever
touch the master netdev.  It can be dedicated to the MBIM management
application (like for example libmbim).

This also has the additional advantage of decoupling the MBIM
wMaxSegmentSize from the IP session 0 MTU, which I believe is necessary
also for some IP session use cases. As it is today, it's impossible to
configure a higher MTU on any IP session > 0 than the MTU on IP session
0.

And with the fix for unaccelerated VLAN tagging this again makes it
possible to send IP session 0 frames without an additional penalty.
Hmm, thinking of it now that might still be possible.  I'll rework the
proposed bugfix. So forget this last point.


> Will it be managed by libmbim?

That sounds like a reasonable way to do it, but it's really up to the
userspace implementation.  There will be more than one way to arrange
this, and I'm not sure there is one "correct" way which suits all.



Bjørn


More information about the libmbim-devel mailing list