From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: Neal Cardwell <ncardwell@google.com>,
Michael Tuexen <michael.tuexen@lurchi.franken.de>,
Neil Horman <nhorman@tuxdriver.com>,
Dmitry Vyukov <dvyukov@google.com>,
Netdev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org, David Miller <davem@davemloft.net>,
David Ahern <dsa@cumulusnetworks.com>,
Eric Dumazet <edumazet@google.com>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs
Date: Tue, 29 May 2018 15:02:57 -0300 [thread overview]
Message-ID: <20180529180257.GE3788@localhost.localdomain> (raw)
In-Reply-To: <CADvbK_fbKbH2wm6Xurr+ELVag-LvyQdL+peJd=wp7OL7_zMZTQ@mail.gmail.com>
On Wed, May 30, 2018 at 01:45:08AM +0800, Xin Long wrote:
> If we're counting on max_t to fix this CPU stuck. It should not that
> matter if min rto < the value causing that stuck.
Yes but putting a floor to rto_{min,max} now is to protect the rtx
timer now, not the heartbeat one.
>
> >
> > Anyway, what about we add a floor to rto_max too, so that RTO can
> > actually grow into something bigger that don't hog the CPU? Like:
> > rto_min floor = 5ms
> > rto_max floor = 50ms
> >
> > Marcelo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: Neal Cardwell <ncardwell@google.com>,
Michael Tuexen <michael.tuexen@lurchi.franken.de>,
Neil Horman <nhorman@tuxdriver.com>,
Dmitry Vyukov <dvyukov@google.com>,
Netdev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org, David Miller <davem@davemloft.net>,
David Ahern <dsa@cumulusnetworks.com>,
Eric Dumazet <edumazet@google.com>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs
Date: Tue, 29 May 2018 18:02:57 +0000 [thread overview]
Message-ID: <20180529180257.GE3788@localhost.localdomain> (raw)
In-Reply-To: <CADvbK_fbKbH2wm6Xurr+ELVag-LvyQdL+peJd=wp7OL7_zMZTQ@mail.gmail.com>
On Wed, May 30, 2018 at 01:45:08AM +0800, Xin Long wrote:
> If we're counting on max_t to fix this CPU stuck. It should not that
> matter if min rto < the value causing that stuck.
Yes but putting a floor to rto_{min,max} now is to protect the rtx
timer now, not the heartbeat one.
>
> >
> > Anyway, what about we add a floor to rto_max too, so that RTO can
> > actually grow into something bigger that don't hog the CPU? Like:
> > rto_min floor = 5ms
> > rto_max floor = 50ms
> >
> > Marcelo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2018-05-29 18:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 17:41 [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs Xin Long
2018-05-25 17:41 ` Xin Long
2018-05-25 19:13 ` Neil Horman
2018-05-25 19:13 ` Neil Horman
2018-05-26 15:42 ` Michael Tuexen
2018-05-26 15:42 ` Michael Tuexen
2018-05-26 15:50 ` Dmitry Vyukov
2018-05-26 15:50 ` Dmitry Vyukov
2018-05-27 1:01 ` Neil Horman
2018-05-27 1:01 ` Neil Horman
2018-05-28 19:43 ` Marcelo Ricardo Leitner
2018-05-28 19:43 ` Marcelo Ricardo Leitner
2018-05-29 11:41 ` Neil Horman
2018-05-29 11:41 ` Neil Horman
2018-05-29 13:06 ` Michael Tuexen
2018-05-29 13:06 ` Michael Tuexen
2018-05-29 15:45 ` Marcelo Ricardo Leitner
2018-05-29 15:45 ` Marcelo Ricardo Leitner
2018-05-29 16:03 ` Neal Cardwell
2018-05-29 16:03 ` Neal Cardwell
2018-05-29 17:06 ` Marcelo Ricardo Leitner
2018-05-29 17:06 ` Marcelo Ricardo Leitner
2018-05-29 17:45 ` Xin Long
2018-05-29 17:45 ` Xin Long
2018-05-29 18:02 ` Marcelo Ricardo Leitner [this message]
2018-05-29 18:02 ` Marcelo Ricardo Leitner
2018-06-04 8:34 ` Dmitry Vyukov
2018-06-04 8:34 ` Dmitry Vyukov
2018-06-04 12:15 ` Xin Long
2018-06-04 12:15 ` Xin Long
2018-05-27 8:58 ` Michael Tuexen
2018-05-27 8:58 ` Michael Tuexen
2018-05-28 18:56 ` Marcelo Ricardo Leitner
2018-05-28 18:56 ` Marcelo Ricardo Leitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180529180257.GE3788@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=dvyukov@google.com \
--cc=edumazet@google.com \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=michael.tuexen@lurchi.franken.de \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.