From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Jiang Wang ." <jiang.wang@bytedance.com>
Cc: cong.wang@bytedance.com,
Xiongchun Duan <duanxiongchun@bytedance.com>,
imbrenda@linux.vnet.ibm.com, xieyongji@bytedance.com,
stefanha@redhat.com, asias@redhat.com,
virtualization@lists.linux-foundation.org
Subject: Re: [External] Re: vsock virtio: questions about supporting DGRAM type
Date: Sun, 14 Mar 2021 18:19:40 -0400 [thread overview]
Message-ID: <20210314181308-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAP_N_Z-Y+a9mHH8GCqnaR=ZP9gQiu26Op35oZWm2LHkvCQ7=qg@mail.gmail.com>
On Thu, Mar 11, 2021 at 08:57:08PM -0800, Jiang Wang . wrote:
> Hi Michael,
>
> Sorry for the late reply. I just saw your email yesterday somehow.
>
> I read the email thread you mentioned, and I think the issue with
> dgram is that it may drop packets because the sender cannot track the
> tx_cnt with subtracting it from peer_fwd_cnt.
>
> I agree with Stefan that the dgram is a best-effort service and may
> drop packets. For the sender, I just add a maximum buffer size to
> limit the memory usage. On the receiving side, I reuse the existing
> virtio_transport_inc_rx_pkt() that Stefano added a year ago to limit
> the memory usage. This will avoid denial of service attack to the
> other end (host or guest VM).
>
> For the application of dgram, we will use it for some remote logging
> application. The application running in the VM will write some logs to
> a server running on the host. This is one way communication and the
> log is not critical.
>
> Regards,
>
> Jiang
To make things short, please submit to the virtio TC a spec patch
documenting how is dgram supposed to work and we'll discuss. The
existing mechanism was designed with a stream socket in mind. dgram is
best-effort but some fairness could be a quality of implementation
issue. I appreciate that your specific application might not care about
such concerns but we do need to worry about building a widely reuseable
interface as opposed to a very narrow one.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
prev parent reply other threads:[~2021-03-14 22:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-12 6:04 vsock virtio: questions about supporting DGRAM type Jiang Wang .
2021-02-12 9:02 ` Stefano Garzarella
2021-02-13 23:26 ` [External] " Jiang Wang .
2021-02-15 8:31 ` Stefano Garzarella
2021-02-16 4:50 ` Jiang Wang .
2021-02-16 8:09 ` Stefano Garzarella
2021-02-16 8:23 ` Jiang Wang .
2021-02-16 8:50 ` Stefano Garzarella
2021-02-16 16:54 ` Jiang Wang .
[not found] ` <e62051f4-e65d-4967-da5c-50ea76f2c783@kaspersky.com>
2021-02-13 23:46 ` Jiang Wang .
[not found] ` <f6dd1500-53cf-afb0-ec3c-47de57f8490f@kaspersky.com>
2021-02-16 5:43 ` Jiang Wang .
2021-02-23 9:53 ` Michael S. Tsirkin
2021-03-12 4:57 ` [External] " Jiang Wang .
2021-03-14 22:19 ` Michael S. Tsirkin [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=20210314181308-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=asias@redhat.com \
--cc=cong.wang@bytedance.com \
--cc=duanxiongchun@bytedance.com \
--cc=imbrenda@linux.vnet.ibm.com \
--cc=jiang.wang@bytedance.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xieyongji@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.