On Fri, Feb 2, 2018 at 12:19 PM, Eric Dumazet wrote:
> On Fri, 2018-02-02 at 09:55 +0800, Tonghao Zhang wrote:
>> On Thu, Feb 1, 2018 at 10:00 PM, Eric Dumazet wrote:
>> > On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote:
>> > > Hi Eric
>> > > One question for you, In the patch ef547f2ac16
On Fri, 2018-02-02 at 09:55 +0800, Tonghao Zhang wrote:
> On Thu, Feb 1, 2018 at 10:00 PM, Eric Dumazet 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 len
On Thu, Feb 1, 2018 at 10:00 PM, Eric Dumazet 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 ma
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 w
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 "/pr
