[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210607121411.GC1002214@nvidia.com>
Date: Mon, 7 Jun 2021 09:14:11 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Leon Romanovsky <leon@...nel.org>,
Doug Ledford <dledford@...hat.com>,
Kees Cook <keescook@...omium.org>,
Nathan Chancellor <nathan@...nel.org>,
Adit Ranadive <aditr@...are.com>,
Ariel Elior <aelior@...vell.com>,
Christian Benvenuti <benve@...co.com>,
clang-built-linux@...glegroups.com,
Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
Devesh Sharma <devesh.sharma@...adcom.com>,
Gal Pressman <galpress@...zon.com>,
linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
Michal Kalderon <mkalderon@...vell.com>,
Mike Marciniszyn <mike.marciniszyn@...nelisnetworks.com>,
Mustafa Ismail <mustafa.ismail@...el.com>,
Naresh Kumar PBS <nareshkumar.pbs@...adcom.com>,
Nelson Escobar <neescoba@...co.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Potnuri Bharat Teja <bharat@...lsio.com>,
Selvin Xavier <selvin.xavier@...adcom.com>,
Shiraz Saleem <shiraz.saleem@...el.com>,
VMware PV-Drivers <pv-drivers@...are.com>,
Yishai Hadas <yishaih@...dia.com>,
Zhu Yanjun <zyjzyj2000@...il.com>
Subject: Re: [PATCH rdma-next v1 10/15] RDMA/cm: Use an attribute_group on
the ib_port_attribute intead of kobj's
On Mon, Jun 07, 2021 at 12:25:03PM +0200, Greg KH wrote:
> On Mon, Jun 07, 2021 at 11:17:35AM +0300, Leon Romanovsky wrote:
> > From: Jason Gunthorpe <jgg@...dia.com>
> >
> > This code is trying to attach a list of counters grouped into 4 groups to
> > the ib_port sysfs. Instead of creating a bunch of kobjects simply express
> > everything naturally as an ib_port_attribute and add a single
> > attribute_groups list.
> >
> > Remove all the naked kobject manipulations.
>
> Much nicer.
>
> But why do you need your counters to be atomic in the first place? What
> are they counting that requires this?
The write side of the counter is being updated from concurrent kernel
threads without locking, so this is an atomic because the write side
needs atomic_add().
Making them a naked u64 will cause significant corruption on the write
side, and packet counters that are not accurate after quiescence are
not very useful things.
Jason
Powered by blists - more mailing lists