From: Alex Elder <elder@linaro.org>
To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Cc: mka@chromium.org, evgreen@chromium.org,
bjorn.andersson@linaro.org, quic_cpratapa@quicinc.com,
quic_avuyyuru@quicinc.com, quic_jponduru@quicinc.com,
quic_subashab@quicinc.com, elder@kernel.org,
netdev@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net-next 0/6] net: ipa: use IDs to track transaction state
Date: Wed, 31 Aug 2022 17:40:11 -0500 [thread overview]
Message-ID: <20220831224017.377745-1-elder@linaro.org> (raw)
This series is the first of three groups of changes that simplify
the way the IPA driver tracks the state of its transactions.
Each GSI channel has a fixed number of transactions allocated at
initialization time. The number allocated matches the number of
TREs in the transfer ring associated with the channel. This is
because the transfer ring limits the number of transfers that can
ever be underway, and in the worst case, each transaction represents
a single TRE.
Transactions go through various states during their lifetime.
Currently a set of lists keeps track of which transactions are in
each state. Initially, all transactions are free. An allocated
transaction is placed on the allocated list. Once an allocated
transaction is committed, it is moved from the allocated to the
committed list. When a committed transaction is sent to hardware
(via a doorbell) it is moved to the pending list. When hardware
signals that some work has completed, transactions are moved to the
completed list. Finally, when a completed transaction is polled
it's moved to the polled list before being removed when it becomes
free.
Changing a transaction's state thus normally involves manipulating
two lists, and to prevent corruption a spinlock is held while the
lists are updated.
Transactions move through their states in a well-defined sequence
though, and they do so strictly in order. So transaction 0 is
always allocated before transaction 1; transaction 0 is always
committed before transaction 1; and so on, through completion,
polling, and becoming free. Because of this, it's sufficient to
just keep track of which transaction is the first in each state.
The rest of the transactions in a given state can be derived from
the first transaction in an "adjacent" state. As a result, we can
track the state of all transactions with a set of indexes, and can
update these without the need for a spinlock.
This first group of patches just defines the set of indexes that
will be used for this new way of tracking transaction state. Two
more groups of patches will follow. I've broken the 17 patches into
these three groups to facilitate review.
-Alex
Alex Elder (6):
net: ipa: use an array for transactions
net: ipa: track allocated transactions with an ID
net: ipa: track committed transactions with an ID
net: ipa: track pending transactions with an ID
net: ipa: track completed transactions with an ID
net: ipa: track polled transactions with an ID
drivers/net/ipa/gsi.h | 9 +++-
drivers/net/ipa/gsi_trans.c | 99 ++++++++++++++++++++++++++++++-------
2 files changed, 89 insertions(+), 19 deletions(-)
--
2.34.1
next reply other threads:[~2022-08-31 22:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 22:40 Alex Elder [this message]
2022-08-31 22:40 ` [PATCH net-next 1/6] net: ipa: use an array for transactions Alex Elder
2022-08-31 22:40 ` [PATCH net-next 2/6] net: ipa: track allocated transactions with an ID Alex Elder
2022-08-31 22:40 ` [PATCH net-next 3/6] net: ipa: track committed " Alex Elder
2022-08-31 22:40 ` [PATCH net-next 4/6] net: ipa: track pending " Alex Elder
2022-08-31 22:40 ` [PATCH net-next 5/6] net: ipa: track completed " Alex Elder
2022-08-31 22:40 ` [PATCH net-next 6/6] net: ipa: track polled " Alex Elder
2022-09-02 11:30 ` [PATCH net-next 0/6] net: ipa: use IDs to track transaction state patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220831224017.377745-1-elder@linaro.org \
--to=elder@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=elder@kernel.org \
--cc=evgreen@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mka@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_avuyyuru@quicinc.com \
--cc=quic_cpratapa@quicinc.com \
--cc=quic_jponduru@quicinc.com \
--cc=quic_subashab@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox