DSS usage

[Dmytro Milinevskyy]

Hello,
I was browsing vlan implementation in kernel and figured out that the vlan interface inherits the link state of the real NIC.
So it won't be sufficient to just modify usbnet to keep submitting URBs if the main wwan interface is down.
In case of maintaining vlan-based solution the application must ensure that the wwan "logical" link never goes down.
That said it's better have an option to create a special character device for DSS on demand.
If there was no explicit request to forward DSS data to the dedicated queue than it can be still be directed to vlan interface.
With this solution you have a flexibility to chose whether you want to use DSS over vlan or over character device.

best regards,
~ Dmytro


----- Original Message -----
> On Thu, Apr 10, 2014 at 9:01 PM, Bjørn Mork <bjorn at mork.no> wrote:
> > Of these, the dependecy on wwan0 is by far the worst IMHO.  And I
> > would
> > have loved to just "fix" that in the driver.  But when Arnaud first
> > made
> > me think about this, I realized that it wasn't really me who added
> > that... It's really an inheritage of the multiplexing protocol.
> >  There
> > is no way you are going to transport those DSS fragments without
> > cooperating with all the other users of the two bulk endpoints on
> > the
> > MBIM data interface.  There just has to be some top level policy
> > manager
> > here "owning" both the MBIM data and control channels. wwan0
> > represents
> > the shared data channel, and /dev/cdc-wdm0 represents the shared
> > control
> > channel.  Both these resources must be managed by one application
> > to
> > facilitate resource sharing.
> 
> I'm personally not unhappy with the VLAN based API; it's just an API,
> and it's convenient. If we can facilitate its usage by hiding within
> libmbim all the VLAN/net interface bits to clients wanting to do DSS,
> then we should definitely do that.
> 
> I'm more worried about the dependency on wwan0 that you point out,
> though. Managing the lifecycle of the wwan interface in a single
> user-space is going to be interesting, although in the worst case we
> can focus on having it in e.g. the mbim-proxy, and have other
> programs
> (e.g. NM) ask the proxy whether there are open DSS channels before
> trying to put the interface down, or something like that. Well, at
> the
> end there's usually just a program in the system managing the
> lifecycle of the interface (the connection manager, like NM or
> ConnMan
> or whatever)... the difference would just be where it really is
> managed. For this case, it makes sense to have it in e.g. the
> mbim-proxy, which is going to be a single instance program always
> running whenever there is an MBIM communication. And the proxy should
> handle not only multiple MBIM interactions from different processes,
> but also multiple interactions with the net interface and its VLANs.
> Worst case, we can even handle the interface ifup/ifdown ourselves in
> the proxy (and ask connection managers not to play with that).
> 
> --
> Aleksander
> https://aleksander.es
> 


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.