Date:   Thu, 04 Apr 2019 22:45:31 -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>
Subject: Re: cellular modem driver APIs

On 2019-04-04 14:38, Johannes Berg wrote:
> Hi,
> 
>> The normal mode of operation of rmnet is using the rmnet netdevices
>> in an embedded device.
> 
> Sure. Can you say what driver this would typically live on top of? I'm
> actually a bit surprised to find out this isn't really a driver :-)
> 

This needs a physical net device such as IP accelerator
https://lkml.org/lkml/2018/11/7/233 or Modem host interface
https://lkml.org/lkml/2018/4/26/1159

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)

> In my view right now, I'd recommend splitting rmnet into two pieces:
> 
>  1) The netlink API, be it called "rmnet" or something else, probably
>     I'd call it something else like "wwan-mux" or so and leave "rmnet"
>     as an alias.
>     This part is certainly going to be generic. I'm not sure where
>     exactly to draw the line here, but I'd rather start out drawing it
>     more over to the API side (i.e. keep it just the API) instead of
>     including some of the RX handlers etc.
> 
>  2) The actual layering protocol implementation, with things like
>     rmnet_map_ingress_handler() and rmnet_map_add_map_header(),
>     basically all the stuff handling MAP headers.
>     This is clearly device specific, but I wonder what device.
> 
>> The bridge mode is used only for testing by sending frames
>> without de-muxing to some other driver such as a USB netdev so packets
>> can be parsed on a tethered PC.
> 
> Yeah, I get it, it's just done in a strange way. You'd think adding a
> tcpdump or some small application that just resends the packets 
> directly
> received from the underlying "real_dev" using a ptype_all socket would
> be sufficient? Though perhaps not quite the same performance, but then
> you could easily not use an application but a dev_add_pack() thing? Or
> probably even tc's mirred?
> 
> And to extend that thought, tc's ife action would let you encapsulate
> the things you have in ethernet headers... I think.

We need raw IP frames from a embedded device transmitted to a PC
and vice versa.

>> I was planning to refactor qmi_wwan to reuse rmnet as much as 
>> possible.
>> Unfortunately, I wasn't able to get qmi_wwan / modem manager
>> configured and never got to this.
> 
> OK.
> 
>> Having a single channel is not common
> 
> Depends what kind of system you're looking at, but I hear you :)
> 
>> so rmnet doesn't support a default
>> channel mode. Most of the uses cases we have require multiple PDNs so
>> this translates to multiple rmnet devices.
> 
> Right, sure. I just wonder then what happens with the underlying 
> netdev.
> Is that just dead?
> 
> In fact, is the underlying netdev even usable without having rmnet on
> top? If not, why is it even a netdev?
> 

Yes, the underlying netdev itself cannot do much on its own as network
stack wont be able to decipher the muxed frames.

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.

> Like I said, I'm thinking that the whole wiphy/vif abstraction makes a
> bit more sense here too, like in wifi, although it requires all new
> userspace or at least not using IFLA_LINK but something else ...
> 
> Then again, I suppose we could have an IFLA_WWAN_DEVICE and have that 
> be
> something else, just like I suppose we could create a wifi virtual
> device by having IFLA_WIPHY and using rtnl_link_ops, just didn't do it.
> 
> Would or wouldn't that make more sense?
> 
> We can still create a default channel netdev on top ...
> 
> 
> 
> My gut feeling is that it would in fact make more sense.
> 
> 
> 
> So, straw man proposal:
> 
>  * create net/wwan/ with some API like
>     - register_wwan_device()/unregister_wwan_device()
>     - struct wwan_device_ops {
>           int (*wdo_add_channel)(struct wwan_device *dev,
>                                  struct wwan_channel_cfg *cfg);
>           int (*wdo_rm_channel)(...);
>           /* ... */
>       }
>  * implement there a rtnl_link_ops that can create new links but needs
>    the wwan device (IFLA_WWAN) instead of underlying netdev (IFLA_LINK)
>  * strip the rtnl_link_ops from rmnet and use that infra instead
> 
> 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.

> So the alternative would be to still have the underlying wwan device
> represent itself as a netdev. But is that the right thing to do when
> that never really transports data frames in the real use cases?
> 
> For wifi we actually had this ('master' netdev), but we decided to get
> rid of it, the abstraction just didn't make sense, and the frames 
> moving
> through those queues etc. also didn't really make sense. But the
> downside is building more APIs here, and for some parts also custom
> userspace.
> 
> Then again, we could also have a 'monitor wwan' device type, right? You
> say you don't add a specific channel, but a sniffer, and then you can
> use tcpdump etc. on the sniffer netdev. Same in wireless, really.
> 

Can you tell how this sniffer netdev works? If rmnet needed to create a
separate netdev for monitoring the muxed raw IP frames, wouldnt that
just serve the same purpose as that of underlying netdev.

> 
> So anyway. Can you say what rmnet is used on top of, and what use the
> underlying netdev is when you say it's not really of much use since you
> need multiple channels?
> 
> johannes

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

Powered by blists - more mailing lists