DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
	"Kavanagh, Mark B" <mark.b.kavanagh@intel.com>,
	Kevin Traynor <ktraynor@redhat.com>,
	Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: dev@dpdk.org, "Weglicki, MichalX" <michalx.weglicki@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"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>,
	olivier.matz@6wind.com
Subject: Re: [dpdk-dev] dpdk/vpp and cross-version migration for vhost
Date: Tue, 29 Nov 2016 09:09:58 +0100	[thread overview]
Message-ID: <8df88bf1-cd59-74e8-5d18-7bb8ee05ff27@redhat.com> (raw)
In-Reply-To: <5176838.Upmb1ZYUhB@xps13>



On 11/28/2016 11:18 PM, Thomas Monjalon wrote:
> 2016-11-28 16:28, Maxime Coquelin:
>> On 11/24/2016 04:24 PM, Kavanagh, Mark B wrote:
>>> 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?
>
> Why do you prefer a build-time option rather than the run-time config
> with rte_vhost_feature_disable()? Because we need to lock the features?

Right, we need to know what the backend supports before it is started,
so that management tool can check where it could be migrated to.

>
> Reminder: build-time configuration options are forbidden in DPDK for
> such usage. It would prevent other applications from using the feature
> in a given distribution, just because it is not implemented in OVS.

I understand, this is not the right solution.
I proposed this because I misunderstood how the distributions package
OVS+DPDK.

>
>> Does that sound reasonable?
>
> Maybe I'm missing something but I feel it is more reasonnable to implement
> the missing code in OVS.

Yes, that would be the ideal solution.
OVS implements TSO and we let management tool decide whether or not
enabling the features.

While this is done, we could deprecate rte_vhost_feature_disable, and
print error message notifying the user it should be done my the
management tool.

> If something is missing in DPDK, do not hesitate to request or add more
> helper functions.

Sure.

Thanks,
Maxime

  reply	other threads:[~2016-11-29  8:10 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
2016-11-28 22:18                           ` Thomas Monjalon
2016-11-29  8:09                             ` Maxime Coquelin [this message]
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=8df88bf1-cd59-74e8-5d18-7bb8ee05ff27@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=olivier.matz@6wind.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas.monjalon@6wind.com \
    --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).