Message ID | 20230811200340.577359-1-vadim.fedorenko@linux.dev (mailing list archive) |
---|---|
Headers | show |
Series | Create common DPLL configuration API | expand |
Fri, Aug 11, 2023 at 10:03:31PM CEST, vadim.fedorenko@linux.dev wrote: >Implement common API for DPLL configuration and status reporting. >The API utilises netlink interface as transport for commands and event >notifications. This API aims to extend current pin configuration >provided by PTP subsystem and make it flexible and easy to cover >complex configurations. > >Netlink interface is based on ynl spec, it allows use of in-kernel >tools/net/ynl/cli.py application to control the interface with properly >formated command and json attribute strings. Here are few command >examples of how it works with `ice` driver on supported NIC: > >- dump dpll devices >$ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >--dump device-get >[{'clock-id': 282574471561216, > 'id': 0, > 'lock-status': 'unlocked', > 'mode': 'automatic', > 'module-name': 'ice', > 'type': 'eec'}, > {'clock-id': 282574471561216, > 'id': 1, > 'lock-status': 'unlocked', > 'mode': 'automatic', > 'module-name': 'ice', > 'type': 'pps'}] > >- get single pin info: >$ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >--do pin-get --json '{"pin-id":2}' >{'clock-id': 282574471561216, > 'module-name': 'ice', > 'pin-board-label': 'C827_0-RCLKA', > 'pin-dpll-caps': 6, > 'pin-frequency': 1953125, > 'pin-id': 2, > 'pin-parent-device': [{'id': 0, > 'pin-direction': 'input', > 'pin-prio': 11, > 'pin-state': 'selectable'}, > {'id': 1, > 'pin-direction': 'input', > 'pin-prio': 9, > 'pin-state': 'selectable'}], > 'pin-type': 'mux'} > >- set pin's state on dpll: >$ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >--do pin-set --json '{"pin-id":2, "pin-parent-device":{"id":1, "pin-state":2}}' > >- set pin's prio on dpll: >$ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >--do pin-set --json '{"pin-id":2, "pin-parent-device":{"id":1, "pin-prio":4}}' > >- set pin's state on parent pin: >$ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >--do pin-set --json '{"pin-id":13, \ > "pin-parent-pin":{"pin-id":2, "pin-state":1}}' > For the record, I'm fine with this patchset version now. Please merge and make this jurney to be over. Thanks!
On 12.08.2023 07:22, Jiri Pirko wrote: > Fri, Aug 11, 2023 at 10:03:31PM CEST, vadim.fedorenko@linux.dev wrote: >> Implement common API for DPLL configuration and status reporting. >> The API utilises netlink interface as transport for commands and event >> notifications. This API aims to extend current pin configuration >> provided by PTP subsystem and make it flexible and easy to cover >> complex configurations. >> >> Netlink interface is based on ynl spec, it allows use of in-kernel >> tools/net/ynl/cli.py application to control the interface with properly >> formated command and json attribute strings. Here are few command >> examples of how it works with `ice` driver on supported NIC: >> >> - dump dpll devices >> $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >> --dump device-get >> [{'clock-id': 282574471561216, >> 'id': 0, >> 'lock-status': 'unlocked', >> 'mode': 'automatic', >> 'module-name': 'ice', >> 'type': 'eec'}, >> {'clock-id': 282574471561216, >> 'id': 1, >> 'lock-status': 'unlocked', >> 'mode': 'automatic', >> 'module-name': 'ice', >> 'type': 'pps'}] >> >> - get single pin info: >> $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >> --do pin-get --json '{"pin-id":2}' >> {'clock-id': 282574471561216, >> 'module-name': 'ice', >> 'pin-board-label': 'C827_0-RCLKA', >> 'pin-dpll-caps': 6, >> 'pin-frequency': 1953125, >> 'pin-id': 2, >> 'pin-parent-device': [{'id': 0, >> 'pin-direction': 'input', >> 'pin-prio': 11, >> 'pin-state': 'selectable'}, >> {'id': 1, >> 'pin-direction': 'input', >> 'pin-prio': 9, >> 'pin-state': 'selectable'}], >> 'pin-type': 'mux'} >> >> - set pin's state on dpll: >> $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >> --do pin-set --json '{"pin-id":2, "pin-parent-device":{"id":1, "pin-state":2}}' >> >> - set pin's prio on dpll: >> $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >> --do pin-set --json '{"pin-id":2, "pin-parent-device":{"id":1, "pin-prio":4}}' >> >> - set pin's state on parent pin: >> $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ >> --do pin-set --json '{"pin-id":13, \ >> "pin-parent-pin":{"pin-id":2, "pin-state":1}}' >> > > For the record, I'm fine with this patchset version now. > Please merge and make this jurney to be over. Thanks! > Thanks Jiri! We are waiting for Jakub to review the code again and hopefully merge the code1
On Fri, 11 Aug 2023 21:03:31 +0100 Vadim Fedorenko wrote: > create mode 100644 Documentation/driver-api/dpll.rst > create mode 100644 Documentation/netlink/specs/dpll.yaml > create mode 100644 drivers/dpll/Kconfig > create mode 100644 drivers/dpll/Makefile > create mode 100644 drivers/dpll/dpll_core.c > create mode 100644 drivers/dpll/dpll_core.h > create mode 100644 drivers/dpll/dpll_netlink.c > create mode 100644 drivers/dpll/dpll_netlink.h > create mode 100644 drivers/dpll/dpll_nl.c > create mode 100644 drivers/dpll/dpll_nl.h > create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.c > create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.h > create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/dpll.c > create mode 100644 include/linux/dpll.h > create mode 100644 include/uapi/linux/dpll.h Feels like we're lacking tests here. Is there a common subset of stuff we can expect reasonable devices to support? Anything you used in development that can be turned into tests?
On 15/08/2023 03:45, Jakub Kicinski wrote: > On Fri, 11 Aug 2023 21:03:31 +0100 Vadim Fedorenko wrote: >> create mode 100644 Documentation/driver-api/dpll.rst >> create mode 100644 Documentation/netlink/specs/dpll.yaml >> create mode 100644 drivers/dpll/Kconfig >> create mode 100644 drivers/dpll/Makefile >> create mode 100644 drivers/dpll/dpll_core.c >> create mode 100644 drivers/dpll/dpll_core.h >> create mode 100644 drivers/dpll/dpll_netlink.c >> create mode 100644 drivers/dpll/dpll_netlink.h >> create mode 100644 drivers/dpll/dpll_nl.c >> create mode 100644 drivers/dpll/dpll_nl.h >> create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.c >> create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.h >> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/dpll.c >> create mode 100644 include/linux/dpll.h >> create mode 100644 include/uapi/linux/dpll.h > > Feels like we're lacking tests here. Is there a common subset of > stuff we can expect reasonable devices to support? > Anything you used in development that can be turned into tests? Well, we were playing with the tool ynl/cli.py and it's stated in the cover letter. But needs proper hardware to run. I'm not sure we can easily create emulation device to run tests.
Tue, Aug 15, 2023 at 01:36:11PM CEST, vadim.fedorenko@linux.dev wrote: >On 15/08/2023 03:45, Jakub Kicinski wrote: >> On Fri, 11 Aug 2023 21:03:31 +0100 Vadim Fedorenko wrote: >> > create mode 100644 Documentation/driver-api/dpll.rst >> > create mode 100644 Documentation/netlink/specs/dpll.yaml >> > create mode 100644 drivers/dpll/Kconfig >> > create mode 100644 drivers/dpll/Makefile >> > create mode 100644 drivers/dpll/dpll_core.c >> > create mode 100644 drivers/dpll/dpll_core.h >> > create mode 100644 drivers/dpll/dpll_netlink.c >> > create mode 100644 drivers/dpll/dpll_netlink.h >> > create mode 100644 drivers/dpll/dpll_nl.c >> > create mode 100644 drivers/dpll/dpll_nl.h >> > create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.c >> > create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.h >> > create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/dpll.c >> > create mode 100644 include/linux/dpll.h >> > create mode 100644 include/uapi/linux/dpll.h >> >> Feels like we're lacking tests here. Is there a common subset of >> stuff we can expect reasonable devices to support? >> Anything you used in development that can be turned into tests? > >Well, we were playing with the tool ynl/cli.py and it's stated in >the cover letter. But needs proper hardware to run. I'm not sure >we can easily create emulation device to run tests. Well, something like "dpllsim", similar to netdevsim would be certainly possible, then you can use it to write selftests for the uapi testing. But why don't we do that as a follow-up patchset?
On 15/08/2023 12:52, Jiri Pirko wrote: > Tue, Aug 15, 2023 at 01:36:11PM CEST, vadim.fedorenko@linux.dev wrote: >> On 15/08/2023 03:45, Jakub Kicinski wrote: >>> On Fri, 11 Aug 2023 21:03:31 +0100 Vadim Fedorenko wrote: >>>> create mode 100644 Documentation/driver-api/dpll.rst >>>> create mode 100644 Documentation/netlink/specs/dpll.yaml >>>> create mode 100644 drivers/dpll/Kconfig >>>> create mode 100644 drivers/dpll/Makefile >>>> create mode 100644 drivers/dpll/dpll_core.c >>>> create mode 100644 drivers/dpll/dpll_core.h >>>> create mode 100644 drivers/dpll/dpll_netlink.c >>>> create mode 100644 drivers/dpll/dpll_netlink.h >>>> create mode 100644 drivers/dpll/dpll_nl.c >>>> create mode 100644 drivers/dpll/dpll_nl.h >>>> create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.c >>>> create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.h >>>> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/dpll.c >>>> create mode 100644 include/linux/dpll.h >>>> create mode 100644 include/uapi/linux/dpll.h >>> >>> Feels like we're lacking tests here. Is there a common subset of >>> stuff we can expect reasonable devices to support? >>> Anything you used in development that can be turned into tests? >> >> Well, we were playing with the tool ynl/cli.py and it's stated in >> the cover letter. But needs proper hardware to run. I'm not sure >> we can easily create emulation device to run tests. > > Well, something like "dpllsim", similar to netdevsim would be certainly > possible, then you can use it to write selftests for the uapi testing. > But why don't we do that as a follow-up patchset? Yeah, I agree, we can implement simulator, but as a follow-up work. Otherwise it might take a year to merge this set :)
On Tue, 15 Aug 2023 13:52:10 +0200 Jiri Pirko wrote: > >> Feels like we're lacking tests here. Is there a common subset of > >> stuff we can expect reasonable devices to support? > >> Anything you used in development that can be turned into tests? > > > >Well, we were playing with the tool ynl/cli.py and it's stated in > >the cover letter. But needs proper hardware to run. I'm not sure > >we can easily create emulation device to run tests. > > Well, something like "dpllsim", similar to netdevsim would be certainly > possible, then you can use it to write selftests for the uapi testing. > But why don't we do that as a follow-up patchset? I was thinking about a test that can be run against real HW. Something that a new vendor implementing DPLL can run and validate that their implementation behaves as expected. And something that distributors and stable kernels could potentially use to validate the code still works. We don't have any well established user space to make use of this new functionality, there's high risk that drivers will invent their own ways of interpreting the API. Perhaps something that Red Hat could help with? I'm guessing you'd be writing test to validate this for RHEL, anyway?
>From: Jakub Kicinski <kuba@kernel.org> >Sent: Tuesday, August 15, 2023 7:02 PM > >On Tue, 15 Aug 2023 13:52:10 +0200 Jiri Pirko wrote: >> >> Feels like we're lacking tests here. Is there a common subset of >> >> stuff we can expect reasonable devices to support? >> >> Anything you used in development that can be turned into tests? >> > >> >Well, we were playing with the tool ynl/cli.py and it's stated in >> >the cover letter. But needs proper hardware to run. I'm not sure >> >we can easily create emulation device to run tests. >> >> Well, something like "dpllsim", similar to netdevsim would be certainly >> possible, then you can use it to write selftests for the uapi testing. >> But why don't we do that as a follow-up patchset? > >I was thinking about a test that can be run against real HW. >Something that a new vendor implementing DPLL can run and >validate that their implementation behaves as expected. >And something that distributors and stable kernels could >potentially use to validate the code still works. > >We don't have any well established user space to make use of this >new functionality, there's high risk that drivers will invent their >own ways of interpreting the API. > >Perhaps something that Red Hat could help with? I'm guessing you'd >be writing test to validate this for RHEL, anyway? RH is doing some manual tests on their own, but also works with Intel's Validation. Usually our Validation team works with end-user point of view, but here we had to engage them to work with cli.py and confirm that control over dpll works as expected. HW agnostic tests were submitted by Michal as RFC for test framework with fake modules implemented here: https://lore.kernel.org/netdev/20230817152209.23868-1-michal.michalik@intel.com/#t We had an agreement on latest dpll-meeting that we will follow up with patches that would test dpll over fake modules, and we have started it. As there was no requests to add HW-aware tests yet, we are not ready for such submission yet. We could probably extended Michal's framework to make it possible test real HW, but Michal's patches were just submitted, we do expect some review/changes there, thus we could think of adding something simpler for now.. Is simple bash script wrapping around cli.py and talking to ice dpll while verifying the outputs, an acceptable solution? Thank you! Arkadiusz
On Fri, 18 Aug 2023 10:15:34 +0000 Kubalewski, Arkadiusz wrote: > HW agnostic tests were submitted by Michal as RFC for test framework > with fake modules implemented here: > https://lore.kernel.org/netdev/20230817152209.23868-1-michal.michalik@intel.com/#t > We had an agreement on latest dpll-meeting that we will follow up with > patches that would test dpll over fake modules, and we have started it. > As there was no requests to add HW-aware tests yet, we are not ready for > such submission yet. We could probably extended Michal's framework to > make it possible test real HW, but Michal's patches were just submitted, > we do expect some review/changes there, thus we could think of adding > something simpler for now.. > > Is simple bash script wrapping around cli.py and talking to ice dpll > while verifying the outputs, an acceptable solution? Okay, it is what it is, let's leave tests as follow up. I'll reply to Michal on the RFC thread/