From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: souvikdey33 <sodey@sonusnet.com>,
stephen@networkplumber.org, huawei.xie@intel.com, dev@dpdk.org
Subject: Re: [PATCH v2] add mtu set in virtio
Date: Thu, 8 Sep 2016 15:30:29 +0800 [thread overview]
Message-ID: <20160908073029.GM23158@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <d141aa3a-e024-19ac-fe99-a9ea07002ce4@redhat.com>
On Wed, Sep 07, 2016 at 11:16:47AM +0200, Maxime Coquelin wrote:
>
>
> On 09/07/2016 05:25 AM, Yuanhan Liu wrote:
> >On Tue, Aug 30, 2016 at 09:57:39AM +0200, Maxime Coquelin wrote:
> >>Hi Souvik,
> >>
> >>On 08/30/2016 01:02 AM, souvikdey33 wrote:
> >>>Signed-off-by: Souvik Dey <sodey@sonusnet.com>
> >>>
> >>>Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>")
> >>>Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
> >>>
> >>>Virtio interfaces should also support setting of mtu, as in case of cloud
> >>>it is expected to have the consistent mtu across the infrastructure that
> >>>the dhcp server sends and not hardcoded to 1500(default).
> >>>---
> >>>drivers/net/virtio/virtio_ethdev.c | 12 ++++++++++++
> >>>1 file changed, 12 insertions(+)
> >>
> >>FYI, there are some on-going changes in the VIRTIO specification
> >>so that the VHOST interface exposes its MTU to its VIRTIO peer.
> >>It may also be used as an alternative of what you patch achieves.
> >>
> >>I am working on its implementation in Qemu/DPDK, our goal being to
> >>reduce performance drops for small packets with Rx mergeable buffers
> >>feature enabled.
> >
> >Mind to educate me a bit on how that works?
>
> Of course.
>
> Basically, this is a way to advise the MTU we want in the guest.
> In the guest, if GRO is not enabled:
> - In case of Kernel virtio-net, it could be used to
> size the SKBs at the expected MTU. If possible, we could disable Rx
> mergeable buffers.
> - In case of virtio PMD, if the MTU advised by host is lower than the
> pre-allocated mbuf size for the receive queue, then we should not need
> mergeable buffers.
Thanks for the explanation!
I see. So, the point is to avoid using mergeable buffers while it is
enabled.
> Does that sound reasonnable?
Yeah, maybe. Just don't know how well it may work in real life. Have
you got any rought data so far?
--yliu
> Do I miss something?
>
> Thanks,
> Maxime
next prev parent reply other threads:[~2016-09-08 7:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 23:02 [PATCH v2] add mtu set in virtio souvikdey33
2016-08-30 7:57 ` Maxime Coquelin
2016-09-01 22:20 ` Dey, Souvik
2016-09-02 7:05 ` Maxime Coquelin
2016-09-07 2:11 ` Dey, Souvik
2016-09-07 8:28 ` Maxime Coquelin
2016-09-07 3:25 ` Yuanhan Liu
2016-09-07 9:16 ` Maxime Coquelin
2016-09-08 7:30 ` Yuanhan Liu [this message]
2016-09-08 7:50 ` Maxime Coquelin
2016-09-08 7:57 ` Yuanhan Liu
2016-09-09 3:44 ` Dey, Souvik
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=20160908073029.GM23158@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=huawei.xie@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=sodey@sonusnet.com \
--cc=stephen@networkplumber.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 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.