All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Kevin Traynor <ktraynor@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Maxime Coquelin" <maxime.coquelin@redhat.com>,
	dev@dpdk.org, "Stephen Hemminger" <stephen@networkplumber.org>,
	qemu-devel@nongnu.org, libvir-list@redhat.com,
	vpp-dev@lists.fd.io,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: dpdk/vpp and cross-version migration for vhost
Date: Thu, 24 Nov 2016 20:33:04 +0800	[thread overview]
Message-ID: <20161124123304.GG5048@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <4d6e8cf0-fe19-43a9-ff73-c2a9cdeb681e@redhat.com>

On Thu, Nov 24, 2016 at 09:30:49AM +0000, Kevin Traynor wrote:
> On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
> > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
> >>>> You keep assuming that you have the VM started first and
> >>>> figure out things afterwards, but this does not work.
> >>>>
> >>>> Think about a cluster of machines. You want to start a VM in
> >>>> a way that will ensure compatibility with all hosts
> >>>> in a cluster.
> >>>
> >>> I see. I was more considering about the case when the dst
> >>> host (including the qemu and dpdk combo) is given, and
> >>> then determine whether it will be a successfull migration
> >>> or not.
> >>>
> >>> And you are asking that we need to know which host could
> >>> be a good candidate before starting the migration. In such
> >>> case, we indeed need some inputs from both the qemu and
> >>> vhost-user backend.
> >>>
> >>> For DPDK, I think it could be simple, just as you said, it
> >>> could be either a tiny script, or even a macro defined in
> >>> the source code file (we extend it every time we add a
> >>> new feature) to let the libvirt to read it. Or something
> >>> else.
> >>
> >> There's the issue of APIs that tweak features as Maxime
> >> suggested.
> > 
> > Yes, it's a good point.
> > 
> >> Maybe the only thing to do is to deprecate it,
> > 
> > Looks like so.
> > 
> >> but I feel some way for application to pass info into
> >> guest might be benefitial.
> > 
> > The two APIs are just for tweaking feature bits DPDK supports before
> > any device got connected. It's another way to disable some features
> > (the another obvious way is to through QEMU command lines).
> > 
> > IMO, it's bit handy only in a case like: we have bunch of VMs. Instead
> > of disabling something though qemu one by one, we could disable it
> > once in DPDK.
> > 
> > But I doubt the useful of it. It's only used in DPDK's vhost example
> > after all. Nor is it used in vhost pmd, neither is it used in OVS.
> 
> rte_vhost_feature_disable() is currently used in OVS, lib/netdev-dpdk.c

