DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Matan Azrad <matan@mellanox.com>, Noa Ezra <noae@mellanox.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Tiwei Bie <tiwei.bie@intel.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] net/vhost: support mrg-rxbuf disabling
Date: Fri, 30 Aug 2019 10:48:51 +0200	[thread overview]
Message-ID: <9369dfc4-c666-f4ce-524a-4dc6ba4ea7ab@redhat.com> (raw)
In-Reply-To: <AM0PR0502MB40190E1077A86488A282E416D2FD0@AM0PR0502MB4019.eurprd05.prod.outlook.com>



On 6/27/19 7:04 AM, Matan Azrad wrote:
> 
> 
> From: Maxime Coquelin 
>>>>>> For functional reasons, I agree. So I that's why I agree with your
>>>>>> tso patch as the application has to support it, but that's not the
>>>>>> case of the mergeable buffers features.
>>>>>
>>>>> Performance reasons are not good enough?
>>>>
>>>> No, that's not what I mean.
>>>> I mean that the application should be able to disable a feature when
>>>> it does not meet the functional requirement.
>>>>
>>>> For performance tuning, the qemu way is available, and enough.
>>>>
>>>
>>> I think that this is the point we are not agree on.
>>>
>>> I think that application may want to disable the feature in some cases
>>> because of performance reasons (maybe others too), And in some other
>> cases to work with the feature.
>>>
>>> So, it makes sense IMO to let the application to decide what it wants
>> without any concern about the QEMU configuration.
>>>
>>> Why to not allow to the PMD user to do it by the application (using prob
>> parameters)?
>>
>> I think we should restrict the Virtio features from the Vhost PMD parameter
>> at as min as possible, only to ensure compatibility with the application
>> (iommu, postcopy, tso, ...). One problem I see with providing the possibility
>> to change any Virtio feature at runtime is reconnection.
>>
>> For example, you start your application with enabling mergeable buffers,
>> stop it and restart it without the feature enabled by the application.
>> As the negotiation with the driver is not done again at reconnect time, Qemu
>> will fail.
> 
> Looks like you are describing a new issue in the vhost PMD, it must close the connection when the PMD is closed\removed.
> So, every probe(hotplug add) it will start from scratch.
> 

No, you can close the application and restart it for example without
having to restart the guest. In this case, the feature negotiation is
not done again.

So I remain convinced we should not provide the possibility to disable
any feature that is not dependent on the application.

Megeable buffers is not dependent on the application, as it is only
related to the ring implementation, and it is supported by the DPDK
Vhost library.

Regards,
Maxime

  reply	other threads:[~2019-08-30  8:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19  6:13 [dpdk-dev] [PATCH 0/2] support tso and " Noa Ezra
2019-06-19  6:13 ` [dpdk-dev] [PATCH 1/2] net/vhost: support TSO disabling Noa Ezra
2019-06-19  9:53   ` Maxime Coquelin
2019-06-20  2:26     ` Tiwei Bie
2019-06-20  6:08       ` Matan Azrad
2019-06-20  7:25         ` Maxime Coquelin
2019-08-30  8:44   ` Maxime Coquelin
2019-09-30  9:02   ` Maxime Coquelin
2019-06-19  6:13 ` [dpdk-dev] [PATCH 2/2] net/vhost: support mrg-rxbuf disabling Noa Ezra
2019-06-19  9:10   ` Maxime Coquelin
2019-06-20  5:57     ` Noa Ezra
2019-06-20  6:52       ` Matan Azrad
2019-06-20  7:19         ` Maxime Coquelin
2019-06-20  7:55           ` Matan Azrad
2019-06-26  7:50             ` Matan Azrad
2019-06-26 10:27               ` Maxime Coquelin
2019-06-26 11:18                 ` Matan Azrad
2019-06-26 12:05                   ` Maxime Coquelin
2019-06-26 13:24                     ` Matan Azrad
2019-06-26 14:17                       ` Maxime Coquelin
2019-06-27  5:04                         ` Matan Azrad
2019-08-30  8:48                           ` Maxime Coquelin [this message]
2019-06-20  7:27       ` Maxime Coquelin
2019-09-30  9:04   ` Maxime Coquelin
2019-06-19 14:20 ` [dpdk-dev] [PATCH 0/2] support tso and " Aaron Conole

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=9369dfc4-c666-f4ce-524a-4dc6ba4ea7ab@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=dev@dpdk.org \
    --cc=matan@mellanox.com \
    --cc=noae@mellanox.com \
    --cc=tiwei.bie@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).