From: Patrik Andersson R <patrik.r.andersson@ericsson.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Yuanhan Liu" <yliu@fridaylinux.org>,
"Jianfeng Tan" <jianfeng.tan@intel.com>,
"Ágota Benyhe" <agota.benyhe@ericsson.com>
Subject: Re: [dpdk-dev] [PATCH v2] virtio_net: kick guest even when virtio queue is full
Date: Fri, 15 Dec 2017 11:29:22 +0000 [thread overview]
Message-ID: <VI1PR0702MB367706D6CA1B719091670A62B30A0@VI1PR0702MB3677.eurprd07.prod.outlook.com> (raw)
In-Reply-To: <0d909636-0757-b028-85b3-5ee9e1d8e637@redhat.com>
Hi Maxime,
apologies for the late answer.
Yes I would think that it would solve the problem that we had. But
there is a slight risk that a driver in a VM (not within our area of
influence) was partly responsible for the severity of the fault and
that we might again experience some difficulties even with your
change. Though the risk is likely to be very low.
However, if your patch protects the file descriptors when in use I
would consider that a better solution than doing the extra writes
on the full queue.
I would recommend going with your solution rather than the one
suggested by us.
Regards,
Patrik
Från: Maxime Coquelin <maxime.coquelin@redhat.com>
Skickat: den 8 december 2017 17:11
Till: Ágota Benyhe; dev@dpdk.org
Kopia: Patrik Andersson R; Yuanhan Liu; Jianfeng Tan
Ämne: Re: [dpdk-dev] [PATCH v2] virtio_net: kick guest even when virtio queue is full
Hi Agota, Patrick,
On 12/05/2017 12:30 PM, Agota Benyhe wrote:
> From: Patrik Andersson R<patrik.r.andersson@ericsson.com>
>
> Changing the vring call file descriptor during virtio device enqueue
> operation may lead to "kick" on a file descriptor that is closed. As
> a consequence the guest might not be notified of new packets in the
> enqueue.
>
> The suggested change will add some extra load on DPDK and on the
> guest if the queue is frequently full. Any application using DPDK
> should avoid attempting retransmissions when the zero packets are
> enqueued.
>
> To overcome this problem, the kick operation in virtio_dev_merge_rx()
> was excluded from the pkt_idx > 0 condition. A similar change was
> done in virtio_dev_rx().
>
> Signed-off-by: Patrik Andersson R<patrik.r.andersson@ericsson.com>
> Signed-off-by: Agota Benyhe<agota.benyhe@ericsson.com>
> ---
> lib/librte_vhost/virtio_net.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
We are working on a patch that protects enqueue & dequeue paths from
vhost-user requests handling.
For your case, it would protect call_fd to be changed while vring is
being processed by the PMD thread.
Do you think that would solve the problem you are facing?
Regards,
Maxime
prev parent reply other threads:[~2017-12-15 11:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 9:07 [dpdk-dev] [PATCH] " Agota Benyhe
2017-12-05 11:30 ` [dpdk-dev] [PATCH v2] " Agota Benyhe
2017-12-08 16:11 ` Maxime Coquelin
2017-12-15 11:29 ` Patrik Andersson R [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=VI1PR0702MB367706D6CA1B719091670A62B30A0@VI1PR0702MB3677.eurprd07.prod.outlook.com \
--to=patrik.r.andersson@ericsson.com \
--cc=agota.benyhe@ericsson.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=yliu@fridaylinux.org \
/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 NNTP newsgroup(s).