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
