WDS Bind Mux Port?

[Bjørn Mork]

Bjørn Mork <bjorn at mork.no> writes:
> Aleksander Morgado <aleksander at aleksander.es> writes:
>
>> If this is indeed something to support, why don't we set it up as well
>> with qmi_wwan/libqmi?
>
> My thought as well. Adding multiplexing support to the qmi_wwan data
> plane does not seem very difficult. Codewise. The main issues are the
> usual policy questions:
>
> 1) We can only add the necessary knobs to adjust the data plane
>
>   We cannot automatically turn then beased on control plane messages,
>   since the qmi_wwan driver is completely control protocol agnotistic.
>   Some userspace tool (i.e libqmi) will have to coordinate the control
>   and data plane, similar to how we do it for raw IP for example: You
>   need both a WDA Set Data Format message and writing to the sysfs file.
>
>
> 2) We need to figure out a sane user interface
>
>   I haven't exactly received much applause for the creative use of VLAN
>   tagging in cdc_mbim ;)  So I'm not sure that is worth copying.  The
>   only reason would be to keep the UI of two multiplexing drivers
>   similar.  But IIUC, QMI multiplexing is tied to raw-ip.  Which with
>   our current implementation excludes VLAN tags as an option.
>
>   So the table is open:  How do you want additional multiplexed qmi_wwan
>   data interfaces implemented? Driver specific netlink messages to add
>   and remove links?  Or extending the raw-ip sysfs interface (dunno if I
>   can sell that in)?
>
>   I assume that we want to keep a single /dev/cdc-wdmX and have proper
>   slave netdevs for every multiplexed channel, in any case.  But what do
>   we do about the original netdev?  Keep it as master only, or should we
>   accept traffic for some default multiplex channel on it?  The cdc_mbim
>   driver is an example I would want to avoid here...  But that's
>   basically because MBIM has multiplexing by default, and most (all)
>   users ignore it.  As long as QMI multiplexing is something that needs
>   to be explicitly enabled, I think we can safely force the users to
>   create a new link even for the first channel.
>
>
> Don't know how much time I will have for this, but I must admit that I
> am curious about this feature.  So I might spend time I don't have :)

So I ended up trying to hack a proof-of-conecpt together in a hurry.
But as usual I did not consider how much time I need to figure out how
this kernel thing works.

I have to accept that I won't have time to work on this.  The attached
patch is my current draft, provided as input for further discussion and
thought.  Nothing else.  Certainly not for use. It DOES NOT WORK. If you
run this as-is, then expect to do a hard power-off type reboot to get
your system up and running again.  I'm not joking.



Bjørn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-qmi_wwan-WiP-add-muxing-support.patch
Type: text/x-diff
Size: 7940 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20170111/2680c358/attachment.patch>