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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 E7B8DC31E5B for ; Tue, 18 Jun 2019 20:55:46 +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 BB72F21530 for ; Tue, 18 Jun 2019 20:55:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BQsRGRg0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BB72F21530 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=tfUE+i9H7W8g2DH7x9Xg6shsM3j4wpX+WFHEGqm8kvM=; b=BQsRGRg0SRCWKQ Wts5AlSMbDKlgoR1H0QX3E2oM2HOn8VjAV27xxu8EGiijmpdRVs9rWzSItTB2FIMRImqKgvP9b8YP W43UwAkwdPMPgnA1bjmF9aE4QLBymMKZcTMW1WXwUOxCdcGoswKXo4MJOOKzwK60hTSrAm9wmAjXc hGQN7kB7TaeVFNr/mutAiN0G+K7zbMS9K5CKgul7P0ymmGAxBFY9ZxD4Gzg45R1RUVwDz8LxKO1rn z+iuvDfjsizjIOP2ILHPB2rWKpxxVtHguW/o9Pnsf4tS/hcwM8DDZkgToJx6YULXC3CT8KHH/cqgi l1CjMFVaDy2bm2gor6FQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hdL8r-00024S-KR; Tue, 18 Jun 2019 20:55:45 +0000 Received: from mail-qk1-f193.google.com ([209.85.222.193]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hdL8p-00023m-6P for linux-arm-kernel@lists.infradead.org; Tue, 18 Jun 2019 20:55:44 +0000 Received: by mail-qk1-f193.google.com with SMTP id t8so9538681qkt.1 for ; Tue, 18 Jun 2019 13:55:42 -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=z9lpWmnxIWG+yn/Q8Kt9kwRJEp4w7nP1RsHOAevW2cM=; b=BCdkcrhFe/GIASpfQn69VdfBZO7pKLdp4ZUhPkyECqnBM9X4FI+7JAEhzQfILNvhDl mUc2s5xq7Y8iVBIPDEmk5Q7h4dcyN2wchjodNPjPobxe9HsdCnAxGX8Zy99AatSVqIMn YEspOsJrz0vWv3Zv42BqGLU4gdthMVYH/zTj18yi9aqrfIPfCcI46yQ4S9Ly2pB/abce 7NWmnL23ax/YGAGrDqYRbdZflraJf/xBAZtZben/MahlrhYkFOuWXpyWQ1v3VuVkTYUA O4wN+qnxx4hYCwPG02PHkyKZAw8aazSAwQplpKAmoBkk0NJvd4M3zrGUAa2kr3Nt0uUk ZFAA== X-Gm-Message-State: APjAAAUhHku5DXOcrZXxULaoHXMrOAeK7UTXIfAi+TI6a7dzrsSnnald 2aNnOmbwXBMNEA/5vB2Gy9L8RpGhpY2eXajcwoc= X-Google-Smtp-Source: APXvYqzMQnj8mooGUNvWO59G0b2ABKwAdRoB6ahNoB3XWyhRG2+Kc2tlKvSqhoNGKyDN+miPCnbs/N9GlnSM6tCUpFo= X-Received: by 2002:a37:a4d3:: with SMTP id n202mr8318000qke.84.1560891341993; Tue, 18 Jun 2019 13:55:41 -0700 (PDT) MIME-Version: 1.0 References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <066e9b39f937586f0f922abf801351553ec2ba1d.camel@sipsolutions.net> <613cdfde488eb23d7207c7ba6258662702d04840.camel@sipsolutions.net> In-Reply-To: <613cdfde488eb23d7207c7ba6258662702d04840.camel@sipsolutions.net> From: Arnd Bergmann Date: Tue, 18 Jun 2019 22:55:23 +0200 Message-ID: Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver To: Johannes Berg X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190618_135543_237076_AFFF0FCF X-CRM114-Status: GOOD ( 23.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: DTML , syadagir@codeaurora.org, Eric Caruso , Dan Williams , linux-arm-msm@vger.kernel.org, abhishek.esse@gmail.com, Linux Kernel Mailing List , evgreen@chromium.org, Bjorn Andersson , Ilias Apalodimas , Linux ARM , Alex Elder , Subash Abhinov Kasiviswanathan , Networking , 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 Tue, Jun 18, 2019 at 10:36 PM Johannes Berg wrote: > > On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote: > > > > From my understanding, the ioctl interface would create the lower > > netdev after talking to the firmware, and then user space would use > > the rmnet interface to create a matching upper-level device for that. > > This is an artifact of the strong separation of ipa and rmnet in the > > code. > > Huh. But if rmnet has muxing, and IPA supports that, why would you ever > need multiple lower netdevs? >From my reading of the code, there is always exactly a 1:1 relationship between an rmnet netdev an an ipa netdev. rmnet does the encapsulation/ decapsulation of the qmap data and forwards it to the ipa netdev, which then just passes data through between a hardware queue and its netdevice. [side note: on top of that, rmnet also does "aggregation", which may be a confusing term that only means transferring multiple frames at once] > > ipa definitely has multiple hardware queues, and the Alex' > > driver does implement the data path on those, just not the > > configuration to enable them. > > OK, but perhaps you don't actually have enough to use one for each > session? I'm lacking the terminology here, but what I understood was that the netdev and queue again map to a session. > > Guessing once more, I suspect the the XON/XOFF flow control > > was a workaround for the fact that rmnet and ipa have separate > > queues. The hardware channel on IPA may fill up, but user space > > talks to rmnet and still add more frames to it because it doesn't > > know IPA is busy. > > > > Another possible explanation would be that this is actually > > forwarding state from the base station to tell the driver to > > stop sending data over the air. > > Yeah, but if you actually have a hardware queue per upper netdev then > you don't really need this - you just stop the netdev queue when the > hardware queue is full, and you have flow control automatically. > > So I really don't see any reason to have these messages going back and > forth unless you plan to have multiple sessions muxed on a single > hardware queue. Sure, I definitely understand what you mean, and I agree that would be the right way to do it. All I said is that this is not how it was done in rmnet (this was again my main concern about the rmnet design after I learned it was required for ipa) ;-) Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel