On Wed, Aug 19, 2020 at 08:18:50AM +0000, David Laight wrote:

From:'Marcelo Ricardo Leitner

quoted

Sent: 18 August 2020 22:38

On Tue, Aug 18, 2020 at 03:38:09PM +0000, David Laight wrote:

quoted

A few years ago (for 5.1) the 'arrays' that sctp uses for
info about data streams was changed to use the 'genradix'
functions.

I'm not sure of the reason for the change, but I don't
thing anyone looked at the performance implications.

I don't have something like a CI for it, but I do run some performance
benchmarks every now and then and it didn't trigger anything
noticeable in my tests.

We have some customers who we think are sending 10000+ short
SCTP data chunks a second.
They are probably sending SMS messages, so that is 5000+ text
messages a second!
It is hard to stop those being sent with more than one
data chunk in each ethernet frame!

Thanks for this info.

quoted

Yet, can it be improved? Certainly. Patches welcomed. :-)

I'll apply some of my copious free time to it...
Actually some simple changes would help:

1) Change SCTP_SO()->x to so=SCTP_SO(); so->x in places
   where there are multiple references to the same stream.

Agree. This is an easy change, mostly just mechanical.

2) Optimise the genradix lookup for the case where there
   is a single page - it can be completely inlined.

And/or our struct sizes.

__idx_to_offset() will basically do:
        if (!is_power_of_2(obj_size)) {
                return (idx / objs_per_page) * PAGE_SIZE +
                        (idx % objs_per_page) * obj_size;
        } else {
                return idx * obj_size;

if we can get it to his the else block, it saves some CPU cycles already (at
the expense of memory).

3) Defer the allocation until the stream is used.
   for outbound streams this could remove the extra buffer.

This can be tricky. What should happen if it gets a packet on a stream
that it couldn't allocate, and then another on a stream that was
already allocated? Just a drop, it will retransmit and recover, and
then again.. While, OTOH, if the application requested such amount of
streams, it is likely going to use it. If not, that's an application
bug.

...

quoted

quoted

For example look at the object code for sctp_stream_clear()
(__genradix_ptr() is in lib/generic-radix-tree.c).

sctp_stream_clear() is rarely called.

Caller graph:
sctp_stream_clear
  sctp_assoc_update
    SCTP_CMD_UPDATE_ASSOC
      sctp_sf_do_dupcook_b
      sctp_sf_do_dupcook_a

So, well, I'm not worried about it.

I wasn't considering the loop.
It was just a place where the object code can be looked at.

But there are quite a few places where the same stream
is looked for lots of times in succession.
Even saving the pointer is probably noticeable.

Yes.

quoted

Specs say 64k streams, so we should support that and preferrably
without major regressions. Traversing 64k elements each time to find
an entry is very not performant.

For a more standard use case, with something like you were saying, 17
streams, genradix here doesn't use too much memory. I'm afraid a
couple of integer calculations to get an offset is minimal overhead if
compared to the rest of the code.

It is probably nearer 40 including a function call - which
is likely to cause register spills.

quoted

For example, the stream scheduler
operations, accessed via struct sctp_sched_ops (due to retpoline), is
probably more interesting fixing than genradix effects here.

Hmmm... the most scheduling M3UA/M2PA (etc) want is (probably)
to send stream 0 first.
But even the use of stream 0 (for non-data messages) is a
misunderstanding (of my understanding) of what SCTP streams are.
IIRC there is only one flow control window.

Only one window, yes, but now we have a more fine grained control on
how it is used:

I thought that tx data just got added to a single tx queue,
and the multiple streams just allowed some messages to passed
on to the receiving application while waiting for retransmissions
(head of line blocking).

That was before stream schedulers.
https://developers.redhat.com/blog/2018/01/03/sctp-stream-schedulers/
https://tools.ietf.org/html/rfc8260

OTOH M2PA seems to wand stream 0 to have the semantics of
ISO transport 'expedited data' - which can be sent even when
the main flow is blocked because it has its own credit (of 1).

That is now doable with the stream schedulers.

But note that even if you don't enable it, you're paying a price
already due to function pointers on struct sctp_sched_ops, which are
used even if you use the standard scheduler (FCFS, First Come First
Served).  In there, it should start using the indirect call wrappers,
such as INDIRECT_CALL_3. After all, they are always compiled in,
anyway.