Date:   Wed, 10 Apr 2019 21:54:56 -0600
From:   Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Dan Williams <dcbw@...hat.com>,
        Bjørn Mork <bjorn@...k.no>,
        netdev@...r.kernel.org, Sean Tranchetti <stranche@...eaurora.org>,
        Daniele Palmas <dnlplm@...il.com>,
        Aleksander Morgado <aleksander@...ksander.es>,
        netdev-owner@...r.kernel.org
Subject: Re: cellular modem driver APIs

> OK. But it means that you have a very specific encapsulation mode on 
> top
> of the "netdev". I'm still not convinced we should actually make that a
> netdev, but I'll elaborate elsewhere.
> 
>> I recall Daniele also managed to get rmnet working with qmi_wwan
>> (with an additional patch in which I had made qmi_wwan a passthrough)
> 
> I guess that uses the same encapsulation then, yes, I see it now:
> qmi_wwan's struct qmimux_hdr and rmnet's struct rmnet_map_header are
> very similar.
> 
> Btw, I see that struct rmnet_map_header uses a bitfield - this seems to
> go down to the device so probably will not work right on both big and
> little endian.
> 

Yes, I have tested so far in big endian only. I need to add support for
little endian.

>> We need raw IP frames from a embedded device transmitted to a PC
>> and vice versa.
> 
> Sure. But you just need to encap them in some kind of ethernet frame to
> transport them on the wire, but don't really need to care much about
> how.
> 

These packets will be processed as raw IP muxed frames on the PC as 
well,
not as ethernet though.

>> Yes, the underlying netdev itself cannot do much on its own as network
>> stack wont be able to decipher the muxed frames.
> 
> Right.
> 
>> The operation of rmnet was to be agnostic of the underlying driver.
>> The netdev model was chosen for it since it was easy to have a
>> rx_handler attach to the netdevice exposed by any of those drivers.
> 
> I really do think it's the wrong model though:
> 
>    1. The network stack cannot do anything with the muxed data, and so
>       there's no value from that perspective in exposing it that way.
>    2. The rx_handler attach thing is a bit of a red herring - if you 
> have
>       some other abstraction that the driver registers with, you can 
> just
>       say "send packets here" and then demux things properly, without
>       having a netdev. Actually, I'd almost argue that rmnet should've 
> just
>       been a sort of encap/decap library that the drivers like 
> qmi_wwan,
>       rmnet_ipa and mhi use to talk to the device.

Currently, iproute2 can be used to add the underlying dev as real_dev 
and
create rmnet links over it (ip link add link rmnet_ipa0 name rmnet0 type 
rmnet
mux_id 1). Would this continue to work if -
1. the rmnet library were to be included directly as part of the 
underlying
driver itself
2. there is no underlying dev at all

>    3. Having this underlying netdev is actually very limiting. We found
>       this with wifi a long time ago, and I suspect with 5G coming up
>       you'll be in a similar situation. You'll want to do things like
>       multi-queue, different hardware queues for different channels, 
> etc.
>       and muxing it all over a single netdev (and a single queue there)
>       becomes an easily avoidable point of contention.
>    4. (I thought about something else but it escapes me now)
> 
>> > Now, OTOH, this loses a bunch of benefits. We may want to be able to
>> > use
>> > ethtool to flash a modem, start tcpdump on the underlying netdev
>> > directly to see everything, etc.?
>> >
>> 
>> Yes, we use that underlying netdev to view the muxed raw IP frames in
>> tcpdump.
> 
> That's the easiest of all - just make the framework able to add a
> 'sniffer' netdev that can see all the TX/RX for the other channels.
> 

One additional use of underlying netdev is for RPS.
This helps to separate out the processing of the underlying netdev and
rmnet. If rmnet were to be converted into a library, we would still need
this functionality.

Having said this, looking forward to trying out your patches :)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists