[ovs-dev] OVS DPDK Latest & HWOL Branches

Aaron Conole aconole at redhat.com
Wed Aug 15 15:52:16 UTC 2018


Ian Stokes <ian.stokes at intel.com> writes:

> On 8/15/2018 10:51 AM, Ophir Munk wrote:
>> Hi,
>> Please find comments inline.
>>
>>> -----Original Message-----
>>> From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
>>> bounces at openvswitch.org] On Behalf Of Stokes, Ian
>>> Sent: Tuesday, August 14, 2018 7:42 PM
>>> To: Ben Pfaff (blp at ovn.org) <blp at ovn.org>
>>> Cc: dev at openvswitch.org
>>> Subject: [ovs-dev] OVS DPDK Latest & HWOL Branches
>>>
>>> Hi Ben,
>>>
>>> Recently at the OVS DPDK community meeting the case for 2 new branches
>>> was raised.
>>>
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
>>> l.openvswitch.org%2Fpipermail%2Fovs-dev%2F2018-
>>> August%2F350898.html&amp;data=02%7C01%7Cophirmu%40mellanox.com
>>> %7C61e0d527081c4e1fbfbf08d60204e62b%7Ca652971c7d2e4d9ba6a4d149
>>> 256f461b%7C0%7C1%7C636698617407744747&amp;sdata=0tKB9%2BdVH%
>>> 2BIfWaCHzaD6oy1mldVs9FUeZVbR2T7Ym1E%3D&amp;reserved=0
>>>
>>> These branches would be:
>>>
>>> (i) OVS DPDK Latest: This branch would essentially be OVS master using the
>>> latest DPDK release (Including non LTS releases).
>>>
>>> The purpose of this branch would be to allow OVS DPDK developers to assess
>>> the latest DPDK releases with OVS and provide feedback to the DPDK
>>> community if changes are required. Currently OVS transitions between
>>> supported DPDK releases using DPDK LTS releases only. DPDK LTS releases
>>> happen annually. The next DPDK LTS release would be 18.11. However the
>>> other non-lts DPDK releases (x.02, x.05, x.08) can introduce/change APIs that
>>> impact OVS DPDK (Such as the HWOL). This feedback would be in place for
>>> the next LTS release before OVS transitions to the next x.11 LTS.
>>>
>>> (ii) OVS DPDK HWOL: This branch would be forked from OVS DPDK Latest but
>>> would encompass the HWOL development work that is ongoing.
>>>
>>> The feeling as regards the need for a OVS DPDK HWOL branch is that it
>>> requires new features only available in the latest DPDK releases and that
>>> there will be a lot of code rework required as its validated with various HW
>>> devices over time before an acceptable solution will be in place.
>>>
>>> There was a question as regards the logistics of where the branches should
>>> reside. It was suggested that they could be part of the OVS Repo to
>>> centralize the development work but that is obviously something that would
>>> have to be raised with yourself and the other project maintainers.
>>>
>>
>> If using OVS Repo for the 2 branches will also enable having
>> frequent builds and
>> running automated CI tests - that would greatly help to make sure the branches
>> are backward compatible with master OVS.
>
> I think this should be simple enough to enable.
>
>>
>>> An alternative would be that it would be hosted on a developers GitHub repo
>>> similar to how the dpdk_merge branches currently work.
>>>
>>
>> Where ever the branches are - I suggest using the patchwork mailing list
>> for sending patches to these branches.
>> We will need to decide on a header prefix to designate a specific patch to
>> its relevant branch (e.g. "HWOL PATCH v1" or "DPDKLATEST PATCH v1").
>
> Sure, I'm not familiar with the inner workings of patchwork but I
> believe it should work once a patch is sent to dev at openvswitch.org.
>
> As you said we just need a to agree the header prefix to distinguish
> that it's not intended for the main OVS repo. (I was thinking
> "OVS_DPDK_LATEST" and "OVS_DPDK_HWOL"), using just DPDK could confuse
> people into think it's a patch for DPDK itself rather than ovs.

Probably best to follow the existing branch convention:

  "branch-XXX"

So, "branch-dpdk-next" and "branch-dpdk-hwol"

Then patches get posted as:
[PATCH branch-dpdk-next]
[PATCH branch-hwol]

I don't think it should be confusing to omit the ovs - after all they're
OVS branches / trees / whatever you want to consider them.  I don't
think anyone would mistake them that way (but maybe they would if there
was an xpost?  the file layout is radically different so the patch won't
even apply accidentally.. I dunno).

> Ian
>>
>>> Neither of the branches would be subject to releases as the end goal of the
>>> development work carried out on them would make its way into OVS Master
>>> eventually.
>>>
>>> Curious as to what your thoughts on this would be?

I think it makes sense - it can help give early feedback.  We can
probably be a bit more 'lax' in that tree as well, since some of the
dpdk compatibility work might need to be thrown away (ie: change in
XX.05, then XX.08, then XX.11-LTS which would merge mainline might have
3 different sets of changes, but hopefully not).

I also like the idea that we could do a nightly integration with dpdk
mainline without needing to affect the ovs master branch.  That means we
could detect breakages in the ovs<->dpdk interface much earlier.

All that said - I really hope that people don't start thinking of
whatever you want to call those branches as anything other than
experimentation / early feedback.  DPDK's LTS branches get continual
backports, and have a much stronger maintenance policy than non-LTS.

>>> Thanks
>>> Ian
>>>


More information about the dev mailing list