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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH autolearn=unavailable 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 3A371C28CC6 for ; Tue, 4 Jun 2019 08:14:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0A81A24860 for ; Tue, 4 Jun 2019 08:14:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="szioQmzZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A81A24860 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wTvFB+AtfagCHqcAyu5DeE+127UKHorSHHSbQE5SuCA=; b=szioQmzZijgoTw 7rdTHeuL430+bR2r/cwPJr35eDfuJTog3ID3PhSUnUxSIHJmBq5lNamaxundYc5s+YBsqqrIEA9IB c67cyZG6csxndhKHcyHh8q6mY33WaIznKYiYOMEEL/biEsVgYHb/O030qwO6zSX2aIAeUtuZQ3Yg1 epguI917uKjgW4nrMYChG6pe+ZWiVwSEKX4WkIssDbwUIkktHzU6+CVVg49mQHNmv/yiopNQ5WLw6 ltXquZJcjuP1PccQpO3IVm+6yMadOoqd3xhuE5QcBP8cYmP4r7AfXeAg9fUZdssF0Cb1JBIePE2te EWdLLoWXCSfEFcmFet3A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hY4Zz-0008OE-At; Tue, 04 Jun 2019 08:13:59 +0000 Received: from mail-qt1-f194.google.com ([209.85.160.194]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hY4Zw-0008Ng-2Q for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2019 08:13:57 +0000 Received: by mail-qt1-f194.google.com with SMTP id a15so12697852qtn.7 for ; Tue, 04 Jun 2019 01:13:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OlXBKw7HgP4DZult/XowRKn8oIkzj5I8Bd8HMNjnVco=; b=OuLOhALF09UAG5NGyTW9QDY4iHcRG9O6Hy6fPLdq46NL2QNkSy/e/+AIuIB3+85hHb sdgryJ2rswKPlcsjfXcm8Abd6y04dqH0tC4QGf4sriBlnWcu2aQvTaH6J5j2S8I2DUjC uiXm6Y/0pZqArBQPbvtIbcqlCUdtv/p0J/gZGpz00roYDcfEBD/CpKZqcepxzxJdCHxW sN1gR46tmKDH9de5yGQBQ89+DzDZhHdN4LXlUfcuF+EGa9yPQo9KYUi/7MWztHKTHMoV 39ZQgL1aYpT2pF8EDj2xBoRj4CXz96PFhvsG3vmlNvVjA/tcs1+19POV2sFSmARmGe27 42cA== X-Gm-Message-State: APjAAAUpvZjWq9Ch2Fb2xUCJoElNs4pJYECq69TCOOnK9TdISdaI5dbY E/vnYnIwZoeRnOqGnCQMA2MGG1ZdcSbngTD3Ar0= X-Google-Smtp-Source: APXvYqz5kir33J5AjmzplbKAfH30cVdEZ3sEoQzuyfFO20zuGZF8LYiKII1TI8KuvJglH3idinfKAhZ4lWT5LqRWGgc= X-Received: by 2002:ac8:3ff5:: with SMTP id v50mr24492574qtk.142.1559636034539; Tue, 04 Jun 2019 01:13:54 -0700 (PDT) MIME-Version: 1.0 References: <20190531035348.7194-1-elder@linaro.org> <065c95a8-7b17-495d-f225-36c46faccdd7@linaro.org> <20190531233306.GB25597@minitux> <040ce9cc-7173-d10a-a82c-5186d2fcd737@linaro.org> In-Reply-To: <040ce9cc-7173-d10a-a82c-5186d2fcd737@linaro.org> From: Arnd Bergmann Date: Tue, 4 Jun 2019 10:13:37 +0200 Message-ID: Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver To: Alex Elder X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190604_011356_108454_E816C34C X-CRM114-Status: GOOD ( 34.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: DTML , syadagir@codeaurora.org, Eric Caruso , Dan Williams , Networking , Ilias Apalodimas , Linux Kernel Mailing List , evgreen@chromium.org, Bjorn Andersson , abhishek.esse@gmail.com, Linux ARM , linux-arm-msm@vger.kernel.org, Subash Abhinov Kasiviswanathan , linux-soc@vger.kernel.org, David Miller , cpratapa@codeaurora.org, Ben Chan Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 3, 2019 at 3:32 PM Alex Elder wrote: > On 6/3/19 5:04 AM, Arnd Bergmann wrote: > > On Sat, Jun 1, 2019 at 1:59 AM Subash Abhinov Kasiviswanathan > > > > - What I'm worried about most here is the flow control handling on the > > transmit side. The IPA driver now uses the modern BQL method to > > control how much data gets submitted to the hardware at any time. > > The rmnet driver also uses flow control using the > > rmnet_map_command() function, that blocks tx on the higher > > level device when the remote side asks us to. > > I fear that doing flow control for a single physical device on two > > separate netdev instances is counterproductive and confuses > > both sides. > > I understand what you're saying here, and instinctively I think > you're right. > > But BQL manages the *local* interface's ability to get rid of > packets, whereas the QMAP flow control is initiated by the other > end of the connection (the modem in this case). > > With multiplexing, it's possible that one of several logical > devices on the modem side has exhausted a resource and must > ask the source of the data on the host side to suspend the > flow. Meanwhile the other logical devices sharing the physical > link might be fine, and should not be delayed by the first one. > > It is the multiplexing itself that confuses the BQL algorithm. > The abstraction obscures the *real* rates at which individual > logical connections are able to transmit data. I would assume that the real rate constantly changes, at least for wireless interfaces that are also shared with other users on the same network. BQL is meant to deal with that, at least when using a modern queuing algorithm. > Even if the multiple logical interfaces implemented BQL, they > would not get the feedback they need directly from the IPA > driver, because transmitting over the physical interface might > succeed even if the logical interface on the modem side can't > handle more data. So I think the flow control commands may be > necessary, given multiplexing. Can you describe what kind of multiplexing is actually going on? I'm still unclear about what we actually use multiple logical interfaces for here, and how they relate to one another. > The rmnet driver could use BQL, and could return NETDEV_TX_BUSY > for a logical interface when its TX flow has been stopped by a > QMAP command. That way the feedback for BQL on the logical > interfaces would be provided in the right place. > > I have no good intuition about the interaction between > two layered BQL managed queues though. Returning NETDEV_TX_BUSY is usually a bad idea as that leads to unnecessary frame drop. I do think that using BQL and the QMAP flow command on the /same/ device would be best, as that throttles the connection when either of the two algorithms wants us to slow down. The question is mainly which of the two devices that should be. Doing it in the ipa driver is probably easier to implement here, but ideally I think we'd only have a single queue visible to the network stack, if we can come up with a way to do that. > > - I was a little confused by the location of the rmnet driver in > > drivers/net/ethernet/... More conventionally, I think as a protocol > > handler it should go into net/qmap/, with the ipa driver going > > into drivers/net/qmap/ipa/, similar to what we have fo ethernet, > > wireless, ppp, appletalk, etc. > > > > - The rx_handler uses gro_cells, which as I understand is meant > > for generic tunnelling setups and takes another loop through > > NAPI to aggregate data from multiple queues, but in case of > > IPA's single-queue receive calling gro directly would be simpler > > and more efficient. > > I have been planning to investigate some of the generic GRO > stuff for IPA but was going to wait on that until the basic > code was upstream. That's ok, that part can easily be changed after the fact, as it does not impact the user interface or the general design. > > From the overall design and the rmnet Kconfig description, it > > appears as though the intention as that rmnet could be a > > generic wrapper on top of any device, but from the > > implementation it seems that IPA is not actually usable that > > way and would always go through IPA. > > As far as I know *nothing* upstream currently uses rmnet; the > IPA driver will be the first, but as Bjorn said others seem to > be on the way. I'm not sure what you mean by "IPA is not > usable that way." Currently the IPA driver assumes a fixed > configuration, and that configuration assumes the use of QMAP, > and therefore assumes the rmnet driver is layered above it. > That doesn't preclude rmnet from using a different back end. Yes, that's what I meant above: IPA can only be used through rmnet (I wrote "through IPA", sorry for the typo), but cannot be used by itself. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel