Re: [PATCH net-next v2 5/6] mptcp: support rstreason for passive reset

2024-04-04 Thread Jason Xing
Hello Mat, On Fri, Apr 5, 2024 at 4:33 AM Mat Martineau wrote: > > On Thu, 4 Apr 2024, Jason Xing wrote: > > > From: Jason Xing > > > > It relys on what reset options in MPTCP does as rfc8684 says. Reusing > > this logic can save us much energy. This patch replaces all the prior > > NOT_SPECIFIE

Re: [PATCH net-next v2 5/6] mptcp: support rstreason for passive reset

2024-04-04 Thread Mat Martineau
On Thu, 4 Apr 2024, Jason Xing wrote: From: Jason Xing It relys on what reset options in MPTCP does as rfc8684 says. Reusing this logic can save us much energy. This patch replaces all the prior NOT_SPECIFIED reasons. Signed-off-by: Jason Xing --- net/mptcp/subflow.c | 26 +++

[PATCH net-next v2 6/6] rstreason: make it work in trace world

2024-04-04 Thread Jason Xing
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=NOT_SPECIFIED Signed-off-by: Jason Xing --- include/trace/events/t

[PATCH net-next v2 5/6] mptcp: support rstreason for passive reset

2024-04-04 Thread Jason Xing
From: Jason Xing It relys on what reset options in MPTCP does as rfc8684 says. Reusing this logic can save us much energy. This patch replaces all the prior NOT_SPECIFIED reasons. Signed-off-by: Jason Xing --- net/mptcp/subflow.c | 26 -- 1 file changed, 20 insertions(+

[PATCH net-next v2 4/6] tcp: support rstreason for passive reset

2024-04-04 Thread Jason Xing
From: Jason Xing Reuse the dropreason logic to show the exact reason of tcp reset, so we don't need to implement those duplicated reset reasons. This patch replaces all the prior NOT_SPECIFIED reasons. Signed-off-by: Jason Xing --- net/ipv4/tcp_ipv4.c | 8 net/ipv6/tcp_ipv6.c | 8

[PATCH net-next v2 3/6] rstreason: prepare for active reset

2024-04-04 Thread Jason Xing
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 --- include/net/tcp.h | 2 +- net/ipv4/tcp.c| 15 ++- net/ipv4/tcp_output.c | 2 +- net/ipv4/tcp_timer.c

[PATCH net-next v2 2/6] rstreason: prepare for passive reset

2024-04-04 Thread Jason Xing
From: Jason Xing Adjust the paramenter and support passing reason of reset which is for now NOT_SPECIFIED. No functional changes. Signed-off-by: Jason Xing --- include/net/request_sock.h | 3 ++- net/dccp/ipv4.c| 10 ++ net/dccp/ipv6.c| 10 ++ net/dccp/

[PATCH net-next v2 1/6] net: introduce rstreason to detect why the RST is sent

2024-04-04 Thread Jason Xing
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 changes. The reset reasons are divided into three parts: 1) reu

[PATCH net-next 0/6] Implement reset reason mechanism to detect

2024-04-04 Thread Jason Xing
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_v4_send_reset()) and active kind (like tcp_send_active_reset()). T