Thread (37 messages) 37 messages, 5 authors, 2018-11-15

[RFC PATCH 10/12] soc: qcom: ipa: data path

From: arnd@arndb.de (Arnd Bergmann)
Date: 2018-11-07 14:55:43
Also in: linux-arm-msm, linux-devicetree, lkml, netdev

On Wed, Nov 7, 2018 at 1:33 AM Alex Elder [off-list ref] wrote:
This patch contains "ipa_dp.c", which includes the bulk of the data
path code.  There is an overview in the code of how things operate,
but there are already plans to rework this portion of the driver.

In particular:
  - Interrupt handling will be replaced with a threaded interrupt
    handler.  Currently handling occurs in a combination of
    interrupt and workqueue context, and this requires locking
    and atomic operations for proper synchronization.
You probably don't want to use just a threaded IRQ handler to
start the poll function, that would still require an extra indirection.

However, you can probably use the top half of the threaded
handler to request the poll function if necessary but use
the bottom half for anything that does not go through poll.
  - Currently, only receive endpoints use NAPI.  Transmit
    completion interrupts are disabled, and are handled in batches
    by periodically scheduling an interrupting no-op request.
    The plan is to arrange for transmit requests to generate
    interrupts, and their completion will be processed with other
    completions in the NAPI poll function.  This will also allow
    accurate feedback about packet sojourn time to be provided to
    queue limiting mechanisms.
Right, that is definitely required here. I also had a look at
the gsi_channel_queue() function, which sits in the middle of
the transmit function and is rather unoptimized. I'd suggest moving
that into the caller so we can see what is going on, and then
optimizing it from there.
  - Not all receive endpoints use NAPI.  The plan is for *all*
    endpoints to use NAPI.  And because all endpoints share a
    common GSI interrupt, a single NAPI structure will used to
    managing the processing for all completions on all endpoints.
  - Receive buffers are posted to the hardware by a workqueue
    function.  Instead, the plan is to have this done by the
    NAPI poll routine.
Makes sense, yes.

      Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help