2017-03-16 17:40, Dumitrescu, Cristian:

From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]

quoted

2017-03-16 16:23, Dumitrescu, Cristian:

quoted

... <snip>

quoted

quoted

Thomas, given Tim's confirmation of Intel's plans to implement this API

for

quoted

quoted

the ixgbe and i40e drivers in DPDK release 17.8, are you in favour of

including

quoted

quoted

this API in 17.5 with experimental tag (subject to full API agreement being
reached)?

I think starting a branch in a dedicated "next" repo is a better approach.
rte_flow and eventdev were (and will be) integrated only when at least

one

quoted

quoted

hardware device is supported.
I suggest to follow the same workflow.

Thomas, if this is the only path forward you are willing to support, then let's

go this way, but let's make sure we are all on the same page with the terms
and conditions that apply.

quoted

Do you agree now to merge this next-tree to DPDK once this API is

implemented for at least one PMD? We would like to avoid getting any last
minute objections from you or anybody else on the fundamentals; if you
have any, please let's discuss them now.

At least one "hardware" PMD, yes. It would prove the API can work for real.
About accepting it definitely in a given release, it will be checked
with the technical board on Monday.

OK, great, thank you. Is the agenda of the technical board meetings published in advance somewhere?

For the previous meeting, it was published:
	https://bimestriel.framapad.org/p/r.a5199d22813a5ac79d1d365b9cecb905
For the next one, please Konstantin, could you publish the agenda on a pad?

quoted

quoted

How do we manage the API freeze on the next-tree? Once the API is

agreed, we would like to freeze it so the driver development can proceed;
we can then do some reasonably small changes to the API based on the
learnings we get during driver development. We would like to welcome any
parties interested in contributing to join Cavium, Intel and NXP in this effort,
but we would like to avoid any last minute major API change requests.

You are taking it the wrong way. Your main concern is to not be disturbed
with change requests. It should be the contrary: you have a chance to
work with other vendors to test and improve the API.
You should embrace this chance and delay the API freeze as much as
possible.

Not really. We definitely welcome change requests done in a timely manner. My concern is about last minute change requests, such as major API change requests just a few days before the release when driver development is complete. Is there a policy in place to prevent against such events for next-tree type of development?

No there is no such policy on a next- tree.
It is free to the maintainer of the tree I guess.