[net-next,00/13] rxrpc: Increasing SACK size and moving away from softirq, part 2

  This is the second set of patches in the process of moving rxrpc from doing
a lot of its stuff in softirq context to doing it in an I/O thread in
process context and thereby making it easier to support a larger SACK table
(full description in part 1[1]).

[!] Note that these patches are based on a merge of a fix in net/master
    with net-next/master.  The fix makes a number of conflicting changes,
    so it's better if this set is built on top of it.

This set of patches includes some cleanups, adds some testing and overhauls
some tracing:

 (1) Remove declaration of rxrpc_kernel_call_is_complete() as the
     definition is no longer present.

 (2) Remove the knet() and kproto() macros in favour of using tracepoints.

 (3) Remove handling of duplicate packets from recvmsg.  The input side
     isn't now going to insert overlapping/duplicate packets into the
     recvmsg queue.

 (4) Don't use the rxrpc_conn_parameters struct in the rxrpc_connection or
     rxrpc_bundle structs - rather put the members in directly.

 (5) Extract the abort code from a received abort packet right up front
     rather than doing it in multiple places later.

 (6) Use enums and symbol lists rather than __builtin_return_address() to
     indicate where a tracepoint was triggered for local, peer, conn, call
     and skbuff tracing.

 (7) Add a refcount tracepoint for the rxrpc_bundle struct.

 (8) Implement an in-kernel server for the AFS rxperf testing program to
     talk to (enabled by a Kconfig option).

Link: https://lore.kernel.org/r/166794587113.2389296.16484814996876530222.stgit@warthog.procyon.org.uk/ [1]

---
The patches are tagged here:

	git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/rxrpc-next-20221121

And can be found on this branch:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-next

David
---
David Howells (13):
      rxrpc: Implement an in-kernel rxperf server for testing purposes
      rxrpc: Remove decl for rxrpc_kernel_call_is_complete()
      rxrpc: Remove handling of duplicate packets in recvmsg_queue
      rxrpc: Remove the [k_]proto() debugging macros
      rxrpc: Remove the [_k]net() debugging macros
      rxrpc: Drop rxrpc_conn_parameters from rxrpc_connection and rxrpc_bundle
      rxrpc: Extract the code from a received ABORT packet much earlier
      rxrpc: trace: Don't use __builtin_return_address for rxrpc_local tracing
      rxrpc: trace: Don't use __builtin_return_address for rxrpc_peer tracing
      rxrpc: trace: Don't use __builtin_return_address for rxrpc_conn tracing
      rxrpc: trace: Don't use __builtin_return_address for rxrpc_call tracing
      rxrpc: Trace rxrpc_bundle refcount
      rxrpc: trace: Don't use __builtin_return_address for sk_buff tracing


 include/net/af_rxrpc.h       |   2 +-
 include/trace/events/rxrpc.h | 385 +++++++++++++++-------
 net/rxrpc/Kconfig            |   7 +
 net/rxrpc/Makefile           |   3 +
 net/rxrpc/af_rxrpc.c         |  10 +-
 net/rxrpc/ar-internal.h      | 121 ++++---
 net/rxrpc/call_accept.c      |  39 +--
 net/rxrpc/call_event.c       |  18 +-
 net/rxrpc/call_object.c      | 120 +++----
 net/rxrpc/conn_client.c      | 112 ++++---
 net/rxrpc/conn_event.c       |  52 ++-
 net/rxrpc/conn_object.c      |  66 ++--
 net/rxrpc/conn_service.c     |  15 +-
 net/rxrpc/input.c            | 103 +++---
 net/rxrpc/key.c              |   2 +-
 net/rxrpc/local_event.c      |   7 +-
 net/rxrpc/local_object.c     |  85 +++--
 net/rxrpc/output.c           |  45 ++-
 net/rxrpc/peer_event.c       |  74 +----
 net/rxrpc/peer_object.c      |  44 ++-
 net/rxrpc/proc.c             |   6 +-
 net/rxrpc/recvmsg.c          |  32 +-
 net/rxrpc/rxkad.c            |  63 ++--
 net/rxrpc/rxperf.c           | 614 +++++++++++++++++++++++++++++++++++
 net/rxrpc/security.c         |   4 +-
 net/rxrpc/sendmsg.c          |   6 +-
 net/rxrpc/server_key.c       |  25 ++
 net/rxrpc/skbuff.c           |  36 +-
 28 files changed, 1403 insertions(+), 693 deletions(-)
 create mode 100644 net/rxrpc/rxperf.c
  

On Wed, 23 Nov 2022 10:06:20 +0000 David Howells wrote:
> [!] Note that these patches are based on a merge of a fix in net/master
>     with net-next/master.  The fix makes a number of conflicting changes,
>     so it's better if this set is built on top of it.

Please post as RFC if the patches don't apply.
  

What's the best way to base on a fix commit that's in net for patches in
net-next?  Here I tried basing on a merge between them.  Should I include the
fix patch on my net-next branch instead? Or will net be merged into net-next
at some point and I should wait for that?

Thanks,
David
  

On Thu, 24 Nov 2022 07:08:08 +0000 David Howells wrote:
> What's the best way to base on a fix commit that's in net for patches in
> net-next?  Here I tried basing on a merge between them.  Should I include the
> fix patch on my net-next branch instead? Or will net be merged into net-next
> at some point and I should wait for that?

We merge net -> net-next each Thursday afternoon (LT / Linus Time)
so if the wait is for something in net then we generally ask for folks
to just hold off posting until the merge. If the dependency is the
other way then just post based on what's in tree and provide the
conflict resolution in the cover letter.
  

Jakub Kicinski <kuba@kernel.org> wrote:

> On Thu, 24 Nov 2022 07:08:08 +0000 David Howells wrote:
> > What's the best way to base on a fix commit that's in net for patches in
> > net-next?  Here I tried basing on a merge between them.  Should I include
> > the fix patch on my net-next branch instead? Or will net be merged into
> > net-next at some point and I should wait for that?
> 
> We merge net -> net-next each Thursday afternoon (LT / Linus Time)
> so if the wait is for something in net then we generally ask for folks
> to just hold off posting until the merge. If the dependency is the
> other way then just post based on what's in tree and provide the
> conflict resolution in the cover letter.

Ok.  I guess last Thursday was skipped because of Thanksgiving.

David
  

On Mon, 28 Nov 2022 20:16:34 +0000 David Howells wrote:
> > We merge net -> net-next each Thursday afternoon (LT / Linus Time)
> > so if the wait is for something in net then we generally ask for folks
> > to just hold off posting until the merge. If the dependency is the
> > other way then just post based on what's in tree and provide the
> > conflict resolution in the cover letter.  
> 
> Ok.  I guess last Thursday was skipped because of Thanksgiving.

Really? Ugh. I wasn't clear enough in communicating to other
maintainers that I'll be out, I guess. 

I'll try to send another PR later today, once I caught up with all 
the traffic, and marge things up properly. Stay tuned.