On Fri, Mar 1, 2024 at 1:10 AM Jason Xing wrote:
>
> From: Jason Xing
>
> When I reviewed other people's patch [1], I noticed that similar thing
> also happens in tcp_event_skb class and tcp_event_sk_skb class. They
> don't print those two addrs of skb/sk w
On Mon, Mar 4, 2024 at 4:24 PM Eric Dumazet wrote:
>
> On Thu, Feb 29, 2024 at 6:10 PM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > Prio to this patch, the trace function doesn't print addresses
> > which might be forgotten. As we can see, it alread
From: Jason Xing
Use the existing parameter and print the address of skbaddr
as other trace functions do.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
From: Jason Xing
When I reviewed other people's patch [1], I noticed that similar things
also happen in tcp_event_skb class and tcp_event_sk_skb class. They
don't print those two addrs of skb/sk which already exist.
In this patch, I just do as other trace functions do, like
From: Jason Xing
Printing the addresses can help us identify the exact skb/sk
for those system in which it's not that easy to run BPF program.
As we can see, it already fetches those, then use it directly
and it will print like below:
...tcp_retransmit_skb: skbaddr=XXX skaddr=XXX family=AF_INET
From: Jason Xing
When I reviewed other people's patch [1], I noticed that similar thing
also happens in tcp_event_skb class and tcp_event_sk_skb class. They
don't print those two addrs of skb/sk which already exist.
They are probably forgotten by the original authors, so this time I
finish
From: Jason Xing
Use the existing parameter and print it then. It will display
the address of skbaddr.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index
From: Jason Xing
Prio to this patch, the trace function doesn't print addresses
which might be forgotten. As we can see, it already fetches
those, use it directly and it will print like below:
...tcp_retransmit_skb: skbaddr=XXX skaddr=XXX family=AF_INET...
Signed-off-by: Jason Xing
From: Jason Xing
Using the macro for other tracepoints use to be more concise.
No functional change.
Jason Xing (3):
trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
trace: use TP_STORE_ADDRS() macro in inet_sk_error_report()
trace: use TP_STORE_ADDRS() macro
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
Put the macro into another standalone file for better extension.
Some tracepoints can use this common part in the future.
Signed-off-by: Jason Xing
---
include/trace/events/net_probe_common.h | 29 +
include/trace/events/tcp.h | 29
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
Introducing entry_saddr and entry_daddr parameters in this macro
for later use can help us record the reverse 4-turple by analyzing
the 4-turple of the incoming skb when receiving.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 21 +++--
1 file
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
From: Jason Xing
Before this, we miss some cases where the TCP layer could send rst but
we cannot trace it. So I decided to complete it :)
Jason Xing (2):
trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters
trace: tcp: fully support trace_tcp_send_reset
include/trace/events/tcp.h | 60
On Mon, Mar 11, 2024 at 11:23 AM Ratheesh Kannoth wrote:
>
> On 2024-03-11 at 08:11:03, Jason Xing (kerneljasonx...@gmail.com) wrote:
> > From: Jason Xing
> >
> > Introducing entry_saddr and entry_daddr parameters in this macro
> > for later use can help
On Mon, Mar 11, 2024 at 11:27 AM Ratheesh Kannoth wrote:
>
> On 2024-03-11 at 08:11:04, Jason Xing (kerneljasonx...@gmail.com) wrote:
> > From: Jason Xing
> >
> > Prior to this patch, what we can see by enabling trace_tcp_send is
> > only happening under two circums
From: Jason Xing
Before this, we miss some cases where the TCP layer could send rst but
we cannot trace it. So I decided to complete it :)
v2
1. fix spelling mistakes
Jason Xing (3):
trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters
trace: tcp: fully support trace_tcp_send_reset
tcp
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
As the title said, use the macro directly like the patch[1] did
to avoid those duplications. No functional change.
[1]
commit 6a6b0b9914e7 ("tcp: Avoid preprocessor directives in tracepoint macro
args")
Signed-off-by: Jason Xing
---
include/trace/events/s
From: Jason Xing
Using the macro for other tracepoints use to be more concise.
No functional change.
Jason Xing (3):
trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
trace: use TP_STORE_ADDRS() macro in inet_sk_error_report()
trace: use TP_STORE_ADDRS() macro
From: Jason Xing
Introducing entry_saddr and entry_daddr parameters in this macro
for later use can help us record the reverse 4-tuple by analyzing
the 4-tuple of the incoming skb when receiving.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 21 +++--
1 file
From: Jason Xing
Put the macro into another standalone file for better extension.
Some tracepoints can use this common part in the future.
Signed-off-by: Jason Xing
---
include/trace/events/net_probe_common.h | 29 +
include/trace/events/tcp.h | 29
From: Jason Xing
In addition to knowing the 4-tuple of the flow which generates RST,
the reason why it does so is very important because we have some
cases where the RST should be sent and have no clue which one
exactly.
Adding location of reset process can help us more, like what
On Tue, Mar 26, 2024 at 9:30 AM Jakub Kicinski wrote:
>
> On Mon, 25 Mar 2024 14:28:28 +0800 Jason Xing wrote:
> > Before this, we miss some cases where the TCP layer could send rst but
> > we cannot trace it. So I decided to complete it :)
> >
> > v2
> > 1. f
On Tue, Mar 26, 2024 at 10:23 AM Jakub Kicinski wrote:
>
> On Tue, 26 Mar 2024 10:13:55 +0800 Jason Xing wrote:
> > Yesterday, I posted two series to do two kinds of things. They are not
> > the same. Maybe you get me wrong :S
>
> Ah, my bad, sorry about that. I see tha
On Mon, Mar 25, 2024 at 11:43 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Using the macro for other tracepoints use to be more concise.
> No functional change.
>
> Jason Xing (3):
> trace: move to TP_STORE_ADDRS related macro to net_probe_common.h
> trace:
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
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
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
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
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
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
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
On Thu, Apr 4, 2024 at 9:50 AM Jakub Kicinski wrote:
>
> On Wed, 3 Apr 2024 15:31:38 +0800 Jason Xing wrote:
> > It's based on top of
> > https://patchwork.kernel.org/project/netdevbpf/list/?series=840182
>
> Please post as RFC if there's a dependency.
> We
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.
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
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
From: Jason Xing
It relys 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
---
net/mptcp/subflow.c | 18 +-
1 file changed, 13 insertions
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
---
include/net/request_sock.h | 3 ++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
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
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
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
Hi Steven,
On Tue, Apr 9, 2024 at 11:36 PM Steven Rostedt wrote:
>
> On Tue, 9 Apr 2024 18:09:34 +0800
> Jason Xing wrote:
>
> > /*
> > * tcp event with arguments sk and skb
> > @@ -74,20 +75,38 @@ DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_
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
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
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
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
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
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
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
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
From: Jason Xing
Introducing entry_saddr and entry_daddr parameters in this macro
for later use can help us record the reverse 4-tuple by analyzing
the 4-tuple of the incoming skb when receiving.
Signed-off-by: Jason Xing
---
include/trace/events/tcp.h | 21 +++--
1 file
From: Jason Xing
Before this, we miss some cases where the TCP layer could send RST but
we cannot trace it. So I decided to complete it :)
v3
1. fix a format problem in patch [3/3]
v2
1. fix spelling mistakes
Jason Xing (3):
trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters
trace: tcp
On Fri, Mar 29, 2024 at 9:15 AM Jakub Kicinski wrote:
>
> On Tue, 26 Mar 2024 12:08:01 +0100 Paolo Abeni wrote:
> > > - TP_PROTO(const struct sock *sk, const struct sk_buff *skb),
> > > + TP_PROTO(
> > > + const struct sock *sk,
> > > + const struct sk_buff *skb,
> > > +
From: Jason Xing
In addition to knowing the 4-tuple of the flow which generates RST,
the reason why it does so is very important because we have some
cases where the RST should be sent and have no clue which one
exactly.
Adding location of reset process can help us more, like what
On Fri, Mar 29, 2024 at 5:13 PM Eric Dumazet wrote:
>
> On Fri, Mar 29, 2024 at 4:43 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > In addition to knowing the 4-tuple of the flow which generates RST,
> > the reason why it does so is very important
On Fri, Mar 29, 2024 at 5:07 PM Eric Dumazet wrote:
>
> On Fri, Mar 29, 2024 at 4:43 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > Prior to this patch, what we can see by enabling trace_tcp_send is
> > only happening under two circumstances:
> >
On Tue, Mar 26, 2024 at 6:29 PM Paolo Abeni wrote:
>
> On Tue, 2024-03-26 at 12:14 +0800, Jason Xing wrote:
> > On Mon, Mar 25, 2024 at 11:43 AM Jason Xing
> > wrote:
> > >
> > > From: Jason Xing
> > >
> > > Using the macro for other t
On Tue, Mar 26, 2024 at 9:18 PM Eric Dumazet wrote:
>
> On Tue, Mar 26, 2024 at 11:44 AM Jason Xing wrote:
>
> > Well, it's a pity that it seems that we are about to abandon this
> > method but it's not that friendly to the users who are unable to
> > dep
From: Jason Xing
Before this, we miss some cases where the TCP layer could send RST but
we cannot trace it. So I decided to complete it :)
v4
Link:
https://lore.kernel.org/all/20240329034243.7929-1-kerneljasonx...@gmail.com/
1. rebased against latest net-next
2. remove {} and add skb test
From: Jason Xing
Introducing entry_saddr and entry_daddr parameters in this macro
for later use can help us record the reverse 4-tuple by analyzing
the 4-tuple of the incoming skb when receiving.
Signed-off-by: Jason Xing
Reviewed-by: Eric Dumazet
---
include/trace/events/net_probe_common.h
From: Jason Xing
Prior to this patch, what we can see by enabling trace_tcp_send is
only happening under two circumstances:
1) active rst mode
2) non-active rst mode and based on the full socket
That means the inconsistency occurs if we use tcpdump and trace
simultaneously to see how rst
Hi Antoine,
On Wed, Apr 10, 2024 at 8:14 PM Antoine Tenart wrote:
>
> Quoting Jason Xing (2024-04-09 12:09:30)
> > void(*send_reset)(const struct sock *sk,
> > - struct sk_buff *skb);
> > +
On Wed, Apr 10, 2024 at 9:21 PM Antoine Tenart wrote:
>
> Quoting Jason Xing (2024-04-10 14:54:51)
> > Hi Antoine,
> >
> > On Wed, Apr 10, 2024 at 8:14 PM Antoine Tenart wrote:
> > >
> > > Quoting Jason Xing (2024-04-09 12:09:30)
> > > >
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
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
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
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
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 | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
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
From: Jason Xing
It relys 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
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17 insertions
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
Reviewed-by: Steven
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_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
Hello Eric,
On Wed, Apr 17, 2024 at 5:02 PM Eric Dumazet wrote:
>
> On Wed, Apr 17, 2024 at 10:51 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive r
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 | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
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
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
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
It relys 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
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17 insertions
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_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
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
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
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
Reviewed-by: Steven
Hello Steven,
On Sat, Apr 20, 2024 at 10:36 AM Steven Rostedt wrote:
>
> On Fri, 19 Apr 2024 16:00:20 +0800
> Jason Xing wrote:
>
> > If other experts see this thread, please help me. I would appreciate
> > it. I have strong interests and feel strong responsibility to
On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
>
> On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > I'm not sure why the patch series has been changed to 'Changes
> > Requested', until now I don't think I need to change something.
> >
> > Should
On Fri, Apr 19, 2024 at 2:51 AM Eric Dumazet wrote:
>
> On Thu, Apr 18, 2024 at 6:24 PM Jason Xing wrote:
> >
> > On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> > >
> > > On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > > > I'
On Fri, Apr 19, 2024 at 6:29 AM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 2:51 AM Eric Dumazet wrote:
> >
> > On Thu, Apr 18, 2024 at 6:24 PM Jason Xing
> > wrote:
> > >
> > > On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> > >
> When I said "If you feel the need to put them in a special group, this
> is fine by me.",
> this was really about partitioning the existing enum into groups, if
> you prefer having a group of 'RES reasons'
Are you suggesting copying what we need from enum skb_drop_reason{} to
enum
On Fri, Apr 19, 2024 at 4:00 PM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 3:44 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 19, 2024 at 9:29 AM Jason Xing
> > wrote:
> > >
> > > On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
> > > &
On Fri, Apr 19, 2024 at 3:44 PM Eric Dumazet wrote:
>
> On Fri, Apr 19, 2024 at 9:29 AM Jason Xing wrote:
> >
> > On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
> > >
> > > On Fri, Apr 19, 2024 at 4:31 AM Jason Xing
> > > wrote:
> > >
On Fri, Apr 19, 2024 at 7:26 AM Jason Xing wrote:
>
> > When I said "If you feel the need to put them in a special group, this
> > is fine by me.",
> > this was really about partitioning the existing enum into groups, if
> > you prefer having a group of
Hello Matthieu,
On Mon, Apr 22, 2024 at 4:47 PM Matthieu Baerts wrote:
>
> Hi Jason,
>
> On 22/04/2024 05:01, Jason Xing wrote:
> > From: Jason Xing
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive r
On Tue, Apr 23, 2024 at 10:14 AM Jason Xing wrote:
>
> Hi Simon,
>
> On Tue, Apr 23, 2024 at 2:28 AM Simon Horman wrote:
> >
> > On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
> >
> > ...
> >
> > > diff --git
Hi Simon,
On Tue, Apr 23, 2024 at 2:28 AM Simon Horman wrote:
>
> On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
>
> ...
>
> > diff --git a/include/net/rstreason.h b/include/net/rstreason.h
>
> ...
>
> > +/**
> > + * There are three parts
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
From: Jason Xing
It relys 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
---
net/mptcp/protocol.h | 28
net/mptcp/subflow.c
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_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
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
Reviewed-by: Steven
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
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
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
1 - 100 of 122 matches
Mail list logo
