netdev - Re: cellular modem driver APIs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 14 Apr 2019 13:09:27 -0600
From:   Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Dan Williams <dcbw@...hat.com>,
        Bjørn Mork <bjorn@...k.no>,
        netdev@...r.kernel.org, Sean Tranchetti <stranche@...eaurora.org>,
        Daniele Palmas <dnlplm@...il.com>,
        Aleksander Morgado <aleksander@...ksander.es>,
        netdev-owner@...r.kernel.org
Subject: Re: cellular modem driver APIs

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