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,URIBL_BLOCKED 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 5F993C04AB5 for ; Mon, 3 Jun 2019 10:05:16 +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 3697128071 for ; Mon, 3 Jun 2019 10:05:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FwWd2zOO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3697128071 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=WBrgA5UvIfkfmApDur+3o3QLjl7ocXPoGNwz/cOQfDM=; b=FwWd2zOOtllA/3 UyaO4MZDxu41kCq7bFQg04V+td8g5Em5wXrKrHrzQLSxPEtN9sKUQbObsTq1YboWddw5Hag0e36Pt rrcRUKVWMgqvFYz8GniX6+x/cfk0zDzUGD9s4+bJWkHWlOdrFqAmMUWEZqPWVk20KedP+ggDIJpf4 SmyVPsWoKd4t/KaxbiWXlak8tgsaGRDiqFXQUc0nLGSWo/ugEMIyyy/Pe0OUHeAk4d9ROphvsjG15 mu742vvGQDkmKyGYhpXpmGSt1pIYyqQ+QcJ+C6+cq0Yct4lf2PS72zfnWl02IB0+/FLtxlsmXZVFt /H+AxXhOXuUW6L9B+X0g==; 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 1hXjq4-0000FQ-8t; Mon, 03 Jun 2019 10:05:12 +0000 Received: from mail-qt1-f193.google.com ([209.85.160.193]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hXjpU-0007IS-S4 for linux-arm-kernel@lists.infradead.org; Mon, 03 Jun 2019 10:04:54 +0000 Received: by mail-qt1-f193.google.com with SMTP id u12so8635681qth.3 for ; Mon, 03 Jun 2019 03:04:36 -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=4mTLQRrHjaRBaZSwkMEWXidv12RrUMv/IgTicgG6H6Y=; b=VlFq3CUiaICbEm4RTs2KAjkURWKCD3+iif8Aak5LWgg0SWgFPEJKWkVy+BdjYXL2g2 JHMi10YBnoPM+Jrry2XLsNJsBgLZgg1y04MDU4BFKtvAC/3UjP7j+B7XXZwaMdFRTRQe Bc32m5WIOS4kDCqg7eq7p/TZmyazVq+OIzLOsSNnER2jY0SzABJRl7JkJTvbGQ8m7q0d /nSG3tjZhffvsxjWZlm5IEffHmyqnHaAE+oYrmOXNerS6NOnxARTV/nKYZ0rnSx8uNMl r0TfZYpJnAYPcP2yjggDOwld4JwX/RmA4bnRxgxlr1ddTCfIjLddFcd2GuKOYEKxzQnn B5yg== X-Gm-Message-State: APjAAAVXW+c8YbRA9zm1BA9R/R2DfTW1GeeuN2usW5F8ZKdMG2W6AVyw isEkXaVCtcwB2BPG9eUXgNqvIOYPpF+Sn4gJvtEtpSnFIJKthg== X-Google-Smtp-Source: APXvYqyJKu5GwO9ABnBYg2Ba17xg3CWHMZcxHiqutvmKcrHX9Lm6N7mfkfbtxvzLf+9LUIihQPa7nJEQpZpARdFTdGA= X-Received: by 2002:a0c:e78b:: with SMTP id x11mr955877qvn.93.1559556275186; Mon, 03 Jun 2019 03:04:35 -0700 (PDT) MIME-Version: 1.0 References: <20190531035348.7194-1-elder@linaro.org> <065c95a8-7b17-495d-f225-36c46faccdd7@linaro.org> <20190531233306.GB25597@minitux> In-Reply-To: From: Arnd Bergmann Date: Mon, 3 Jun 2019 12:04:18 +0200 Message-ID: Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver To: Subash Abhinov Kasiviswanathan X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190603_030437_230331_54AE9A1F X-CRM114-Status: GOOD ( 17.47 ) 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 , linux-arm-msm@vger.kernel.org, Ilias Apalodimas , Linux Kernel Mailing List , evgreen@chromium.org, Bjorn Andersson , abhishek.esse@gmail.com, Linux ARM , Alex Elder , 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 Sat, Jun 1, 2019 at 1:59 AM Subash Abhinov Kasiviswanathan wrote: > On 2019-05-31 17:33, Bjorn Andersson wrote: > > On Fri 31 May 13:47 PDT 2019, Alex Elder wrote: > >> On 5/31/19 2:19 PM, Arnd Bergmann wrote: > > But any such changes would either be years into the future or for > > specific devices and as such not applicable to any/most of devices on > > the market now or in the coming years. > > > > > > But as Arnd points out, if the software split between IPA and rmnet is > > suboptimal your are encouraged to fix that. > > The split rmnet design was chosen because we could place rmnet > over any transport - IPA, PCIe (https://lkml.org/lkml/2018/4/26/1159) > or USB. > > rmnet registers a rx handler, so the rmnet packet processing itself > happens in the same softirq when packets are queued to network stack > by IPA. I've read up on the implementation some more, and concluded that it's mostly a regular protocol wrapper, doing IP over QMAP. There is nothing wrong with the basic concept I think, and as you describe this is an abstraction to keep the common bits in one place, and have them configured consistently. A few observations on more details here: - 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 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'm still not sure I understand the purpose of the layering with using an rx_handler as opposed to just using EXPORT_SYMBOL(rmnet_rx_handler) and calling that from the hardware driver directly. 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. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel