[ovs-dev] [PATCHv3] DPDK: add support for v2.0.0

Kavanagh, Mark B mark.b.kavanagh at intel.com
Mon Apr 27 08:27:52 UTC 2015


>On Fri, 24 Apr 2015 14:04:05 +0000
>"Kavanagh, Mark B" <mark.b.kavanagh at intel.com> wrote:
>
>> >
>> >>On Fri, 24 Apr 2015 10:32:32 +0000
>> >>"Kavanagh, Mark B" <mark.b.kavanagh at intel.com> wrote:
>> >>
>> >>>
>> >>> >
>> >>> >On 04/23/2015 11:58 PM, Kavanagh, Mark B wrote:
>> >>> >> Hi all,
>> >>> >>
>> >>> >> Just a quick poll: are the resolutions to review comments in
>> >>> >> this patch acceptable to
>> >>> >everyone?
>> >>> >>
>> >>> >> If I've missed anything, or are there any additional opens that
>> >>> >> need to be addressed
>> >>> >before it can be merged, just let me know.
>> >>> >>
>> >>> >> Thanks in advance,
>> >>> >> Mark
>> >>> >>
>> >>> >>>
>> >>> >>> Update relevant artifacts to add support for DPDK v2.0.0
>> >>> >>> - INSTALL.DPDK.md
>> >>> >>> - travis build script
>> >>> >>> - acinclude.m4: add 'mssse3' flag to OVS_CFLAGS
>> >>> >>> - netdev-dpdk: fix build with unified offload types in DPDK
>> >>> >>> v2.0.0
>> >>> >>>
>> >>> >>> Note that this breaks compatibility with DPDK v1.8.0
>> >>> >>>
>> >>> >>> v1: - update DPDK version & build instructions in
>> >>> >>> INSTALL.DPDK.md
>> >>> >>>     - update DPDK version and remove compile flags in
>> >>> >>> travis/build.sh
>> >>> >>>     - fix build with unified offload types in DPDK v2.0.0
>> >>> >>>
>> >>> >>> v2: - add mssse3 flag to OVS_CFLAGS in acinclude.m4
>> >>> >>>     - reinstate '-Wno-cast-align' compile flag for clang
>> >>> >>>     - add details of vhost user support limitations to
>> >>> >>> INSTALL.DPDK.md
>> >>> >>>     - refactor travis/build.sh to reflect these changes
>> >>> >>>
>> >>> >>> v3: -correct minor typos in commit message
>> >>> >>>
>> >>> >>> Signed-off-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
>> >>> >>> Signed-off-by: Panu Matilainen <pmatilai at redhat.com>
>> >>> >
>> >>> >It feels a bit strange to have signed off something I hadn't seen
>> >>> >before this (unless it refers to the actual code change) but
>> >>> >maybe I'm just unfamiliar with the signed-off protocol.
>> >>> >
>> >>>
>> >>> Hey Panu,
>> >>>
>> >>> I included you in the 'signed-off-by' field, due to your earlier
>> >>> contribution re fixing the build with DPDK 2.0 unified rss hash
>> >>> types
>> >>> (http://openvswitch.org/pipermail/dev/2015-March/052022.html).
>> >>>
>> >>> Contributing.md states 'If the patch has more than one author, all
>> >>> must sign off'; however, maybe in this case it would have been
>> >>> best to allow you to review the patch first, and then you could
>> >>> have signed off when satisfied with the patch in its entirety.
>> >>> Given that you had previously contributed a subset of the content
>> >>> (which, incidentally I had -1'd at the time), I felt it prudent
>> >>> to include you in the tag, rather than leave it open to
>> >>> misinterpretation regarding the origin of the code.
>> >>>
>> >>> Any clarification the maintainers could provide on this matter
>> >>> would be greatly appreciated for future reference.
>> >>
>> >>I am not the maintainer but I can tell that you can carry on
>> >>signatures of all the authors of the original work with their
>> >>consent, of course.
>> >>
>> >
>> >Hi Fabio,
>>
>> Apologies for the typo here Flavio.
>>
>> >
>> >Thanks for your feedback. The point you've made here really is the
>> >crux of the issue in question: whether to include another's name in
>> >a signoff tag, without their consent, or not. Using this patch as an
>> >example: Panu previously proposed changes which were rejected at the
>> >time, but were later integrated into a patch that I submitted. In
>> >order for him to receive credit for his contributions, I added him
>> >to the patch's signoff. However, this could potentially carry the
>> >connotation that he had approved/signed off on the entire patch;
>> >conversely, if I had omitted his name, it could potentially be
>> >perceived that I had attempted to pass his code as my own. So, what
>> >to do?
>> >
>> >The Linux kernel submission guidelines
>> >(https://www.kernel.org/doc/Documentation/SubmittingPatches) specify
>> >the following procedure, which, while slightly different from this
>> >scenario, are IMO equally applicable:
>> >
>> >	If you are a subsystem or branch maintainer, sometimes you
>> >	need to slightly modify patches you receive in order to
>> >	merge them, because the code is not exactly the same in your
>> >	tree and the submitters'. If you stick strictly to rule (c),
>> >	you should ask the submitter to rediff, but this is a
>> >	totally counter-productive waste of time and energy. Rule
>> >	(b) allows you to adjust
>> >=>	the code, but then it is very impolite to change one
>> >submitter's code and =>	make him endorse your bugs. To solve
>> >this problem, it is recommended that =>	you add a line
>> >between the last Signed-off-by header and yours, indicating
>> >	the nature of your changes. While there is nothing mandatory
>> >	about this, it seems like prepending the description with
>> >	your mail and/or name, all enclosed in square brackets, is
>> >	noticeable enough to make it obvious that you are
>> >	responsible for last-minute changes. Example :
>> >
>> >	Signed-off-by: Random J Developer
>> >	<random at developer.example.org>
>> >	[lucky at maintainer.example.org: struct foo moved from foo.c
>> >	to foo.h] Signed-off-by: Lucky K Maintainer
>> >	<lucky at maintainer.example.org>
>> >
>> >Is this approach amenable? If so, I can upload a patch for
>> >CONTRIBUTING.md
>
>In this case you're not the maintainer.  The above is valid when the
>one merging the patch finds something that needs to be changed because
>the current tree has changed since posting and merging.  So, the
>maintainer does the small changes needed and adds that small text part
>to indicate his actions.
>

Sure, I understand - I was merely proposing that a similar process could be used in a situation where one author's patch uses another's previously-submitted code.

>In our case, there are two contributors exchanging ideas about the
>patch, so just post the patch with CC to Panu and to be polite tell
>that he is free to signed off due to his contributions after the '--'.
>The maintainers should give enough time for the CC'ed folks to review
>and reply with their signed off or any other tag or no tag as they
>feel appropriated.
>
>When in doubt, ask the person.

Yes, this sounds like the way to go - thanks for your feedback Flavio.

>
>fbl
>
>_______________________________________________
>dev mailing list
>dev at openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev


More information about the dev mailing list