Message ID | 20221201102626.56390-1-michal.wilczynski@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Implement new netlink attributes for devlink-rate in iproute2 | expand |
On Thu, 1 Dec 2022 11:26:22 +0100 Michal Wilczynski wrote: > Patch implementing new netlink attributes for devlink-rate got merged to > net-next. > https://lore.kernel.org/netdev/20221115104825.172668-1-michal.wilczynski@intel.com/ > > Now there is a need to support these new attributes in the userspace > tool. Implement tx_priority and tx_weight in devlink userspace tool. Update > documentation. I forgot to ask you - is there anything worth adding to the netdevsim rate selftests to make sure devlink refactoring doesn't break your use case? Probably the ability for the driver to create and destroy the hierarchy?
Hello: This series was applied to iproute2/iproute2-next.git (main) by David Ahern <dsahern@kernel.org>: On Thu, 1 Dec 2022 11:26:22 +0100 you wrote: > Patch implementing new netlink attributes for devlink-rate got merged to > net-next. > https://lore.kernel.org/netdev/20221115104825.172668-1-michal.wilczynski@intel.com/ > > Now there is a need to support these new attributes in the userspace > tool. Implement tx_priority and tx_weight in devlink userspace tool. Update > documentation. > > [...] Here is the summary with links: - [iproute2-next,v2,1/4] devlink: Add uapi changes for tx_priority and tx_weight (no matching commit) - [iproute2-next,v2,2/4] devlink: Introduce new attribute 'tx_priority' to devlink-rate https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=a6b9cd50e69a - [iproute2-next,v2,3/4] devlink: Introduce new attribute 'tx_weight' to devlink-rate https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=0f71480932f1 - [iproute2-next,v2,4/4] devlink: Add documentation for tx_prority and tx_weight https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=2e2b53467172 You are awesome, thank you!
On 12/1/2022 5:53 PM, Jakub Kicinski wrote: > On Thu, 1 Dec 2022 11:26:22 +0100 Michal Wilczynski wrote: >> Patch implementing new netlink attributes for devlink-rate got merged to >> net-next. >> https://lore.kernel.org/netdev/20221115104825.172668-1-michal.wilczynski@intel.com/ >> >> Now there is a need to support these new attributes in the userspace >> tool. Implement tx_priority and tx_weight in devlink userspace tool. Update >> documentation. > I forgot to ask you - is there anything worth adding to the netdevsim > rate selftests to make sure devlink refactoring doesn't break your use > case? Probably the ability for the driver to create and destroy the > hierarchy? Hi, I think it's a great idea, possibility to export the hierarchy from the driver is key for our use case. Would you like me to add this to netdevism ? Thanks, MichaĆ
On Mon, 5 Dec 2022 09:41:26 +0100 Wilczynski, Michal wrote: > On 12/1/2022 5:53 PM, Jakub Kicinski wrote: > > On Thu, 1 Dec 2022 11:26:22 +0100 Michal Wilczynski wrote: > >> Patch implementing new netlink attributes for devlink-rate got merged to > >> net-next. > >> https://lore.kernel.org/netdev/20221115104825.172668-1-michal.wilczynski@intel.com/ > >> > >> Now there is a need to support these new attributes in the userspace > >> tool. Implement tx_priority and tx_weight in devlink userspace tool. Update > >> documentation. > > I forgot to ask you - is there anything worth adding to the netdevsim > > rate selftests to make sure devlink refactoring doesn't break your use > > case? Probably the ability for the driver to create and destroy the > > hierarchy? > > I think it's a great idea, possibility to export the hierarchy from the driver > is key for our use case. Would you like me to add this to netdevism ? Great! Yes, netdevsim and a script that exercises it. There are some rate tests already in tools/testing/selftests/drivers/net/netdevsim/devlink.sh Either just extend that or factor it out to its own script, if the rate testing gets big. You don't have to be too "unit-testy" it's mostly about exercising the functionality so that we can catch refactoring errors.