From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DC02C10F13 for ; Sun, 14 Apr 2019 19:09:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E2C6206B7 for ; Sun, 14 Apr 2019 19:09:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="J8D8XRCB"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="kaUkuNTx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726475AbfDNTJ3 (ORCPT ); Sun, 14 Apr 2019 15:09:29 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:39182 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726126AbfDNTJ3 (ORCPT ); Sun, 14 Apr 2019 15:09:29 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 3135C613A7; Sun, 14 Apr 2019 19:09:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1555268968; bh=CZs1mSDGJF9zX2A14Me9dtB2Mz/Up3xysT9rIFG1Fj8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=J8D8XRCBfxDgRj6y2C5LhHfPpUx4rWM4BfJzd5HFfdxGQafrzohWynobn1ZVPJYSm aTjOUn8JT3hNEHqYhimkZF//3lmLs5xlYg7A8xILhQ0fMvxNWDiKVP55WLiRygye9R xXW+zJRu3P03FrD8++CYdoEnqWQo3Kw7gf/p+0YU= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 5B872613A7; Sun, 14 Apr 2019 19:09:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1555268967; bh=CZs1mSDGJF9zX2A14Me9dtB2Mz/Up3xysT9rIFG1Fj8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kaUkuNTx3k2xfX9ixam8b/Z+5lqIm/na82vkXNl/Z8MSOB4I4MVrQiLXbTk9FQuNi etxRPJ9Ff+sUBObvoF4l0oTrk6d9t8iiayeZmMBPNs/9nOFxGV6D04YkSG/1BLjod9 dK1wgtTwFPNLtVIWbEN3Jp0wfaHxIIpycfPYAK5s= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 14 Apr 2019 13:09:27 -0600 From: Subash Abhinov Kasiviswanathan To: Johannes Berg Cc: Dan Williams , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , netdev@vger.kernel.org, Sean Tranchetti , Daniele Palmas , Aleksander Morgado , netdev-owner@vger.kernel.org Subject: Re: cellular modem driver APIs In-Reply-To: <7980f3d8a567a16f94e03b4c90f14362fc901560.camel@sipsolutions.net> References: <3f22629aa165d69655ea4623dfa3c97d07f3e621.camel@sipsolutions.net> <87h8bem9vg.fsf@miraculix.mork.no> <159ca474b4f1f4f923452854b3e979bffaa7cb2a.camel@redhat.com> <8c4f4e90901e136a96501df30bbe455e@codeaurora.org> <8ee094c9cefa257af61b564b45c5d15b@codeaurora.org> <75f9f963c1d07f5739ce76fcfc832e7e83586bda.camel@sipsolutions.net> <7980f3d8a567a16f94e03b4c90f14362fc901560.camel@sipsolutions.net> Message-ID: X-Sender: subashab@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.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