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 74F08C10F13 for ; Thu, 11 Apr 2019 03:55:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 31305217F4 for ; Thu, 11 Apr 2019 03:55:00 +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="eQ02ZMvh"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="EmOHUzr4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbfDKDy6 (ORCPT ); Wed, 10 Apr 2019 23:54:58 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:42648 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbfDKDy6 (ORCPT ); Wed, 10 Apr 2019 23:54:58 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 69B00601D7; Thu, 11 Apr 2019 03:54:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1554954897; bh=F6+xhhC8F8R69xlaFa/ia9qKFwZ/wx57bE9I+vzusvY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eQ02ZMvhW/VobWY5EdnqRn5/zKIHR+2cXkN+CqGygZF51rlVufl7yPPt3KEKJV1U+ ZADI9+4g7YpjfzupMeP8MGq1xWcHGoSR+ehTpsYOUq63eqjRyduQpO4gWTl6j48HrT jFO0Fud2DRXvbcAlPpWsCpgKGlJpk3M5Zm9RvvOk= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 5CAE9601D7; Thu, 11 Apr 2019 03:54:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1554954896; bh=F6+xhhC8F8R69xlaFa/ia9qKFwZ/wx57bE9I+vzusvY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EmOHUzr4PAQVtA6WZuy17KCtKVX+HG938AOl2Xdxf+g9Mc6oh6mfR68CkJzwPDlfS IIw6WMkKOK0uyZzltoGwA+9n+BkUWOa9Iv8v+gT9WItmvUa34IsXdPSWgOQ5MzPndg W1zXCzjbWt9BXw3eMOaOmb8MMlElthMWX1iqeGss= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Apr 2019 21:54:56 -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: <75f9f963c1d07f5739ce76fcfc832e7e83586bda.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> 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 > OK. But it means that you have a very specific encapsulation mode on > top > of the "netdev". I'm still not convinced we should actually make that a > netdev, but I'll elaborate elsewhere. > >> I recall Daniele also managed to get rmnet working with qmi_wwan >> (with an additional patch in which I had made qmi_wwan a passthrough) > > I guess that uses the same encapsulation then, yes, I see it now: > qmi_wwan's struct qmimux_hdr and rmnet's struct rmnet_map_header are > very similar. > > Btw, I see that struct rmnet_map_header uses a bitfield - this seems to > go down to the device so probably will not work right on both big and > little endian. > Yes, I have tested so far in big endian only. I need to add support for little endian. >> We need raw IP frames from a embedded device transmitted to a PC >> and vice versa. > > Sure. But you just need to encap them in some kind of ethernet frame to > transport them on the wire, but don't really need to care much about > how. > These packets will be processed as raw IP muxed frames on the PC as well, not as ethernet though. >> Yes, the underlying netdev itself cannot do much on its own as network >> stack wont be able to decipher the muxed frames. > > Right. > >> The operation of rmnet was to be agnostic of the underlying driver. >> The netdev model was chosen for it since it was easy to have a >> rx_handler attach to the netdevice exposed by any of those drivers. > > I really do think it's the wrong model though: > > 1. The network stack cannot do anything with the muxed data, and so > there's no value from that perspective in exposing it that way. > 2. The rx_handler attach thing is a bit of a red herring - if you > have > some other abstraction that the driver registers with, you can > just > say "send packets here" and then demux things properly, without > having a netdev. Actually, I'd almost argue that rmnet should've > just > been a sort of encap/decap library that the drivers like > qmi_wwan, > rmnet_ipa and mhi use to talk to the device. 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 > 3. Having this underlying netdev is actually very limiting. We found > this with wifi a long time ago, and I suspect with 5G coming up > you'll be in a similar situation. You'll want to do things like > multi-queue, different hardware queues for different channels, > etc. > and muxing it all over a single netdev (and a single queue there) > becomes an easily avoidable point of contention. > 4. (I thought about something else but it escapes me now) > >> > Now, OTOH, this loses a bunch of benefits. We may want to be able to >> > use >> > ethtool to flash a modem, start tcpdump on the underlying netdev >> > directly to see everything, etc.? >> > >> >> Yes, we use that underlying netdev to view the muxed raw IP frames in >> tcpdump. > > That's the easiest of all - just make the framework able to add a > 'sniffer' netdev that can see all the TX/RX for the other channels. > One additional use of underlying netdev is for RPS. This helps to separate out the processing of the underlying netdev and rmnet. If rmnet were to be converted into a library, we would still need this functionality. Having said this, looking forward to trying out your patches :) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project