[dpdk-dev] [PATCH 00/49] shared code update

Maxime Coquelin maxime.coquelin at redhat.com
Fri Jun 7 14:53:19 CEST 2019

Hi Leyi,

On 6/6/19 7:44 AM, Rong, Leyi wrote:
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com]
>> Sent: Wednesday, June 5, 2019 12:56 AM
>> To: Rong, Leyi <leyi.rong at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 00/49] shared code update
>> Hi Leyi,
>> On 6/4/19 7:41 AM, Leyi Rong wrote:
>>> Main changes:
>>> 1. Advanced switch rule support.
>>> 2. Add more APIs for tunnel management.
>>> 3. Add some minor features.
>>> 4. Code clean and bug fix.
>> In order to ease the review process, I think it would be much better to split this series in multiple ones, by features.
>> Otherwise, it is more difficult to keep track if comments are taken into account in the next revision.
>> Also, it is suggested to put the fixes first in the series to ease the backporting.
>> Thanks,
>> Maxime
> +Paul,
> Hello Maxime,
> Thanks for all your constructive comments, but we do the same process for the CVL shared code update to DPDK upstream on the previous release.
> This series of patches are extracted/reorganized/squashed from the ND released packages, which the shared code difference between 1905 and 1908 can be more than 200 commits from the original shared code repo.
> IMHO, there might be some reasons for take all these patches into one patchset.
> 	- the patchset try to keeps the history order as the commits in the original shared code repo.
> 	- the relatively behind patch in the patchset may have dependency on the front patches.
> 	- it's difficult to split this series into multiple ones, since the patches are irregular and squashed.

On the other hand, it means we should just apply the series without even
reviewing it as it would not be taken into account.

I personally think this is not a sane practice.

This is not the case of this series, which is almost good to me except
some missing errors handling, but imagine there is a security issue in
it, should we just apply it as-is not to diverge from your internal code
base and wait for the next shared code release to get the fix?

Note that my comment is not intended at Intel drivers specifically, as
it seems a common practice to have the base driver not reviewed and
applied as-is.

Best regards,
> Best Regards,
> Leyi Rong

More information about the dev mailing list