On Sun, Feb 28, 2021 at 11:56:01AM +0200, Gal Pressman wrote: > 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? I'm not keen on it, it doesn't work well for other use-cases, it seems too hacky. Jason
