Re: [PATCH net-next v3 06/15] quic: add stream management

Paolo Abeni
2025-09-25T16:03:35Z

On 9/23/25 7:57 PM, Xin Long wrote:
> On Tue, Sep 23, 2025 at 9:39 AM Paolo Abeni <pabeni@redhat.com> wrote:
>> On 9/19/25 12:34 AM, Xin Long wrote:
>>> +/* Create and register new streams for sending. */
>>> +static struct quic_stream *quic_stream_send_create(struct quic_stream_table *streams,
>>> + s64 max_stream_id, u8 is_serv)
>>> +{
>>> + struct quic_stream *stream;
>>> + s64 stream_id;
>>> +
>>> + stream_id = streams->send.next_bidi_stream_id;
>>> + if (quic_stream_id_uni(max_stream_id))
>>> + stream_id = streams->send.next_uni_stream_id;
>>> +
>>> + /* rfc9000#section-2.1: A stream ID that is used out of order results in all streams
>>> + * of that type with lower-numbered stream IDs also being opened.
>>> + */
>>> + while (stream_id <= max_stream_id) {
>>> + stream = kzalloc(sizeof(*stream), GFP_KERNEL);
>>> + if (!stream)
>>> + return NULL;
>>
>> How many streams and connections ID do you foresee per socket? Could
>> such number grow significantly (possibly under misuse/attack)? If so you
>> you likely use GFP_KERNEL_ACCOUNT here (and in conn_id allocation).
> connections ID: 8 (QUIC_CONN_ID_LIMIT) at most per socket.
> streams: 4096 (QUIC_MAX_STREAMS) at most per socket.

Will such limit fit a (very) busy server? I guess it's more a question
those who already run quic workload at scale...

> I can switch to GFP_KERNEL_ACCOUNT in quic_stream_send_create().
>
> For quic_stream_recv_create(), it’s typically invoked in atomic context.
> Since there’s no predefined GFP_ATOMIC_ACCOUNT, I assume using
> (GFP_ATOMIC | __GFP_ACCOUNT) should be acceptable.

I see there are already a few other allocations using such flags, and I
could not find any explicit limitation/drawback for it. I hope it's not
just cargo cult programming :-P

/P