From: Cong Wang <xiyou.wangcong@gmail.com>
To: Dust Li <dust.li@linux.alibaba.com>
Cc: lsf-pc@lists.linux-foundation.org, bpf <bpf@vger.kernel.org>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
"a.mehrab@bytedance.com" <a.mehrab@bytedance.com>
Subject: Re: [LSF/MM/BPF TOPIC] Inter-VM Shared Memory Communications with eBPF
Date: Tue, 7 May 2024 10:18:34 -0700 [thread overview]
Message-ID: <ZjpiaoJsL1jH7Q+9@pop-os.localdomain> (raw)
In-Reply-To: <20240311095456.GA40084@linux.alibaba.com>
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@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
(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.
prev parent reply other threads:[~2024-05-07 17:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 23:05 [LSF/MM/BPF TOPIC] Inter-VM Shared Memory Communications with eBPF Cong Wang
2024-03-04 9:59 ` Dust Li
2024-03-08 3:52 ` Cong Wang
2024-03-11 9:54 ` Dust Li
2024-05-07 17:18 ` Cong Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjpiaoJsL1jH7Q+9@pop-os.localdomain \
--to=xiyou.wangcong@gmail.com \
--cc=a.mehrab@bytedance.com \
--cc=bpf@vger.kernel.org \
--cc=dust.li@linux.alibaba.com \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).