On Mon, Jan 13, 2025 at 07:49:44PM +0800, Dust Li wrote:
> On 2025-01-07 12:17:12, D. Wythe wrote:
> >The introduction of IPPROTO_SMC enables eBPF programs to determine
> >whether to use SMC based on the context of socket creation, such as
> >network namespaces, PID and comm name, etc.
> >
> >As a subsequent enhancement, to introduce a new generic hook that
> >allows decisions on whether to use SMC or not at runtime, including
> >but not limited to local/remote IP address or ports.
> >
> >Moreover, in the future, we can achieve more complex extensions to the
> >protocol stack by extending this ops.
> >
> >Signed-off-by: D. Wythe <alibuda@xxxxxxxxxxxxxxxxx>
> >---
> > include/net/netns/smc.h | 3 ++
> > include/net/smc.h | 51 ++++++++++++++++++++++
> > net/ipv4/tcp_output.c | 15 +++++--
> > net/smc/Kconfig | 12 ++++++
> > net/smc/Makefile | 1 +
> > net/smc/smc_ops.c | 51 ++++++++++++++++++++++
> > net/smc/smc_ops.h | 25 +++++++++++
> > net/smc/smc_sysctl.c | 95 +++++++++++++++++++++++++++++++++++++++++
> > 8 files changed, 249 insertions(+), 4 deletions(-)
> > create mode 100644 net/smc/smc_ops.c
> > create mode 100644 net/smc/smc_ops.h
> >
> >+
> >+struct smc_ops {
>
> One more thing.
> Can we call it smc_bpf_ops ? I think smc_ops is a bit ambiguous.
> Same for smc_ops.h/c source file.
I don't think smc_bpf_ops is a good idea. BPF is just a way to implement
smc_ops. Similarly, we can also implement this ops within the kernel module,
just like tcp_congestion_ops dose. If you think this is ambiguous, perhaps
we can call it as smc_handshake_ops ? This should eliminate the ambiguity.
Best wishes,
D. Wythe
>
> Best regards,
> Dust
