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
Yeah, this is the big question.
If there's no underlying netdev at all, then no, it wouldn't work.
Though, it could be "faked" in a sense, by doing two things:
a) having the driver/infra always create a default channel interface,
say mux_id 0?
b) by treating
ip link add link rmnet_ipa0 name rmnet0 type rmnet mux_id 1
as not creating a new netdev *on top of* but rather *as sibling to*
"rmnet0".
The alternative is to just keep rmnet and the underlying driver, but
tie
them together a little more closely so that they can - together -
register with a hypothetical new WWAN framework.
See - even if we create such a framework in a way that it doesn't
require an underlying netdev (which I think is the better choice for
various reasons, particularly related to 5G), then there's nothing that
says that you *cannot* have it anyway and keep the exact same rmnet +
underlying driver model.
Hmm, not sure I understand this. If you do RPS/RSS then that's a
hardware function, and the netdev doesn't really come into play
immediately? If the underlying driver directly deals with multiple
netdevs that's actually an *advantage*, no?
RPS is in SW only though.
I think this shouldn't be a concern if the existing underlying netdev
model
could co-exist with the new framework.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
