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 :-)
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?
> 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?
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.?
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.
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
