On 27/01/2021 18:57, Jason Gunthorpe wrote: > On Thu, Jan 21, 2021 at 09:40:49PM +0200, Gal Pressman wrote: >> On 21/01/2021 20:35, Jason Gunthorpe wrote: >>> On Tue, Jan 19, 2021 at 09:17:14AM +0200, Gal Pressman wrote: >>>> On 05/01/2021 12:43, Gal Pressman wrote: >>>>> The following two patches add the userspace version to the host >>>>> information struct reported to the device, used for debugging and >>>>> troubleshooting purposes. >>>>> >>>>> PR was sent: >>>>> https://github.com/linux-rdma/rdma-core/pull/918 >>>>> >>>>> Thanks, >>>>> Gal >>>> >>>> Anything stopping this series from being merged? >>> >>> Honestly, I'm not very keen on this >>> >>> Why does this have to go through a kernel driver, can't you collect >>> OS telemetry some other way? >> >> Hmm, it has to go through rdma-core somehow, what sort of component can >> rdma-core interact with to pass such data? The only one I could think of is the >> RDMA driver :). >> >> As I said, I get your concern, I was going on and off about this as well, but >> the userspace version is a very useful piece of information in the context of a >> kernel bypass device. It's just as important as the kernel version. >> I agree that this is not the place to pass things like gcc version, but I don't >> think that's the case here :). > > Well, if we were to do this for mlx5 we'd want to pass UCX and maybe > other stuff, it seems like it gets quickly out of hand. Agree, that's why I think this should be limited to things in rdma-core's reach, sounds like a reasonable limit to me. > I think telemetry is better done as some telemetry subsystem, not > integrated all over the place Interesting, but that would still be all over the place as each package would have to report its version to that telemetry driver. And since this currently doesn't exist, should we stay without a solution? Specifically talking about rdma-core version, do you think it could be merged?
