patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Matan Azrad <matan@mellanox.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Jingjing Wu <jingjing.wu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 1/2] app/testpmd: fix scatter offload configuration
Date: Tue, 30 Jul 2019 16:21:52 +0100	[thread overview]
Message-ID: <93e46254-6d07-83d6-5999-04f9b0309dfd@intel.com> (raw)
In-Reply-To: <AM0PR0502MB40190225B9C89B48E89D5098D2DC0@AM0PR0502MB4019.eurprd05.prod.outlook.com>

On 7/30/2019 2:17 PM, Matan Azrad wrote:
> Hi Ferruh
> 
> From: Ferruh Yigit
>> Sent: Tuesday, July 30, 2019 4:09 PM
>> To: Matan Azrad <matan@mellanox.com>; Wenzhuo Lu
>> <wenzhuo.lu@intel.com>; Jingjing Wu <jingjing.wu@intel.com>
>> Cc: dev@dpdk.org; stable@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix scatter offload
>> configuration
>>
>> On 7/29/2019 1:36 PM, Matan Azrad wrote:
>>> When the mbuf data size cannot contain the maximum Rx packet length
>>> with the mbuf headroom, a packet should be scattered in more than one
>> mbuf.
>>>
>>> The application did not configure scatter offload in the above case.
>>>
>>> Enable the Rx scatter offload in the above case.
>>>
>>> Fixes: 33f9630fc23d ("app/testpmd: create mbuf based on max supported
>>> segments")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Matan Azrad <matan@mellanox.com>
>>
>> Deferring the patchset to next release, they were late anyway and not
>> actually fixing a defect, safer to defer than getting them in rc3.
> 
> Yes this patch came late for RC3 but it is a fix.
> 
> What are you concerns here?
> Why don't you think defect found?

First patch changes the behavior, when mbuf size is larger than configured size
and user didn't provided the scatter offload, should test application
automatically enable it? It may or not, but this is the change of the behavior,
I think not a fix.

And second patch adds more detail into the statistics, so I believe it is clear
that it is not a fix.

The concern is getting changes very close to release, to balance between risk
and benefit of the feature. I don't see any reason why these changes can't wait
next release, so I don't see any reason to get the risk.

> 
> What's about RC4?

No, it is even worse, there will be only a little testing after rc4 and a little
time before release.

  reply	other threads:[~2019-07-30 15:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 12:36 [dpdk-stable] " Matan Azrad
2019-07-30  9:00 ` [dpdk-stable] [dpdk-dev] " Matan Azrad
2019-07-30 11:36   ` Moti Haimovsky
2019-07-30 13:09 ` Ferruh Yigit
2019-07-30 13:17   ` Matan Azrad
2019-07-30 15:21     ` Ferruh Yigit [this message]
2019-07-30 15:56       ` Matan Azrad
2019-07-30 17:28         ` Ferruh Yigit
2019-07-30 18:34           ` Matan Azrad
2019-07-30 18:55             ` Ferruh Yigit
2019-07-31  6:11               ` Matan Azrad
2019-10-08 14:18                 ` Yigit, Ferruh
2019-10-22  7:06                   ` Matan Azrad

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=93e46254-6d07-83d6-5999-04f9b0309dfd@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    --cc=matan@mellanox.com \
    --cc=stable@dpdk.org \
    --cc=wenzhuo.lu@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).