[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ffbcce1-f93d-5746-5037-9dcc03cd73f0@linaro.org>
Date: Mon, 24 Jun 2019 11:21:50 -0500
From: Alex Elder <elder@...aro.org>
To: Johannes Berg <johannes@...solutions.net>,
Arnd Bergmann <arnd@...db.de>
Cc: abhishek.esse@...il.com, Ben Chan <benchan@...gle.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
cpratapa@...eaurora.org, David Miller <davem@...emloft.net>,
Dan Williams <dcbw@...hat.com>,
DTML <devicetree@...r.kernel.org>,
Eric Caruso <ejcaruso@...gle.com>, evgreen@...omium.org,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-arm-msm@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-soc@...r.kernel.org, Networking <netdev@...r.kernel.org>,
Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
syadagir@...eaurora.org
Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
On 6/18/19 2:22 PM, Johannes Berg wrote:
> On Tue, 2019-06-18 at 09:00 -0500, Alex Elder wrote:
. . .
> Anyway, I think for now we could probably live with not having this
> configurable for the IPA driver, and if it *does* need to be
> configurable, it seems like it should be a driver configuration, not a
> channel configuration - so something like a debugfs hook if you really
> just need to play with it for performance testing, or a module
> parameter, or something else?
>
> Or even, in the WWAN framework, a knob that we provide there for the
> WWAN device, rather than for the (newly created) channel.
Agreed. I think a knob is appropriate, it's just a question of how
that control exposed. Same answer to your question below.
-Alex
>> The hardware is capable of aggregating QMAP packets
>> arriving on a connection into a single buffer, so this provides
>> a way of requesting it do that.
>>
>>>> #define RMNET_FLAGS_INGRESS_MAP_COMMANDS (1U << 1)
>>>
>>> Similar here? If you have flow control you probably want to use it?
>>
>> I agree with that, though perhaps there are cases where it
>> is pointless, or can't be supported, so one might want to
>> simply *not* implement/advertise the feature. I don't know.
>
> Sure, but then that's likely something the driver would need to know,
> not necessarily userspace?
>
> johannes
>
Powered by blists - more mailing lists