Hmmm. I must have checked very old code ...
> 
> netdev_dpdk_vhost_class_init(void)
> {
>     static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
> 
>     /* This function can be called for different classes.  The
> initialization
>      * needs to be done only once */
>     if (ovsthread_once_start(&once)) {
>         rte_vhost_driver_callback_register(&virtio_net_device_ops);
>         rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
>                                   | 1ULL << VIRTIO_NET_F_HOST_TSO6
>                                   | 1ULL << VIRTIO_NET_F_CSUM);

I saw the commit introduced such change, but it tells no reason why
it was added.

commit 362ca39639ae871806be5ae97d55e1cbb14afd92
Author: mweglicx <michalx.weglicki@intel.com>
Date:   Thu Apr 14 17:40:06 2016 +0100

    Update relevant artifacts to add support for DPDK 16.04.

    Following changes are applied:
     - INSTALL.DPDK.md: CONFIG_RTE_BUILD_COMBINE_LIBS step has been
       removed because it is no longer present in DPDK configuration
       (combined library is created by default),
     - INSTALL.DPDK.md: VHost Cuse configuration is updated,
     - netdev-dpdk.c: Link speed definition is changed in DPDK and
       netdev_dpdk_get_features is updated accordingly,
     - netdev-dpdk.c: TSO and checksum offload has been disabled for
       vhostuser device.
     - .travis/linux-build.sh: DPDK version is updated and legacy
       flags have been removed in configuration.

    Signed-off-by: Michal Weglicki <michalx.weglicki@intel.com>
    Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
    Acked-by: Daniele Di Proietto <diproiettod@vmware.com>

	--yliu

WARNING: multiple messages have this Message-ID (diff)
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Kevin Traynor <ktraynor@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Maxime Coquelin" <maxime.coquelin@redhat.com>,
	dev@dpdk.org, "Stephen Hemminger" <stephen@networkplumber.org>,
	qemu-devel@nongnu.org, libvir-list@redhat.com,
	vpp-dev@lists.fd.io,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [Qemu-devel] [dpdk-dev] dpdk/vpp and cross-version migration for vhost
Date: Thu, 24 Nov 2016 20:33:04 +0800	[thread overview]
Message-ID: <20161124123304.GG5048@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <4d6e8cf0-fe19-43a9-ff73-c2a9cdeb681e@redhat.com>

On Thu, Nov 24, 2016 at 09:30:49AM +0000, Kevin Traynor wrote:
> On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
> > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
> >>>> You keep assuming that you have the VM started first and
> >>>> figure out things afterwards, but this does not work.
> >>>>
> >>>> Think about a cluster of machines. You want to start a VM in
> >>>> a way that will ensure compatibility with all hosts
> >>>> in a cluster.
> >>>
> >>> I see. I was more considering about the case when the dst
> >>> host (including the qemu and dpdk combo) is given, and
> >>> then determine whether it will be a successfull migration
> >>> or not.
> >>>
> >>> And you are asking that we need to know which host could
> >>> be a good candidate before starting the migration. In such
> >>> case, we indeed need some inputs from both the qemu and
> >>> vhost-user backend.
> >>>
> >>> For DPDK, I think it could be simple, just as you said, it
> >>> could be either a tiny script, or even a macro defined in
> >>> the source code file (we extend it every time we add a
> >>> new feature) to let the libvirt to read it. Or something
> >>> else.
> >>
> >> There's the issue of APIs that tweak features as Maxime
> >> suggested.
> > 
> > Yes, it's a good point.
> > 
> >> Maybe the only thing to do is to deprecate it,
> > 
> > Looks like so.
> > 
> >> but I feel some way for application to pass info into
> >> guest might be benefitial.
> > 
> > The two APIs are just for tweaking feature bits DPDK supports before
> > any device got connected. It's another way to disable some features
> > (the another obvious way is to through QEMU command lines).
> > 
> > IMO, it's bit handy only in a case like: we have bunch of VMs. Instead
> > of disabling something though qemu one by one, we could disable it
> > once in DPDK.
> > 
> > But I doubt the useful of it. It's only used in DPDK's vhost example
> > after all. Nor is it used in vhost pmd, neither is it used in OVS.
> 
> rte_vhost_feature_disable() is currently used in OVS, lib/netdev-dpdk.c

Hmmm. I must have checked very old code ...
> 
> netdev_dpdk_vhost_class_init(void)
> {
>     static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
> 
>     /* This function can be called for different classes.  The
> initialization
>      * needs to be done only once */
>     if (ovsthread_once_start(&once)) {
>         rte_vhost_driver_callback_register(&virtio_net_device_ops);
>         rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
>                                   | 1ULL << VIRTIO_NET_F_HOST_TSO6
>                                   | 1ULL << VIRTIO_NET_F_CSUM);

I saw the commit introduced such change, but it tells no reason why
it was added.

commit 362ca39639ae871806be5ae97d55e1cbb14afd92
Author: mweglicx <michalx.weglicki@intel.com>
Date:   Thu Apr 14 17:40:06 2016 +0100

    Update relevant artifacts to add support for DPDK 16.04.

    Following changes are applied:
     - INSTALL.DPDK.md: CONFIG_RTE_BUILD_COMBINE_LIBS step has been
       removed because it is no longer present in DPDK configuration
       (combined library is created by default),
     - INSTALL.DPDK.md: VHost Cuse configuration is updated,
     - netdev-dpdk.c: Link speed definition is changed in DPDK and
       netdev_dpdk_get_features is updated accordingly,
     - netdev-dpdk.c: TSO and checksum offload has been disabled for
       vhostuser device.
     - .travis/linux-build.sh: DPDK version is updated and legacy
       flags have been removed in configuration.

    Signed-off-by: Michal Weglicki <michalx.weglicki@intel.com>
    Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
    Acked-by: Daniele Di Proietto <diproiettod@vmware.com>

	--yliu

  reply	other threads:[~2016-11-24 12:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 17:50 dpdk/vpp and cross-version migration for vhost Michael S. Tsirkin
2016-10-13 17:50 ` [Qemu-devel] " Michael S. Tsirkin
2016-11-16 20:43 ` Maxime Coquelin
2016-11-16 20:43   ` [Qemu-devel] " Maxime Coquelin
2016-11-17  8:29 ` Yuanhan Liu
2016-11-17  8:29   ` [Qemu-devel] " Yuanhan Liu
2016-11-17  8:47   ` Maxime Coquelin
2016-11-17  8:47     ` [Qemu-devel] " Maxime Coquelin
2016-11-17  9:49     ` Yuanhan Liu
2016-11-17  9:49       ` [Qemu-devel] " Yuanhan Liu
2016-11-17 15:25       ` [vpp-dev] " Thomas F Herbert
2016-11-17 15:25         ` [Qemu-devel] " Thomas F Herbert
2016-11-17 17:37       ` Michael S. Tsirkin
2016-11-17 17:37         ` [Qemu-devel] " Michael S. Tsirkin
2016-11-22 13:02         ` Yuanhan Liu
2016-11-22 13:02           ` [Qemu-devel] " Yuanhan Liu
2016-11-22 14:53           ` Michael S. Tsirkin
2016-11-22 14:53             ` [Qemu-devel] " Michael S. Tsirkin
2016-11-24  6:31             ` Yuanhan Liu
2016-11-24  6:31               ` [Qemu-devel] " Yuanhan Liu
2016-11-24  9:30               ` Kevin Traynor
2016-11-24  9:30                 ` [Qemu-devel] [dpdk-dev] " Kevin Traynor
2016-11-24 12:33                 ` Yuanhan Liu [this message]
2016-11-24 12:33                   ` Yuanhan Liu
2016-11-24 12:47                   ` Maxime Coquelin
2016-11-24 12:47                     ` [Qemu-devel] [dpdk-dev] " Maxime Coquelin
2016-11-24 15:01                     ` Kevin Traynor
2016-11-24 15:01                       ` [Qemu-devel] [dpdk-dev] " Kevin Traynor
2016-11-24 15:24                       ` Kavanagh, Mark B
2016-11-24 15:24                         ` [Qemu-devel] [dpdk-dev] " Kavanagh, Mark B
2016-11-28 15:28                         ` Maxime Coquelin
2016-11-28 15:28                           ` [Qemu-devel] [dpdk-dev] " Maxime Coquelin
2016-11-28 22:18                           ` Thomas Monjalon
2016-11-28 22:18                             ` [Qemu-devel] [dpdk-dev] " Thomas Monjalon
2016-11-29  8:09                             ` Maxime Coquelin
2016-11-29  8:09                               ` [Qemu-devel] [dpdk-dev] " Maxime Coquelin
2016-12-09 13:35               ` Maxime Coquelin
2016-12-09 13:35                 ` [Qemu-devel] " Maxime Coquelin
2016-12-09 14:42                 ` Daniel P. Berrange
2016-12-09 14:42                   ` [Qemu-devel] " Daniel P. Berrange
2016-12-09 16:45                   ` Maxime Coquelin
2016-12-09 16:45                     ` [Qemu-devel] " Maxime Coquelin
2016-12-09 16:48                     ` Daniel P. Berrange
2016-12-09 16:48                       ` [Qemu-devel] " Daniel P. Berrange

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=20161124123304.GG5048@yliu-dev.sh.intel.com \
    --to=yuanhan.liu@linux.intel.com \
    --cc=dev@dpdk.org \
    --cc=ktraynor@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stephen@networkplumber.org \
    --cc=vpp-dev@lists.fd.io \
    /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.