Re: cellular modem driver APIs

[Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>]

>> 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