* Compare length of req sock queue with sk_max_ack_backlog
@ 2018-02-01 12:34 Tonghao Zhang
2018-02-01 14:00 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: Tonghao Zhang @ 2018-02-01 12:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers
Hi Eric
One question for you, In the patch ef547f2ac16 ("tcp: remove
max_qlen_log"), why we compared the length of req sock queue with
sk_max_ack_backlog. If we remove the max_qlen_log, we should check the
length of req sock queue with tcp_max_syn_backlog, right ?
With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog"
will be unsed anymore, right ?
I hope we should
1. Add a variate in sock struct, such as sk_max_syn_backlog. Then req
sock queue and accept sock queue can control their max value. When we
create the sock, we can store the tcp_max_syn_backlog value to
sk_max_syn_backlog.
2. Update the backlog, we can update it via ioctl.
Hope for your reply.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compare length of req sock queue with sk_max_ack_backlog
2018-02-01 12:34 Compare length of req sock queue with sk_max_ack_backlog Tonghao Zhang
@ 2018-02-01 14:00 ` Eric Dumazet
2018-02-02 1:55 ` Tonghao Zhang
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2018-02-01 14:00 UTC (permalink / raw)
To: Tonghao Zhang, Eric Dumazet; +Cc: Linux Kernel Network Developers
On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote:
> Hi Eric
> One question for you, In the patch ef547f2ac16 ("tcp: remove
> max_qlen_log"), why we compared the length of req sock queue with
> sk_max_ack_backlog. If we remove the max_qlen_log, we should check the
> length of req sock queue with tcp_max_syn_backlog, right ?
>
> With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog"
> will be unsed anymore, right ?
Not right.
Please "git grep -n sysctl_max_syn_backlog" to convince it is still
used.
>
> I hope we should
> 1. Add a variate in sock struct, such as sk_max_syn_backlog. Then req
> sock queue and accept sock queue can control their max value. When we
> create the sock, we can store the tcp_max_syn_backlog value to
> sk_max_syn_backlog.
>
There is a single /proc/sys/net/ipv4/tcp_max_syn_backlog value shared
by all sockets of a given network namespace.
But you can have thousands of TCP listeners, each of them having a
distinct listen() backlog
> 2. Update the backlog, we can update it via ioctl.
No need to add an ugly ioctl.
Simply call listen() again with another backlog value.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compare length of req sock queue with sk_max_ack_backlog
2018-02-01 14:00 ` Eric Dumazet
@ 2018-02-02 1:55 ` Tonghao Zhang
2018-02-02 4:19 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: Tonghao Zhang @ 2018-02-02 1:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, Linux Kernel Network Developers
On Thu, Feb 1, 2018 at 10:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote:
>> Hi Eric
>> One question for you, In the patch ef547f2ac16 ("tcp: remove
>> max_qlen_log"), why we compared the length of req sock queue with
>> sk_max_ack_backlog. If we remove the max_qlen_log, we should check the
>> length of req sock queue with tcp_max_syn_backlog, right ?
>>
>> With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog"
>> will be unsed anymore, right ?
>
> Not right.
>
> Please "git grep -n sysctl_max_syn_backlog" to convince it is still
> used.
>
In the tcp_conn_request(), we call the inet_csk_reqsk_queue_is_full()
to check the length of req sock queue. But
inet_csk_reqsk_queue_is_full()
compares it with sk_max_ack_backlog.
inet_csk_reqsk_queue_is_full
inet_csk_reqsk_queue_len(sk) >= sk->sk_max_ack_backlog;
inet_csk_reqsk_queue_len
reqsk_queue_len(&inet_csk(sk)->icsk_accept_queue);
If we set sysctl_max_syn_backlog to 1024 via
/proc/sys/net/ipv4/tcp_max_syn_backlog, and
backlog(sk_max_ack_backlog) to 128 via listen() , tcp_conn_request
will drop the packets when
length of req sock queue > 128, but not 1024.
tcp_conn_request
if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
inet_csk_reqsk_queue_is_full(sk)) && !isn) {
want_cookie = tcp_syn_flood_action(sk, skb, rsk_ops->slab_name);
if (!want_cookie)
goto drop; // drop the packets
}
>> I hope we should
>> 1. Add a variate in sock struct, such as sk_max_syn_backlog. Then req
>> sock queue and accept sock queue can control their max value. When we
>> create the sock, we can store the tcp_max_syn_backlog value to
>> sk_max_syn_backlog.
>>
>
> There is a single /proc/sys/net/ipv4/tcp_max_syn_backlog value shared
> by all sockets of a given network namespace.
>
> But you can have thousands of TCP listeners, each of them having a
> distinct listen() backlog
>
>> 2. Update the backlog, we can update it via ioctl.
>
> No need to add an ugly ioctl.
>
> Simply call listen() again with another backlog value.
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compare length of req sock queue with sk_max_ack_backlog
2018-02-02 1:55 ` Tonghao Zhang
@ 2018-02-02 4:19 ` Eric Dumazet
2018-02-02 5:41 ` Tonghao Zhang
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2018-02-02 4:19 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Eric Dumazet, Linux Kernel Network Developers
On Fri, 2018-02-02 at 09:55 +0800, Tonghao Zhang wrote:
> On Thu, Feb 1, 2018 at 10:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote:
> > > Hi Eric
> > > One question for you, In the patch ef547f2ac16 ("tcp: remove
> > > max_qlen_log"), why we compared the length of req sock queue with
> > > sk_max_ack_backlog. If we remove the max_qlen_log, we should check the
> > > length of req sock queue with tcp_max_syn_backlog, right ?
> > >
> > > With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog"
> > > will be unsed anymore, right ?
> >
> > Not right.
> >
> > Please "git grep -n sysctl_max_syn_backlog" to convince it is still
> > used.
> >
>
> In the tcp_conn_request(), we call the inet_csk_reqsk_queue_is_full()
> to check the length of req sock queue. But
> inet_csk_reqsk_queue_is_full()
> compares it with sk_max_ack_backlog.
>
> inet_csk_reqsk_queue_is_full
> inet_csk_reqsk_queue_len(sk) >= sk->sk_max_ack_backlog;
>
>
> inet_csk_reqsk_queue_len
> reqsk_queue_len(&inet_csk(sk)->icsk_accept_queue);
>
> If we set sysctl_max_syn_backlog to 1024 via
> /proc/sys/net/ipv4/tcp_max_syn_backlog, and
> backlog(sk_max_ack_backlog) to 128 via listen() , tcp_conn_request
> will drop the packets when
> length of req sock queue > 128, but not 1024.
>
> tcp_conn_request
> if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
> inet_csk_reqsk_queue_is_full(sk)) && !isn) {
> want_cookie = tcp_syn_flood_action(sk, skb, rsk_ops->slab_name);
> if (!want_cookie)
> goto drop; // drop the packets
> }
It seems to work as intended and documented in the changelog.
A socket listen backlog is determined at the time listen() system call
is issued, using the standard somaxconn as safe guard, for all socket
types.
We want to get rid of tcp_max_syn_backlog eventually, since TCP
listeners can use listen(fd, 10000000) these days if they want,
it is a matter of provisioning the needed memory.
Old mechanism was not allowing a listener to reduce or increase its
backlog dynamically (listener was using a private hash table, sized at
the time of first listen() and not resized later)
Having a global sysctl to magically change behavior on all TCP
listeners is not very practical, unless you had dedicated hosts to deal
with one service.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compare length of req sock queue with sk_max_ack_backlog
2018-02-02 4:19 ` Eric Dumazet
@ 2018-02-02 5:41 ` Tonghao Zhang
0 siblings, 0 replies; 5+ messages in thread
From: Tonghao Zhang @ 2018-02-02 5:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, Linux Kernel Network Developers
On Fri, Feb 2, 2018 at 12:19 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2018-02-02 at 09:55 +0800, Tonghao Zhang wrote:
>> On Thu, Feb 1, 2018 at 10:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote:
>> > > Hi Eric
>> > > One question for you, In the patch ef547f2ac16 ("tcp: remove
>> > > max_qlen_log"), why we compared the length of req sock queue with
>> > > sk_max_ack_backlog. If we remove the max_qlen_log, we should check the
>> > > length of req sock queue with tcp_max_syn_backlog, right ?
>> > >
>> > > With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog"
>> > > will be unsed anymore, right ?
>> >
>> > Not right.
>> >
>> > Please "git grep -n sysctl_max_syn_backlog" to convince it is still
>> > used.
>> >
>>
>> In the tcp_conn_request(), we call the inet_csk_reqsk_queue_is_full()
>> to check the length of req sock queue. But
>> inet_csk_reqsk_queue_is_full()
>> compares it with sk_max_ack_backlog.
>>
>> inet_csk_reqsk_queue_is_full
>> inet_csk_reqsk_queue_len(sk) >= sk->sk_max_ack_backlog;
>>
>>
>> inet_csk_reqsk_queue_len
>> reqsk_queue_len(&inet_csk(sk)->icsk_accept_queue);
>>
>> If we set sysctl_max_syn_backlog to 1024 via
>> /proc/sys/net/ipv4/tcp_max_syn_backlog, and
>> backlog(sk_max_ack_backlog) to 128 via listen() , tcp_conn_request
>> will drop the packets when
>> length of req sock queue > 128, but not 1024.
>>
>> tcp_conn_request
>> if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
>> inet_csk_reqsk_queue_is_full(sk)) && !isn) {
>> want_cookie = tcp_syn_flood_action(sk, skb, rsk_ops->slab_name);
>> if (!want_cookie)
>> goto drop; // drop the packets
>> }
>
> It seems to work as intended and documented in the changelog.
>
> A socket listen backlog is determined at the time listen() system call
> is issued, using the standard somaxconn as safe guard, for all socket
> types.
>
> We want to get rid of tcp_max_syn_backlog eventually, since TCP
> listeners can use listen(fd, 10000000) these days if they want,
> it is a matter of provisioning the needed memory.
In some case, the user may use different value for tcp_max_syn_backlog
and sk_max_ack_backlog.
Then in the tcp_conn_request, we should compare the length of req sock
queue with tcp_max_syn_backlog, but not sk_max_ack_backlog.
We can update the tcp_max_syn_backlog for specific socket via ioctl,
such like listen updating the ack backlog.
inet_csk_reqsk_queue_is_full
inet_csk_reqsk_queue_len(sk) >= sk->sk_max_ack_backlog;
to:
inet_csk_reqsk_queue_is_full
inet_csk_reqsk_queue_len(sk) >= tcp_max_syn_backlog; // for example
The sk_acceptq_is_full is ok in the sk_acceptq_is_full().
sk_acceptq_is_full
sk->sk_ack_backlog > sk->sk_max_ack_backlog;
> Old mechanism was not allowing a listener to reduce or increase its
> backlog dynamically (listener was using a private hash table, sized at
> the time of first listen() and not resized later)
>
> Having a global sysctl to magically change behavior on all TCP
> listeners is not very practical, unless you had dedicated hosts to deal
> with one service.
I got it.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-02-02 5:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-01 12:34 Compare length of req sock queue with sk_max_ack_backlog Tonghao Zhang
2018-02-01 14:00 ` Eric Dumazet
2018-02-02 1:55 ` Tonghao Zhang
2018-02-02 4:19 ` Eric Dumazet
2018-02-02 5:41 ` Tonghao Zhang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).