Merge branch 'net-ipa-transaction-state-IDs'
authorDavid S. Miller <davem@davemloft.net>
Fri, 2 Sep 2022 11:08:44 +0000 (12:08 +0100)
committerDavid S. Miller <davem@davemloft.net>
Fri, 2 Sep 2022 11:08:44 +0000 (12:08 +0100)
commit25de4a0b7b1aceedf0d3764b718974e7c5c3c71e
treefafcfc1b096c8033990273281f16b3423b8b0971
parenta01105f1748e8151ef43c300659b99d471f5f61d
parentfd3bd0398a0dfc7fc30bc9281bd1ae879527f96c
Merge branch 'net-ipa-transaction-state-IDs'

Alex Elder says:

====================
net: ipa: use IDs to track transaction state

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.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>