From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver Date: Fri, 31 May 2019 23:12:20 +0200 Message-ID: References: <20190531035348.7194-1-elder@linaro.org> <065c95a8-7b17-495d-f225-36c46faccdd7@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Alex Elder Cc: Dan Williams , David Miller , Bjorn Andersson , Ilias Apalodimas , evgreen@chromium.org, Ben Chan , Eric Caruso , cpratapa@codeaurora.org, syadagir@codeaurora.org, Subash Abhinov Kasiviswanathan , abhishek.esse@gmail.com, Networking , DTML , Linux Kernel Mailing List , linux-soc@vger.kernel.org, Linux ARM , linux-arm-msm@vger.kernel.org List-Id: devicetree@vger.kernel.org On Fri, May 31, 2019 at 10:47 PM Alex Elder wrote: > On 5/31/19 2:19 PM, Arnd Bergmann wrote: > > On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote: > >> On 5/31/19 9:58 AM, Dan Williams wrote: > >>> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote: > > > > Does this mean that IPA can only be used to back rmnet, and rmnet > > can only be used on top of IPA, or can or both of them be combined > > with another driver to talk to instead? > > No it does not mean that. > > As I understand it, one reason for the rmnet layer was to abstract > the back end, which would allow using a modem, or using something > else (a LAN?), without exposing certain details of the hardware. > (Perhaps to support multiplexing, etc. without duplicating that > logic in two "back-end" drivers?) > > To be perfectly honest, at first I thought having IPA use rmnet > was a cargo cult thing like Dan suggested, because I didn't see > the benefit. I now see why one would use that pass-through layer > to handle the QMAP features. > > But back to your question. The other thing is that I see no > reason the IPA couldn't present a "normal" (non QMAP) interface > for a modem. It's something I'd really like to be able to do, > but I can't do it without having the modem firmware change its > configuration for these endpoints. My access to the people who > implement the modem firmware has been very limited (something > I hope to improve), and unless and until I can get corresponding > changes on the modem side to implement connections that don't > use QMAP, I can't implement such a thing. Why would that require firmware changes? What I was thinking here is to turn the bits of the rmnet driver that actually do anything interesting on the headers into a library module (or a header file with inline functions) that can be called directly by the ipa driver, keeping the protocol unchanged. > > Always passing data from one netdev to another both ways > > sounds like it introduces both direct CPU overhead, and > > problems with flow control when data gets buffered inbetween. > > My impression is the rmnet driver is a pretty thin layer, > so the CPU overhead is probably not that great (though > deaggregating a message is expensive). I agree with you > on the flow control. The CPU overhead I mean is not from executing code in the rmnet driver, but from passing packets through the network stack between the two drivers, i.e. adding each frame to a queue and taking it back out. I'm not sure how this ends up working in reality but from a first look it seems like we might bounce in an out of the softirq handler inbetween. Arnd