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

On 9/23/25 7:57 PM, Xin Long wrote:
> On Tue, Sep 23, 2025 at 9:39 AM Paolo Abeni <[email protected]> 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