Re: [PATCHv6 00/33] NXP DPAA2 PMD
From: Hemant Agrawal <hidden>
Date: 2017-01-26 12:19:00
On 1/26/2017 5:25 PM, Ferruh Yigit wrote:
On 1/23/2017 5:56 PM, Ferruh Yigit wrote:quoted
On 1/23/2017 11:59 AM, Hemant Agrawal wrote: <...>quoted
Hemant Agrawal (33): mk/dpaa2: add the crc support to the machine type drivers/common/dpaa2: adding qbman driver bus/fslmc: introducing fsl-mc bus driver bus/fslmc: introduce mc object functions bus/fslmc: add mc dpni object support bus/fslmc: add mc dpio object support bus/fslmc: add mc dpbp object support bus/fslmc: add mc dpseci object support eal/vfio: adding vfio utility functions in map file bus/fslmc: add vfio support bus/fslmc: scan for net and sec devices net/dpaa2: introducing NXP dpaa2 pmd driver doc: add dpaa2 nic details bus/fslmc: add debug log message support drivers/common/dpaa2: dpio portal driver drivers/pool/dpaa2: adding hw offloaded mempool drivers/common/dpaa2: dpio routine to affine to crypto threads net/dpaa2: adding eth ops to dpaa2 net/dpaa2: add rss flow distribution net/dpaa2: configure mac address at init net/dpaa2: attach the buffer pool to dpni net/dpaa2: add support for l3 and l4 checksum offload net/dpaa2: add support for promiscuous mode net/dpaa2: add mtu config support net/dpaa2: add packet rx and tx support net/dpaa2: rx packet parsing and packet type support net/dpaa2: link status update net/dpaa2: basic stats support net/dpaa2: enable stashing for LS2088A devices net/dpaa2: add support for non hw buffer pool packet transmit net/dpaa2: enabling the use of physical addresses bus/fslmc: add support for dmamap to ARM SMMU drivers/common/dpaa2: frame queue based dq storage alloc<...>quoted
66 files changed, 15984 insertions(+), 5 deletions(-)I have some concerns about this PMD, - This is a big one, as seen above, and it is hard to review it all, I don't feel confident about the amount of review done, more reviewers are welcome. And we are already post RC1. - Although this driver introduces a new bus type, in some parts, driver still has virtual devices like usage, perhaps this is not because of this PMD but mostly because of overall dpdk bus structure. Still I have concerns about getting driver like this, and would like to hear more comments.As a result of above concerns, I propose postponing this PMD to 17.05 release. The dependent rte_bus just get into main repo less than two weeks ago, also this driver comes with a few new things first of its kind, and it matters to make first samples correct. I believe it is good to let the PMD be around a little more to give chance to both PMD and rte_bus to become more mature.
I agree that this driver is coming with few new thing and it is taking time to come up with agreeable and good solution for some of this new stuff. Finalizing the right framework for adding SoC based drivers took a little longer than expected. But thanks to Thomas help in the last that we got the basic bus framework integrated. Thomos- is it possible to integrate it early in 17.05 cycle, rather than waiting till end?
Thanks, ferruh