From: "Bjørn Mork" <bjorn@mork.no>
To: Oliver Neukum <oneukum@suse.de>
Cc: alexey.orishko@stericsson.com, netdev@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: MBIM
Date: Fri, 07 Sep 2012 10:53:02 +0200 [thread overview]
Message-ID: <87392u1afl.fsf@nemi.mork.no> (raw)
In-Reply-To: <3121990.L41g6gGrVV@linux-lqwf.site> (Oliver Neukum's message of "Fri, 07 Sep 2012 09:40:59 +0200")
Oliver Neukum <oneukum@suse.de> writes:
> On Thursday 06 September 2012 10:17:46 Bjørn Mork wrote:
>> Not really related, but I am still worrying how MBIM is going to fit
>> into the usbnet model where you have a strict relation between one
>> netdev and one USB interface. Do you see any way usbnet could be
>> extended to manage a list of netdevs?
>>
>> All the netdev related functions doing
>>
>> struct usbnet *dev = netdev_priv(net);
>>
>> would still work. But all the USB related functions using dev->net to
>> get the netdev would fail. Maybe this will be too difficult to
>> implement within the usbnet framework at all?
>
> It depends on how much support we get from upper layers.
> You can give two IPs to an ethernet card as well.
Yes, of course. But I don't think that fits the MBIM model, where
multiple independent connections (Internet, VoIP, MMS, VPN1, VPN2, etc)
to different APNs will be multiplexed over the same USB endpoints. And
to make this not fly at all: Some of these may be IPv4, some IPv6 and
some dual stack. You cannot support that on a single netdev. Mixing
them all together on the host will not do. When the driver sees an IPv6
multicast packet (RS, ND, whatever) on the netdev, which MBIM session
should it forward that packet too?
If I understand MBIM correctly, we will see device configurations with
_one_ CDC data interface carrying all data traffic for multiple device
functions. A MBIM driver must de-multiplex this, and each IP function
should be routed to its own netdev IMHO.
> It would be best if you could come up with some preliminary code
> at least.
Yup. Finally got a device. Will start playing.
Bjørn
next prev parent reply other threads:[~2012-09-07 8:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-05 20:12 changing usbnet's API to better deal with cdc-ncm Oliver Neukum
[not found] ` <2791550.LhGu6po6Xy-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
2012-09-06 3:23 ` Ming Lei
[not found] ` <CACVXFVMXz1mqANBYR56KZsh3RgN5M_og_OggDEHT02w0Pe-UiA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-06 8:30 ` Bjørn Mork
[not found] ` <87a9x33656.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2012-09-06 16:09 ` Ming Lei
2012-09-06 17:56 ` Oliver Neukum
[not found] ` <1676538.CEPj2RtrPe-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
2012-09-07 3:55 ` Ming Lei
2012-09-07 7:35 ` Oliver Neukum
[not found] ` <1446113.XC2Qbo4flT-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
2012-09-07 12:01 ` Alexey ORISHKO
[not found] ` <2AC7D4AD8BA1C640B4C60C61C8E520154A6AA5741E-8ZTw5gFVCTjVH5byLeRTJxkTb7+GphCuwzqs5ZKRSiY@public.gmane.org>
2012-09-07 13:08 ` Oliver Neukum
2012-09-07 15:23 ` Alexey ORISHKO
[not found] ` <2AC7D4AD8BA1C640B4C60C61C8E520154A6AA5753D-8ZTw5gFVCTjVH5byLeRTJxkTb7+GphCuwzqs5ZKRSiY@public.gmane.org>
2012-09-07 18:23 ` Oliver Neukum
[not found] ` <1609320.M17H7UceTZ-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
2012-09-10 17:10 ` Alexey ORISHKO
2012-09-06 8:13 ` Alexey ORISHKO
2012-09-06 8:50 ` Oliver Neukum
[not found] ` <6556435.5o3fR8ZcBa-ugxBuEnWX9yG/4A2pS7c2Q@public.gmane.org>
2012-09-06 9:11 ` Eric Dumazet
2012-09-06 9:22 ` Eric Dumazet
2012-09-07 12:58 ` Ming Lei
2012-09-07 13:10 ` Alexey ORISHKO
2012-09-06 8:17 ` Bjørn Mork
[not found] ` <87ehmf36qd.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2012-09-07 7:40 ` MBIM (was: Re: changing usbnet's API to better deal with cdc-ncm) Oliver Neukum
2012-09-07 8:53 ` Bjørn Mork [this message]
[not found] ` <87392u1afl.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2012-09-07 17:02 ` MBIM Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87392u1afl.fsf@nemi.mork.no \
--to=bjorn@mork.no \
--cc=alexey.orishko@stericsson.com \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).