2017-03-10 18:37, Dumitrescu, Cristian: > From: O'Driscoll, Tim > > > > OK I better understand now. > > > > You should add this level of explanation in your patch. > > > > > > > > However I am reluctant to add an API if there is no user. > > > > I think we should wait to have at least one existing driver > > > implementing > > > > this API before integrating it. > > > > It was the approach of eventdev which has a dedicated next- tree. > > > > > > The next-tree solution could work, but IMO is not the best for this > > > case, as this is purely driver development. This is just a TX offload > > > feature that is well understood, as opposed to a new library with a huge > > > design effort required like eventdev. > > > > > > I think we are reasonably close to get agreement on the API from Cavium, > > > Intel and NXP. When this is done, how about including it in DPDK with > > > the experimental tag attached to it until several drivers implement it? > > > > > > From Intel side, there are solid plans to implement it for ixgbe and > > > i40e drivers in next DPDK releases, I am CC-ing Tim to confirm this. > > > > That's correct. We plan to add support for this in the ixgbe and i40e > > drivers in > > 17.08. > > Thomas, given Tim's confirmation of Intel's plans to implement this API for > the ixgbe and i40e drivers in DPDK release 17.8, are you in favour of > including 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 hardware device is supported. I suggest to follow the same workflow. > IMO this approach has the advantage of showing that API agreement has been > reached and driver development is in progress. Having it in DPDK is also a > better way to advertise this API to the developers that would otherwise be > unaware about this effort. IMO we can advertise a work in progress in a side branch.
