Meeting notes for the DPDK technical board meeting held on 2020-05-06
Attendees:
- Bruce Richardson
- Ferruh Yigit
- Hemant Agrawal
- Jerin Jacob (Chair)
- Kevin Traynor
- Konstantin Ananyev
- Olivier Matz
- Stephen Hemminger
"No telemetry legacy support " prints pops up on all the default dpdk
applications now.
Is it worth to print? Since it using direct 'printf', we cannot even disable
through dynamic logging.
Is possible to remove that print at least, if non legacy telemetry init is
successful.
Thoughts?
I think, original discussion[1] on this topic got lost in GitHub vs current
workflow.
I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow.
Current scheme:
- When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually
delegate the patch to Tree maintain
Based on the discussion happed on http://patches.dpdk.org/patch/69681/,
I would like simply the rte_log to use constructor scheme and submit patch to
update existing consumer of rte_log to use new scheme for v20.08.
RTE_LOG_REGISTER will an optional symbol to use the rte_log registration
mechanism
General:
1) hash: unify crc32 API header for x86 and ARM
http://patches.dpdk.org/patch/70132/
2) rte_log registration simplification using constructor scheme
http://mails.dpdk.org/archives/dev/2020-May/168874.html
3) PCI probe optimization by removing RTE_KDRV_NONE based probe
http://
5 matches
Mail list logo