WDS Bind Mux Port?

[Daniele Palmas]

2017-01-11 21:21 GMT+01:00 Bjørn Mork <bjorn at mork.no>:
> 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.
>

Thanks!! I'll try to take a look at this and, if possible, do some tests!

Daniele

>
>
> Bjørn
>