Re: [LSF/MM/BPF TOPIC] Inter-VM Shared Memory Communications with eBPF

[Dust Li <dust.li@linux.alibaba.com>]

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@linux.alibaba.com> 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@linux.alibaba.com
[2] https://lore.kernel.org/all/cover.1692147782.git.geliang.tang@suse.com

>
>(There are some other problems with SMC too, for instance, it requires more
>than a 3-way handshake.)

Right, but I don't see much performance penalty because of the extra handshake,
setting up the share memory is always the slowest part in a share memory
communication model.

>
>And I don't think there is any conflict or overlap here at all. Our eBPF-based
>solution relies on the existing inter-VM shared memory, no matter it is ivshmem
>or virtio-ism. We don't propose any new way of sharing memory, what we
>propose is merely using an existing one and building our solution on top.
>
>In fact, we believe our solution can be on top of your virtio-ism,
>since it is just
>another flat memory region from our point of view.
>
>Hope this helps.

Don't get me wrong, I'm not against to your proposal at all, I like it.
I just hope different solutions can be seen.

Best regards,
Dust

>
>Thanks.