* Add Multipath TCP (MPTCP) Support to the Java Networking API
@ 2025-09-05 1:43 Geliang Tang
2025-09-05 9:00 ` Geliang Tang
0 siblings, 1 reply; 7+ messages in thread
From: Geliang Tang @ 2025-09-05 1:43 UTC (permalink / raw)
To: net-dev, core-libs-dev
Cc: Matthieu Baerts, Mat Martineau, mptcp, Gang Yan, Xiang Gao
Hi OpenJDK maintainers,
I hope this message finds you well. The purpose of this letter is to
propose the integration of Multipath TCP (MPTCP) support into OpenJDK.
We have developed a set of patches to enable this functionality and are
eager to submit it for upstream inclusion. We would greatly appreciate
your feedback and opinions on this contribution.
1. Introduction
Multipath TCP (MPTCP), as standardized in RFC 8684, is a major
evolution of the TCP protocol. It enables a transport connection to use
multiple network paths simultaneously for redundancy, resilience, and
bandwidth aggregation. Since its introduction in Linux kernel v5.6, it
has become a key technology for modern networking, particularly on
mobile devices with multiple interfaces (e.g., Wi-Fi and cellular).
Key benefits include:
Bandwidth Aggregation: Combine the bandwidth of multiple network
links.
Seamless Handover: Maintain connections when switching networks
without dropping the session.
Improved Resilience: Traffic is automatically rerouted if one path
fails.
For more details, see the project website: https://mptcp.dev.
2. Technical Background
On a supporting system like Linux, an MPTCP socket is created by
specifying the IPPROTO_MPTCP protocol in the socket() system call
instead of IPPROTO_TCP (or 0):
int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
This creates a socket that looks like a standard TCP socket to the
application but uses the MPTCP protocol stack underneath.
With the Java API, it is possible to create "stream" sockets, but it is
not possible to change the last argument, which blocks apps to ask to
use MPTCP.
3. Proposed Java API Changes
The goal is to allow Java applications to opt-in to using MPTCP when
creating sockets, without breaking existing code. The proposed changes
are additive and backward-compatible.
The core idea is to add a boolean mptcp parameter through the API
layers, from the public Socket class down to the native system call.
4. Implementation Plan
The implementation involves changes across four layers of the JDK:
JNI Layer (sun.nio.ch.Net):
Modify Java_sun_nio_ch_Net_socket0 to accept a new jboolean mptcp
parameter.
The native implementation will be updated to use this parameter:
int protocol = mptcp == JNI_TRUE ? IPPROTO_MPTCP : 0;
fd = socket(domain, type, protocol);
NIO Layer (sun.nio.ch):
Add the mptcp parameter to the Net.socket() and Net.serverSocket()
methods.
Propagate the parameter down to the JNI call.
Socket Implementation Layer (java.net):
Add the mptcp parameter to the constructor of NioSocketImpl.
Within NioSocketImpl, pass the parameter to the Net.socket() or
Net.serverSocket() calls.
Public API Layer (java.net.Socket & java.net.ServerSocket):
Add new constructors that accept the mptcp parameter.
Example:
// Proposed new constructor
public Socket(String host, int port, boolean stream, boolean
mptcp) throws IOException {
// ... implementation that passes 'mptcp' to NioSocketImpl
}
5. Full Implementation
The complete working implementation for this proposal is available for
review:
https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master
We look forward to your valuable feedback and suggestions on this
proposal.
we can create a new issue for this feature, and submit a proper pull
request after if that's OK for you. We didn't do that yet because we
noticed that it is recommended to send more explanations to this list
first.
Best regards,
MPTCP Upstream Developers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Add Multipath TCP (MPTCP) Support to the Java Networking API
@ 2025-09-05 8:43 Geliang Tang
[not found] ` <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com>
0 siblings, 1 reply; 7+ messages in thread
From: Geliang Tang @ 2025-09-05 8:43 UTC (permalink / raw)
To: net-dev, core-libs-dev
Cc: Matthieu Baerts, Mat Martineau, mptcp, Gang Yan, Xiang Gao
Hi OpenJDK maintainers,
I hope this message finds you well. The purpose of this letter is to
propose the integration of Multipath TCP (MPTCP) support into OpenJDK.
We have developed a set of patches to enable this functionality and are
eager to submit it for upstream inclusion. We would greatly appreciate
your feedback and opinions on this contribution.
1. Introduction
Multipath TCP (MPTCP), as standardized in RFC 8684, is a major
evolution of the TCP protocol. It enables a transport connection to use
multiple network paths simultaneously for redundancy, resilience, and
bandwidth aggregation. Since its introduction in Linux kernel v5.6, it
has become a key technology for modern networking, particularly on
mobile devices with multiple interfaces (e.g., Wi-Fi and cellular).
Key benefits include:
Bandwidth Aggregation: Combine the bandwidth of multiple network
links.
Seamless Handover: Maintain connections when switching networks
without dropping the session.
Improved Resilience: Traffic is automatically rerouted if one path
fails.
For more details, see the project website: https://mptcp.dev.
2. Technical Background
On a supporting system like Linux, an MPTCP socket is created by
specifying the IPPROTO_MPTCP protocol in the socket() system call
instead of IPPROTO_TCP (or 0):
int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
This creates a socket that looks like a standard TCP socket to the
application but uses the MPTCP protocol stack underneath.
With the Java API, it is possible to create "stream" sockets, but it is
not possible to change the last argument, which blocks apps to ask to
use MPTCP.
3. Proposed Java API Changes
The goal is to allow Java applications to opt-in to using MPTCP when
creating sockets, without breaking existing code. The proposed changes
are additive and backward-compatible.
The core idea is to add a boolean mptcp parameter through the API
layers, from the public Socket class down to the native system call.
4. Implementation Plan
The implementation involves changes across four layers of the JDK:
JNI Layer (sun.nio.ch.Net):
Modify Java_sun_nio_ch_Net_socket0 to accept a new jboolean mptcp
parameter.
The native implementation will be updated to use this parameter:
int protocol = mptcp == JNI_TRUE ? IPPROTO_MPTCP : 0;
fd = socket(domain, type, protocol);
NIO Layer (sun.nio.ch):
Add the mptcp parameter to the Net.socket() and Net.serverSocket()
methods.
Propagate the parameter down to the JNI call.
Socket Implementation Layer (java.net):
Add the mptcp parameter to the constructor of NioSocketImpl.
Within NioSocketImpl, pass the parameter to the Net.socket() or
Net.serverSocket() calls.
Public API Layer (java.net.Socket & java.net.ServerSocket):
Add new constructors that accept the mptcp parameter.
Example:
// Proposed new constructor
public Socket(String host, int port, boolean stream, boolean
mptcp) throws IOException {
// ... implementation that passes 'mptcp' to NioSocketImpl
}
5. Full Implementation
The complete working implementation for this proposal is available for
review:
https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master
We look forward to your valuable feedback and suggestions on this
proposal.
We can create a new issue for this feature, and submit a proper pull
request after if that's OK for you. We didn't do that yet because we
noticed that it is recommended to send more explanations to this list
first.
Best regards,
MPTCP Upstream Developers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Add Multipath TCP (MPTCP) Support to the Java Networking API
2025-09-05 1:43 Geliang Tang
@ 2025-09-05 9:00 ` Geliang Tang
0 siblings, 0 replies; 7+ messages in thread
From: Geliang Tang @ 2025-09-05 9:00 UTC (permalink / raw)
To: Matthieu Baerts, Mat Martineau, Gang Yan, Xiang Gao; +Cc: mptcp
Hi,
I just received a message that this email was not delivered: Your
message to net-dev awaits moderator approval, reason: Post by non-
member to a members-only list. So I had to subscribe to the openjdk
net-dev and core-libs-dev mailing lists and resend the email.
If you want to reply to this email in the future, please subscribe to
these two mailing lists before replying:
https://mail.openjdk.org/mailman/listinfo/net-dev
https://mail.openjdk.org/mailman/listinfo/core-libs-dev
Thanks,
-Geliang
On Fri, 2025-09-05 at 09:43 +0800, Geliang Tang wrote:
> Hi OpenJDK maintainers,
>
> I hope this message finds you well. The purpose of this letter is to
> propose the integration of Multipath TCP (MPTCP) support into
> OpenJDK.
> We have developed a set of patches to enable this functionality and
> are
> eager to submit it for upstream inclusion. We would greatly
> appreciate
> your feedback and opinions on this contribution.
>
> 1. Introduction
>
> Multipath TCP (MPTCP), as standardized in RFC 8684, is a major
> evolution of the TCP protocol. It enables a transport connection to
> use
> multiple network paths simultaneously for redundancy, resilience, and
> bandwidth aggregation. Since its introduction in Linux kernel v5.6,
> it
> has become a key technology for modern networking, particularly on
> mobile devices with multiple interfaces (e.g., Wi-Fi and cellular).
>
> Key benefits include:
>
> Bandwidth Aggregation: Combine the bandwidth of multiple network
> links.
>
> Seamless Handover: Maintain connections when switching networks
> without dropping the session.
>
> Improved Resilience: Traffic is automatically rerouted if one
> path
> fails.
>
> For more details, see the project website: https://mptcp.dev.
>
> 2. Technical Background
>
> On a supporting system like Linux, an MPTCP socket is created by
> specifying the IPPROTO_MPTCP protocol in the socket() system call
> instead of IPPROTO_TCP (or 0):
>
> int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
>
> This creates a socket that looks like a standard TCP socket to the
> application but uses the MPTCP protocol stack underneath.
>
> With the Java API, it is possible to create "stream" sockets, but it
> is
> not possible to change the last argument, which blocks apps to ask to
> use MPTCP.
>
> 3. Proposed Java API Changes
>
> The goal is to allow Java applications to opt-in to using MPTCP when
> creating sockets, without breaking existing code. The proposed
> changes
> are additive and backward-compatible.
>
> The core idea is to add a boolean mptcp parameter through the API
> layers, from the public Socket class down to the native system call.
>
> 4. Implementation Plan
>
> The implementation involves changes across four layers of the JDK:
>
> JNI Layer (sun.nio.ch.Net):
>
> Modify Java_sun_nio_ch_Net_socket0 to accept a new jboolean mptcp
> parameter.
>
> The native implementation will be updated to use this parameter:
>
> int protocol = mptcp == JNI_TRUE ? IPPROTO_MPTCP : 0;
> fd = socket(domain, type, protocol);
>
> NIO Layer (sun.nio.ch):
>
> Add the mptcp parameter to the Net.socket() and
> Net.serverSocket()
> methods.
>
> Propagate the parameter down to the JNI call.
>
> Socket Implementation Layer (java.net):
>
> Add the mptcp parameter to the constructor of NioSocketImpl.
>
> Within NioSocketImpl, pass the parameter to the Net.socket() or
> Net.serverSocket() calls.
>
> Public API Layer (java.net.Socket & java.net.ServerSocket):
>
> Add new constructors that accept the mptcp parameter.
>
> Example:
>
> // Proposed new constructor
> public Socket(String host, int port, boolean stream, boolean
> mptcp) throws IOException {
> // ... implementation that passes 'mptcp' to
> NioSocketImpl
> }
>
> 5. Full Implementation
>
> The complete working implementation for this proposal is available
> for
> review:
>
> https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master
>
> We look forward to your valuable feedback and suggestions on this
> proposal.
>
> we can create a new issue for this feature, and submit a proper pull
> request after if that's OK for you. We didn't do that yet because we
> noticed that it is recommended to send more explanations to this list
> first.
>
> Best regards,
> MPTCP Upstream Developers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Add Multipath TCP (MPTCP) Support to the Java Networking API
[not found] ` <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com>
@ 2025-09-05 10:05 ` Geliang Tang
2025-09-05 10:11 ` Geliang Tang
1 sibling, 0 replies; 7+ messages in thread
From: Geliang Tang @ 2025-09-05 10:05 UTC (permalink / raw)
To: Alan Bateman, net-dev, nio-dev@openjdk.org
Cc: Matthieu Baerts, Mat Martineau, mptcp, Gang Yan, Xiang Gao,
core-libs-dev
Hi Alan,
Thanks for your reply.
On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote:
>
> On 05/09/2025 09:43, Geliang Tang wrote:
>
>
> >
> > :
> >
> > 3. Proposed Java API Changes
> >
> > The goal is to allow Java applications to opt-in to using MPTCP
> > when
> > creating sockets, without breaking existing code. The proposed
> > changes
> > are additive and backward-compatible.
> >
> > The core idea is to add a boolean mptcp parameter through the API
> > layers, from the public Socket class down to the native system
> > call.
> >
>
> (moving the discussion to nio-dev and net-dev).
>
> Adding new constructors to legacy Socket/ServerSocket may work for
> your initial prototype but would be problematic to propose as it
> would bake non-standard features into the standard API. Also many
> high performance servers use SocketChannel rather than Socket.
>
> One suggestion for a next prototype is to model the enablement of
> MultiPath TCP as as a JDK-specific socket option (see
> jdk.net.ExtendingSocketOptions). All of the standard APIs for
> networking sockets define a setOption method for setting socket
I was initially concerned that calling setOption() after Socket()
creation to convert TCP to MPTCP was too late. Creating an MPTCP socket
must be done during the socket() system call.
> options. If modeled as a socket option then enabling can create a new
> AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place
Until I saw here, it should be feasible if the socket can be created
again and dup when calling setOption().
I will try to reimplement MPTCP support using
jdk.net.ExtendingSocketOptions soon and give you feedback.
Thanks,
-Geliang
> so that the original AF_INET6/SOCK_STREAM/0 socket is closed.
> Enabling can be made to fail if the socket is already bound. It could
> copy over existing socket options if needed. Look at the built-in
> (and no longer used) SDP support for an example that does similar
> with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a
> socket option defined in jdk.net.ExtendingSocketOptions.
>
> -Alan
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Add Multipath TCP (MPTCP) Support to the Java Networking API
[not found] ` <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com>
2025-09-05 10:05 ` Geliang Tang
@ 2025-09-05 10:11 ` Geliang Tang
2025-09-18 7:36 ` Geliang Tang
1 sibling, 1 reply; 7+ messages in thread
From: Geliang Tang @ 2025-09-05 10:11 UTC (permalink / raw)
To: Alan Bateman, net-dev, nio-dev@openjdk.org
Cc: Matthieu Baerts, Mat Martineau, mptcp, Gang Yan, Xiang Gao,
core-libs-dev
Hi Alan,
Thanks for your reply.
On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote:
>
> On 05/09/2025 09:43, Geliang Tang wrote:
>
>
> >
> > :
> >
> > 3. Proposed Java API Changes
> >
> > The goal is to allow Java applications to opt-in to using MPTCP
> > when
> > creating sockets, without breaking existing code. The proposed
> > changes
> > are additive and backward-compatible.
> >
> > The core idea is to add a boolean mptcp parameter through the API
> > layers, from the public Socket class down to the native system
> > call.
> >
>
> (moving the discussion to nio-dev and net-dev).
>
> Adding new constructors to legacy Socket/ServerSocket may work for
> your initial prototype but would be problematic to propose as it
> would bake non-standard features into the standard API. Also many
> high performance servers use SocketChannel rather than Socket.
>
> One suggestion for a next prototype is to model the enablement of
> MultiPath TCP as as a JDK-specific socket option (see
> jdk.net.ExtendingSocketOptions). All of the standard APIs for
> networking sockets define a setOption method for setting socket
I was initially concerned that calling setOption() after Socket()
creation to convert TCP to MPTCP was too late. Creating an MPTCP socket
must be done during the socket() system call.
> options. If modeled as a socket option then enabling can create a new
> AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place
Until I saw here, it should be feasible if the socket can be created
again and dup when calling setOption().
I will try to reimplement MPTCP support using
jdk.net.ExtendingSocketOptions soon and give you feedback.
Thanks,
-Geliang
> so that the original AF_INET6/SOCK_STREAM/0 socket is closed.
> Enabling can be made to fail if the socket is already bound. It could
> copy over existing socket options if needed. Look at the built-in
> (and no longer used) SDP support for an example that does similar
> with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a
> socket option defined in jdk.net.ExtendingSocketOptions.
>
> -Alan
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Add Multipath TCP (MPTCP) Support to the Java Networking API
2025-09-05 10:11 ` Geliang Tang
@ 2025-09-18 7:36 ` Geliang Tang
[not found] ` <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com>
0 siblings, 1 reply; 7+ messages in thread
From: Geliang Tang @ 2025-09-18 7:36 UTC (permalink / raw)
To: Alan Bateman, net-dev, nio-dev@openjdk.org
Cc: Matthieu Baerts, Mat Martineau, mptcp, Gang Yan, Xiang Gao,
core-libs-dev
Hi Alan,
On Fri, 2025-09-05 at 18:11 +0800, Geliang Tang wrote:
> Hi Alan,
>
> Thanks for your reply.
>
> On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote:
> >
> > On 05/09/2025 09:43, Geliang Tang wrote:
> >
> >
> > >
> > > :
> > >
> > > 3. Proposed Java API Changes
> > >
> > > The goal is to allow Java applications to opt-in to using MPTCP
> > > when
> > > creating sockets, without breaking existing code. The proposed
> > > changes
> > > are additive and backward-compatible.
> > >
> > > The core idea is to add a boolean mptcp parameter through the API
> > > layers, from the public Socket class down to the native system
> > > call.
> > >
> >
> > (moving the discussion to nio-dev and net-dev).
> >
> > Adding new constructors to legacy Socket/ServerSocket may work for
> > your initial prototype but would be problematic to propose as it
> > would bake non-standard features into the standard API. Also many
> > high performance servers use SocketChannel rather than Socket.
> >
> > One suggestion for a next prototype is to model the enablement of
> > MultiPath TCP as as a JDK-specific socket option (see
> > jdk.net.ExtendingSocketOptions). All of the standard APIs for
> > networking sockets define a setOption method for setting socket
>
> I was initially concerned that calling setOption() after Socket()
> creation to convert TCP to MPTCP was too late. Creating an MPTCP
> socket
> must be done during the socket() system call.
>
> > options. If modeled as a socket option then enabling can create a
> > new
> > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into
> > place
>
> Until I saw here, it should be feasible if the socket can be created
> again and dup when calling setOption().
>
> I will try to reimplement MPTCP support using
> jdk.net.ExtendingSocketOptions soon and give you feedback.
I have completed the implementation. Thanks to Xiang Gao and Gang Yan
for their help. I added a new option named TCP_MPTCPIFY in
jdk.net.ExtendedSocketOptions (the name was chosen to align with
'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is
set, it calls the JNI function mptcpify0.
Following your suggestion, mptcpify0 is implemented by referencing
Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket,
uses dup2 to duplicate it, and then closes the redundant socket.
I have added your tag in the patch:
Suggested-by: Alan Bateman <alan.bateman@oracle.com>
I also included a test example for this option. All modifications can
be found here:
https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master
Please provide any feedback or suggestions. As for the next steps,
should I create a new issue for this feature and submit a proper pull
request?
Thanks,
-Geliang
>
> Thanks,
> -Geliang
>
> > so that the original AF_INET6/SOCK_STREAM/0 socket is closed.
> > Enabling can be made to fail if the socket is already bound. It
> > could
> > copy over existing socket options if needed. Look at the built-in
> > (and no longer used) SDP support for an example that does similar
> > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a
> > socket option defined in jdk.net.ExtendingSocketOptions.
> >
> > -Alan
> >
> >
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Add Multipath TCP (MPTCP) Support to the Java Networking API
[not found] ` <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com>
@ 2025-09-23 9:55 ` Geliang Tang
0 siblings, 0 replies; 7+ messages in thread
From: Geliang Tang @ 2025-09-23 9:55 UTC (permalink / raw)
To: Alan Bateman, net-dev, nio-dev@openjdk.org
Cc: Matthieu Baerts, Mat Martineau, mptcp, Gang Yan, Xiang Gao,
core-libs-dev
Hi Alan,
Thanks for your reply.
On Thu, 2025-09-18 at 12:30 +0100, Alan Bateman wrote:
>
> On 18/09/2025 08:36, Geliang Tang wrote:
>
> >
> > I have completed the implementation. Thanks to Xiang Gao and Gang
> > Yan
> > for their help. I added a new option named TCP_MPTCPIFY in
> > jdk.net.ExtendedSocketOptions (the name was chosen to align with
> > 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option
> > is
> > set, it calls the JNI function mptcpify0.
> >
> > Following your suggestion, mptcpify0 is implemented by referencing
> > Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP
> > socket,
> > uses dup2 to duplicate it, and then closes the redundant socket.
> >
> > I have added your tag in the patch:
> >
> > Suggested-by: Alan Bateman <alan.bateman@oracle.com>
> >
> > I also included a test example for this option. All modifications
> > can
> > be found here:
> >
> > https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master
> >
> > Please provide any feedback or suggestions. As for the next steps,
> > should I create a new issue for this feature and submit a proper
> > pull
> > request?
> >
>
> Thanks for confirming that the direction suggested works. This at
> least demonstrates a feasible direction that does not impact the
> standard API.
>
> As regards next steps then I think start a thread on net-dev to try
> to get input. I think it would be useful to show potential scenarios
> where it would be useful and what performance benefits might come
> from it. I think also useful to talk about whether this is something
> that an application has to opt into, maybe there are other
> configuration approaches that would not require application changes?
>
> I think it would be useful to discuss testing. If this feature were
> integrated into the JDK then how would it be tested? Who would test
> and maintain it? There is a JDK release every 6 months, is someone
> going test it with each release?
>
> If it goes ahead then there the name of the extended socket option
> and its API docs will need discussion. Details around state will need
> to be specified, would it be supported to set TCP_MPTCP when bound or
> connected, does it make sense to ever attempt to set it to false
> after setting it to true (these are just examples of the details that
> will need to be specified, they are not important right now).
Following your suggestion, I have started a new thread on net-dev:
Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK
https://mail.openjdk.org/pipermail/net-dev/2025-September/028085.html
Thanks,
-Geliang
>
> -Alan.
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-09-23 9:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-05 8:43 Add Multipath TCP (MPTCP) Support to the Java Networking API Geliang Tang
[not found] ` <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com>
2025-09-05 10:05 ` Geliang Tang
2025-09-05 10:11 ` Geliang Tang
2025-09-18 7:36 ` Geliang Tang
[not found] ` <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com>
2025-09-23 9:55 ` Geliang Tang
-- strict thread matches above, loose matches on Subject: below --
2025-09-05 1:43 Geliang Tang
2025-09-05 9:00 ` Geliang Tang
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.