On Fri, Apr 26, 2024 at 7:25 AM Masami Hiramatsu wrote:
>
> Hi Andrii,
>
> On Wed, 24 Apr 2024 14:52:12 -0700
> Andrii Nakryiko wrote:
>
> > Improve objpool (used heavily in kretprobe hot path) performance with two
> > improvements:
> > - inlining performance critical objpool_push()/objpool_pop
Hi Andrii,
On Wed, 24 Apr 2024 14:52:12 -0700
Andrii Nakryiko wrote:
> Improve objpool (used heavily in kretprobe hot path) performance with two
> improvements:
> - inlining performance critical objpool_push()/objpool_pop() operations;
> - avoiding re-calculating relatively expensive nr_poss
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni :
On Thu, 25 Apr 2024 11:13:33 +0800 you wrote:
> From: Jason Xing
>
> In production, there are so many cases about why the RST skb is sent but
> we don't have a very convenient/fast method to detect the exact underlyin
On Thu, Apr 25, 2024 at 5:13 AM Jason Xing wrote:
>
> From: Jason Xing
>
> In production, there are so many cases about why the RST skb is sent but
> we don't have a very convenient/fast method to detect the exact underlying
> reasons.
>
> RST is implemented in two kinds: passive kind (like tcp_v
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> At last, we should let it work by introducing this reset reason in
> trace world.
>
> One of the possible expected outputs is:
> ... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
> state=TCP_ESTABLISHED reason=NO
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Since we have mapped every mptcp reset reason definition in enum
> sk_rst_reason, introducing a new helper can cover some missing places
> where we have already set the subflow->reset_reason.
>
> Note: using SK_RST_REASON_
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> It relies on what reset options in the skb are as rfc8684 says. Reusing
> this logic can save us much energy. This patch replaces most of the prior
> NOT_SPECIFIED reasons.
>
> Signed-off-by: Jason Xing
> Reviewed-by: Mat
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Like what we did to passive reset:
> only passing possible reset reason in each active reset path.
>
> No functional changes.
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Adjust the parameter and support passing reason of reset which
> is for now NOT_SPECIFIED. No functional changes.
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Thu, Apr 25, 2024 at 5:13 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Add a new standalone file for the easy future extension to support
> both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
>
> This patch only does the preparations for reset reason mechanism,
> nothing else
10 matches
Mail list logo