Hi Leyi,
On 6/6/19 7:44 AM, Rong, Leyi wrote:
-----Original Message-----
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Wednesday, June 5, 2019 12:56 AM
To: Rong, Leyi <leyi.r...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com>
Cc: dev@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,
Maxime
Best Regards,
Leyi Rong
