On Mon, Mar 11, 2024 at 05:54:56PM +0800, Dust Li wrote: > On Thu, Mar 07, 2024 at 07:52:52PM -0800, Cong Wang wrote: > >On Mon, Mar 4, 2024 at 1:59 AM Dust Li <dust.li@xxxxxxxxxxxxxxxxx> wrote: > >> > >> On Fri, Feb 23, 2024 at 03:05:59PM -0800, Cong Wang wrote: > >> > >> Hi Cong, > >> > >> This is a good topic ! > >> We have proposed another solution to accelerate Inter-VM tcp/ip communication > >> transparently within the same host based on SMC-D + virtio-ism > >> https://lists.oasis-open.org/archives/virtio-comment/202212/msg00030.html > >> > >> I don't know, can we do better with your proposal ? > > > >We knew SMC and it _is_ actually why I have this eBPF based proposal. > >Sorry for not providing more details here, since I just want to keep > >this proposal > >brief and will certain have all the details in our presentation if our > >proposal gets > >accepted. > > > >The main problem of SMC is it is not fully transparent, LD_PRELOAD could > >work for most cases but not all. Therefore, I don't think introducing any new > >socket family is in the right direction at all. > > Actually, this is not really true. We have introduce several ways to solve > this. The best way I think is to support IPPROTO_SMC[1] in SMC and using the > same eBPF infrastructure as MPTCP has already contributed[2]. > > [1] https://lore.kernel.org/netdev/20231113045758.GB121324@xxxxxxxxxxxxxxxxx > [2] https://lore.kernel.org/all/cover.1692147782.git.geliang.tang@xxxxxxxx (Sorry for missing your email.) I think this is wrong, basically and literally speaking, it is saying "you want to use a kernel module to replace another kernel module with eBPF as a trigger". The trigger itself could not function at all without the actual module which provides the implementation. Nor it works for kernel sockets, you need to think about NVMe-oF which is a very legitimate case since it supports both TCP and RDMA. Unlike SMC, all those eBPF components we need here can be easily used independently for any other purposes. Neither sockmap nor sockops (not even ivmshem) is designed for this specific case, we just combine and reuse them. I hope now you could see how and why flexibilities matter. We prefer eBPF not because it is cool or new, it is because of this kind of flexibility. BTW, its granularity is less ideal than sockops which is per container. Thanks.
