On 27/01/2021 19:53, Gal Pressman wrote: > 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? > Jason?
