[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <b59be15f1d0caa4eaa4476bbd8457afc44d57089.camel@sipsolutions.net>
Date: Mon, 27 May 2019 15:20:16 +0200
From: Johannes Berg <johannes@...solutions.net>
To: netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Cc: Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
Dan Williams <dcbw@...hat.com>,
Sean Tranchetti <stranche@...eaurora.org>,
Daniele Palmas <dnlplm@...il.com>,
Aleksander Morgado <aleksander@...ksander.es>,
Bjørn Mork <bjorn@...k.no>
Subject: cellular modem APIs - take 2
Hi all,
Sorry for the long delay in getting back to this. I'm meaning to write
some code soon also for this, to illustrate better, but I figured I'd
still get some thoughts out before I do that.
After more discussion (@Intel) and the previous thread(s), I've pretty
much come to the conclusion that we should have a small subsystem for
WWAN, rather than fudging everything like we previously did.
We can debate whether or not that should use 'real' netlink or generic
netlink - personally I know the latter better and I think it has some
real advantages like easier message parsing (it's automatic more or
less) including strict checking and automatic policy introspection (I
recently wrote the code for this and it's plugged into generic netlink
family, for other netlink families it needs more hand-written code). But
I could possibly be convinced of doing something else, and/or perhaps
building more infrastructure for 'real' netlink to realize those
benefits there as well.
In terms of what I APIs are needed, the kernel-driver side and userspace
side go pretty much hand in hand (the wwan subsystem just providing the
glue), so what I say below is pretty much both a method/function call
(kernel internal API) or a netlink message (userspace API).
1) I think a generic abstraction of WWAN device that is not a netdev
is needed. Yes, on the one hand it's quite nice to be able to work on
top of a given netdev, but it's also limiting because it requires the
data flow to go through there, and packets that are tagged in some
way be exchanged there.
For VLANs this can be out-of-band (in a sense) with hw-accel, but for
rmnet-style it's in-band, and that limits what we can do.
Now, of course this doesn't mean there shouldn't be a netdev created
by default in most cases, but it gives us a way to do additional
things that we cannot do with *just* a netdev.
From a driver POV though, it would register a new "wwan_device", and
then get some generic callback to create a netdev on top, maybe by
default from the subsystem or from the user.
2) Clearly, one needs to be able to create PDN netdevs, with the PDN
given to the command. Here's another advantage: If these are created
on top of another abstraction, not another netdev, they can have
their own queues, multiqueue RX etc. much more easily.
Also, things like the "if I have just a single channel, drop the mux
headers" can then be entirely done in the driver, and the default
netdev no longer has the possibility of muxed and IP frames on the
same datapath.
This also enables more things like handling checksum offload directly
in the driver, which doesn't behave so well with VLANs I think.
All of that will just be easier for 5G too, I believe, with
acceleration being handled per PDN, multi-queue working without
ndo_select_queue, etc.
Quite possibly there might be some additional (vendor-dependent?)
configuration for when such netdevs are created, but we need to
figure out if that really needs to be at creation time, or just
ethtool later or something like that. I guess it depends on how
generic it needs to be.
3) Separately, we need to have an ability to create "generalized control
channels". I'm thinking there would be a general command "create
control channel" with a given type (e.g. ATCMD, RPC, MBIM, GNSS) plus
a list of vendor-specific channels (e.g. for tracing).
I'm unsure where this channel should really go - somehow it seems to
me that for many (most?) of these registering them as a serial line
would be most appropriate, but some, especially vendor-defined
channels like tracing, would probably better use a transport that's
higher bandwidth than, e.g. netdevs.
One way I thought of doing this was to create an abstraction in the
wwan framework that lets the driver use SKBs anyway (i.e. TX and RX
on these channels using SKBs) and then translate them to some channel
in the framework - that way, we can even select at runtime if we want
a netdev (not really plugged into the network stack, ARPHDR_VOID?) or
some other kind of transport. Building that would allow us to add
transport types in the future too.
I guess such a channel should also be created by default, if it's
not already created by the driver in some out-of-band way anyway (and
most likely it shouldn't be, but I guess drivers might have some
entirely different communication channels for AT CMDs?)
4) There was a question about something like pure IP channels that
belong to another PDN and apparently now separate netdevs might be
used, but it seems to me that could just be a queue reserved on the
regular netdevs and then when you say ("enable video streaming on
wwan1 interface") that can do some magic to classify the video
packets (DSCP?) to another hardware queue for better QoS.
Anyway, if all of this doesn't seem completely outlandish I'll try to
write some code to illustrate it (sooner, rather than later).
Thanks,
johannes
Powered by blists - more mailing lists