[dpdk-dev] [dpdk-techboard] [PATCH] doc: update contribution guideline for dependent work

[Olivier MATZ]

On Tue, Dec 12, 2017 at 10:57:48AM -0800, Ferruh Yigit wrote:
> On 12/12/2017 7:54 AM, Olivier MATZ wrote:
> > Hi,
> > 
> > On Mon, Dec 11, 2017 at 02:26:34PM +0000, Mcnamara, John wrote:
> >> From: Yigit, Ferruh
> >>> Changing some part of the libraries but not updating all dependent code
> >>> cause maintenance problems.
> >>>
> >>> ...
> >>>
> >>> Signed-off-by: Ferruh Yigit <ferruh.yigit at intel.com>
> >>>
> >>
> >>
> >> integration testing.
> >>>
> >>> +* If changes effect other parts of the project, update all those parts as
> >>> well unless updating requires special knowledge.
> > 
> > I feel that "requiring special knowledge" is a bit blury. 
> 
> Yes it is, but hard to define where to put the line. My point is if author has
> enough knowledge to go and update dependent part, please do so.
> 
> > Shouldn't we add some
> > examples? Typically, I'm thinking about changes in ethdev that imply updating
> > the PMDs. Any opinion for this use case?
> 
> Overall many libraries to PMDs fit into this. eal/mbuf/ethdev -> PMD changes.
> 
> I think, the dynamic logging update in the other libraries and PMDs should be
> done with the original patch, adding dynamic logging to any library doesn't
> require library specific information, but agree this is more work.

Being the author of this patchset, I can give my feeling in this particular
case. That's right adding dynamic logging to all libraries may not require
to know the specifics or the library.

I did these changes to help me while debugging the i40e driver. Once
done, it was worth doing clean EAL upstreamable patches to lay the
foundations for a generic dynamic logging system in DPDK. If I had to do
the work for all the libraries, I would not have done it, because it was
really out of scope of my task.

So the choice was between having nothing, or having something which is
not much used at first, but can be more widely adopted over time.

That said, I understand that the problem with the second approach is to
stay for too long in a situation where the old system is used.

> For new ethdev offload method, I believe it fits into more gray area, it may be
> possible to update PMDs to use new offloading method but some part PMDs can be
> challenging.
> 
> Converting flow director filtering to the rte_flow filtering is something I
> believe fair to expect from PMD owner instead of rte_flow author.

Yes, agree for these 2 examples.