[net-next,0/2] Introduce IPPROTO_SMC

Message

D. Wythe May 10, 2024, 4:12 a.m. UTC

From: "D. Wythe" <[e-mail]>

This patch allows to create smc socket via AF_INET,
similar to the following code,

/* create v4 smc sock */
v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_SMC);

/* create v6 smc sock */
v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_SMC);

There are several reasons why we believe it is appropriate here:

1. For smc sockets, it actually use IPv4 (AF-INET) or IPv6 (AF-INET6)
address. There is no AF_SMC address at all.

2. Create smc socket in the AF_INET(6) path, which allows us to reuse
the infrastructure of AF_INET(6) path, such as common ebpf hooks.
Otherwise, smc have to implement it again in AF_SMC path. Such as:
  1. Replace IPPROTO_TCP with IPPROTO_SMC in the socket() syscall
     initiated by the user, without the use of LD-PRELOAD.
  2. Select whether immediate fallback is required based on peer's port/ip
     before connect().

A very significant result is that we can now use eBPF to implement smc_run
instead of LD_PRELOAD, who is completely ineffective in scenarios of static
linking.

Another potential value is that we are attempting to optimize the performance of
fallback socks, where merging socks is an important part, and it relies on the
creation of SMC sockets under the AF_INET path. (More information :
https://lore.kernel.org/netdev/[e-mail]/T/)

D. Wythe (2):
  net/smc: refatoring initialization of smc sock
  net/smc: Introduce IPPROTO_SMC

 include/uapi/linux/in.h |   2 +
 net/smc/af_smc.c        | 222 +++++++++++++++++++++++++++++++++++++++---------
 net/smc/inet_smc.h      |  32 +++++++
 3 files changed, 214 insertions(+), 42 deletions(-)
 create mode 100644 net/smc/inet_smc.h

Comments

D. Wythe May 10, 2024, 9:14 a.m. UTC | #1

On 5/10/24 12:12 PM, D. Wythe wrote:
> From: "D. Wythe" <[e-mail]>
>
> This patch allows to create smc socket via AF_INET,
> similar to the following code,
>
> /* create v4 smc sock */
> v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_SMC);

A eBPF version of smc_run is also available here:

https://github.com/D-Wythe/smc-tools/tree/ipproto_smc

You can test IPPROTO_SMC by script:

   smc_run.pid COMMAND

While you can still test AF_SMC by script:

   smc_run COMMAND

D. Wythe

Wenjia Zhang May 10, 2024, 10:22 a.m. UTC | #2

On 10.05.24 06:12, D. Wythe wrote:
> From: "D. Wythe" <[e-mail]>
> 
> This patch allows to create smc socket via AF_INET,
> similar to the following code,
> 
> /* create v4 smc sock */
> v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_SMC);
> 
> /* create v6 smc sock */
> v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_SMC);
> 
> There are several reasons why we believe it is appropriate here:
> 
> 1. For smc sockets, it actually use IPv4 (AF-INET) or IPv6 (AF-INET6)
> address. There is no AF_SMC address at all.
> 
> 2. Create smc socket in the AF_INET(6) path, which allows us to reuse
> the infrastructure of AF_INET(6) path, such as common ebpf hooks.
> Otherwise, smc have to implement it again in AF_SMC path. Such as:
>    1. Replace IPPROTO_TCP with IPPROTO_SMC in the socket() syscall
>       initiated by the user, without the use of LD-PRELOAD.
>    2. Select whether immediate fallback is required based on peer's port/ip
>       before connect().
> 
> A very significant result is that we can now use eBPF to implement smc_run
> instead of LD_PRELOAD, who is completely ineffective in scenarios of static
> linking.
> 

> Another potential value is that we are attempting to optimize the performance of
> fallback socks, where merging socks is an important part, and it relies on the
> creation of SMC sockets under the AF_INET path. (More information :
> https://lore.kernel.org/netdev/[e-mail]/T/)
> 
> D. Wythe (2):
>    net/smc: refatoring initialization of smc sock
>    net/smc: Introduce IPPROTO_SMC
> 
>   include/uapi/linux/in.h |   2 +
>   net/smc/af_smc.c        | 222 +++++++++++++++++++++++++++++++++++++++---------
>   net/smc/inet_smc.h      |  32 +++++++
>   3 files changed, 214 insertions(+), 42 deletions(-)
>   create mode 100644 net/smc/inet_smc.h
> 
Replacing the preload library is indeed a good reason for this method. 
And that could be a new era for smc. However, there are still some 
details we need to take care of. Thus, I'd like to ask for more time to 
review and test these patches.

Thank you,
Wenjia