From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Kavanagh, Mark B" <mark.b.kavanagh@intel.com>,
Kevin Traynor <ktraynor@redhat.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
"Weglicki, MichalX" <michalx.weglicki@intel.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"libvir-list@redhat.com" <libvir-list@redhat.com>,
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [dpdk-dev] dpdk/vpp and cross-version migration for vhost
Date: Mon, 28 Nov 2016 16:28:58 +0100 [thread overview]
Message-ID: <67cfb109-8729-916e-5535-80af620bafe5@redhat.com> (raw)
In-Reply-To: <DC5AD7FA266D86499789B1BCAEC715F85C75B841@irsmsx105.ger.corp.intel.com>
On 11/24/2016 04:24 PM, Kavanagh, Mark B wrote:
>>
>> On 11/24/2016 12:47 PM, Maxime Coquelin wrote:
>>>
>>>
>>> On 11/24/2016 01:33 PM, Yuanhan Liu wrote:
>>>> 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.
>>>
>>> I'm also interested to know the reason.
>>
>> I can't remember off hand, added Mark K or Michal W who should be able
>> to shed some light on it.
>
> DPDK v16.04 added support for vHost User TSO; as such, by default, TSO is advertised to guest devices as an available feature during feature negotiation with QEMU.
> However, while the vHost user backend sets up the majority of the mbuf fields that are required for TSO, there is still a reliance on the associated DPDK application (i.e. in this case OvS-DPDK) to set the remaining flags and/or offsets. Since OvS-DPDK doesn't currently provide that functionality, it is necessary to explicitly disable TSO; otherwise, undefined behaviour will ensue.
Thanks Mark for the clarification.
In this case, maybe we could add a DPDK build option to disable Vhost's
TSO support, that would be selected for OVS packages?
Does that sound reasonable?
Cheers,
Maxime
>>
>>> In any case, I think this is something that can/should be managed by
>>> the management tool, which should disable it in cmd parameters.
>>>
>>> Kevin, do you agree?
>>
>> I think best to find out the reason first. Because if no reason to
>> disable in the code, then no need to debate!
>>
>>>
>>> Cheers,
>>> Maxime
>
next prev parent reply other threads:[~2016-11-28 15:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 17:50 Michael S. Tsirkin
2016-11-16 20:43 ` Maxime Coquelin
2016-11-17 8:29 ` Yuanhan Liu
2016-11-17 8:47 ` Maxime Coquelin
2016-11-17 9:49 ` Yuanhan Liu
2016-11-17 15:25 ` [dpdk-dev] [vpp-dev] " Thomas F Herbert
2016-11-17 17:37 ` [dpdk-dev] " Michael S. Tsirkin
2016-11-22 13:02 ` Yuanhan Liu
2016-11-22 14:53 ` Michael S. Tsirkin
2016-11-24 6:31 ` Yuanhan Liu
2016-11-24 9:30 ` Kevin Traynor
2016-11-24 12:33 ` Yuanhan Liu
2016-11-24 12:47 ` Maxime Coquelin
2016-11-24 15:01 ` Kevin Traynor
2016-11-24 15:24 ` Kavanagh, Mark B
2016-11-28 15:28 ` Maxime Coquelin [this message]
2016-11-28 22:18 ` Thomas Monjalon
2016-11-29 8:09 ` Maxime Coquelin
2016-12-09 13:35 ` Maxime Coquelin
2016-12-09 14:42 ` Daniel P. Berrange
2016-12-09 16:45 ` Maxime Coquelin
2016-12-09 16:48 ` 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=67cfb109-8729-916e-5535-80af620bafe5@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=dev@dpdk.org \
--cc=ktraynor@redhat.com \
--cc=libvir-list@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mark.b.kavanagh@intel.com \
--cc=michalx.weglicki@intel.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen@networkplumber.org \
--cc=vpp-dev@lists.fd.io \
--cc=yuanhan.liu@linux.intel.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 NNTP newsgroup(s).